# Begrippenlijst observability | Observability Architect > Zesentwintig begrippen uit observability en monitoring, kort uitgelegd: van metrics, traces en logs tot MTTR, SLO en alert fatigue. Met een link per begrip. https://observability-architect.nl/begrippen/ · Dutch Observability heeft zijn eigen woorden, en de meeste zijn Engels. Hieronder staan de begrippen die in onze gesprekken het vaakst voorbijkomen, elk in twee of drie zinnen. Elk begrip heeft een eigen adres, zodat u ernaar kunt verwijzen. ## Observability Het vermogen om uit de signalen die een systeem naar buiten geeft af te leiden wat er binnenin gebeurt, ook bij vragen die vooraf niet gesteld zijn. Waar monitoring bekende fouten bewaakt, maakt observability onbekende problemen onderzoekbaar. Meer hierover: https://observability-architect.nl/#kennisbank ## Monitoring Het bewaken van vooraf gekozen metingen tegen vooraf gekozen drempels, met een melding zodra een drempel wordt overschreden. Onmisbaar voor bekende faalwijzen, blind voor nieuwe. ## Telemetrie Verzamelnaam voor de data die een systeem over zichzelf uitstuurt: metrics, traces en logs. Goede telemetrie is gestructureerd, gecorreleerd en vrij van persoonsgegevens. ## Metrics Numerieke metingen in de tijd, zoals verzoeken per seconde, foutpercentage of geheugengebruik. Goedkoop op te slaan en ideaal voor trends en alerts, maar zonder de context van één individueel verzoek. ## Traces De reis van één verzoek door alle onderdelen van een systeem, opgebouwd uit spans. Een trace laat zien waar tijd verloren gaat en welk onderdeel een fout veroorzaakte. ## Span Eén stap binnen een trace: een bewerking met begin, einde, status en attributen. Spans die naar elkaar verwijzen vormen samen de boom van een verzoek. ## Logs Tijdgestempelde gebeurtenissen met vrije tekst of gestructureerde velden. Gestructureerde logs, met een vaste set velden en zonder gevoelige data, zijn doorzoekbaar en correleerbaar; vrije tekst is dat zelden. ## Correlatie Het koppelen van metrics, traces en logs aan hetzelfde verzoek, dezelfde release of dezelfde sessie, meestal via een gedeeld identificatienummer. Zonder correlatie blijven het drie losse verhalen. ## MTTR Mean Time To Recovery: de gemiddelde tijd tussen het ontstaan van een incident en het herstel. De belangrijkste maat voor wat observability oplevert, want context bij een melding verkort het zoeken. Meer hierover: https://observability-architect.nl/#resultaten ## MTTD Mean Time To Detect: de gemiddelde tijd tussen het ontstaan van een probleem en het moment dat iemand het weet. Fouten die netjes worden afgehandeld hebben vaak een onzichtbaar hoge MTTD. Meer hierover: https://observability-architect.nl/cases/belderbrandt/ ## SLI Service Level Indicator: een concrete meting van een aspect van de dienstverlening, zoals het percentage geslaagde boekingen of de laadtijd die 95 procent van de bezoekers haalt. ## SLO Service Level Objective: het doel dat u voor een SLI stelt, bijvoorbeeld 99,5 procent geslaagde verzoeken per maand. Een SLO is een interne afspraak die bepaalt wanneer een melding de moeite waard is. ## SLA Service Level Agreement: een contractuele belofte aan een klant, met gevolgen als die niet gehaald wordt. Een SLA hoort ruimer te zijn dan de SLO die erachter ligt. ## Error budget De ruimte tussen 100 procent en uw SLO: de hoeveelheid falen die u zich per periode kunt veroorloven. Zolang er budget is, mag een team risico nemen; is het op, dan gaat betrouwbaarheid voor. ## Alert fatigue Het afstompen van een team door te veel of te weinig relevante meldingen, waardoor de echte melding wordt gemist. Het antwoord is minder meldingen met meer context, niet meer meldingen. Meer hierover: https://observability-architect.nl/#resultaten ## Golden signals De vier metingen die voor vrijwel elke dienst de kern vormen: latency, verkeer, fouten en verzadiging. Een goed startpunt voor wat u minimaal moet meten. ## APM Application Performance Monitoring: tooling die de prestaties en fouten van applicaties volgt, vaak met automatische instrumentatie. APM is een onderdeel van observability, niet het geheel. Meer hierover: https://observability-architect.nl/#faq-apm ## RUM Real User Monitoring: metingen uit de browsers van echte bezoekers, zoals de laadtijd die zij werkelijk ervaren. Het tegenwicht van labmetingen, die een apparaat en netwerk simuleren. Meer hierover: https://observability-architect.nl/cases/belderbrandt/ ## Synthetische monitoring Geautomatiseerde controles die op vaste tijden een pagina of API aanroepen en het resultaat toetsen. Zien een storing ook als er geen bezoeker is, maar veroorzaken zelf verkeer bij de systemen die ze testen. ## Sampling Het bewaren van een deel van de telemetrie in plaats van alles, om kosten te beperken. Bij laag volume gooit sampling vooral bewijs weg; pas het toe op basis van gemeten volume, niet uit gewoonte. ## Cardinaliteit Het aantal unieke waarden van een label of attribuut, zoals gebruikers-id's of URL's. Hoge cardinaliteit maakt metrics duur en traag; traces en logs kunnen er beter mee om. ## Runbook Een stapsgewijze handleiding voor een bekend incident: wat te controleren, wat te doen, wie te bellen. Een melding zonder runbook verplaatst het probleem naar wie toevallig dienst heeft. ## Postmortem De schuldvrije analyse na een incident: wat gebeurde er, waarom, en welke verandering voorkomt herhaling. De bron van de beste verbeteringen aan observability. ## Performance budget Een vaste grens voor laadtijd, paginagewicht of scripttijd die een wijziging niet mag overschrijden, gecontroleerd in de pipeline. Werkt als veranderingsdetector; de echte kwaliteitsmaat komt uit metingen bij bezoekers. Meer hierover: https://observability-architect.nl/cases/belderbrandt/ ## Core Web Vitals De drie door Google gedefinieerde maten voor de gebruikerservaring van een webpagina: laadsnelheid van het grootste element, reactietijd op interactie en visuele stabiliteit. Ze wegen mee in de zoekresultaten. ## Capaciteitsplanning Het voorspellen van de belasting die een systeem aankan en de groei die eraan komt, op basis van gemeten verzadiging en stress testing. Voorkomt dat piekverkeer, zoals een verkoopactie, tot uitval leidt. Meer hierover: https://observability-architect.nl/#service-performance ## Klaar om helder te zien? Plan een gratis strategiegesprek. Wij analyseren uw situatie en adviseren vrijblijvend. - Gesprek inplannen: https://calendly.com/patrick-pdict/30min - Stuur een mail: patrick@pdict.eu