Ga naar inhoud

Monitoring uitrollen

Gebruik dit runbook als je voor het eerst alertrouting voor een platform instelt, als je overstapt naar een andere on-call- tool, of als je een platform overneemt (Checklist voor dag één). Aan het eind bereiken alerts met severity 0 tot 2 de mensen die incidenten afhandelen, en zijn de alert policies toegewezen.

De achtergrond staat in Hoe alerting werkt. De voorbeelden gebruiken een on-call-tool die een incident opent vanuit een webhook en dat in een chatkanaal plaatst. Elke tool met een webhook-ontvanger werkt.

Voordat je begint

Beslissing Opties
Wie ontvangt alerts Het platformteam (XMMS of je eigen team)
Wanneer Alleen kantooruren, of ook buiten kantoortijden (24/7). 24/7 is in het managed model een contractkwestie
Welke tool Je incident- of on-call-tool. Die moet een webhook accepteren en bij kritieke alerts iemand kunnen bellen of sms'en
Welk chatkanaal Eén kanaal per platform of klant voor de incidentfeed
Ontvangers per omgeving Canary kan naar een testkanaal sturen. Prod stuurt naar de echte route

Voer de wijziging door via de normale wijzigingsworkflow: branch, pull request, canary, prod.

1. Maak de service aan in de on-call-tool

  1. Als je organisatie services groepeert per klant of platform, maak die groepering dan eerst aan.
  2. Maak een service voor het platform aan. Kies een escalation policy die past bij de afgesproken uren (bijvoorbeeld een policy voor kantooruren, of een 24/7-policy).
  3. Voeg op het tabblad Integrations een integratie voor Microsoft Azure toe (of een generieke webhook, als de tool geen Azure- integratie heeft).
  4. Kopieer de integratie-URL. Behandel die als een secret: iedereen die hem heeft kan incidenten aanmaken.

2. Koppel het chatkanaal (optioneel)

  1. Maak een kanaal aan voor de platformalerts, intern voor het platformteam.
  2. Open in de on-call-tool de service en voeg een extensie of koppeling voor je chattool toe.
  3. Koppel de service aan het kanaal. Controleer dat er een testevent aankomt.

3. Zet de ontvanger in de configuratie

Stel de ontvangers van de action groups van het platform in in <primary region>/foundation.auto.tfvars van elke map van een platform- omgeving. De algemene action group haalt zijn webhook uit monitor_action_group_general_webhook_receiver. De action group die de landing zone-alerts ontvangt heeft eigen variabelen (monitor_action_group_xpirit_*). Stel beide in, anders route je maar een deel van de alerts (Hub-config).

monitor_action_group_general_webhook_receiver = {
  "Webhook Receiver - <platform name> Hub (Production)" = {
    name                    = "Webhook Receiver - <platform name> Hub (Production)"
    service_uri             = "https://<on-call tool>/integration/<integration-key>/enqueue"
    use_common_alert_schema = true
    aad_auth                = null
  }
}
Veld Waarde
Map key en name Een leesbare naam. Gebruik er één per omgeving en geef aan welke canary en welke prod is
service_uri De integratie-URL uit stap 1
use_common_alert_schema true. De on-call-tool ontvangt het common alert schema
aad_auth null, tenzij je ontvanger een Entra ID-token valideert

Commit geen geheime URL naar een repository die veel mensen kunnen lezen als je beleid dat verbiedt. Controleer waar je configuratierepository zulke waarden opslaat en wie ze kan lezen.

E-mailontvangers stel je op dezelfde manier in (monitor_action_group_general_email_receiver en de bijbehorende variabele van de tweede groep). Gebruik een groepsmailbox, geen persoon.

4. Apply

  1. Open een pull request en review het plan. De layer foundation hoort alleen wijzigingen aan de action groups te tonen.
  2. Pas toe op canary, controleer de action groups in de portal (Monitor > Alerts > Action groups) en pas daarna toe op prod.

5. Wijs de alert initiatives toe

Controleer alerting_management_groups in <primary region>/postdeployment.auto.tfvars: de keys cloudplatform en landingzones zijn verplicht, en elke vlag deploy_alerting_* zet één initiative aan. Zie Monitoringregels.

Draai hub. Start voor bestaande subscriptions remediation tasks, zodat de regels voor bestaande resources worden aangemaakt (wijs de standaardregels toe).

6. Optioneel: de hub 24/7-route

Als alerts buiten kantoortijd voor de hub in je service zitten, schakel dan hub_247_support in met een eigen webhook (en een andere integratie in de on-call-tool, met een eigen escalation policy). Instellingen en standaardwaarden: Monitoringregels.

Verifiëren

  1. Regels bestaan. Ga in de portal naar Monitor > Alerts > Alert rules, gefilterd op een platformsubscription.
  2. Policy is compliant. Policy > Compliance voor de alert initiatives. Herstel wat niet compliant is.
  3. Er komt een bericht aan. Trigger een testevent in de on-call-tool, of wacht op de volgende Service Health- of Resource Health- alert, en controleer dat het incident verschijnt, dat het in het chatkanaal wordt geplaatst, en dat een kritiek incident de on-callpersoon bereikt via de afgesproken middelen (bellen en sms).
  4. Escalatie werkt. Controleer dat een niet-bevestigd kritiek incident escaleert zoals afgesproken.
  5. Leg het vast. Schrijf de ontvangers, de uren en de eigenaar van de integratie op, op de plek waar je team zijn platformdocumentatie bewaart.

Beheren

  • Review alerts wekelijks, stem drempels af die te veel ruis geven en controleer ontvangers als mensen erbij komen of vertrekken (Houd de alerting gezond).
  • Roteer de integratie-URL als die lekt, en werk de configuratie op dezelfde manier bij als hierboven.
  • Houd een runbook bij voor elke alert met severity 0 (Alertcatalogus).

Terugdraaien

Verwijder of wijzig de ontvanger in het tfvars-bestand en draai hub opnieuw. De alertregels blijven bestaan, maar meldingen stoppen, dus vertel dat eerst aan de mensen die erop vertrouwen.