Het systeem werkt. Tot het moment dat het dat niet meer doet
Stel je een webwinkel voor waarin klanten producten kunnen bekijken, ze aan de winkelwagen kunnen toevoegen en naar de betaling kunnen gaan. De server reageert, de pagina wordt geopend en de basisstatistieken van de infrastructuur wijzen niet op een ernstig probleem. Op het eerste gezicht lijkt alles correct te werken.
Ondertussen kan een deel van de klanten de bestelling niet afronden. Bij de één duurt de betaling tientallen seconden, bij de ander verschijnt er een fout. Het technische team ontvangt meldingen, maar weet nog niet of de oorzaak ligt bij de betaalgateway, de database, de laatste applicatie-update of misschien bij een communicatieprobleem tussen services.
Dat is een situatie waarin gewone monitoring tekort kan schieten. Het kan aangeven dat het aantal fouten is toegenomen of dat de responstijd is langer geworden, maar levert niet altijd de informatie die nodig is om snel de oorzaak te vinden.
Juist op deze leemte speelt observability, oftewel waarneembaarheid van het systeem, in. Het doel is niet alleen vaststellen dat de applicatie niet goed werkt. Het gaat om de mogelijkheid om het gedrag te analyseren, het verloop van gebeurtenissen te reconstrueren en de bron van het probleem te vinden, ook wanneer eerder geen specifiek storingsscenario was voorzien.
Monitoring en observability - vergelijkbare doelen, andere mogelijkheden
Monitoring en observability hangen nauw met elkaar samen, maar betekenen niet hetzelfde.
Monitoring draait om het systematisch verzamelen en analyseren van gegevens over de status van de applicatie en de infrastructuur. Het maakt het mogelijk om specifieke parameters te volgen, afwijkingen van vastgestelde normen te detecteren en alerts te activeren wanneer zich een situatie voordoet die actie vereist.
Voorbeeldvragen waarop monitoring antwoord geeft zijn:
- Is de server beschikbaar?
- Wat is de gemiddelde responstijd van de API?
- Overschrijdt het aantal HTTP 500-fouten de vastgestelde drempel?
- Hoe groot is het geheugengebruik en CPU-gebruik?
- Groeit de wachtrij met taken sneller dan het systeem kan verwerken?
Observability gaat verder. Het maakt het mogelijk om gegevens uit verschillende delen van het systeem te analyseren en ze te combineren in een context die helpt te begrijpen waarom bepaald gedrag is opgetreden.
Dit kan worden samengevat in drie vragen:
- Monitoring: Is er iets mis?
- Diagnostiek: Waar is het probleem verschenen?
- Observability: Wat is er gebeurd, waarom en wat was de impact op de werking van het systeem?
Observability vervangt monitoring niet. Het is een benadering die monitoring en goed voorbereide telemetriegegevens gebruikt om een dieper onderzoek naar het gedrag van de applicatie mogelijk te maken. OpenTelemetry beschrijft observability als de mogelijkheid om het systeem vragen te stellen over zijn gedrag op basis van signalen zoals logs, metrics en distributed traces. <Cite ref="turn154932search0"/>
De drie pijlers van observability: logs, metrics en tracing
De basis van observability bestaat uit drie soorten telemetriegegevens: logs, metrics en traces. Elk daarvan laat een ander aspect van de werking van de applicatie zien. Pas hun correlatie geeft een breder beeld van de situatie.
1. Logs - wat is er in de applicatie gebeurd?
Logs zijn gestructureerde registraties van gebeurtenissen die worden gegenereerd door de applicatie, het besturingssysteem, servers, databases en andere infrastructuurcomponenten.
Ze kunnen bijvoorbeeld registreren:
- het starten en beëindigen van een proces,
- een inlogpoging van een gebruiker,
- het verzenden van een verzoek naar een externe API,
- een validatiefout van gegevens,
- een mislukte transactie,
- een uitzondering die door de applicatie wordt gemeld,
- een wijziging in de status van een bestelling.
Een log kan een tijdstempel, ernstniveau, servicenaam, bericht, request-ID en aanvullende attributen bevatten die de gebeurtenis beschrijven.
Het is belangrijk om tekstlogs te onderscheiden van gestructureerde logs. Een tekstuele registratie kan er als volgt uitzien:Fout tijdens het verwerken van de bestelling
Zo'n bericht geeft aan dat er een probleem is opgetreden, maar zegt weinig over de context ervan. Een gestructureerd log kan daarentegen aparte velden bevatten, zoals order-ID, operatienaam, foutcode, uitvoeringstijd en trace-ID. Daardoor kunnen gegevens automatisch worden gefilterd, gegroepeerd en geanalyseerd.
Goede praktijk: logs moeten worden ontworpen met het oog op latere analyse, en niet alleen op het opslaan van berichten. Het is de moeite waard om consistente naamgeving, ernstniveaus en correlatie-ID's te gebruiken waarmee gebeurtenissen uit verschillende componenten kunnen worden gekoppeld.
Tegelijkertijd vereist logging verstandige keuzes. Het vastleggen van elke operatie in volle omvang kan enorme hoeveelheden gegevens genereren, de opslagkosten verhogen en het moeilijker maken om relevante informatie te vinden. Even belangrijk is dat logs geen wachtwoorden, toegangstokens, betaalkaartgegevens of andere vertrouwelijke informatie mogen onthullen. Er moeten masking, toegangscontrole, passende bewaartermijnen en regels voor veilige gegevensverwerking worden toegepast.
2. Metrics - hoe gedraagt het systeem zich in de tijd?
Metrics zijn geaggregeerde numerieke gegevens die de status, prestaties en het gedrag van het systeem binnen een bepaalde tijd beschrijven.
Voorbeeldmetrics zijn onder meer:
- het aantal verzoeken dat per seconde is afgehandeld,
- het percentage verzoeken dat met een fout is beëindigd,
- de responstijd van de API,
- CPU- en geheugengebruik,
- het aantal actieve sessies,
- de lengte van de wachtrij met taken,
- het aantal afgeronde transacties,
- de wachttijd voor een databaseverbinding.
Hun grootste voordeel is de mogelijkheid om trends te observeren. Een enkele fout kan een incident zijn, maar een geleidelijk oplopende responstijd, een toenemend aantal mislukte transacties of een groeiende wachtrij met taken kunnen wijzen op een zich ontwikkelend probleem.
In de praktijk helpen metrics niet alleen om de vraag te beantwoorden of de applicatie werkt, maar ook of haar prestaties voldoen aan de verwachtingen van gebruikers en de zakelijke eisen.
Bijzonder nuttig zijn percentielen van de responstijd, bijvoorbeeld p95 en p99. Het gemiddelde kan een situatie verhullen waarin de meeste gebruikers snel een antwoord krijgen, maar een klein deel zeer grote vertragingen ervaart. Percentielen laten zien hoe lang de afhandeling van trage verzoeken duurt en helpen problemen op te merken die in gemiddelde waarden onzichtbaar blijven.
Goede praktijk: kies metrics die relevant zijn voor de gebruiker en het bedrijfsproces. Alleen informatie over CPU-belasting vertelt je niet of een klant een bestelling kan plaatsen. Het is daarom de moeite waard ook indicatoren te monitoren die verband houden met kernfuncties, zoals het succespercentage van betalingen, de doorlooptijd van bestellingen of de beschikbaarheid van de belangrijkste handelingen.
3. Tracing - via welke route verliep het verzoek?
Tracing, en met name distributed tracing, oftewel gedistribueerde tracing, maakt het mogelijk om het pad van een afzonderlijk verzoek door verschillende componenten van het systeem te volgen.
In een moderne applicatie kan een gebruikershandeling uit meerdere stappen bestaan. Een klik op de knop ‘Bestelling plaatsen’ kan een verzoek in de browser activeren dat naar de API gaat, vervolgens naar de bestelservice, de database, het voorraadsysteem en een externe betalingsprovider.
Als het proces vertraagt, is alleen informatie over de responstijd van de hele API mogelijk niet voldoende. Tracing maakt het mogelijk deze tijd op te splitsen in afzonderlijke operaties en te zien welke stap verantwoordelijk is voor de vertraging.
Het basisonderdeel van een trace is een span, een registratie van één enkele operatie. Een span kan de begin- en eindtijd, de naam van de operatie, de status en metadata bevatten. Gerelateerde spans vormen samen een trace die het verloop van het hele verzoek laat zien.
Bijvoorbeeld:
- De API ontvangt het verzoek en geeft het door.
- De bestelservice controleert de gegevens.
- De database slaat de bestelling op.
- De magazijnservice controleert de beschikbaarheid van het product.
- De externe betaalgateway verwerkt de transactie.
- De applicatie geeft het resultaat terug aan de gebruiker.
Als het hele proces 8 seconden duurt, kan tracing laten zien dat 6,5 seconden werd besteed aan het antwoord van de externe betaalgateway, terwijl de overige operaties correct verliepen. Het team krijgt dan een concreet aanknopingspunt voor verdere analyse, in plaats van de diagnose te beginnen bij willekeurige componenten.
Tracing is vooral nuttig in microservice-architecturen, gedistribueerde systemen, toepassingen op basis van wachtrijen en oplossingen die veel externe diensten integreren. <Cite ref="turn154932search0"/>
Alerts - de informatie moet de juiste persoon bereiken
Telemetriegegevens zijn alleen nuttig als je er actie op kunt ondernemen. Daarom is een waarschuwingssysteem een belangrijk onderdeel van observability.
Een alert is een melding van een gebeurtenis of toestand die aandacht vereist. Het kan worden geactiveerd wanneer een metriek een drempel overschrijdt, een bepaald foutenpatroon wordt gedetecteerd of wordt vastgesteld dat een kernfunctie van de applicatie niet werkt zoals verwacht.
Niet elke toename van belasting zou echter een alarm moeten genereren. Als het systeem tijdens piekuren regelmatig veel verkeer verwerkt, zal een melding bij elke toename van het aantal verzoeken informatieruis veroorzaken. Te veel alerts leiden ertoe dat ze worden genegeerd, waardoor een daadwerkelijk belangrijk incident over het hoofd wordt gezien.
Daarom is het verstandig om vast te leggen:
- welke gebeurtenissen onmiddellijke reactie vereisen,
- welke problemen in de standaard werkwijze kunnen worden geanalyseerd,
- wie verantwoordelijk is voor een bepaald type alert,
- welke informatie de melding moet bevatten,
- welke acties na ontvangst moeten worden ondernomen.
Een goed vertrekpunt is het definiëren van alerts op basis van de impact op de gebruiker en betrouwbaarheidsdoelen, en niet alleen op infrastructuurparameters. Zo kan een alert over een stijgend percentage mislukte betalingen meer zakelijke betekenis hebben dan een kortstondige piek in CPU-gebruik.
Een alert moet tot actie leiden. Als niet duidelijk is wie hem moet afhandelen of wat er moet gebeuren, is het slechts een extra bericht in het systeem.
Voorbeeld uit de praktijk: hoe helpt observability de oorzaak van een storing te vinden?
Stel dat gebruikers van een B2B-applicatie melden dat het genereren van rapporten veel langer duurt dan normaal. Monitoring detecteert een toename in de responstijd en activeert een alert.
Het team start de analyse:
- Metingen laten zien dat het probleem vooral betrekking heeft op rapporten met grote datasets. De overige functies werken normaal.
- Tracing toont dat de grootste vertraging optreedt tijdens het uitvoeren van de databasequery.
- Logboeken bevatten details van de query, de operationele parameters en foutinformatie, zonder gevoelige gegevens prijs te geven.
- Datacorelatie maakt het mogelijk een specifieke trace te koppelen aan de juiste logregels en de veranderingen die zichtbaar zijn in grafieken van metingen.
- Wijzigingsanalyse laat zien dat het probleem ontstond na de uitrol van een nieuwe versie van het rapport, die een kostbare query begon uit te voeren.
Dankzij dit hoeft het team niet blind de hele infrastructuur te controleren. Het kan zich richten op een concrete operatie, het gedrag voor en na de uitrol vergelijken en vervolgens de query optimaliseren of de wijziging terugdraaien.
Observability voorkomt geen storingen en garandeert niet dat elke oorzaak automatisch wordt gevonden. Het helpt wel om het zoekgebied te beperken, de diagnose te versnellen en beslissingen te baseren op data in plaats van op aannames.
Datacorelatie - de grootste waarde ontstaat samen
Logboeken, metingen en tracing zijn afzonderlijk nuttig, maar hun echte waarde komt naar voren wanneer ze met elkaar kunnen worden verbonden.
Stel je voor dat een dashboard een plotselinge toename van de responstijd toont. De metriek laat zien wanneer en in welke mate het probleem zich voordeed. De trace laat zien welke operaties deel uitmaakten van het trage verzoek. Logboeken maken het mogelijk te controleren welke gebeurtenissen zich in een specifieke fase hebben voorgedaan.
Om dit mogelijk te maken, moet het systeem de verzoekcontext consequent tussen services doorgeven. Trace- en span-id's kunnen worden gebruikt om logregels aan traces te koppelen. Het is ook nuttig om consistente informatie te bewaren over servicenaam, omgeving, applicatieversie en andere attributen die de bron van de data beschrijven.
Zonder correlatie kan het team toegang hebben tot veel dashboards, bestanden en tools, maar toch tijd verliezen met handmatig vaststellen welke gebeurtenissen met elkaar verband houden. OpenTelemetry wijst de correlatie van logboeken, traces en resourcecontext aan als een belangrijk element bij het opbouwen van bruikbare telemetrie. <Cite ref="turn154932search1"/>
OpenTelemetry - een gemeenschappelijke standaard voor telemetriegegevens
De implementatie van observability hoeft niet te betekenen dat je afhankelijk wordt van één leverancier van tools. Een oplossing die interoperabiliteit ondersteunt is OpenTelemetry (OTel) - een open set standaarden, API's, bibliotheken en hulpmiddelen voor het instrumenteren, genereren, verzamelen en exporteren van telemetriegegevens.
OpenTelemetry stelt een applicatie in staat om metingen, logboeken en traces volgens één consistent model uit te zenden. De gegevens kunnen vervolgens worden doorgegeven aan een gekozen observability-backend, die verantwoordelijk is voor opslag, zoeken, visualisatie en analyse.
Een belangrijk onderdeel van het ecosysteem is de OpenTelemetry Collector. Deze kan gegevens uit verschillende bronnen ontvangen, verwerken, verrijken met extra context en exporteren naar geconfigureerde systemen. Daardoor hoeft de applicatie niet direct gekoppeld te zijn aan elk hulpmiddel dat voor analyse wordt gebruikt.
Deze aanpak is vooral nuttig wanneer een bedrijf met meerdere technologieën werkt, de systeemarchitectuur verder ontwikkelt of de mogelijkheid wil behouden om van toolleverancier te wisselen. De standaard alleen biedt echter nog geen volledige observability. Er zijn nog steeds de juiste instrumentatie, een doordachte strategie voor gegevensverzameling, passende dashboards, alerts en responsprocedures nodig. <Cite ref="turn154932search3"/>
Wanneer is het de moeite waard om observability te implementeren?
Observability kan zowel in grote gedistribueerde systemen als in kleinere applicaties nuttig zijn, waar downtime of een moeilijk te detecteren storing aanzienlijke zakelijke gevolgen heeft.
Het is vooral de moeite waard om deze aanpak te overwegen wanneer:
- de applicatie bestaat uit vele diensten of integraties,
- problemen doen zich onregelmatig voor en zijn moeilijk te reproduceren,
- gebruikers melden fouten die niet zichtbaar zijn in standaardtests,
- de tijd om incidenten te diagnosticeren is te lang,
- opeenvolgende implementaties veroorzaken moeilijk voorspelbare gevolgen,
- het bedrijf ontwikkelt het systeem verder en heeft gegevens nodig om de prestaties te plannen,
- de applicatie ondersteunt kritieke verkoop-, operationele of financiële processen,
- het team moet beter begrijpen welke invloed externe diensten hebben op het functioneren van de hele oplossing.
Dat betekent echter niet dat elke website een uitgebreid telemetry-omgeving nodig heeft. In een kleine, eenvoudige service kunnen basislogs, beschikbaarheidsbewaking en een paar kernmetrics voldoende zijn. De omvang van de oplossing moet passen bij de complexiteit van de applicatie, de schaal van het verkeer, de betrouwbaarheidseisen en de kosten van mogelijke uitvaltijd.
Wanneer kan observability meer vorm dan inhoud zijn?
Het implementeren van uitgebreide tools zonder een duidelijk doel kan meer kosten dan voordelen opleveren.
De meest voorkomende fouten zijn:
- Alles verzamelen zonder plan. Te veel gegevens verhogen de kosten en maken het moeilijker om informatie te vinden die relevant is voor diagnose.
- Geen vragen hebben waarop het systeem moet antwoorden. Dashboards kunnen er indrukwekkend uitzien, maar niet helpen bij het oplossen van echte problemen.
- Voor elke afwijking een alert sturen. Een te groot aantal meldingen veroorzaakt alertmoeheid en vergroot het risico dat een incident over het hoofd wordt gezien.
- Geen verantwoordelijkheid voor de reactie. Zelfs een goed gedetecteerd probleem kan lang duren als niemand weet wie het moet oppakken.
- Geen gegevensbescherming. Telemetrie kan gevoelige informatie, gebruikersidentifiers of operationele gegevens bevatten die beperkte toegang en passende retentie vereisen.
- De kosten van instrumentatie negeren. Het verzamelen van gedetailleerde traces en logs op grote schaal kan de prestaties van de applicatie beïnvloeden en aanzienlijke opslag- en verwerkingskosten veroorzaken.
- De tool als kant-en-klare oplossing beschouwen. Alleen het installeren van een platform garandeert nog geen correcte instrumentatie of een soepel diagnoseproces.
Observability vereist daarom niet alleen technologie, maar ook organisatorische beslissingen: welke gegevens nodig zijn, wie ze analyseert, hoe het team reageert en hoe inzichten uit incidenten worden omgezet in wijzigingen in het systeem.
Hoe plan je een observability-implementatie?
Het is het veiligst om observability gefaseerd uit te bouwen, beginnend bij processen en functies waarvan een storing de grootste impact heeft op gebruikers en het bedrijf.
1. Bepaal de kritieke bedrijfsprocessen
Breng de belangrijkste operaties in kaart, zoals inloggen, bestellingen plaatsen, betalingen, documenten genereren of gegevens synchroniseren. Zij moeten het vertrekpunt zijn om vast te stellen wat het correct functioneren van de applicatie betekent.
2. Stel betrouwbaarheidsindicatoren vast
Kies metrics die de gebruikerservaring weerspiegelen, bijvoorbeeld de beschikbaarheid van kernfuncties, responstijd of het percentage succesvol afgeronde handelingen. Voor belangrijke diensten kun je SLI (Service Level Indicator), oftewel service-levelindicator, en SLO (Service Level Objective), oftewel het doel voor die indicator, definiëren.
3. Zorg voor gestructureerde logs
Uniformeer het logformaat, de importantieniveaus en de basisattributen. Zorg voor correlatie-ID's en een beleid voor het verwijderen of maskeren van vertrouwelijke gegevens. Logs moeten leesbaar zijn voor het team en verwerkbaar door tools.
4. Voeg tracing toe in kritieke paden
Begin met processen die meerdere diensten, databases of externe integraties omvatten. Volg het verloop van een request door het systeem en zorg voor propagatie van context tussen componenten.
5. Bouw dashboards rond concrete vragen
Maak niet één enorm paneel, maar views die aansluiten bij de behoeften van verschillende rollen. Het technische team kan informatie nodig hebben over fouten en vertragingen, terwijl de producteigenaar gegevens nodig heeft over de effectiviteit van kernprocessen en de impact van storingen op gebruikers.
6. Ontwerp alerts en responsprocedures
Stel drempels, prioriteiten, verantwoordelijke personen en handelingsinstructies vast. Een alert moet context bevatten die helpt om de diagnose snel te starten, en niet alleen informeren over het overschrijden van een waarde.
7. Test observability
Controleer of het team de oorzaak van een voorbeeldfout kan vinden op basis van de beschikbare gegevens. Je kunt gecontroleerde storingstests uitvoeren in een testomgeving of oefeningen voor incidentrespons doen. Het is ook de moeite waard om te verifiëren of alerts afgaan wanneer dat zou moeten.
8. Ontwikkel de oplossing op basis van incidenten
Na elk belangrijk probleem is het de moeite waard om te bekijken welke informatie beschikbaar was, wat ontbrak en hoe instrumentatie, alerting of procedures kunnen worden verbeterd. Observability is geen eenmalig project, maar een proces van het verbeteren van kennis over het functioneren van het systeem.
Kosten en beveiliging - twee aspecten die niet mogen worden weggelaten
Telemetriegegevens hebben hun prijs. Kosten kunnen voortkomen uit instrumentatie, transport, indexering, opslag, retentie en data-analyse. In systemen met veel verkeer kan het verzamelen van alle traces of zeer gedetailleerde logs bijzonder kostbaar zijn.
Daarom is het verstandig om retentie af te stemmen op de behoeften, gegevens te filteren, traces te samplen (sampling) en verschillende detailniveaus te gebruiken afhankelijk van de omgeving. Een productiesysteem kan bijvoorbeeld volledige gegevens verzamelen voor fouten en geselecteerde kritieke operaties, terwijl een deel van de succesvolle requests wordt gesampled om het volume te beperken.
Even belangrijk is gegevensbescherming. Logs en traces kunnen onbedoeld persoonsgegevens, sessie-ID's, fragmenten van queries of informatie over de infrastructuurstructuur bevatten. Toegang tot telemetrie moet worden beperkt, onnodige gegevens moeten worden verwijderd, vertrouwelijke informatie moet worden gemaskeerd en bewaartermijnen moeten worden gecontroleerd. Het is ook de moeite waard om observability-systemen te behandelen als onderdeel van de productieomgeving, die zelf beveiliging, back-ups en toegangsbeheer vereisen.
Observability als managementinstrument, niet alleen als diagnostiek
Hoewel observability meestal wordt geassocieerd met het werk van ontwikkelaars, DevOps en beheerders, reikt de waarde ervan verder dan IT.
Gegevens over responstijd, fouten, beschikbaarheid en proceseffectiviteit kunnen een bedrijf helpen begrijpen welke technologische onderdelen de bedrijfsvoering ondersteunen en welke deze beperken. Ze maken het mogelijk terugkerende problemen te identificeren, de gevolgen van wijzigingen te beoordelen en de ontwikkeling te plannen op basis van het werkelijke gedrag van het systeem.
Als bijvoorbeeld het bestelsysteem op vaste tijdstippen regelmatig vertraagt, kunnen telemetriegegevens helpen vaststellen of optimalisatie van queries nodig is, een andere manier van taakverwerking, of uitbreiding van de infrastructuur. In plaats van te investeren in extra middelen op basis van intuïtie, kan het bedrijf eerst de werkelijke knelpunt vaststellen.
Observability ondersteunt ook de analyse van de gevolgen van implementaties. Het vergelijken van metrics, traces en logs vóór en ná een wijziging maakt het mogelijk regressies sneller te detecteren en te beoordelen of de update het verwachte effect heeft opgeleverd.
Observability mag echter niet worden gelijkgesteld aan automatische besluitvorming. De gegevens tonen het gedrag van het systeem, maar hun interpretatie vereist kennis van de architectuur, de bedrijfsprocessen en de context van het specifieke incident.
Begrippenlijst
- Observability (waarneembaarheid) - het vermogen om het interne gedrag van een systeem te begrijpen op basis van de gegevens die het uitzendt.
- Monitoring - het continu volgen van geselecteerde parameters en het detecteren van bepaalde toestanden die aandacht vereisen.
- Telemetry (telemetrie) - gegevens die worden verzameld en verzonden vanuit applicaties en infrastructuur om hun werking te analyseren.
- Logs (logboeken) - registraties van gebeurtenissen die zich voordoen in de applicatie of infrastructuur.
- Metrics (metrics) - numerieke metingen van de toestand, prestaties of het gedrag van het systeem in de tijd.
- Tracing - het volgen van het verloop van operaties door de componenten van de applicatie.
- Distributed tracing - het volgen van een afzonderlijke aanvraag in een systeem dat bestaat uit meerdere services of processen.
- Span - een registratie van een afzonderlijke operatie die deel uitmaakt van een trace.
- Trace - een set gerelateerde spans die het verloop van een operatie weergeven.
- Alert - een melding over een gedetecteerde toestand of gebeurtenis die reactie vereist.
- SLI - een indicator die een specifiek aspect van de werking van een dienst meet.
- SLO - een vastgesteld doel voor een gekozen betrouwbaarheidsindicator.
- Sampling - een techniek om de hoeveelheid verzamelde telemetriegegevens te beperken door een representatief deel van de gebeurtenissen te kiezen.
- OpenTelemetry - een open set standaarden en tools die instrumentatie en export van telemetriegegevens ondersteunen.
Samenvatting
Een storing in een applicatie begint niet altijd met een onbereikbare server of een foutmelding. Soms werkt het systeem formeel wel, maar wordt een kernfunctie te traag, eindigt een deel van de transacties zonder succes of faalt een integratie alleen onder bepaalde omstandigheden.
Monitoring helpt afwijkingen te detecteren. Observability maakt het mogelijk te begrijpen waardoor ze zijn ontstaan en wat hun invloed was op de werking van de applicatie. Logs, metrics, tracing en goed ontworpen alerts vormen samen de basis voor effectievere diagnose, bewuste ontwikkeling en het beperken van operationele risico's.
Het gaat er niet om zoveel mogelijk gegevens te verzamelen of de meest uitgebreide dashboards te maken. Het gaat erom dat je op het moment dat zich een probleem voordoet niet alleen vraagt: „Werkt het systeem?”, maar kunt vaststellen: „Wat is er precies in het systeem gebeurd, waarom en wat moeten we daarna doen?”
Een volwassen applicatie is niet alleen een applicatie die werkt. Het is ook een applicatie waarvan het gedrag kan worden begrepen, gediagnosticeerd en verbeterd.
