Come sviluppatore di backend che lavora con i microservizi negli ultimi anni, una verità è diventata dolorosamente ovvia: il debugging dei problemi di produzione in sistemi distribuiti può sembrare un lavoro di detective nel buio. Hai servizi che chiamano servizi, a volte dozzine di profondità. Un utente fa clic su un pulsante sull'interfaccia utente e 15 microservizi girano in azione. Se qualcosa si rompe - o peggio, solo rallenta - scoprendo dove e perché può masticare ore. E se stai costruendo o mantenendo microservizi nel 2024, OpenTelemetry è lo strumento che desideri nel tuo angolo. Che cos’è l’osservazione, davvero? L'osservabilità è più di un semplice log. Si tratta di capire perché il sistema si comporta in un certo modo, non solo ciò che sta facendo. Log – Eventi crudi, utili per il debugging. Metrica – Numeri che si possono tracciare nel tempo (ad es. numero di richieste, CPU). Traces – flussi di richieste end-to-end tra i servizi (chiamati anche "stack di chiamata" distribuiti). Gli strumenti di monitoraggio tradizionali si concentrano principalmente su metriche e log, ma il tracciamento è il vero cambiatore di gioco per i microservizi. Perché abbiamo scelto OpenTelemetry Abbiamo sperimentato con diversi stack di osservabilità - Datadog, New Relic, Prometheus, Jaeger, Zipkin - ma tutti avevano un problema: o erano bloccati dal fornitore o mancavano di coerenza in tutte le lingue. OpenTelemetry (OTel) ha controllato tutte le nostre caselle: Open-source, sotto CNCF Funziona in tutte le lingue (utilizziamo Node.js, Go e Python) Venditore neutrale – esportazione a Grafana, Jaeger, New Relic, ecc. Supporto di tutti nel settore (letteralmente: AWS, GCP, Microsoft, ecc.) Come usare OpenTelemetry in Node.js Microservices Lasciatemi passeggiare attraverso come abbiamo effettivamente strumentalizzato un servizio reale. Supponiamo di avere un semplice servizio utente costruito in Node.js utilizzando Express. Espone un endpoint `/users' che raccoglie i dati utente. Step 1: Install Dependencies npm install @opentelemetry/api \
@opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http
 Esporteremo tracce tramite OTLP a un'istanza Jaeger locale. 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"));
 Il nostro servizio sta ora esportando tracce. Step 4: Spin Up Jaeger Locally (or Use Grafana Tempo) Ecco come testare localmente: docker run -d --name jaeger \
 -e COLLECTOR_OTLP_ENABLED=true \
 -p 4318:4318 -p 16686:16686 \
 jaegertracing/all-in-one:latest
 Visita http://localhost:16686 per visualizzare le tue tracce. Visita Per vedere le tue tracce. http://localhost:16686 La catena di tracce attraverso i servizi Ora diciamo che hai un altro servizio - ordine-servizio - che chiama servizio utente. Se entrambi sono strumentalizzati con OpenTelemetry, otterrai una traccia completa della richiesta dell'utente saltando tra di loro. E la parte migliore? OpenTelemetry gestisce automaticamente la propagazione del contesto di traccia tramite gli intestazioni HTTP. Non è necessario passare manualmente gli ID di traccia tra i servizi. Aggiungere spazi personalizzati per la logica aziendale Ad esempio, se si desidera tracciare una query DB o una chiamata API esterna: 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();
 }
});
 Questo è super utile quando si desidera tenere traccia delle prestazioni di una logica aziendale specifica. Best Practices We've Learned the Hard Way 1.  Use Semantic Conventions Invece di inventare i propri nomi di attributi, segui le convenzioni semantiche di OpenTelemetry.Queste rendono le tue tracce più facili da capire e compatibili con strumenti come Grafana, Tempo, ecc. Esempio di: JavaScript
span.setAttribute("http.method", req.method);
span.setAttribute("http.route", req.path);
 2. Sample Wisely Se tracci ogni singola richiesta, il tuo sistema si annegherà nei dati.Utilizza il campionamento di traccia (ad esempio il 10% o solo gli errori). di JavaScript const sdk = new NodeSDK ({
 sampler: new TraceIdRatioBasedSampler (0.1), // 10% sampling
});
 3. Use OpenTelemetry Collector in Production Non esportare i dati di telemetria direttamente dai tuoi servizi al tuo backend. Route attraverso l'OpenTelemetry Collector - ti dà buffering, batch, retries e conversione di formato. 4. Don't Log PII in Spans Siate molto attenti a non memorizzare nomi utente, email, informazioni sulla carta di credito, ecc. in attributi o log di span. Dove questo ci ha aiutato di più Debugging problemi di latenza: Vedere tracce complete su 4-5 microservizi ci ha aiutato a identificare le lacune in bottiglia in pochi minuti. Identificazione delle tempeste di retry: abbiamo notato un servizio che chiamava un altro in un ciclo con retries, qualcosa che non avremmo catturato attraverso i log. Regressioni di distribuzione: confrontando tracce da una versione alla prossima ci ha mostrato esattamente cosa è cambiato. Bonus: tracciamento in una pila multilingue Stiamo usando Node.js per alcuni servizi, Go per altri. OpenTelemetry ha reso facile strumentalizzare entrambi e inviare tutti i dati in un unico luogo - Jaeger per dev, Grafana Cloud in staging/prod. Nessun vendor lock-in. nessun mismatch nei formati di traccia. Solo visibilità pura. Conclusion: If You're Building Microservices, Start with Observability I microservizi ci danno scala e flessibilità, ma portano anche complessità. OpenTelemetry è diventata una parte fondamentale della nostra architettura, non solo per il debugging, ma per ottimizzare le prestazioni, l’affidabilità e, in ultima analisi, l’esperienza utente. Anche una configurazione di base con Jaeger e un paio di servizi vi farà chiedersi come avete mai vissuto senza di esso.

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

Questo audio è prodotto nella lingua originale della storia!

Microservices Observability: sfruttando OpenTelemetry in sistemi del mondo reale di Gajinder Sharma

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Netflix Brings Out the Big Guns

The Ultimate FAQ Guide to HackerNoon's Business Blogging

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

Netflix Brings Out the Big Guns

The Ultimate FAQ Guide to HackerNoon's Business Blogging

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps