Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.
Het verschil in een tabel
| Monitoring | Observability | |
|---|---|---|
| Vraag die het beantwoordt | Is er iets mis? | Waarom gaat dit mis? |
| Type problemen | Known unknowns: faalmodi die je vooraf kent | Unknown unknowns: problemen die je niet had voorzien |
| Benodigde data | Vooraf gekozen metrics en checks | Rijke telemetrie met context: logs, metrics en traces, correleerbaar |
| Wie het gebruikt | Beheerders en operations | SRE’s, platformengineers, ontwikkelaars |
| Wanneer het tekortschiet | Bij nieuwe, onvoorziene faalmodi in gedistribueerde systemen | Bij eenvoudige omgevingen: onnodig duur en complex |
De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.
The three pillars of observability: logs, metrics en traces
Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.
Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.
Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.
En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.
Wanneer monitoring genoeg is
Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:
- Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
- Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
- Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.
Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.
Van dashboards naar service-inzicht
Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.
Wat je nodig hebt om te beginnen
- Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
- Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
- Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
- Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.
Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.
