Como desarrollador de backend que trabaja con microservicios durante los últimos años, una verdad se ha vuelto dolorosamente obvia: el desgaste de problemas de producción en sistemas distribuidos puede sentirse como trabajo de detective en la oscuridad. You’ve got services calling services, sometimes dozens deep. A user clicks a button on the UI, and 15 microservices spin into action. If something breaks — or worse, just slows down — figuring out where and why can chew up hours. This is exactly why observability matters. And if you’re building or maintaining microservices in 2024, OpenTelemetry is the tool you want in your corner. What Even Is Observability, Really? La observabilidad es más que solo registros. Se trata de comprender por qué su sistema se comporta de una determinada manera, no sólo lo que está haciendo. Logs – Eventos crudos, útiles para el debugging. Metrics – Numbers you can track over time (e.g. request count, CPU). Traces – End-to-end request flows across services (aka your distributed "call stack"). Las herramientas de seguimiento tradicionales se centran principalmente en las métricas y los registros, pero el rastreo es el verdadero cambio de juego para los microservicios. Por qué elegimos OpenTelemetry Experimentamos con varias pilas de observabilidad - Datadog, New Relic, Prometheus, Jaeger, Zipkin - pero todos tenían un problema: o estaban bloqueados por el vendedor o carecían de coherencia en todos los idiomas. OpenTelemetry (OTel) checked all our boxes: Open Source, bajo CNCF Works across languages (we use Node.js, Go, and Python) Vendedor-neutral - exportación a Grafana, Jaeger, New Relic, etc. Supported by everyone in the industry (literally: AWS, GCP, Microsoft, etc.) Cómo usar OpenTelemetry en Node.js Microservices Déjame que te pase por cómo realmente instrumentamos un servicio real. Digamos que tenemos un servicio de usuario simple construido en Node.js usando Express. Expone un punto final '/usuarios' que recoge datos de usuarios. Step 1: Install Dependencies npm install @opentelemetry/api \
@opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http
 Vamos a exportar rastros a través de OTLP a una instancia Jaeger local. 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"));
 Nuestro servicio ya está exportando huellas. Step 4: Spin Up Jaeger Locally (or Use Grafana Tempo) Here’s how we test locally: docker run -d --name jaeger \
 -e COLLECTOR_OTLP_ENABLED=true \
 -p 4318:4318 -p 16686:16686 \
 jaegertracing/all-in-one:latest
 Visit   to view your traces. http://localhost:16686 Visit  para ver sus huellas. http://localhost:16686 Chaining traces a través de servicios Ahora digamos que tiene otro servicio —orden-servicio— que llama servicio de usuario. Si ambos están instrumentados con OpenTelemetry, obtendrá un rastro completo de la solicitud del usuario saltando entre ellos. And the best part? OpenTelemetry handles trace context propagation via HTTP headers automatically. You don’t have to manually pass trace IDs between services. Adding Custom Spans for Business Logic A veces la automatización no es suficiente, por ejemplo, si desea rastrear una consulta DB o una llamada de API externa: 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();
 }
});
 Esto es muy útil cuando desea rastrear el rendimiento de una lógica de negocio específica. Best Practices We've Learned the Hard Way 1.  Use Semantic Conventions En lugar de inventar sus propios nombres de atributos, siga las convenciones semánticas de OpenTelemetry. Estos hacen que sus rastros sean más fáciles de entender y compatibles con herramientas como Grafana, Tempo, etc. El ejemplo: JavaScript
span.setAttribute("http.method", req.method);
span.setAttribute("http.route", req.path);
 2. Sample Wisely If you trace every single request, your system will drown in data. Use trace sampling (e.g. 10%, or only errors). JavaScript const sdk = new NodeSDK ({
 sampler: new TraceIdRatioBasedSampler (0.1), // 10% sampling
});
 3. Use OpenTelemetry Collector in Production Don’t export telemetry data directly from your services to your backend. Route it through the OpenTelemetry Collector — it gives you buffering, batching, retries, and format conversion. 4. Don't Log PII in Spans This one’s critical. Be super careful not to store user names, emails, credit card info, etc. in span attributes or logs. Stick to metadata and identifiers. Dónde nos ha ayudado más Debugging problemas de latencia: Ver rastros completos en 4 a 5 microservicios nos ayudó a identificar las brechas de botella en minutos. Identifying retry storms: We spotted a service calling another in a loop with retries, something we wouldn’t have caught via logs. Regresiones de implementación: Comparando rastros de una versión a la siguiente nos mostró exactamente lo que cambió. Bonus: Tracing in a Multi-Language Stack We're using Node.js for some services, Go for others. OpenTelemetry made it easy to instrument both and send all data to a single place — Jaeger for dev, Grafana Cloud in staging/prod. No hay bloqueo de vendedores. No hay desacuerdo en los formatos de rastro. Sólo visibilidad pura. Conclusion: If You're Building Microservices, Start with Observability Microservices give us scale and flexibility, but they also bring complexity. Without proper observability, you're flying blind. OpenTelemetry has become a core part of our architecture, not just for debugging, but for optimizing performance, reliability, and ultimately — the user experience. Incluso una configuración básica con Jaeger y un par de servicios te hará preguntarte cómo alguna vez viviste sin él.

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

Este audio es producido en el idioma original de la historia!

Observabilidad de microservicios: aprovechando la OpenTelemetry en sistemas del mundo real por Gajinder Sharma

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Telegram: el puente de Crypto Island hacia el continente

El modelo Bitcoin UTXO, impulsando un ecosistema único

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Telegram: el puente de Crypto Island hacia el continente

El modelo Bitcoin UTXO, impulsando un ecosistema único

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps