Monitoring en alerting¶
Niemand wil de hele dag dashboards bekijken en wachten tot er iets kapotgaat. Het platform deployt daarom zijn alerting als code en dwingt die af met Azure Policy, zodat de alerts die moeten bestaan ook bestaan, en een melding de mensen bereikt die kunnen handelen.
Deze sectie legt uit hoe alerting werkt, welke alerts er zijn en hoe je de routering van alerts instelt (of overneemt).
Wie alerts ontvangt en afhandelt, hangt af van je beheermodel. In het managed model is de ontvanger de on-call-route van XMMS. In het zelfbeheermodel is het je eigen platformteam.
Pagina's in deze sectie¶
| Pagina | Gebruik hem om |
|---|---|
| Hoe alerting werkt | De alert-initiatives, severities, action groups, processing rules en de optionele 24/7-route te begrijpen |
| Alertcatalogus | Te zien wat er wordt gemonitord, per severity en per resourcegebied |
| Monitoring uitrollen | Het platform aan je on-call-tool te koppelen en de alerting aan te zetten |
| Monitoringregels (toewijzen of verwijderen voor een spoke) | De standaard alertregels van één spoke te wijzigen |
| Maandelijkse healthcheck | Te controleren of de alerts en hun policies aanwezig zijn en niet te veel ruis geven |
Monitoring en observability¶
| Term | Betekenis | In het platform |
|---|---|---|
| Monitoring | Bekende indicatoren verzamelen (beschikbaarheid, CPU, doorvoer) en handelen op drempelwaarden | Metric- en activity log-alerts van de alerting-initiatives |
| Observability | Nieuwe vragen aan het systeem kunnen stellen, ook vragen waar je niet op had gerekend | Logs en metrics in Log Analytics, doorzoekbaar en te correleren. Een dashboardtool erbovenop (bijvoorbeeld Grafana) geeft één plek om te beginnen en door te klikken naar de portal |
Alerts vertellen je dat iets wat je verwachtte is gebeurd. Met logs kom je erachter wat je niet verwachtte. Gebruik beide. Voor een eerste diagnose, zie Waar je als eerste kijkt.
Wie waarvoor verantwoordelijk is¶
| Gebied | Verantwoordelijk | Opmerkingen |
|---|---|---|
| Hub-alerts, action groups van het platform, routering | Platformteam | De layers foundation, connectivity en postdeployment (Deployment layers) |
| Standaard alertregels in de spoke-subscriptions | Platformteam deployt ze via policy | Het workload team kan vragen ze te verwijderen (Monitoringregels) |
| Alerts voor de applicatie zelf | Workload team | Alertregels, action groups en dashboards op de eigen workspace van de workload (Je workload beheren) |
| De mensen en de tool die alerts ontvangen | Wie de service draait (Beheermodellen) | Contactlijsten en escalatie zijn placeholders in je contract of je eigen beleid |
Het principe erachter: het team dat een workload bouwt, is verantwoordelijk voor de hele levenscyclus, inclusief de alerting. Het platform levert een baseline, zodat teams niet bij nul beginnen.
De service meten: voorbeelddoelen¶
Om te beoordelen of het platform gezond is, definieer je een paar doelen die meetbaar zijn en tot actie leiden. Meet ze elke maand op dezelfde manier en rapporteer ze (Service level management).
| Doel | Beschrijving | Voorbeeldstreefwaarde | Gemeten met |
|---|---|---|---|
| Hersteltijd | Gemiddelde hersteltijd van incidenten met severity 1 | 1 uur, binnen kantooruren | Tijd van detectie tot oplossing in het ticketsysteem |
| Beschikbaarheid | Percentage van de tijd dat het platform beschikbaar is | De Microsoft SLA van de componenten | Service Health |
| Succespercentage van deployments | Aandeel succesvolle productiedeployments | 99% | Succespercentage van pipelines |
Dit zijn voorbeelden van een managed platform, geen standaardwaarden. Kies je eigen streefwaarden en zeg waar de cijfers vandaan komen. Een dashboard dat ze rapporteert (bijvoorbeeld in Grafana) bespaart tijd bij de maandelijkse review.