nais / alerterator Goto Github PK

Når man lager flere alerts for en app, oppgir man app i expr for å filterere på riktig app.
Dette blir veldig gjentakende. Hadde vært deilig å kunne Definere en miljøvariabel som "injectes" i yaml-filen. Dermed så blir det lettere å endre navn på app om man trenger det.

Noe liknende denne querien:
expr: up{app="{{ app_name }}", job="kubernetes-pods"} == 0
Slik at {{ app_name }} kan erstattes av en miljøvariabel.

Burde vi ha en liste med "hemmelige" alerts som sier i fra til teams om at de ikke har metrikker på appen sin? Slik at vi er proaktive på at man bør ha alerts og metrikker (så klart må man kunne opte ut).

En utfordring er at vi ikke vet hvilken slack-kanal team bruker, men heldigvis har vi navn på teamet, og da vet vi også hva e-posten deres er!

Team PUS bruker følgende for å overvåke deres apper for manglende metrikker:

- alert: mangler up-metrikk
      expr: absent(up{app="<appname>",kubernetes_namespace="<namespace>"})
      for: 3m
      action: sjekk hvorfor spørringen 'absent(up{app="<appname>",kubernetes_namespace="<namespace>"})' ikke gir resultater
    - alert: mangler logd_messages_total-metrikk
      expr: absent(logd_messages_total{log_app="<appname>",log_level="Info"})
      for: 3m
      action: sjekk hvorfor spørringen 'absent(logd_messages_total{log_app="<appname>",log_level="Info"})' ikke gir resultater
    - alert: mangler logd_messages_total-metrikk
      expr: absent(logd_messages_total{log_app="<appname>"})
      for: 3m
      action: sjekk hvorfor spørringen 'absent(logd_messages_total{log_app="<appname>"})' ikke gir resultater
    - alert: mangler selftests_aggregate_result_status-metrikk
      expr: absent(selftests_aggregate_result_status{app="<appname>",kubernetes_namespace="<namespace>"})
      for: 3m
      action: sjekk hvorfor spørringen 'absent(selftests_aggregate_result_status{app="<appname>",kubernetes_namespace="<namespace>"})' ikke gir resultater
    - alert: mangler jetty_responses_total-metrikk
      expr: absent(jetty_responses_total{app="<appname>",kubernetes_namespace="<namespace>",code=~"1xx|2xx|3xx"})
      for: 3m
      action: sjekk hvorfor spørringen 'absent(jetty_responses_total{app="<appname>",kubernetes_namespace="<namespace>",code=~"1xx|2xx|3xx"})' ikke gir resultater
    - alert: mangler jetty_requests_total-metrikk
      expr: absent(jetty_requests_total{app="<appname>",kubernetes_namespace="<namespace>"})
      for: 3m
      action: sjekk hvorfor spørringen 'absent(jetty_requests_total{app="<appname>",kubernetes_namespace="<namespace>"})' ikke gir resultater

Vi støtter ikke variabler uten anførselstegn. Ha en liten regex sjekk som påser at description har " rundt seg.

description: {{ $labels }} er ikke gyldig
description: "{{ $labels }}" er gyldig

