Waar Azure Monitor alerts wél sterk in zijn
Azure Monitor is een van de meest gebruikte monitoring stacks ter wereld. Het verzamelt drie streams: metrics (numeriek, time-series), logs (tekst, queryable via KQL in Log Analytics) en traces (Application Insights). Daarbovenop bouw je alert rules die afgaan bij een drempel-overschrijding of wanneer een log query rijen oplevert.
Voor infrastructuur en applicatie-monitoring is dit precies wat je nodig hebt:
| Use case | Azure Monitor dekking | Typische alert |
|---|---|---|
| VM CPU-piek | Metric alert op Percentage CPU | "VM-prod-01 CPU > 90% gedurende 5 min" |
| App-exception | Application Insights log alert | "Meer dan 10 errors in 1 min" |
| Pipeline-runtime | Log alert op ADFActivityRun | "Activity duration > 30 min" |
| Kostenanomalie | Cost Management alert | "Dagelijkse uitgave > $500" |
| Key Vault niet-geautoriseerde toegang | Activity Log alert | "Vault benaderd door onbekende principal" |
Wanneer de vraag is "is deze Azure resource gezond?", beantwoorden Azure Monitor alerts die snel en goedkoop.
Microsoft's eigen Azure Monitor docs beschrijven alert rules als "de manier om proactief te worden gemeld wanneer een belangrijke conditie is gedetecteerd." Let op de framing: een conditie die jij definieerde, op een signaal dat Azure al verzamelt.
De blinde vlekken die datateams parten spelen
De problemen beginnen als de vraag verschuift van "is de resource gezond?" naar "klopt de data?". Drie soorten storingen bereiken regelmatig business-gebruikers zonder dat Azure Monitor het opmerkt.
1. Stille datakwaliteitsproblemen Een pipeline draait succesvol. De job exit met code 0. De downstream-tabel is gevuld. Azure Monitor ziet een groen vinkje. Maar de rijen die er hadden moeten zijn ontbreken, omdat een upstream API stilletjes een veldnaam heeft gewijzigd. Azure Monitor kan hierover geen waarschuwing geven, want per definitie ging er niets fout.
2. Lineage-breuken tussen tools ADF voedt Databricks. Databricks schrijft naar een Lakehouse. Power BI leest uit de Lakehouse. Azure Monitor bewaakt elk apart. Wanneer de keten breekt bij de overdracht van Lakehouse naar Power BI (refresh faalt, semantisch model hercompileert, dataset wordt stale), legt geen Azure Monitor alert de verbinding terug naar ADF of upstream Databricks.
3. Power BI refresh-anomalieën Azure Monitor kan worden gekoppeld aan Power BI activity logs, maar het begrijpt niet native: - Een refresh die slaagt maar drie keer langer duurt dan baseline - Een model dat 18 uur niet ververst is, terwijl het iedere 6 uur zou moeten - Een capaciteit die refreshes stilzwijgend heeft afgeremd door uitgeputte CU
Dit zijn de symptomen waar datateams om geven en ze zijn onzichtbaar in standaard Azure Monitor-alerting.
Een 2024-onderzoek van Wakefield Research / Monte Carlo meldt dat datateams gemiddeld 70 incidenten per 1.000 tabellen per jaar rapporteren. (Monte Carlo, 2024) De meeste daarvan komen niet eens in zicht bij infrastructuur-monitoring.
Waarom dit gebeurt (het ligt niet aan Azure)
Azure Monitor is ontworpen rondom resources. Een VM, een function app, een SQL database, elk een afgebakend object met voorspelbare signalen. Het platform is uitstekend in die signalen bewaken en alerten op drempel-overschrijdingen.
Data reliability heeft een andere orde. Waar het je om gaat, is niet één enkele resource. Het is een datastroom door veel resources, waarbij een storing in één van de drie lagen verderop een effect produceert. De juiste eenheid van monitoring is de dataset, niet de VM. Azure Monitor modelleert datasets niet native.
Je kunt hiertegen vechten door complexe KQL-query's te schrijven die ADFActivityRun, DatabricksJobRun, PowerBIDatasetActivity en AzureDiagnostics joinen om de levenscyclus van een dataset te benaderen. Veel teams doen dat. Het resultaat is broos, duur (Log Analytics-ingestion is niet goedkoop) en moeilijk te onderhouden.
| Wat je zou willen monitoren | Wat Azure Monitor native biedt |
|---|---|
| "Sales daily.parquet is stale" | Storage account-metrics, vangt geen stale files |
| "Customer dim row count gedaald" | Niets, vereist custom KQL met row count history |
| "Pipeline produceerde foute data, dashboard nu fout" | Niets, Azure Monitor ziet pipeline als 'succeeded' |
| "Model refresh duur week af van baseline" | Mogelijk via custom Log Analytics query, geen anomalie-detectie |
Wat je kunt bouwen (of kopen) om het gat te dichten
Drie patronen waarmee teams Azure Monitor uitbreiden voor data reliability. Elk met afwegingen.
Patroon 1: Custom KQL + Logic Apps Schrijf scheduled KQL-query's die freshness, row counts en refresh-duurpercentielen berekenen. Trigger Logic Apps wanneer resultaten een drempel overschrijden. Stuur naar Teams of e-mail.
Pro: Volledige controle, blijft binnen het Azure-ecosysteem, factureerbaar op de bestaande Log Analytics workspace. Con: Maanden werk om een echte stack af te dekken. KQL-onderhoud groeit met elke nieuwe pipeline. Geen anomalie-detectie out of the box. Lineage moet handmatig gemodelleerd worden.
Patroon 2: Native Power BI alerting + Azure Function callbacks Gebruik de ingebouwde alerts op Power BI dashboard-tegels. Koppel ze aan Azure Functions die uitfanout naar de rest van je stack.
Pro: Snel op te zetten voor stacks met alleen Power BI. Con: Werkt alleen op numerieke tile-waarden. Geen cross-pipeline view. Waarschuwingen gaan pas af nadat een handmatig gebouwd dashboard het probleem weergeeft — wat te laat is.
Patroon 3: Aparte data observability tool erbovenop Leg een tool als MetricSign bovenop Azure Monitor. De tool abonneert zich op dezelfde Azure logs en metrics, plus PBI Service-API's, plus dbt manifests, plus ADF activities en redeneert daarover als een verbonden pipeline in plaats van als losse resources.
Pro: Dagen, geen maanden, tot eerste bruikbare alert. Cross-tool lineage inbegrepen. Anomalie-detectie op freshness en volume zonder handmatige drempels. Con: Extra tool om te evalueren en verantwoorden. Wat overlap met Azure Monitor op de basics.
Een IDC-rapport schatte dat data engineers tot 30% van hun tijd besteden aan incident-triage en root cause analyse. (IDC, 2023) Patroon 1 reduceert dat getal niet. Patroon 3 is daar juist op ontworpen.
Wanneer Azure Monitor alerts genoeg zijn
Niet elk team hoeft een laag toe te voegen. Past jouw situatie op alle vier punten? Dan is Azure Monitor op zichzelf prima:
- Je stack is grotendeels compute en infra (VM's, AKS, App Services), met weinig BI of analytics erbovenop
- Data-leveringen zijn batch, simpel en veranderen zelden van vorm
- Je hebt één bron die één sink voedt, geen lineage tussen tools om mee om te gaan
- Je hebt een engineer die oprecht plezier heeft in KQL schrijven en onderhouden
Als twee of meer van deze punten een rek voelen, halen de kosten van puur Azure Monitor je vroeg of laat in. Meestal als incident op een dinsdagochtend waarvan het zes uur duurt om de oorzaak te achterhalen.
Hoe MetricSign aansluit bij Azure Monitor
We hebben MetricSign gebouwd voor het geval Azure Monitor je infrastructuur-laag is en je een data-laag erbovenop nodig hebt. Ze vullen elkaar aan.
Azure Monitor blijft de bron van waarheid voor compute, networking, security en kosten. MetricSign leest uit Power BI Service, ADF, Databricks, dbt (Cloud en Core) en Fabric en levert de cross-tool lineage en freshness-alerting die Azure Monitor niet modelleert.
Geen vervanging van bestaande alerts. Geen vereiste om iets uit Log Analytics te migreren. We zitten vóór de data-laag waar Azure Monitor vóór de infrastructuur-laag zit.