Nederlandse overheidsorganisaties beheren een mozaïek van workloads in eigen datacenters, Azure-regio's, edge-omgevingen en SaaS-diensten. Burgers verwachten dat vergunningportalen, meldkamers en financiële systemen altijd beschikbaar zijn, terwijl toezichthouders eisen dat beveiligingsincidenten binnen minuten worden gedetecteerd. Klassieke monitoring die zich beperkt tot ping-tests en losse servermetrics kan dat tempo niet bijbenen. Alleen een geïntegreerd observability-platform dat infrastructuur, applicatiegedrag en gebruikerservaring samenbrengt, levert het inzicht dat nodig is om continuïteit te garanderen én aan BIO-vereisten te voldoen.
Azure Monitor vormt de orchestrator van die observability-capability. Platformmetrics, Log Analytics, Application Insights, Container Insights en dashboards in Workbooks gebruiken één datalaag waarop je met Kusto Query Language (KQL) relaties legt tussen events. Daarmee wordt elke wijziging, storing of verdachte activiteit direct gekoppeld aan de onderliggende componenten. NIS2 artikel 21 schrijft voor dat organisaties afwijkingen snel detecteren en escaleren; Azure Monitor levert de telemetriebasis om dat bewijsbaar te doen, inclusief retentie-instellingen, audittrails en automatisering.
In deze gids werken we stap voor stap uit hoe je een telemetriearchitectuur ontwerpt die alle lagen afdekt, hoe je alerting en respons structureert en hoe je governance en kostenbeheersing borgt. Elk hoofdstuk combineert technische configuraties met organisatorische afspraken zodat observability geen los project blijft, maar een kerncompetentie binnen de Nederlandse Baseline voor Veilige Cloud.
Deze gids is bedoeld voor observability-architecten, cloudbeheerders, SOC-teams en dienstverleningsmanagers binnen de rijksoverheid die één platform willen inrichten voor metrics, logs en traces. We koppelen architectuurkeuzes expliciet aan BIO- en NIS2-controles, zodat bestuurders, auditors en operations dezelfde dataset gebruiken voor besluitvorming en bewijsvoering.
Maak voor elke kritieke dienst een ketenkaart waarin clienttelemetrie, API-metrics, middleware-logs en database-events in één Workbook worden samengebracht. Combineer realtime grafieken met change-events uit Azure DevOps en ITSM, zodat degradatie direct te herleiden is tot een release, patch of configuratiewijziging. Dit verlaagt de Mean Time To Detect en biedt direct materiaal voor RCA-rapportages richting toezichthouders.
Telemetriearchitectuur: volledige dekking van bron tot gebruiker
Een volwassen observability-strategie begint bij het principe dat elk relevant signaal wordt verzameld, verrijkt en veilig opgeslagen. Voor Nederlandse overheidsinstellingen betekent dit dat platformtelemetrie vanuit Azure-resources standaard wordt geactiveerd via diagnostische instellingen die sturen naar centrale Log Analytics-workspaces. Deze werkruimten bevinden zich bij voorkeur in EU-regio's met gegevensresidentie die aansluit bij het Rijksbeleid voor informatieveiligheid en de Nederlandse Baseline voor Veilige Cloud. De logische opzet volgt de zonering van de organisatie: gescheiden werkruimten voor staatsgeheime workloads, financiële ketens, basisregistraties en generieke dienstverlening. Cross-workspace queries maken het mogelijk om waar nodig rapportages te bundelen, terwijl rolgebaseerde toegang en dataclassificatie voorkomen dat vertrouwelijke gegevens ongeoorloofd worden ingezien.
Servers in eigen datacenters of andere clouds vallen buiten het standaardbereik van Azure-resources, maar mogen niet buiten beeld blijven. De Azure Monitor Agent in combinatie met Data Collection Rules vormt daarom een verplichte standaard in het technische basisbeeld. Voor elk type server en voor elke workloadcategorie wordt vastgelegd welke prestatiemeters, Windows Event Logs, syslog-faciliteiten en specifieke applicatielogs noodzakelijk zijn om incidenten te kunnen verklaren. Deze configuratie wordt afgedwongen met beleid in Azure Policy en, waar relevant, met configuratiebeheer op locatie. Nieuwe virtuele machines en schaalsets worden daardoor automatisch voorzien van de juiste agent en dataverzamelingsregels, zodat niemand per ongeluk monitoring uitschakelt of vergeet aan te zetten. In combinatie met Update Management, Defender for Cloud en configuratiemanagement ontstaat een keten waarin zowel configuratiedrift als ontbrekende telemetrie direct zichtbaar wordt.
Applicaties leveren de fijnmazige context die nodig is om storingen te begrijpen vanuit de beleving van burgers en medewerkers. Door Application Insights standaard in de bouwstraat op te nemen, worden webapps en API's automatisch verrijkt met informatie over responscodes, afhankelijkheden, wachttijden en foutdetails. De distributed tracing-functionaliteit zorgt ervoor dat een verzoek van begin tot eind gevolgd kan worden, van aanroep op de website tot databasequery en terugkoppeling richting gebruiker. Daarmee wordt de stap gezet van simpele uptime-controle naar transactionele observability, waarin elke stap in de keten is terug te zien. Voor legacy-applicaties waarvoor geen codewijzigingen meer mogelijk zijn, wordt gebruikgemaakt van codeloze monitoring met agentprofielen of OpenTelemetry-koppelingen, zodat ook deze systemen aansluiten op hetzelfde platform.
De ervaring van de eindgebruiker is minstens zo belangrijk als de prestaties van achterliggende systemen. Met browsergebaseerde monitoring en synthetische beschikbaarheidstesten wordt gemeten hoe snel pagina's laden, hoe vaak foutmeldingen optreden en welke regio's extra kwetsbaar zijn voor vertraging. Deze metingen worden gecombineerd met metingen uit API-beheer en wachtrijsystemen, zodat verschillen tussen gebruikerservaring en backendcapaciteit direct aan het licht komen. Voor mobiele toepassingen, IoT-oplossingen en meldkamersystemen worden aparte telemetriepaden ingericht via eventstromen, waarbij duidelijk is welke gegevens in bijna realtime nodig zijn en welke gegevens periodiek kunnen worden samengevat.
Dataverrijking en beveiliging vormen de laatste bouwstenen van de telemetriearchitectuur. Telemetrie wordt niet alleen opgeslagen, maar ook gekoppeld aan begrippen die bestuurders en auditors herkennen, zoals kritikaliteitsniveaus, proceseigenaren, verantwoordelijke managers en bijbehorende runbooks. Deze informatie wordt beheerd in tabellen die in Kusto-query's worden meegenomen en in dashboards automatisch worden weergegeven. Toegang tot ruwe gegevens wordt begrensd via Microsoft Entra-beveiligingsgroepen, fijnmazige roltoekenning en toegang op basis van tijdelijke goedkeuring. Waar organisaties samenwerken in ketens, wordt telemetrie via beveiligde dataverzamelingspunten opgehaald en voor opslag gepseudonimiseerd. Zo wordt voldaan aan eisen voor gegevensbescherming en blijft het tegelijkertijd mogelijk om patronen over de gehele keten te herkennen.
Tot slot wordt de architectuur verankerd in ontwerpprincipes en standaardsjablonen. Nieuwe projecten krijgen een startpakket met aanbevolen werkruimten, verzamelingstabellen, metrieken en queryvoorbeelden. Architectuurreviewboards toetsen of oplossingen aansluiten op de bestaande observability-laag en of er geen schaduwmonitoring ontstaat via losse tools. Op die manier groeit het observability-platform mee met de organisatie, zonder dat het een lappendeken van ad-hocoplossingen wordt.
Alerting, escalatie en ketenrespons
Zodra telemetrie betrouwbaar stroomt, verschuift de aandacht van verzamelen naar interpreteren en handelen. Een goed opgezet alertingframework maakt onderscheid tussen signalen die direct aandacht vereisen en signalen die gebruikt worden voor trendanalyse. Voor overheidsorganisaties sluit deze indeling aan bij de classificatie van processen in de Baseline Informatiebeveiliging Overheid. Diensten die direct raken aan veiligheid, gezondheid of wettelijke termijnen krijgen strak gedefinieerde drempels en responstijden, terwijl ondersteunende processen ruimer bemeten worden. Voor elke dienst wordt beschreven welke indicatoren cruciaal zijn, wie verantwoordelijk is voor opvolging en welke impactmaat voor bestuurders relevant is.
De technische basis bestaat uit metric alerts voor infrastructuur en platformcomponenten. Virtuele machines, containers, databases, wachtrijen en webapps leveren een stroom aan metingen over belasting, wachttijden en fouten. Met behulp van drempels, relatieve afwijkingen en automatisch lerende grenswaarden worden patronen herkend zonder dat kortdurende pieken direct tot een alarmlawine leiden. Door alerts te groeperen op dienstniveau ontstaat één duidelijk signaal per keten in plaats van tientallen losse meldingen per component. Dit vermindert vermoeidheid bij beheerders en maakt het gesprek over beschikbaarheid concreet.
Voor complexe storingen zijn logalerts op basis van query's onmisbaar. Verschillende logbronnen worden samengebracht in één zoekopdracht waarin foutcodes, prestatieproblemen, configuratiewijzigingen en beveiligingsgebeurtenissen worden gecombineerd. Wanneer bijvoorbeeld een toename in foutmeldingen in een burgerportaal samenvalt met gewijzigde toegangsregels en een reeks time-outs in een achterliggende database, wordt er één incidentmelding aangemaakt met alle relevante context. De alertmelding bevat verwijzingen naar runbooks, bekende foutpatronen en recente wijzigingen, zodat het triageteam gericht kan handelen en niet eerst hoeft te zoeken naar basisinformatie.
Escalatieafspraken vormen het verbindende element tussen techniek en organisatie. Voor elke categorie wordt vastgelegd welke ploeg dienst heeft, welke responstijd acceptabel is en wanneer opschaling naar crisisteams of bestuurders nodig is. Kritieke meldingen sturen direct een bericht naar de dienstdoende specialist via sms, telefoon en samenwerkingskanalen. Wanneer binnen een vooraf bepaalde tijd geen bevestiging plaatsvindt, gaat het signaal automatisch door naar het volgende niveau. Minder urgente meldingen leiden tot taken in het werkvoorraadsysteem, voorzien van logfragmenten en trendgrafieken. Zo blijft het beheer overzichtelijk en voorspelbaar, terwijl toch wordt voldaan aan de eisen uit onder andere NIS2 voor tijdige detectie en reactie.
Automatisering versterkt de ketenrespons. Standaardmaatregelen, zoals het tijdelijk vergroten van capaciteit, het terugdraaien van een configuratiewijziging of het inschakelen van uitgebreide logging, kunnen automatisch worden uitgevoerd wanneer een alert afgaat. Daarbij wordt altijd vastgelegd welke acties zijn genomen, zodat achteraf beoordeeld kan worden of de gekozen aanpak effectief was en binnen de afgesproken bevoegdheden viel. Voor beveiligingsincidenten worden waarschuwingssignalen doorgezet naar het centrale detectieplatform, waar verdere analyse en coördinatie plaatsvindt.
Leren van incidenten is minstens zo belangrijk als snel reageren. Organisaties plannen periodieke oefeningen waarin fictieve storingen of degradaties worden nagebootst. Tijdens deze sessies wordt gemeten of alerts op tijd worden gegenereerd, of de juiste mensen worden bereikt en of runbooks voldoende duidelijk zijn. Bevindingen uit deze oefeningen worden vertaald naar verbeteringen in drempels, dashboards, escalatiepaden en opleidingen. Op die manier ontwikkelt het observability-landschap zich van een reactieve meldingsstroom naar een continu verbeterprogramma dat aantoonbaar bijdraagt aan stabiele dienstverlening.
Door technische metingen tenslotte te verbinden aan doelstellingen op het gebied van dienstverlening, ontstaat een gemeenschappelijke taal tussen techniek en bestuur. Beschikbaarheid van digitale loketten, doorlooptijden van berichtenverkeer en wachttijden in telefoniesystemen worden zichtbaar in overzichten die zijn afgestemd op bestuurlijke rapportages. Observability wordt daarmee een stuurinstrument dat inzicht geeft in de mate waarin de organisatie voldoet aan de Nederlandse Baseline voor Veilige Cloud en andere normkaders, in plaats van een verzameling losse foutmeldingen.
Governance, dashboards en kostenbeheersing
Observability wordt pas duurzaam wanneer de bestuurlijke inbedding en de financiële sturing net zo volwassen zijn als de techniek. Overheidsorganisaties doen er daarom goed aan een Observability Board in te richten waarin vertegenwoordigers van beheer, beveiliging, architectuur, financiën en de belangrijkste diensten zitting hebben. Dit overlegorgaan vertaalt de Nederlandse Baseline voor Veilige Cloud, de BIO en NIS2-verplichtingen naar concrete afspraken over logopslag, retentietermijnen, toegangsrechten en rapportagelijnen. Besluiten worden vastgelegd in een governancehandboek en vervolgens doorvertaald naar sjablonen en beleidsregels in het cloudplatform, zodat naleving niet afhankelijk is van individuele beheerders.
Een belangrijke taak van het governanceorgaan is het bepalen van de standaardopzet van werkruimten. Er worden richtlijnen opgesteld voor naamgeving, tagging en scheiding van gegevens. Kritieke diensten, zoals meldkamers, basisregistraties of systemen voor uitkeringen, krijgen eigen observability-domeinen met striktere toegangsrechten en langere bewaartermijnen. Minder gevoelige diensten kunnen gebruikmaken van gedeelde werkruimten met kortere retentie en sterkere nadruk op kostenoptimalisatie. Door voor elk domein vast te leggen welke gegevens minimaal nodig zijn voor opsporing, forensisch onderzoek en audit, ontstaat een helder kader voor ontwerpkeuzes in projecten.
Dashboards vormen het zichtbare resultaat van deze inrichting. Strategische overzichten laten bestuurders in één oogopslag zien hoe vaak diensten binnen afgesproken prestatieniveaus functioneren, welke trends zich aftekenen in incidenten en waar zich structurele knelpunten voordoen. Operationele dashboards tonen realtime de gezondheid van agents, de snelheid van logverwerking, de verdeling van meldingen over teams en de voortgang van lopende storingen. Analisten in beveiligings- of fraudeteams gebruiken meer diepgaande visualisaties waarin observabilitygegevens worden gecombineerd met dreigingsinformatie en casusdata. In alle gevallen wordt gewerkt vanuit één consistente gegevensbron, zodat discussies over cijfers worden vervangen door gesprekken over duiding en maatregelen.
Kostenbeheersing krijgt een vaste plek op de agenda. Omdat logplatformen doorgaans rekenen op basis van datavolume en bewaartermijn, is het verstandig periodiek te beoordelen welke gegevens echt nodig zijn. Met behulp van rapportages worden ingestiekosten per dienst, per logtype en per omgeving inzichtelijk gemaakt. Projecten die veel gegevens genereren, worden uitgenodigd om hun logstrategie tegen het licht te houden. Soms is het voldoende om detailgegevens na een korte periode samen te vatten, in andere gevallen kan filtering of sampling worden toegepast zonder dat de kwaliteit van incidentonderzoek in het gedrang komt. De keuzes worden vastgelegd en periodiek herzien, zodat de balans tussen transparantie, forensische robuustheid en betaalbaarheid behouden blijft.
Automatisering ondersteunt deze governance-afspraken. Implementatiescripts in Bicep of Terraform zorgen ervoor dat nieuwe omgevingen volgens dezelfde patronen worden opgezet, inclusief werkruimten, diagnostische instellingen, dataverzamelingsregels en meldingsmechanismen. Wijzigingen aan deze patronen doorlopen dezelfde beoordelings-, test- en uitrolstappen als reguliere applicatiewijzigingen. Elke aanpassing wordt gekoppeld aan een wijzigingsrecord met motivatie, risicoafweging en terugvalscenario. Daarmee ontstaat een spoor van besluitvorming dat bij audits eenvoudig kan worden overlegd.
De menselijke factor is minstens zo belangrijk als techniek en proces. Medewerkers die met observability werken, krijgen toegang tot oefenomgevingen waarin zij kunnen experimenteren met querytaal, visualisaties en geautomatiseerde acties zonder risico voor productie. Binnen de organisatie ontstaat een gemeenschap waarin specialisten ervaringen en oplossingen uitwisselen. Succesvolle patronen worden gedocumenteerd en via het governanceorgaan breed ingevoerd. Op die manier groeit het observability-platform uit tot een kernvoorziening voor sturing en verantwoording, en niet slechts een hulpmiddel voor incidentafhandeling.
Wanneer governance, dashboards en kostenbeheersing op elkaar zijn afgestemd, wordt observability een vanzelfsprekend onderdeel van de digitale ruggengraat. Bestuurders beschikken over betrouwbare indicatoren, beheerteams hebben grip op hun werklast en securityteams kunnen aantonen dat detectie en respons aansluiten op het actuele dreigingsbeeld. Daarmee levert het observability-platform een directe bijdrage aan het aantoonbaar naleven van de Nederlandse Baseline voor Veilige Cloud en de continuïteit van publieke dienstverlening.
Azure Monitor ontwikkelt zich tot het zenuwstelsel van digitale overheidsdiensten. Door alle lagen – infrastructuur, applicaties, security en gebruikerservaring – aan één telemetriearchitectuur te koppelen, ontstaat een single source of truth waarmee teams sneller reageren, minder escalaties nodig hebben en onderbouwing kunnen geven aan iedere auditvraag. Wanneer alerting is verbonden aan duidelijke runbooks en escalaties, verandert monitoring van een reactieve taak in een voorspelbaar proces dat bestuurlijke rust geeft.
Succesvolle organisaties investeren bovendien in governance en kostenbewustzijn. Ze standaardiseren deployments, bewaken retentie en koppelen dashboards aan businessdoelen. Daarmee voldoen ze niet alleen aan de Nederlandse Baseline voor Veilige Cloud, BIO en NIS2, maar verhogen ze aantoonbaar de kwaliteit van dienstverlening aan burgers en bedrijven.
Maak observability daarom onderdeel van je digitale transformatieagenda: neem de tijd om architectuurprincipes vast te leggen, train teams in KQL en automatiseer zoveel mogelijk configuraties. Hoe consistenter de datalaag, hoe sneller elke wijziging, storing of aanval kan worden begrepen en opgelost.