Formulera larm med observation och planerad åtgärd
Ett portalexempel kopplar felandel, ansvarig och första kontroll. Ett larm ensamt bevisar varken orsaken eller att felet är åtgärdat.
Ett användbart larm visar vad som är fel i en applikation och vilken första respons som är planerad. Mottagaren ska kunna förstå det utan att gissa tjänsten utifrån ett okänt servernamn.
Från användaruppgift till signal
Börja med en viktig uppgift, till exempel att ladda projektlistan i en kundportal. För interaktiva tjänster rekommenderar Prometheus bland annat användarsynliga fel och lämpliga vyer för orsaksanalys. Ett mått på resursutnyttjande kan ge sammanhang; det förklarar inte automatiskt om projektlistan fungerar.
Bestäm vilka förfrågningar och svar som ingår i mätningen. Upprepade anrop är fler förfrågningar, inte automatiskt fler berörda personer. En felandel behöver därför en tydlig nämnare.
Ett genomarbetat larmexempel
Följande mjukvaruteam, mätvärden och regler är påhittade. Det är varken en ASES-incident, allmänna gränsvärden eller ett supportlöfte. Alla registrerade förfrågningar för den angivna operationen utgör nämnaren här. Regeln bedömer ett fönster på 5 minuter utan ytterligare krav på varaktighet.
Fält | Exempel |
|---|---|
Meddelande | Kundportalens projektlista returnerar serverfel. |
Omfattning |
|
Tidsfönster | 09:10–09:15, Europe/Berlin |
Observation | 100 förfrågningar, varav 20 serverfelsvar |
Exempelregel | Mer än 10 % serverfel i fönstret på 5 minuter vid minst 50 förfrågningar. |
Ansvarig | Beredskapen i |
Startpunkt | Vy för exakt denna tjänst, operation och period; runbook “Projektlista”. |
Här överskrids både minsta antalet förfrågningar och felgränsen. De 20 % beskriver förfrågningar i detta fönster. De bevisar varken motsvarande andel berörda användare eller en viss orsak.
Förbered den första responsen
Runbooken är en kort anvisning för den planerade diagnosen. Först bekräftar den ansvariga personen övertagandet och undersöker om problemet kvarstår. Bekräftelsen innebär inte att felet är löst. Förvalda filter måste använda samma tjänst, operation och tidsperiod.
Därefter avgränsas berörda instanser, versioner och beroenden. En release klockan 09:08 skulle här vara en händelse att undersöka, inget bevis på orsaken. Återställning till tidigare version kräver ett lämpligt, förkontrollerat förfarande; larmet tillåter inte godtyckliga omstarter eller ändringar.
Kontrollera även meddelandets väg
Alertmanager kan gruppera liknande larm och skicka dem till konfigurerade mottagare. Berörda instanser måste förbli synliga. Oberoende problem får inte slås ihop bara för att namnen liknar varandra.
Kontrollera med ett tydligt märkt testmeddelande även mottagning, övertagande och planerad reservväg. Prometheus nämner uttryckligen övervakning av själva övervakningen. Senare normala mätvärden kan avsluta larmtillståndet; de ersätter varken kontroll av användaruppgiften eller fortsatt orsaksanalys. Funktionellt felaktiga svar med lyckad status eller långsamma svar täcks inte av denna enkla serverfelsregel ensam.
Källor
Läs vidare
Alla artiklar
Cloud & drift med ASES
Hosting, driftsättning, underhåll och support