Hoe alerting werkt

Het platform maakt zijn alerts aan met Azure Policy en Terraform, niet met de hand. Deze pagina legt de onderdelen uit en hoe een alert van een resource bij een persoon komt. Voor de lijst met alerts, zie de Alertcatalogus. Voor de stappen om je eigen on-calltool te koppelen, zie Monitoring uitrollen.

De onderdelen

Onderdeel	Wat het is	Aangemaakt door
Alert initiatives	Azure Policy initiatives met de alertdefinities. Ze volgen de best practice van Azure Monitor Baseline Alerts (AMBA), die Microsoft uit praktijkervaring heeft verzameld. Er zijn er vijf: Alerting-ServiceHealth, Alerting-Management, Alerting-Connectivity, Alerting-Identity en Alerting-LandingZone	Definities in de foundation layer
Assignments	Eén assignment per management group, ingeschakeld met alerting_management_groups	De postdeployment layer
Activity log alerts	Alerts op subscription-gebeurtenissen van de platform-subscriptions, ingeschakeld met enable_activity_log_alerts (standaard aan)	De foundation layer
Action groups	De ontvangers: e-mailadressen en webhooks. Twee per regio: een algemene (ag-<company>-mgmtgeneral-<env>-<region>-001) en een voor de alerts van de landing zone assignments (ag-<company>-mgmtxpirit-<env>-<region>-001)	De foundation layer
Alert processing rules	Regels die op basis van severity bepalen welke alerts naar welke action group gaan	De layers connectivity, identity, management, en de landing zone initiative in elke landing zone-subscription
Hub 24/7-route (optioneel)	Een eigen action group en processing rule voor alerts buiten kantooruren op geselecteerde hubcomponenten	De connectivity layer, ingeschakeld met hub_247_support

Hoe de assignments worden ingeschakeld, waar de spoke zijn regels vandaan haalt en hoe je ze weer verwijdert, staat in Monitoringregels. De namen van de action groups staan in de naamgevingsreferentie.

Waarom policy

Alerts die met policy worden gedeployd, volgen de resources:

• Wordt een resource aangemaakt of gewijzigd, dan maakt de deployIfNotExists policy de alertregel aan. Niemand hoeft eraan te denken.
• Een regel kan niet ongemerkt ontbreken: de compliance van de alertpolicies is zichtbaar in Azure Policy en maakt deel uit van de maandelijkse healthcheck.
• Voor resources die al bestaan wanneer een assignment wordt ingeschakeld, verschijnen de regels pas na een remediation task (Monitoringregels, stap 4).

Severity

Azure Monitor kent vijf severities. Onderscheid tussen die niveaus voorkomt alertmoeheid: wordt het team gepaged voor dingen die geen probleem zijn, dan gaan mensen de berichten negeren, en op een dag negeren ze het bericht dat wel telt. Een kritieke alert vraagt om een snelle reactie. Een informatieve alert kan in de backlog wachten.

Severity	Naam	Betekenis	Wat er gebeurt
0	Kritiek	De dienst faalt of de beveiliging loopt gevaar. Handel nu.	Verwerkt en naar de action group gestuurd. Bel de on-callpersoon als je service level dat zegt
1	Fout	Aanzienlijke degradatie	Verwerkt en verstuurd
2	Waarschuwing	Een drempel voor prestaties of capaciteit is overschreden	Verwerkt en verstuurd
3	Informatief	Operationeel bewustzijn	Gelogd in Azure Monitor. Geen notificatie
4	Verbose	Audit trail: administratieve en beveiligingsgebeurtenissen	Gelogd in Azure Monitor. Geen notificatie

Severities 0 tot en met 2 worden gerouteerd door de alert processing rules. Severities 3 en 4 blijven in Azure Monitor voor geschiedenis en compliancerapportage. Alle alerts worden in Azure Monitor gelogd, ongeacht hun routering.

Hoe je elk niveau afhandelt, bepaal je zelf

