Alarmmeldingen opstellen met bevinding en reactiepad
Een uitgewerkt portaalvoorbeeld verbindt foutpercentage, eigenaar en eerste controle. Een alarm alleen bewijst de oorzaak of het herstel niet.
Een bruikbare alarmmelding toont wat er misgaat in een applicatie en welk eerste reactiepad is voorzien. De ontvanger moet de melding begrijpen zonder de dienst uit een onbekende servernaam te hoeven raden.
Van gebruikerstaak naar signaal
Begin met een belangrijke taak, zoals het laden van een projectlijst in een klantportaal. Voor interactieve diensten beveelt Prometheus onder meer gebruikerszichtbare fouten en geschikte overzichten voor oorzaakanalyse aan. Een benuttingswaarde kan context geven; ze verklaart niet automatisch of de projectlijst werkt.
Leg vast welke verzoeken en antwoorden in de meting vallen. Herhaalde aanroepen zijn extra verzoeken, niet automatisch extra getroffen personen. Een foutpercentage vraagt daarom een duidelijke noemer.
Een uitgewerkte alarmmelding
Het volgende softwareteam, de meetwaarden en regels zijn verzonnen. Dit is geen ASES-incident, algemene drempel of supportbelofte. Alle vastgelegde verzoeken voor de genoemde operatie vormen hier de noemer. De gekozen regel beoordeelt een venster van 5 minuten, zonder extra aanhoudtijd.
Veld | Voorbeeldwaarde |
|---|---|
Melding | De projectlijst van het klantportaal geeft serverfouten terug. |
Bereik |
|
Tijdvenster | 09:10–09:15, Europe/Berlin |
Bevinding | 100 verzoeken, waarvan 20 serverfoutantwoorden |
Voorbeeldregel | Meer dan 10 % serverfouten in het venster van 5 minuten bij minstens 50 verzoeken. |
Eigenaar | Bereikbaarheidsdienst van |
Startpunt | Overzicht voor precies deze dienst, operatie en periode; runbook “Projectlijst”. |
Hier zijn zowel het minimumaantal verzoeken als de foutdrempel overschreden. De 20 % beschrijft verzoeken in dit venster. Dit percentage bewijst geen overeenkomstig aandeel getroffen gebruikers of een bepaalde oorzaak.
De eerste reactie voorbereiden
Het runbook is een korte handleiding voor het voorziene diagnosepad. Eerst bevestigt de verantwoordelijke de overname en controleert of het probleem voortduurt. Die bevestiging betekent niet dat de fout is opgelost. De vooraf gekozen filters moeten dezelfde dienst-, operatie- en tijdgegevens overnemen.
Daarna worden betrokken instanties, versies en afhankelijkheden afgebakend. Een release om 09:08 zou hier een te onderzoeken gebeurtenis zijn, geen bewijs van de oorzaak. Terugdraaien vereist een passend, vooraf gecontroleerd pad; de melding geeft geen toestemming voor willekeurige herstarts of wijzigingen.
Ook het meldingspad controleren
Alertmanager kan vergelijkbare meldingen groeperen en naar ingestelde ontvangers sturen. Betrokken instanties moeten zichtbaar blijven. Onafhankelijke problemen mogen niet samenvallen alleen omdat hun namen op elkaar lijken.
Controleer met een duidelijk gemarkeerde testmelding ook ontvangst, overname en het voorziene reservepad. Prometheus noemt het bewaken van de bewaking uitdrukkelijk. Later normale meetwaarden kunnen de alarmtoestand beëindigen; ze vervangen niet de controle van de gebruikerstaak of verdere oorzaakanalyse. Functioneel onjuiste succesantwoorden of trage antwoorden worden niet door deze eenvoudige serverfoutregel alleen gedekt.
Bronnen
Verder lezen
Alle artikelen
Cloud & beheer met ASES
Hosting, deployment, onderhoud en support