Wat is observability? Logs, metrics en traces uitgelegd

Wat is observability? Het is het vermogen om uit te zoeken wat een systeem doet, en waarom, met alleen de data die het zelf uitstuurt: logs, metrics en traces. Als monitoring je vertelt dat er iets kapot is, laat observability je de volgende vraag stellen: waar, voor wie en sinds wanneer. Als je in spreadsheets werkt, doe je dat al in het klein elke keer dat je een raar getal terugvolgt naar de bronrij.

De versie van één minuut voor mensen die in spreadsheets leven

Stel je een maandelijkse omzetsheet voor waarin het totaal niet klopt. Een dashboard dat zegt "het totaal klopt niet" is monitoring. Kunnen filteren op regio, dag en product, en dan de ene import vinden die 400 rijen verdubbelde, dat is observability.

Softwareteams lopen tegen dezelfde muur aan met live systemen. Een checkoutpagina wordt traag. Er gaat een alarm af. Nu moet iemand uitzoeken welke service, welk klantsegment en welke release de oorzaak is. De data die dat mogelijk maakt heet telemetrie, en hoe goed je die kunt gebruiken, dat is wat mensen met observability bedoelen.

Biscuit heeft hier ook een versie van. Hij hoeft niet verteld te worden dat de bal weg is. Hij moet nagaan waar de bal het laatst gezien werd.

Monitoring versus observability: bekende problemen tegenover verrassingen

Monitoring houdt dingen in de gaten die je van tevoren hebt besloten te bekijken. Een CPU boven 90 procent, een foutpercentage boven 2 procent, een pagina die niet meer antwoordt. Jij schrijft de regel, en de tool slaat alarm zodra de regel gebroken wordt.

Observability is bedoeld voor de problemen waar je geen regel voor schreef. Het OpenTelemetry-project beschrijft het als een manier om een systeem van buitenaf te begrijpen, zonder de binnenkant te kennen. Dat helpt bij de zogeheten "onbekende onbekenden".

Denk niet dat het ene het andere vervangt. Monitoring is je rookmelder. Observability is de plattegrond en de camerabeelden die je daarna opvraagt. Je wilt allebei.

Logs, metrics en traces: de drie ruwe ingrediënten

Bijna elke uitleg komt uit op dezelfde drie signalen. Hier is elk ervan in spreadsheettermen.

Logs zijn tijdgestempelde berichten over losse gebeurtenissen. In een sheet is dat één rij per gebeurtenis: tijd, gebruiker, actie, resultaat. Ze bevatten het meeste detail en nemen de meeste ruimte in.

Metrics zijn getallen die over tijd zijn samengevat, zoals foutpercentage, aanvragen per minuut of gebruikt geheugen. In een sheet is dat je samenvattingstabblad. Goedkoop om op te slaan en snel in een grafiek te zetten, maar ze kunnen je niet vertellen welke ene aanvraag mislukte.

Traces volgen één aanvraag terwijl die door meerdere services loopt, met de tijd die elke stap kostte. In een sheet denk je aan één ordernummer dat je over vijf tabbladen volgt, en bij elk tabblad noteer je hoelang het daar bleef hangen.

De gebruikelijke samenvatting: metrics vertellen je dat er iets mis is, traces vertellen je ongeveer waar, en logs geven het detail. Hoe dat er in een echte cel uitziet, zie je zo.

Je hebt 5.000 logregels in een bestand: een uitgewerkt voorbeeld in Sheets

Stel dat je 5.000 regels uit een applicatielog in Google Sheets hebt geëxporteerd. Kolom A bevat de tijdstempel, kolom B de servicenaam, kolom C de statuscode en kolom D de responstijd in milliseconden. Werkt in Excel en Sheets, tenzij anders vermeld.

Eerst het foutpercentage, een klassieke metric:

=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)

• Het bereik is C2:C5001, de statuscodes.

• Het criterium ">=500" telt elke serverfout.

• Delen door COUNTA geeft het aandeel van alle aanvragen. Zet de cel op procentueel.

Dat is monitoring: één getal, één drempel. Nu het observability-deel. Welke service is verantwoordelijk?

=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)

Deze werkt alleen in Sheets, omdat QUERY geen Excel-tegenhanger heeft. De argumenten:

• De data is A1:D5001, inclusief de koppen.

• De tekst is een kleine SQL-achtige query: tel de fouten per service, grootste eerst.

• De laatste 1 betekent dat er één kopregel is.

In Excel 365 krijg je hetzelfde antwoord met een ander recept:

=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))

Dat heeft Excel 365 of 2021 nodig, want FILTER, UNIQUE en HSTACK staan niet in Excel 2016. Oudere versies zijn beter af met een draaitabel.

En voor de trage aanvragen is het 95e percentiel eerlijker dan het gemiddelde:

=PERCENTILE(D2:D5001, 0.95)

Als de gemiddelde responstijd 180 ms is maar het 95e percentiel 2,400 ms, heeft één op de twintig gebruikers een slechte dag. Gemiddelden verbergen dat, en precies die valkuil proberen observability-tools je te helpen vermijden.

Vergeet je steeds weer de formule? Formula.dog zet een beschrijving in gewone taal om in zo'n formule, zodat je niet elke keer opnieuw hoeft te zoeken.

Waar observability in een gewone werkdag opduikt

