Prometheus

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. ...

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? ...

Je kunt niet fixen wat je niet kunt zien. Je kunt niet optimaliseren wat je niet kunt meten. Prometheus is de standaard voor Kubernetes metrics. Het werkt prachtig — totdat je lange-termijn opslag nodig hebt, of meerdere clusters, of hoge beschikbaarheid. Dan loop je tegen de limieten aan. Thanos breidt Prometheus uit zonder het te vervangen. Behoud je bestaande setup, voeg Thanos componenten toe, krijg onbeperkte retentie en globale queries. ...