OpenTelemetry in productie: stop met foutopsporing in het donker

De eerste keer dat je echt waarneembaarheid nodig hebt, is niet wanneer je rustig naar een dashboard kijkt. Het is wanneer een gebruiker schrijft: "afrekenen is traag", de foutgrafiek ziet er normaal uit en in de logs vindt u alleen een rij met niet-verbonden berichten.

OpenTelemetry is gemaakt om dat moment te vermijden: niet om meer graphics te hebben, maar om de stukken met elkaar te verbinden. Een verzoek komt binnen in de API, roept een database aan, gaat via een externe provider, plaatst een taak in de wachtrij en mislukt misschien drie services later. Zonder gedistribueerde tracering reconstrueer je dat verhaal met de hand. Met OpenTelemetry heb je tenminste een kaart.

Het punt is niet de trace, het is het verhaal

Een trace is een reeks van span. Zo gezegd, het klinkt koud. In de praktijk is elke span een stukje van het verhaal: POST /checkout, SELECT inventory, call payment provider, publish order.created.

De waarde komt wanneer je echte vragen begint te beantwoorden:

welke externe dienst vertraagt?
komen de fouten uit een specifieke versie?
treft het probleem iedereen of slechts één huurder?
Verbergt een nieuwe poging een time-out?
de asynchrone taak start maar vervolgens ergens anders doodgaat?

Deze vragen kunnen niet worden opgelost door haastig een console.log te gooien. Vaak helpt het logboek dat in een noodgeval wordt toegevoegd u vandaag en wordt het morgen lawaai.

Hoe zou ik dit in een app plaatsen Node.js

De gezondste opzet is simpel: de app produceert telemetrie, de Collector beslist waar deze naartoe wordt gestuurd.

Node.js app -> OpenTelemetry Collector -> backend di observability

Waarom exporteert u niet rechtstreeks naar de leverancier? Omdat het in eerste instantie sneller lijkt, realiseer je je dat elke service verschillende configuraties, verschillende nieuwe pogingen, verschillende filters en geen centraal punt heeft om gevoelige gegevens te verwijderen of de bestemming te wijzigen.

De Collector is op de juiste manier saai. Het ontvangt OTLP, voert batchverwerking uit, kan filteren, kan monsters nemen, kan gemeenschappelijke attributen toevoegen en kan naar meerdere systemen exporteren.

Zelfinstrumentatie: goed, maar niet genoeg

In Node.js zou ik beginnen met automatische instrumentatie. Het geeft u direct inzicht in HTTP, ondersteunde frameworks, databases en algemene bibliotheken.

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

Vervolgens initialiseert u de SDK vóór de rest van de app:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Dit ziet echter het raamwerk, niet uw product. Het weet dat u een zoekopdracht hebt uitgevoerd, maar weet niet dat de zoekopdracht in de volgorde 'Aanmaakvolgorde' of 'Abonnement verlengen' stond. Daarvoor heb je span handleidingen nodig op de punten waar dominantie telt.

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

Ik zou nergens span handleidingen neerleggen. Ik zou ze ergens neerleggen, om drie uur 's ochtends, ik zou graag willen begrijpen wat er gebeurde zonder de helft van de codebasis te lezen.

Drie regels die veel chaos voorkomen

Eerste regel: elke service moet service.name, omgeving en versie hebben. Het lijkt triviaal, maar zonder deze attributen is een trace veel minder nuttig. Wanneer een implementatie iets kapot maakt, wil je binnen twee seconden op versie filteren.

Tweede regel: plaats geen gevoelige gegevens in de attributen. E-mails, tokens, integer-payloads en adressen mogen niet per ongeluk in een observatie-backend terechtkomen. Als u een gebruiker wilt identificeren, overweeg dan interne ID's, hashing of minder gevoelige velden.

Derde regel: let op kardinaliteit. user.id als attribuut van trace kan zinvol zijn. Als metrisch label kan het uw kosten en prestaties vernietigen.

Statistieken: weinig, maar goed

Ik zou beginnen met zeer praktische statistieken:

tarieven, fouten en duur van verzoeken;
latentie van externe afhankelijkheden;
aantal time-outs en nieuwe pogingen;
diepte van de staarten;
duur van de baan;
percentage fouten per versie.

De rest wordt toegevoegd wanneer dat nodig is. Dashboards vol grafieken waar niemand naar kijkt, zijn meubels, geen waarneembaarheid.

Logboeken: nog steeds nuttig, maar gekoppeld

Logboeken verdwijnen niet. Ze worden gewoon veel nuttiger als ze trace_id en span_id bij zich hebben. U kunt dus beginnen vanuit een foutenlogboek en de trace openen, of beginnen vanaf een langzame trace en alleen de logboeken lezen die in dat pad zijn geproduceerd.

Zonder correlatie ben je op zoek naar naalden. Met correlatie weet je tenminste in welke lade je moet kijken.

De checklist die ik zou gebruiken voordat ik zeg "we zijn gedekt"

De trace kruisen feitelijk meerdere services.
Logboeken bevatten trace_id en span_id.
De Collector is geconfigureerd met batch- en geheugenlimieten.
Fouten worden vastgelegd in span.
Er is een bemonsteringsbeleid.
Metrieken hebben een gecontroleerde kardinaliteit.
Gevoelige gegevens worden gefilterd.
Waarschuwingen starten op basis van gebruikerssymptomen, niet op willekeurige grafieken.

Conclusie

OpenTelemetry lost productieproblemen niet alleen op. Maar de manier waarop je ermee omgaat, verandert. In plaats van blindelings logboeken toe te voegen, begint u het daadwerkelijke pad van een verzoek te volgen.

Voor mij is het teken dat het werkt eenvoudig: als er iets gebeurt, stopt het team met de vraag "waar kijken we naar?" en begint te vragen "waarom is dat stuk traag?". Dat is waar waarneembaarheid een hulpmiddel wordt, en niet een verzameling dashboards.

Bronnen