Observability die tijdens een incident echt helpt

Tijdens een incident openen de meesten eerst Grafana. Request rate, p99, CPU, alles groen. En precies daar blijft het team steken.

Groen betekent hier namelijk alleen: gemiddeld is alles oké. Het zegt niets over waar in een keten van vijf services die ene request sterft waar het nu net om gaat. Het aggregaat verslaat het losse geval, en een incident is altijd het losse geval.

Het signaal dat echt helpt is onopvallender. istio_requests_total, uitgesplitst naar source en destination, naar response_code en response_flags. Eén query, en “er hangt iets” wordt “service A naar service B, 503, flag UF”. Precies de flag uit de vorige aflevering, nu niet in de log van één enkele pod, maar zichtbaar over de hele mesh.

Bij meerdere hops komt de trace erbij. De span-keten laat zien op welke hop de latency explodeert of de call afbreekt. Hier zit de valkuil: Istio genereert de spans, het doorgeven van de trace headers is aan de services zelf. Eén service die de header inslikt, en de keten breekt. Dan heb je waterdichte dashboards met een lek precies waar het pijn doet.

Kiali maakt er een plaatje van. De graph toont de rode edge waar de traffic kantelt. Uit drie letters ontstaat een topologie.

Het punt is niet de tool. Prometheus, Kiali en tracing zitten er in de meeste Istio-setups allang bij. Wat ontbreekt is de beslissing welke vraag jullie moeten kunnen beantwoorden als het erop aankomt, en dat het doorgeven van de trace headers voor elke service verplicht is in plaats van optioneel.

Welke signalen we echt nodig hebben als het erop aankomt, en dat elke service de trace headers verplicht doorgeeft: precies dat leg ik in assessments als eerste vast. Niet omdat het dashboard ontbreekt. Omdat het de verkeerde vraag beantwoordt.

Een groen dashboard is geen bewijs dat het draait. Het is een bewijs dat niemand de juiste vraag meet.

Welk signaal verraadde jullie bij het laatste incident echt de stervende hop? En welk groen dashboard zweeg daarbij in alle talen?