Je hoeft geen servers te draaien om er tegenaan te lopen. Een supportlead die vraagt "waarom zijn de tickets op dinsdag verdubbeld?" doet het al. Dat geldt ook voor een financieel analist die een afwijking terugvolgt naar één leveranciersfactuur, of iemand die ontdekt dat een nachtelijke import stilletjes een bestand heeft overgeslagen.

In software worden dezelfde vragen scherper, omdat systemen uit veel onderdelen bestaan. Eén klik op een knop kan een API-gateway, een authenticatieservice, een database en een betaalprovider raken. Als het misgaat, staat de foutmelding die je ziet zelden op de plek waar het begon. Een trace laat de hele keten zien, met de trage of kapotte schakel gemarkeerd, zodat niemand hoeft te gokken.

Drie termen komen constant voorbij, dus hier zijn ze in gewone woorden:

• Instrumentatie is de code toevoegen die telemetrie uitstuurt. Zie het als een tijdstempel- en een ID-kolom toevoegen aan een rapport dat die nooit had.

• Cardinaliteit is het aantal verschillende waarden dat een veld kan hebben. Regio heeft een lage cardinaliteit, een gebruikers-ID een zeer hoge. Velden met hoge cardinaliteit beantwoorden de scherpste vragen en kosten het meeste om te bewaren.

• SLO (service level objective) is een doel dat je jezelf belooft, zoals "99.5 procent van de afrekeningen is binnen twee seconden klaar". Het maakt vage zorg tot een getal dat je kunt volgen.

Waarom een stapel dashboards niet hetzelfde is als observability

Hier is de mening waar leveranciers zich aan ergeren: alle drie de signalen hebben betekent nog niet dat je observability hebt. Staan metrics in de ene tool, logs in een tweede en traces in een derde, dan moet iemand ze om twee uur 's nachts met de hand op één lijn leggen. Dat is het equivalent van drie werkmappen zonder gedeelde ID-kolom.

De toets is simpel. Als er iets onverwachts misgaat, kun je dan een nieuwe vraag aan je data stellen zonder nieuwe code uit te rollen? Als het antwoord is "we moeten logging toevoegen en opnieuw deployen", dan heb je monitoring met extra stappen.

Twee dingen maken in de praktijk het verschil:

• Context bij elke gebeurtenis. Elke logregel draagt een aanvraag-ID, een servicenaam en een versie, zodat je later kunt groeperen en filteren. Het is de ID-kolom die je in elke export had willen zien.

• Detail lang genoeg bewaren. Data met hoge cardinaliteit, zoals gebruikers-ID's en order-ID's, is waar de antwoorden verborgen zitten. Het is ook precies wat de rekening doet stijgen.

De tools die mensen echt gebruiken, en wat elk je kost

Je hoeft niets te kopen om het idee te begrijpen, maar de markt is de moeite van het kennen waard.

OpenTelemetry is de open standaard om telemetrie te maken, geen plek om die op te slaan of te bekijken. Je instrumenteert één keer en stuurt de data naar waar je maar wilt.

Grafana Cloud is gebouwd op open standaarden, met een gratis laag van 10,000 actieve metric-reeksen en elk 50 GB logs, traces en profielen per maand. Je kunt de open-sourcestack ook zelf hosten, al moet je Prometheus, Loki en Tempo dan zelf in elkaar zetten.

Datadog is de kant-en-klare optie: installeer de agent, krijg binnen enkele minuten werkende dashboards en alles op één plek voor infrastructuur, APM en logs. De adder onder het gras is de facturatie. Een prijs per host (rond $15 per host per maand voor alleen infrastructuur) plus aparte kosten voor logs en eigen metrics kan vanaf ongeveer 50 hosts snel oplopen, en er is geen permanente gratis laag.

New Relic zit qua prijs ertussenin: 100 GB dataopname per maand gratis, daarna $0.40 per GB, met één volledige platformgebruiker inbegrepen.

De investering is het waard als je een klein platformteam hebt en geen zin om infrastructuur voor je infrastructuur te draaien. Sla het over als je twee servers en één ontwikkelaar hebt. Een goed logformaat en de formules hierboven brengen je verrassend ver.

Wat je op maandag doet als je geen ingenieur bent

Je komt misschien nooit een trace tegen. Maar het observability-denken past goed bij iedereen die voor zijn werk met getallen rapporteert.

1. Voeg een ID toe aan elke export. Een kolom waarop je kunt joinen verslaat elke slimme formule.

2. Bewaar de ruwe rijen. Plak geen waarden over het detailtabblad heen. Samenvattingen zijn metrics, ruwe rijen zijn logs.

3. Leg vast wat "normaal" is. Een drempel die je nooit hebt gedefinieerd, kan nooit afgaan.

4. Stel de derde vraag. "De omzet daalt" is het alarm. "Waar daalt hij?" is de metric. "Door welke rijen daalt hij?" is observability.

Doe dat, en de volgende rare totaalsom in je sheet kost tien minuten om uit te leggen in plaats van een middag. Goed zo, spreadsheet.

Snelle antwoorden op de vragen die mensen echt intypen

Korte versies van de meest voorkomende vervolgvragen staan in de FAQ hieronder. Als je er maar één onthoudt: observability is geen product dat je koopt. Het is hoe goed de data die je systeem uitstuurt je in staat stelt vragen te beantwoorden die je niet had gepland.