Observability

Je hebt Grafana. Je hebt Prometheus metrics. Je hebt logs in Loki en traces in Tempo. Je hebt ook 47 dashboards waar niemand naar kijkt. Dashboard rot is echt. Teams maken dashboards voor elke mogelijke metric, elke service, elk potentieel probleem. Zes maanden later weet niemand meer wat de helft ervan toont of waarom ze bestaan. Goede dashboards zijn anders. Ze worden dagelijks geopend. Ze beantwoorden vragen voor je ze stelt. Ze helpen je je systeem te begrijpen, niet alleen nummers te tonen. ...

Je telefoon trilt om 3 uur ’s nachts. Je checkt slaperig: “High CPU usage on node-worker-3.” Je kijkt naar de grafiek, ziet dat hij 10 minuten op 75% staat, en gaat weer slapen. Morgen, dezelfde alert. Volgende week check je niet meer. Dit is alert fatigue, en het is gevaarlijk. Als alles alert, doet niets het. Echte incidenten verdwijnen in de ruis. Ik ben aan beide kanten geweest — verdrinken in alerts, en systemen draaien waar pages zeldzaam zijn en altijd actionable. Het verschil is niet betere tools. Het is beter nadenken over wat aandacht verdient. ...

Je hebt metrics die je vertellen dat iets traag is. Je hebt logs die vertellen dat er errors waren. Maar welke request faalde? Waar kwam de latency vandaan? Welke service in de keten veroorzaakte de timeout? Dit is waar distributed tracing om de hoek komt kijken. Het volgt individuele requests terwijl ze door je microservices stromen, en toont je precies wat er gebeurde en waar. De Observability Driehoek flowchart TD subgraph observability["Complete Observability"] M["Metrics<br/>(Prometheus/Thanos)<br/>WAT gebeurt er"] L["Logs<br/>(Loki)<br/>WAAROM gebeurde het"] T["Traces<br/>(Tempo)<br/>WAAR gebeurde het"] end M <--> L L <--> T T <--> M G["Grafana"] --> M G --> L G --> T Metrics beantwoorden: “Wat is de error rate? Wat is de latency?” Logs beantwoorden: “Welke error message? Wat was de context?” Traces beantwoorden: “Welke service? Welke call? Wat was het pad?” Samen geven ze je volledig begrip. ...

Je hebt Prometheus voor metrics. Je kunt zien wat er gebeurt in je clusters. Maar als iets kapotgaat, vertellen metrics je dat er iets mis is — logs vertellen je waarom. Het traditionele antwoord is Elasticsearch. Het is krachtig, flexibel, en… duur. Het indexeert alles, wat betekent dat je betaalt voor elke byte aan logdata in CPU, geheugen en opslag. Loki kiest een andere aanpak: indexeer labels, niet content. Het is dezelfde filosofie die Prometheus efficiënt maakt voor metrics, toegepast op logs. ...

In mijn vorige post over Prometheus en Thanos behandelde ik de sidecar architectuur — Thanos Sidecar draait naast Prometheus, uploadt TSDB blocks naar object storage, en stelt data beschikbaar aan de Querier. Het werkt uitstekend voor clusters met stabiele connectiviteit naar je centrale infrastructuur. Maar wat als je clusters aan de edge staan? Als ze uren of dagen connectiviteit kunnen verliezen? Als je tientallen of honderden kleine clusters draait en geen sidecar complexiteit op elk daarvan wilt? ...