Vrijdagavond klikt een klant op ‘Betalen’. Het verzoek gaat via nginx, de checkout-API, de inventarisservice in gRPC, Redis, PostgreSQL en vervolgens een asynchrone webhook-taak. Ondersteuning krijgt een “time-out”. API-logboeken tonen upstream time-out; inventarislogboeken, niets abnormaals in volume. Echter, een enkele langzame gRPC-oproep – verdronken in het gemiddelde – verklaart het wachten. Zonder een uniform spoor ziet niemand het.
Zodra een actie twee of meer stenen overschrijdt, raakt de diagnose gefragmenteerd. Gedistribueerde tracering koppelt een trace_id aan het oorspronkelijke verzoek en registreert elk segment (span): duur, service, fout. Je ziet de hele boom, geen geïsoleerde bladeren. De echte vraag: weet jij hoe je de draad die een gebruiker ervaart als een enkele actie moet reconstrueren?
Sporen, logboeken en statistieken: drie pijlers, niet drie vervangers
Prometheus zal een verdubbelde p95 rapporteren op /api/checkout — zie Prometheus: metrics kiezen die traagheid verklaren. De gecentraliseerde logs zullen op een bepaald moment een stacktracering tonen. Noch koppelt de nginx-time-out aan de langzame SQL-query in de catalogus, noch aan de webhook-taak zonder context.
| Pijler | Wat het onthult | Typische limiet |
|---|---|---|
| Statistieken | Trends, waarschuwingen, naleving van SLO's | Aggregeren — een zeldzaam geval verdwijnt in de p95 |
| Logboeken | Tekstcontext, instellingen, fouten | Eén silo per afdeling, handmatige correlatie |
| Sporen | Volledig pad van een query | Opslagkosten bij slechte bemonstering |
Het verwijderen van de sporen betekent dat je moet raden waar het pad brak – het soort blindheid dat alert vermoeidheid voedt.
Span-, trace- en contextvoortplanting
Een trace vertegenwoordigt het volledige traject van een gebruikersactie, bijvoorbeeld checkout-abc123. Een span is een eenheidsbewerking binnen deze reis: een HTTP GET /stock-oproep, een SQL SELECT-query, een Redis-publicatie. Elke periode registreert de duur, de status en de service die deze heeft uitgevoerd.
Contextvoortplanting is de meest voorkomende zwakke schakel. De trace_id moet reizen van de omgekeerde proxy naar de asynchrone werkrollen, via W3C HTTP-headers (traceparent, tracestate), gRPC-metagegevens of de payload van de taak in de wachtrij. Zonder deze overdracht creëert de medewerker een weesspoor dat geen verband houdt met het oorspronkelijke verzoek – en verdwijnt de helft van het verhaal bij de eerste uitgestelde verwerking.
| Onderdeel | Huidige instrumentatie |
|---|---|
| nginx | OpenTelemetry-module of service mesh-ingang |
| PHP/Laravel | open-telemetry/opentelemetry-php bibliotheek |
| Ga/Java | volwassen native kits, eenvoudige integratie |
| Wachtrijmedewerker | extractie van context uit vacaturebericht |
Het instrumenteren van de reverse proxy zonder de applicatie te instrumenteren betekent dat je de input en output ziet – niet wat er daartussen gebeurt.
OpenTelemetry, Jaeger en Tempo: kies je stapel
OpenTelemetry (OTel) verzamelt sporen, statistieken en logboeken met unieke instrumenten. Exporteer naar Jaeger (standalone interface), Grafana Tempo (objectopslag, Loki/Prometheus-correlatie) of een beheerde service. Op een bescheiden VPS vermijdt een OTel Collector-agent van Tempo Cloud of Grafana Cloud het hosten van Jaeger en Elasticsearch zelf.
Bemonstering: traceer niet al het verkeer
Het traceren van elke query in de productie genereert een hoeveelheid gegevens die moeilijk op te slaan en te bevragen is. Twee strategieën domineren.
Hoofdbemonstering beslist over deelname (bijvoorbeeld één zoekopdracht op honderd) — eenvoudig, maar een zeldzaam geval kan aan het net ontsnappen. Staartbemonstering volgt systematisch langzame of dwalende paden; Grafana Tempo blinkt uit op dit model. Configureer deze regels vóór een piekbelasting, niet tijdens het incident.
Correleer logs en traces: sluit de lus
Injecteer de trace_id in uw JSON-logboeken (“trace_id”: “abc123...”`). In Grafana opent een klik vanuit een langzame reeks het logboek met de stacktrace. Incidentprocedure: p95-waarschuwing → langzaamste trace → foutieve SQL-reeks → exacte query in het logboek. Sluit gevoelige gegevens (e-mail, kaart, patiënt-ID) uit van span-attributen.
Veelvoorkomende beperkingen en valkuilen
Omspant te gedetailleerd → overbelasting en onleesbare interface. Klokken niet synchroon → inconsistente structuur (NTP vereist). Istio traceert HTTP tussen peulen, niet uw SQL-query's zonder toepassingsinstrumentatie. “Jaeger geïnstalleerd” ≠ “langzaam afrekenen diagnosticeerbaar”: begin met de routes die cijfers opleveren.
De top: drie dashboards, nul verhalen
Dit is wat ‘waarneembare’ stapels die kant-en-klaar worden verkocht vaak over het hoofd worden gezien.
Beslis en ga vooruit zonder blinde vlek
Maak in één tot twee dagen een multiservice-architectuur diagnosticeerbaar. Identificeer eerst een kritiek pad (afrekenen, inloggen, partner-API) en instrumenteer dit als prioriteit. Implementeer OpenTelemetry op de omgekeerde proxy, toepassing en werkrollen en controleer vervolgens of de context de asynchrone wachtrijen doorloopt. Configureer staartbemonstering om foutieve sporen en sporen boven uw latentiedrempel te behouden. Injecteer de trace_id in de JSON-logboeken en test de span → log-navigatie. Simuleer een opzettelijk langzaam verzoek: als het niet voorkomt in een end-to-end-trace, corrigeer dan de voortplanting vóór het volgende incident.
Vergelijk de hosts waar u uw eigen agents kunt installeren via de overzicht en de vergelijker. Als Prometheus verslechtering vertoont zonder de defecte laag te lokaliseren, lees dan Prometheus: kies statistieken die de traagheid verklaren voordat u een dashboard toevoegt.
Veelgestelde vragen
Traceringen, logboeken of statistieken: wat moet u kiezen?
De drie vullen elkaar aan, geen enkele vervangt de andere. De statistieken worden in de loop van de tijd verzameld en geven waarschuwingen; logs beschrijven een specifiek moment met tekstuele context; traces verbinden segmenten van hetzelfde gebruikersverzoek over meerdere services. Prometheus alleen kan niet zeggen welke SQL-query het afrekenen heeft geblokkeerd; een tracering zal dit in één oogopslag laten zien.
Is OpenTelemetry de standaard die moet worden toegepast?
Ja, het is vandaag de dag de meest duurzame keuze. OpenTelemetry biedt leveranciersneutrale instrumentatie, met exporteurs naar Jaeger, Grafana Tempo, Datadog of andere backends. Vermijd het koppelen van uw applicatie aan één enkele eigen SDK: u zult waarschijnlijk de visualisatietools moeten wijzigen voordat u uw code herschrijft.
Hoe kan ik context tussen services doorgeven?
Gebruik de W3C traceparent- en tracestate-headers vanaf het toegangspunt tot asynchrone werkrollen. Elke hop (reverse proxy, gRPC-oproep, berichtenwachtrij) moet dezelfde trace-ID verzenden. Zonder deze voortplanting creëert elke dienst een geïsoleerd weesspoor en verlies je de helft van het verhaal bij de eerste uitgestelde taak.
Welke bemonstering in de productie?
Voor algemeen verkeer is een head sampling van 1-10% vaak voldoende. Tail sampling – aangeboden door Grafana Tempo – houdt systematisch langzame of foutieve sporen bij, waardoor de opslagkosten en de diagnostische mogelijkheden in evenwicht zijn. Configureer deze regels vóór een piekbelasting, niet tijdens het incident.
De volgende keer dat een incident drie services doorkruist zonder duidelijke dader, stel dan een vraag: kunnen we een enkel verzoek end-to-end volgen? Als het antwoord nee is, zal de ontbrekende trace_id meer kosten dan de instrumentatie ervan.