Som en backend-utvecklare som arbetar med microservices under de senaste åren har en sanning blivit smärtsamt uppenbar: debugging produktionsproblem över distribuerade system kan kännas som detektivarbete i mörkret. Du har tjänster som ringer tjänster, ibland dussintals djupt.En användare klickar på en knapp på användargränssnittet och 15 microservices snurrar in i åtgärden.Om något bryts - eller värre, sakta ner - ta reda på var och varför kan tugga upp timmar. Och om du bygger eller underhåller mikrotjänster år 2024, är OpenTelemetry det verktyg du vill ha i ditt hörn. Vad är observerbarhet egentligen? Observabilitet är mer än bara loggar. Det handlar om att förstå varför ditt system beter sig på ett visst sätt, inte bara vad det gör. Loggar – råhändelser, användbara för debugging. Metrik – Antal som du kan spåra över tid (t.ex. begäran antal, CPU). Spår – End-to-end-förfrågningsflöden över tjänster (även kallad din distribuerade "kallstack"). Traditionella övervakningsverktyg fokuserar mest på mätvärden och loggar, men spårning är den verkliga spelförändraren för microservices. Varför vi valde OpenTelemetry Vi experimenterade med flera observabilitetspåsar – Datadog, New Relic, Prometheus, Jaeger, Zipkin – men de hade alla ett problem: antingen var de leverantörslåsta eller saknade enhetlighet över språk. OpenTelemetry (OTel) kontrollerade alla våra lådor: Öppen källkod, under CNCF Fungerar på flera språk (vi använder Node.js, Go och Python) Leverantörsneutral – export till Grafana, Jaeger, New Relic, etc. Stöds av alla i branschen (bokstavligen: AWS, GCP, Microsoft, etc.) Hur vi använder OpenTelemetry i Node.js Microservices Låt mig gå igenom hur vi faktiskt instrumenterade en riktig tjänst. Låt oss säga att vi har en enkel användartjänst inbyggd i Node.js med hjälp av Express. Det avslöjar en slutpunkt `/användare' som hämtar användardata. Step 1: Install Dependencies npm install @opentelemetry/api \
@opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http
 Vi kommer att exportera spår via OTLP till en lokal Jaeger-instans. Step 2: Create tracing.js to Initialize OpenTelemetry JavaScript: tracing.js const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
const { Resource } = require('@opentelemetry/resources');
const traceExporter = new OTLPTraceExporter({
url: 'http://localhost:4318/v1/traces',
});

const sdk = new NodeSDK({
traceExporter,
instrumentations: [getNodeAutoInstrumentations()],
resource: new Resource({
[SemanticResourceAttributes.SERVICE_NAME]: 'user-service',})
});
sdk.start();
 Step 3: Add It to Your Entry File JavaScript: Index.js

require('./tracing'); // Always load this first

const express = require('express');
const app = express();

app.get('/users', (req, res) => {
 res.json([{ id: 1, name: "Alice" }, { id: 2, name: "Bob" }]);
});

app.listen(3000, () => console.log("User service running on port 3000"));
 Vår tjänst exporterar nu spår. Step 4: Spin Up Jaeger Locally (or Use Grafana Tempo) Så här testar vi lokalt: docker run -d --name jaeger \
 -e COLLECTOR_OTLP_ENABLED=true \
 -p 4318:4318 -p 16686:16686 \
 jaegertracing/all-in-one:latest
 Besök http://localhost:16686 för att se dina spår. Besök För att se dina spår. http://localhost:16686 Chaining spår över tjänster Anta nu att du har en annan tjänst - order-tjänst - som kallar användartjänst. Om båda är instrumenterade med OpenTelemetry får du ett fullständigt spår av användarförfrågan hoppar mellan dem. Och det bästa? OpenTelemetry hanterar spårkontext spridning via HTTP-huvuden automatiskt. Lägga till anpassade intervall för affärslogik Ibland räcker det inte med automatiska verktyg, till exempel om du vill spåra en DB-fråga eller ett externt API-samtal: const { trace } = require('@opentelemetry/api');
const tracer = trace.getTracer('user-service');

app.get('/users', async (req, res) => {
 const span = tracer.startSpan('fetch-user-data');
 try {
  const users = await fetchUsersFromDB();
  res.json(users);
 } catch (err) {
  span.recordException(err);
  throw err;
 } finally {
  span.end();
 }
});
 Detta är super användbart när du vill spåra prestanda av specifik affärslogik. Best Practices We've Learned the Hard Way 1.  Use Semantic Conventions Istället för att uppfinna egna attributnamn, håll dig till OpenTelemetry semantiska konventioner. Dessa gör dina spår lättare att förstå och kompatibla med verktyg som Grafana, Tempo, etc. Exempel på: JavaScript
span.setAttribute("http.method", req.method);
span.setAttribute("http.route", req.path);
 2. Sample Wisely Om du spårar varje enskild begäran, kommer ditt system att drunkna i data. Använd spårprovtagning (t.ex. 10%, eller bara fel). För JavaScript const sdk = new NodeSDK ({
 sampler: new TraceIdRatioBasedSampler (0.1), // 10% sampling
});
 3. Use OpenTelemetry Collector in Production Exportera inte telemetriska data direkt från dina tjänster till din backend. Ruta den genom OpenTelemetry Collector – det ger dig buffring, batchning, retries och formatkonvertering. 4. Don't Log PII in Spans Var super försiktig med att inte lagra användarnamn, e-post, kreditkortsinformation etc. i span attribut eller loggar. Där detta har hjälpt oss mest Debugga latensproblem: Att se fullständiga spår över 4-5 microservices hjälpte oss att identifiera flaskhalsar på några minuter. Identifiera retry stormar: Vi märkte en tjänst som ringde en annan i en loop med retries, något vi inte skulle ha fångat via loggar. Distribution regressioner: Jämför spår från en version till nästa visade oss exakt vad som förändrades. Bonus: Spårning i en flerspråkig stack Vi använder Node.js för vissa tjänster, Go för andra. OpenTelemetry gjorde det enkelt att instrumentera båda och skicka alla data till en enda plats - Jaeger för dev, Grafana Cloud i staging/prod. Ingen leverantörslåsning. Inga missmatchningar i spårformat. Bara ren synlighet. Conclusion: If You're Building Microservices, Start with Observability Microservices ger oss skala och flexibilitet, men de ger också komplexitet. OpenTelemetry har blivit en viktig del av vår arkitektur, inte bara för debugging, utan för att optimera prestanda, tillförlitlighet och i slutändan – användarupplevelsen. Även en grundläggande installation med Jaeger och ett par tjänster kommer att få dig att undra hur du någonsin levde utan det.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Det här ljudet är producerat på berättelsens originalspråk!

Microservices Observability: Utnyttja OpenTelemetry i verkliga system av Gajinder Sharma

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps