Het dashboard is groen en toch klagen klanten dat de kassa niet werkt. Als u in deze positie heeft gezeten, begrijpt u het verschil al tussen monitoring en waarneembaarheid. Uw monitoring controleerde alleen wat u dacht te controleren, en deze mislukking is iets nieuws.

Deze gids legt beide ideeën uit zonder de marketingtaal, en volgt één fictief incident, van waarschuwing tot hoofdoorzaak. De logboeken, traceringen en cijfers zijn bedacht om het proces te illustreren. U moet ook weten dat verkopers en praktijkmensen deze grens verschillend trekken, en sommigen beschouwen het gedeeltelijk als een marketingonderscheid. Wij concentreren ons op het praktische gedeelte.

Het korte antwoord

Monitoring is een activiteit. U bepaalt vooraf waar u naar kijkt, zoals CPU, foutenpercentage of schijfruimte, en u stelt drempels in die waarschuwingen activeren. Het antwoordt: “Is datgene waar ik me zorgen over maakte?”

Waarneembaarheid is een eigenschap van uw systeem. De term komt uit de controletheorie, waar hij beschrijft hoe goed je de interne toestand van een systeem kunt afleiden uit de externe outputs. In de praktijk antwoordt het: “Wat gebeurt er en waarom, ook bij problemen die ik nooit had verwacht?”

Denk aan een auto. De waarschuwingslampjes op het dashboard houden toezicht. Ze behandelen een reeks bekende problemen. De volledige diagnosepoort van een monteur, waarmee iemand nieuwe vragen kan stellen over welk onderdeel van de motor dan ook, is dichter bij de waarneembaarheid.

Monitoring versus waarneembaarheid naast elkaar

Dit is geen keuze tussen de twee. Je hebt nog steeds waarschuwingen nodig die je vertellen wanneer je moet kijken.

Waarom monitoren alleen niet genoeg is

Met één applicatie op één server is de lijst met dingen die fout kunnen gaan vrij kort, zodat je ze allemaal kunt bekijken. Een modern systeem kan tientallen services, wachtrijen en API’s van derden bevatten, plus containers die komen en gaan. Storingen worden combinaties die niemand had voorspeld: één regio, één klanttype, een specifieke appversie en één enkele langzame afhankelijkheid.

Je kunt niet vooraf een dashboard schrijven voor een vraag waar je niet aan hebt gedacht. Je hebt gegevens nodig waarmee je deze achteraf kunt opvragen.

Logboeken, statistieken en sporen

Deze drie soorten telemetrie worden vaak de pijlers van waarneembaarheid genoemd. Ieder beantwoordt een andere vraag:

Statistieken

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Metrieken zijn goedkoop op te slaan en snel op te vragen, waardoor ze ideaal zijn voor dashboards en waarschuwingen. Wees in veel metrische systemen op uw hoede voor labels met een hoge kardinaliteit, zoals een gebruikers-ID, omdat deze de kosten sterk kunnen verhogen.

Sporen

Een tracering volgt één verzoek voor verschillende services. Elke stap is een reeks met een starttijd en een duur:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Een trace maakt een langzame stap duidelijk, wat erg moeilijk te zien is in afzonderlijke logboeken van afzonderlijke services.

Logboeken

Logboeken geven de details van wat er op een bepaald moment is gebeurd. We bekijken hoe we ze in een oogwenk nuttig kunnen maken.

Een incidentoverzicht

Hier ziet u hoe de stukken in elkaar passen, in een fictief voorbeeld.

Monitoring behandelde stap 1. Alles daarna was waarneembaarheid. Merk op hoe elke vraag voortkwam uit het vorige antwoord. Niemand had van tevoren een dashboard kunnen bouwen voor “query van coupons voor mobiele apps uit de campagne van vandaag”. Voor de oplossing zelf laat onze gids voor SQL-queryoptimalisatie zien hoe u een dergelijk plan moet lezen.

Betere logboeken

Logboeken met platte tekst zijn gemaakt voor het menselijk oog en moeilijk te doorzoeken. Gestructureerde logboeken gebruiken velden waarop een machine kan filteren:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Met het tweede formulier kun je direct de vraag stellen ‘hoeveel storingen per aanbieder in het afgelopen uur?’ Het veld trace_id is vooral waardevol, omdat het een logregel koppelt aan het hele verzoek, voor elke dienst die ermee in aanraking komt.

Registreer nooit wachtwoorden, tokens of kaartnummers en ga voorzichtig om met persoonlijke gegevens. Zoals onze gids uitlegt, kunnen JWT’s worden hergebruikt door iedereen die ze uit een logbestand leest.

De gouden signalen

Weet u niet zeker wat u moet controleren? Het Site Reliability Engineering-boek van Google suggereert vier signalen voor gebruikersgerichte systemen:

Gebruik percentielen voor de latentie, omdat gemiddelden langzame verzoeken verbergen, zoals we hebben laten zien in belastingstests versus stresstests.

Waarschuwt mensen vertrouwen

Als waarschuwingen de hele tijd worden geactiveerd, stoppen mensen met het lezen ervan. Goede degenen volgen een paar regels:

• Waarschuwing bij symptomen die gebruikers ervaren. ‘Checkout-fouten boven 2%’ verslaat ‘CPU op 85%’. Een hoge CPU die niemand schaadt, mag niemand wakker maken.
• Maak elke melding actiegericht. Als niemand iets hoeft te doen, maak er dan een dashboarditem van of verwijder het.
• Link naar een runbook. Vertel de responder waar hij moet zoeken en wat hij moet proberen.
• Bekijk ze regelmatig. Verwijder of corrigeer eventuele waarschuwingen die de afgelopen maand zijn genegeerd.

Serviceniveaudoelstellingen

Een SLO maakt van “de site moet snel en betrouwbaar zijn” een meetbaar doel, zoals “99,9% van de betaalverzoeken slaagt binnen 30 dagen”. Dat zorgt voor ongeveer 0,1% van de mislukkingen, ook wel een error budget genoemd. Als u nog voldoende over heeft, kunt u sneller verzenden en als deze bijna op is, kunt u prioriteit geven aan betrouwbaarheid. Het is een handige manier om argumenten tussen leveringssnelheid en stabiliteit op te lossen.

OpenTelemetrie en hulpmiddelen

OpenTelemetry is een open source, leveranciersneutrale standaard voor het genereren en exporteren van telemetrie. Het is een project van de Cloud Native Computing Foundation. Als u ermee instrumenteert, kunt u uw backend later wijzigen zonder uw code te herschrijven. Het is zelf geen opslag- of dashboardproduct, dus je koppelt het aan één:

Controleer zelf de huidige kenmerken en prijzen, aangezien deze producten vaak veranderen. De kosten kunnen snel stijgen met het datavolume, dus gebruik steekproeven en stel bewaarlimieten in.

Hoe u aan de slag kunt gaan

1. Begin met de gouden signalen voor uw belangrijkste dienst.
2. Voeg een of twee waarschuwingen toe over symptomen die gebruikers opmerken.
3. Schakel over naar gestructureerde logboeken met een verzoek-ID op elke regel.
4. Voeg tracering toe aan uw hoofdgebruikerstraject met OpenTelemetry, omdat automatische instrumentatie veel voorkomende raamwerken kan omvatten.
5. Koppel implementaties aan uw grafieken zodat u kunt zien of een release uit uw CI/CD-pijplijn een verandering heeft veroorzaakt.
6. Leer van elk incident. Vraag na elk incident welke gegevens het sneller hadden kunnen oplossen, en voeg die toe.

Een klein team met één dienst heeft geen enorm platform nodig. Basisstatistieken, goede logboeken en een paar waarschuwingen kunnen voldoende zijn. Tracering verdient zijn geld naarmate het aantal diensten groeit.

Veel voorkomende fouten

• Een tool kopen en deze waarneembaarheid noemen. De waarde komt voort uit goede instrumenten en de manier waarop je de gegevens gebruikt.
• Behandel drie pijlers als een checklist. Afzonderlijke gegevens zonder enige mogelijkheid om deze aan elkaar te koppelen, zorgen ervoor dat je door tabbladen moet zoeken. Gedeelde ID’s zijn belangrijk.
• Alles verzamelen. Ongefilterde telemetrie wordt duur en zorgt voor ruis.
• Te veel dashboards. Een paar vertrouwde weergaven verslaan de honderd die niemand opent.
• Ik denk dat het testen vervangt. Je hebt nog steeds tests nodig voordat je het uitbrengt. Canarische releases passen echter goed bij deze signalen.

Tot slot

Monitoring vertelt u dat er iets mis is gegaan, en observatie geeft u de middelen om erachter te komen waarom. De praktische test is eenvoudig: als er een onbekend probleem optreedt, kunt u dan de oorzaak vinden zonder een nieuwe code te verzenden? De volgende keer dat u bij een incident betrokken raakt, noteert u elke vraag die u niet kon beantwoorden. Die lijst is je routekaart.

Veelgestelde vragen

Blijf leren