Första gÄngen du verkligen behöver observerbarhet Àr inte nÀr du lugnt tittar pÄ en instrumentpanel. Det Àr nÀr en anvÀndare skriver "utcheckningen Àr lÄngsam", feldiagrammet ser normalt ut och i loggarna hittar du bara en rad med frÄnkopplade meddelanden.
OpenTelemetry skapades för att undvika det ögonblicket: inte för att ha mer grafik, utan för att koppla ihop bitarna. En begÀran gÄr in i API, anropar en databas, gÄr via en extern leverantör, lÀgger upp ett köat jobb och misslyckas kanske tre tjÀnster senare. Utan distribuerad spÄrning rekonstruerar du den historien för hand. Med OpenTelemetry har du Ätminstone en karta.
PoÀngen Àr inte trace, det Àr historien
En trace Àr en sekvens av span. Satt sÄ lÄter det kallt. I praktiken Àr varje span en del av berÀttelsen: POST /checkout, SELECT inventory, call payment provider, publish order.created.
VÀrdet kommer nÀr du börjar svara pÄ riktiga frÄgor:
- vilken extern tjÀnst saktar ner?
- kommer felen frĂ„n en specifik version? â drabbar problemet alla eller bara en hyresgĂ€st?
- döljer ett nytt försök en timeout?
- det asynkrona jobbet börjar men dör sedan nÄgon annanstans?
Dessa frÄgor kan inte lösas genom att en console.log kastas i en hast. Faktum Àr att ofta loggen som lÀggs till i en nödsituation hjÀlper dig idag och blir till buller i morgon.
Hur skulle jag lÀgga detta i en app Node.js
Den hÀlsosammaste installationen Àr enkel: appen producerar telemetri, Collector bestÀmmer vart den ska skickas.
Node.js app -> OpenTelemetry Collector -> backend di observability
Varför inte exportera direkt till leverantören? För till en början verkar det snabbare, sedan inser du att varje tjÀnst har olika konfigurationer, olika försök, olika filter och ingen central punkt för att ta bort kÀnslig data eller byta destination.
Collector Àr trÄkigt pÄ alla de rÀtta sÀtten. Den tar emot OTLP, gör batchning, kan filtrera, kan göra sampling, kan lÀgga till vanliga attribut och kan exportera till flera system.
SjÀlvinstrumentering: bra, men inte tillrÀckligt
I Node.js skulle jag börja med autoinstrumentering. Det ger dig omedelbar insyn i HTTP, ramverk som stöds, databaser och vanliga bibliotek.
npm install @opentelemetry/sdk-node \ @opentelemetry/auto-instrumentations-node \ @opentelemetry/exporter-trace-otlp-http
Sedan initierar du SDK före resten av appen:
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();
Detta ser dock ramverket, inte din produkt. Den vet att du gjorde en frÄga, men den vet inte att frÄgan var i "skapa ordning" eller "förnya prenumeration". För det behöver du span manualer pÄ de punkter dÀr dominans rÀknas.
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(); }
Jag skulle inte lÀgga span manualer nÄgonstans. Jag skulle lÀgga dem dÀr jag klockan tre pÄ morgonen skulle vilja förstÄ vad som hÀnde utan att lÀsa halva kodbasen.
Tre regler som undviker mycket kaos
Första regeln: varje tjÀnst mÄste ha service.name, miljö och version. Det verkar trivialt, men utan dessa attribut Àr en trace mycket mindre anvÀndbar. NÀr en distribution bryter nÄgot vill du filtrera efter version pÄ tvÄ sekunder.
Andra regeln: lÀgg inte kÀnslig information i attributen. E-postmeddelanden, tokens, heltalsnyttolaster och adresser bör inte hamna i en observerbar backend av misstag. Om du behöver identifiera en anvÀndare, övervÀg interna ID:n, hashing eller mindre kÀnsliga fÀlt.
Tredje regeln: var uppmÀrksam pÄ kardinalitet. user.id som ett attribut för trace kan vara vettigt. Som en metrisk etikett kan den förstöra dina kostnader och prestanda.
MÀtvÀrden: fÄ, men bra
Jag skulle börja med mycket praktiska mÄtt:
- antal, fel och varaktighet för förfrÄgningar.
- latens för externa beroenden;
- antal timeouts och omförsök;
- djupet pÄ svansarna;
- jobbets varaktighet;
- procentandel av fel per version.
Resten tillsÀtts vid behov. Instrumentpaneler fulla av grafer som ingen tittar pÄ Àr möbler, inte observerbarhet.
Loggar: Fortfarande anvÀndbara, men lÀnkade
Loggar försvinner inte. De blir helt enkelt mycket mer anvÀndbara nÀr de bÀr trace_id och span_id. SÄ du kan börja frÄn en fellogg och öppna trace, eller börja frÄn en lÄngsam trace och bara lÀsa loggarna som skapas i den sökvÀgen.
Utan korrelation letar du efter nÄlar. Med korrelation vet du Ätminstone vilken lÄda du ska titta i.
Checklistan jag skulle anvÀnda innan jag sa "vi Àr tÀckta"
- trace korsar faktiskt flera tjÀnster.
- Loggar inkluderar
trace_idochspan_id. - Collector Àr konfigurerad med batch- och minnesgrÀnser.
- Fel registreras i span. â Det finns en provtagningspolicy. â MĂ€tvĂ€rden har kontrollerat kardinalitet.
- KĂ€nsliga data filtreras.
- Varningar utgÄr frÄn anvÀndarsymptom, inte slumpmÀssiga grafer.
Slutsats
OpenTelemetry löser inte produktionsproblem pÄ egen hand. Men sÀttet du hanterar dem förÀndras. IstÀllet för att blint lÀgga till loggar börjar du följa den faktiska sökvÀgen för en begÀran.
För mig Àr tecknet pÄ att det fungerar enkelt: nÀr nÄgot hÀnder slutar teamet att frÄga "var letar vi?" och börjar frÄga "varför Àr den biten lÄngsam?". Det Àr dÀr observerbarhet blir ett verktyg, inte en samling instrumentpaneler.