De tabel toont de standaardroutering. Reactietijden voor severity 0 tot en met 2, en of ze ook buiten kantooruren gelden, horen in je service levels (Service level management). In het managed model komen ze uit het contract.

Hoe een alert reist

flowchart LR
    r["Resource or activity log"] --> a["Alert rule<br/>(created by policy)"]
    a --> p["Alert processing rule<br/>(severity 0 to 2)"]
    p --> g["Action group<br/>(e-mail, webhook)"]
    g --> t["On-call / incident tool"]
    t --> c["Chat channel"]
    t --> o["On-call engineer<br/>(call, SMS)"]

1. Een alertregel gaat af op een metric of een activity log-gebeurtenis.
2. Een alert processing rule selecteert alerts op severity en stuurt ze naar een action group.
3. De action group roept een webhook aan bij je incident- of on-calltool en stuurt optioneel e-mail.
4. De tool opent of werkt een incident bij, plaatst het in het chatkanaal van het platformteam en, voor kritieke alerts, waarschuwt de on-callengineer met een telefoontje en sms, als je dat hebt ingesteld.
5. Het incidentproces start (Incident management).

Laat alle alerts van het platform via dezelfde action groups lopen. Een centrale route is makkelijker te testen, te wijzigen en te auditen dan ontvangers die over veel regels zijn verspreid.

Optionele 24/7-route voor de hub

Buiten kantooruren wil je misschien dat slechts een paar hubalerts iemand wakker maken. De optionele hub 24/7-route (ADR-0007) doet dat, alleen voor de hub. Per platform ingeschakeld maakt hij een eigen action group en processing rule aan op de connectivity- subscription, met een webhook naar keuze en een dagelijks tijdvenster (standaard 18:00 tot 08:00, West-Europese tijd). Standaard dekt de regel resource health- en service health-alerts voor de firewall, Virtual WAN, de virtual hub, de VPN gateway en Application Gateway.

Waarom een eigen action group: de webhook van één klant blijft gescheiden van de gedeelde kanalen, en het inschakelen verandert niet hoe andere alerts worden gerouteerd. De prijs is één extra action group en een lijst met alertnamen die je zelf bijhoudt als de namen upstream veranderen. De instellingen staan in Monitoringregels.

Een managed service kan 24/7-afhandeling bieden met een on-callrotatie en runbooks voor elke kritieke alert. Of dat voor jou geldt, is een kwestie van het contract.

Spokes en workload teams

Subscriptions onder de management group landingzones krijgen de alertregels van de landing zone, en hun alerts met severity 0 tot en met 2 gaan naar de action group van het platform. Een workload team kan vragen om de standaardregels van zijn spoke te verwijderen, met de tag MonitorDisable of een policy-uitzondering (Monitoringregels).

Het platform alert niet op wat de applicatie doet. Het workload team maakt die alerts zelf aan, met eigen action groups en op zijn eigen workspace (Je workload beheren).

Houd de alerting gezond

Taak	Hoe vaak	Waar
Beoordeel de alerts van de week: stel ruisende regels bij, maak work items aan voor echte problemen	Wekelijks	Onderhoudskalender
Controleer dat de alertpolicies compliant zijn en dat de alerts die in de maand afgingen bruikbaar waren	Maandelijks	Maandelijkse healthcheck
Controleer de ontvangers: mensen zijn vertrokken, een webhook is geroteerd, de on-calltool is veranderd	Elk kwartaal, en bij elke teamwijziging	Ontvangers in foundation.auto.tfvars (Monitoring uitrollen)
Controleer dat een kritieke alert echt een persoon bereikt	Na elke wijziging van de route	Monitoring uitrollen

Een site-to-site-verbinding die connected meldt maar geen verkeer doorlaat, wordt niet door een statusalert gevangen. Alert ook op verkeer (Bekende problemen).

Upgrades en oude alertobjecten

Oudere versies deployden custom alertpolicy-objecten die met de hand moesten worden verwijderd toen de alertpolicies werden vervangen. Zoek ernaar als je upgradet over v4.5.1 of v4.11.x: Upgradehandleidingen voor het platform.