Utform alarmer med funn og en planlagt respons

En nyttig alarm viser hva som er galt i en applikasjon, og hvilken første respons som er planlagt. Mottakeren skal kunne forstå den uten å gjette tjenesten ut fra et ukjent servernavn.

Fra brukeroppgave til signal

Begynn med en viktig oppgave, som å laste prosjektlisten i en kundeportal. For interaktive tjenester anbefaler Prometheus blant annet brukersynlige feil og egnede oversikter for å undersøke årsaker. Et mål på ressursutnyttelse kan gi sammenheng; det forklarer ikke automatisk om prosjektlisten virker.

Fastsett hvilke forespørsler og svar som inngår i målingen. Gjentatte kall er flere forespørsler, ikke automatisk flere berørte personer. En feilandel trenger derfor en tydelig nevner.

Et gjennomarbeidet alarmeksempel

Det følgende programvareteamet, måleverdiene og reglene er oppdiktet. Eksemplet beskriver verken en ASES-hendelse, generelle grenseverdier eller et supportløfte. Alle registrerte forespørsler for den angitte operasjonen utgjør nevneren her. Regelen vurderer et vindu på 5 minutter uten ytterligere krav til varighet.

Her er både minsteantallet forespørsler og feilgrensen overskredet. De 20 % beskriver forespørsler i dette vinduet. De beviser verken en tilsvarende andel berørte brukere eller en bestemt årsak.

Forbered den første responsen

Runbooken er en kort veiledning for den planlagte diagnosen. Først bekrefter den ansvarlige overtakelsen og undersøker om problemet vedvarer. Bekreftelsen betyr ikke at feilen er rettet. Forhåndsvalgte filtre må bruke samme tjeneste, operasjon og tidsperiode.

Deretter avgrenses berørte instanser, versjoner og avhengigheter. En release klokken 09:08 ville her vært en hendelse å undersøke, ikke et bevis på årsaken. Tilbakerulling krever en egnet og forhåndskontrollert fremgangsmåte; alarmen gir ikke tillatelse til vilkårlige omstarter eller endringer.

Kontroller også meldingsveien

Alertmanager kan gruppere lignende alarmer og sende dem til konfigurerte mottakere. Berørte instanser må fortsatt være synlige. Uavhengige problemer skal ikke slås sammen bare fordi navnene ligner.

Kontroller også mottak, overtakelse og planlagt reservevei med en tydelig merket testmelding. Prometheus nevner eksplisitt overvåking av selve overvåkingen. Senere normale målinger kan avslutte alarmtilstanden; de erstatter verken kontroll av brukeroppgaven eller videre årsaksanalyse. Funksjonelt feilaktige svar med vellykket status eller langsomme svar dekkes ikke av denne enkle serverfeilregelen alene.

Kilder

• Google SRE — Monitoring Distributed Systems

• Prometheus — Alerting best practices

• Prometheus — Alertmanager

• GitLab — Incident Diagnosis in a Symptom-based World