Kunne kanskje vært kjekt med støtte for record.
Her er et eksempel hvor det brukes for å lage en macro for å håndtere sommertid/vintertid problematikk (hentet fra https://medium.com/@tom.fawcett/time-of-day-based-notifications-with-prometheus-and-alertmanager-1bf7a23b7695):

  expr: |
      (vector(1) and (month() > 3 and month() < 10))
      or
      (vector(1) and (month() == 3 and (day_of_month() - day_of_week()) >= 25) and absent((day_of_month() >= 25) and (day_of_week() == 0)))
      or
      (vector(1) and (month() == 10 and (day_of_month() - day_of_week()) < 25) and absent((day_of_month() >= 25) and (day_of_week() == 0)))
      or
      (vector(1) and ((month() == 10 and hour() < 1) or (month() == 3 and hour() > 0)) and ((day_of_month() >= 25) and (day_of_week() == 0)))
      or
      vector(0)```

Ønsker meg konfig for å kunne slå av "resolved" meldingene i slack, de er ofte bare spam for vår del

Vi i NAIS-teamet ser behov for å ha mulighet til å få alerts via SMS. Alertmanger støtter ikke dette, men vi kan bruke NAV sin interne tjeneste for å sende SMS.

Vi burde sikre at configmap-ene til Alertmanager kun inneholder data som kommer fra Alerterator. Dette gjøres enklest ved at Alerterator lager et helt nytt configmap basert på alert-ressursene den har.

Utfordringen da er hvordan vi skal håndtere add, update, delete, og synchronize. For synchronize blir kjørt for hver alert-ressurs i clusteret, som betyr at vi lager helt ny configmap for hver synchronize, så blir det gjort veldig mange ganger.

Koden er skrevet slik at den kun legger til nye routes, så hvis du endrer en route (label eller continue), så blir ikke de tatt høyde for.

When one fired alert is reported simultaneously as one resolved alert both messages looks like a fired alert in slack. This makes it hard to see that one alert is actually resolved.

Unsure if this is something that is fixable in alertarator or if is an issue with https://github.com/prometheus/alertmanager

Følgende expr ble sendt inn:

expr: 'sum(max_over_time(logd_messages_total{log_app=“su-se-bakover”,log_level=“Error”}[15m])
              or vector(0)) -
             sum(max_over_time(logd_messages_total{log_app=“su-se-bakover”,log_level=“Error”}[15m]
             offset 15m) or vector(0)) > 0'

Den inneholder feil type anførselstegn ( “ vs "). Vi må finne en måte å vaske eller validere dette.

• Change how the resource works
• Find easiest migration path for users (new resource version? pull requests to repos?)
• Make sure resources are migrated

• Hvis noen klarer å spytte inn en alert som ikke validerer, så knekker hele Alerterator. Dette må fikses.
• Vi må også definere specen til å ikke tillate array hvor det egentlig skal være objekter.

Følgende yaml er ikke gyldig. Fjern - fra .receivers.slack og .receivers.email.

 receivers:
  - email:
      send_resolved: false
      to: ""
  - slack:
      channel: '#sp-sak'
      prependText: ""

Selve feilmeldingen som tipset oss om feilen:

E0827 10:12:22.749350 1 reflector.go:134] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:95: Failed to list *v1alpha1.Alert: v1alpha1.AlertList.Items: []v1alpha1.Alert: v1alpha1.Alert.Spec: v1alpha1.AlertSpec.Receivers: readObjectStart: expect { or n, but found [, error found in #10 byte of ...|ceivers":[{"slack":{|..., bigger context ...|nd within 1h, during office hours"}],"receivers":[{"slack":{"channel":"#sp-sak"}}]}},{"apiVersion":"|...

description: '{{ $labels.app }} har betydningsfull lag mot {{labels.topic}}'

Skulle vært

description: '{{ $labels.app }} har betydningsfull lag mot {{ $labels.topic }}'

spec.alerts.severity skal egentlig bli satt til danger hvis brukeren selv ikke har satt den.

{"level":"error","msg":"syfoalerts: error while storing alert sync metadata: Alert.nais.io \"syfoalerts\" is invalid: spec.alerts.severity: Invalid value: \"\": spec.alerts.severity in body should match 'good|warning|danger|#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})'","time":"2020-02-20T07:19:44.893989315Z"}
{"level":"error","msg":"while storing alert sync metadata: Alert.nais.io \"syfoalerts\" is invalid: spec.alerts.severity: Invalid value: \"\": spec.alerts.severity in body should match 'good|warning|danger|#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})'","time":"2020-02-20T07:19:44.894021041Z"}

{"level":"error","msg":"vault-alerts: error while storing alert sync metadata: Alert.nais.io \"vault-alerts\" is invalid: spec.alerts.severity: Invalid value: \"\": spec.alerts.severity in body should match 'good|warning|danger|#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})'","time":"2020-02-20T07:20:25.21557808Z"}
{"level":"error","msg":"while storing alert sync metadata: Alert.nais.io \"vault-alerts\" is invalid: spec.alerts.severity: Invalid value: \"\": spec.alerts.severity in body should match 'good|warning|danger|#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})'","time":"2020-02-20T07:20:25.215602184Z"}

• Migrate AURA/Platform alerts to Alerterator format
• Move route configuration from nais-yaml to Alert resources
• Delete default AlertManager config from nais-yaml

Jeg ønsker meg en annen modell på alertene enn å filtrere etter teamnavn.

For større team som jobber på vidt forskjellige applikasjoner hadde det vært fint å kunne ha forskjellige alerts på forskjellige kanaler. I vårt eksempel er vi tre subteam til et stort team, som per nå må dele på èn alert channel. Mange har gjerne ikke noe stort forhold til de andres subteamenes apper, og kanalen vil i større grad oppleves som støy.

Et annet poeng er at jeg ikke skjønte hva som skjedde da jeg fikk masse ekstravarsler med på kjøpet i den nyopprettede varselkanalen vår etter å ha deployet en alertressurs med et par varsler for èn app. Det opplevdes ikke som forventet oppførsel at jeg da skulle få med alle varslene til hele teamet.

doc til slack-api?
Så det er icon_url og/ellericon_emojijeg ønsker meg muligheten til å sette

Jeg er litt redd for at jeg er veldig radikal nå, men jeg ønsker egentlig å kunne sette tittelen også.
Den ser i dag ca slik ut [FIRING:1]
Ser ut til å komme herfra i dag

If an alert is specified without duration:

for: ""

Prometheus will fail on loading the alert configmap:

{"caller":"manager.go:761","component":"rule manager","err":"not a valid duration string: \"\"","level":"error","msg":"loading groups failed","ts":"2019-10-16T22:52:32.152Z"}

So when such alert exists, no alert updates will read by Prometheus and Prometheus will fail starting.

Foreløpig så gjør ikke severity noe, men har diskutert dette med @dagframstad i navikt/nais-yaml#31. Flytter saken over til dette repoet.

Slik det er i dag blir alle alerter markert med color: 'danger' (rød) (eller color: 'good' (grønn) ved alert resolution).
Ønsker at det skal tas hensyn til severity ved alerts, slik at severity warning blir gul/oransje (color: 'warning'),
severity info blir f.eks. blå eller grå, og critical kanskje en annen farge enn 'danger' for å skille den fra error (lilla?).
Kanskje også noen bilder i dok som viser hvordan alerts blir seende ut i slack, og hvilke severities som kan settes (er casing av betydning?)

Oppgaven blir da å kunne skille på farger, og ha bilder i dokumentasjonen. Det jeg også lurer på er om vi burde fjerne prependText på alerts som ikke er critical eller error?

The operator must:

• Subscribe to AlertConfig updates
• Join all AlertConfig specs and convert them to Prometheus configuration
• Insert Prometheus configuration as ConfigMaps in Kubernetes

Logg fra prometheus:

{
  "caller": "manager.go:910",
  "component": "rule manager",
  "err": "/etc/alerterator-rules/**************: 57:11: group \"**************\", rule 2, \"høy feilrate i logger\": could not parse expression: 1:73: parse error: unexpected character inside braces: ~",
  "level": "error",
  "msg": "loading groups failed",
  "ts": "2020-11-16T11:16:09.906Z"
}

Alert:

(100 * sum by (log_app, log_namespace) (rate(logd_messages_total{log_app~"appnavn|appnavn2",log_level=~"Warning|Error"}[3m])) / sum by (log_app, log_namespace) (rate(logd_messages_total{log_app~"appnavn|appnavn2"}[3m]))) > 10

Feilen her er: log_app~ skulle vært log_app=~

Det har blitt etterlyst muligheten for inhibition rule, som lar oss skru av andre alerts basert på en alert.

Inhibition is a concept of suppressing notifications for certain alerts if certain other alerts are already firing.

Med dette kunne man enkelt lagt til regel som skrudde av alerts utenfor arbeidstid, eller skru av alerts som man vet er følge-alerts pga. en annen feil.

inhibit_rules:
- source_match:
    alertname: QuietHours
  target_match:
    component: 'data_source'

Dette er noe som skal inn i alertmanager-configen.

https://prometheus.io/docs/alerting/alertmanager/#inhibition
https://prometheus.io/docs/alerting/configuration/#inhibit_rule

prependText https://doc.nais.io/observability/alerts/reference/#receiversslackprependtext blir bare lagt på meldinger i Slack for alerts med severity danger. Jeg ønsker meg at prependText blir lagt til alle meldinger uavhengig av severity. Jeg ønsker å bruke prepepndText til å inneholde navnet på appen, slik at jeg kan lese i Slack-meldingen hvilken app som var opphavet til alerten (jeg har én alerts.yml fil per applikasjon).

Jeg har faktisk trodd lenge at det var slik prependText fungerte, men da jeg fikk noen alerts med severity warning her om dagen oppdaget jeg at det ikke sto noe sted i Slack-meldingen hvilken app det gjaldt.

Se også nais/doc#223

To make use of inhibition rules in alertmanager, label names should be consistent across metrics.
Config
For example, the application name is now called "app", "log_app", "container" depending on the metrics you use.
While there is some logic behind this (eg. "app" being the app producing the logging metrics), we should in theory be able to leverage smarter alerting rules by being able to inhib restart alerts if an app is down.

See this issues