En tant que développeur de back-end travaillant avec les microservices depuis quelques années, une vérité est devenue douloureusement évidente: le débogage des problèmes de production sur les systèmes distribués peut se sentir comme un travail de détective dans l'obscurité. Vous avez des services qui appellent des services, parfois des dizaines de profondeurs. Un utilisateur clique sur un bouton sur l'interface utilisateur, et 15 microservices tournent en action. Et si vous construisez ou entretenez des microservices en 2024, OpenTelemetry est l’outil que vous voulez dans votre coin. Qu’est-ce que l’observation, en fait ? L'observabilité est plus que des journaux.Il s'agit de comprendre pourquoi votre système se comporte d'une certaine manière, pas seulement ce qu'il fait. Logs – Événements bruts, utiles pour le débogage. Métriques – Les nombres que vous pouvez suivre au fil du temps (par exemple, le nombre de demandes, CPU). Traces – Des flux de demandes de bout en bout à travers les services (aussi appelé votre « pile d’appels » distribuée). Les outils de surveillance traditionnels se concentrent principalement sur les métriques et les journaux, mais le suivi est le véritable changement de jeu pour les microservices. Pourquoi nous avons choisi OpenTelemetry Nous avons expérimenté plusieurs piles d'observabilité - Datadog, New Relic, Prometheus, Jaeger, Zipkin - mais elles avaient toutes un problème: soit elles étaient bloquées par les fournisseurs, soit elles manquaient de cohérence entre les langues. OpenTelemetry (OTel) a vérifié toutes nos boîtes : Source ouverte, sous CNCF Fonctionne dans plusieurs langages (nous utilisons Node.js, Go et Python) Fournisseur neutre – exportation vers Grafana, Jaeger, New Relic, etc. Soutenu par tout le monde dans l’industrie (littéralement : AWS, GCP, Microsoft, etc.) Comment utiliser OpenTelemetry dans Node.js Microservices Laissez-moi vous expliquer comment nous avons effectivement instrumenté un service réel. Disons que nous avons un service utilisateur simple construit dans Node.js en utilisant Express. Step 1: Install Dependencies npm install @opentelemetry/api \
@opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http
 Nous allons exporter des traces via OTLP à une instance 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"));
 Notre service exporte désormais des traces. Step 4: Spin Up Jaeger Locally (or Use Grafana Tempo) Voici comment nous testons localement: docker run -d --name jaeger \
 -e COLLECTOR_OTLP_ENABLED=true \
 -p 4318:4318 -p 16686:16686 \
 jaegertracing/all-in-one:latest
 Visitez http://localhost:16686 pour voir vos traces. Visiteurs Pour voir tes traces. http://localhost:16686 La chaîne des traces à travers les services Maintenant, disons que vous avez un autre service - service de commande - qui appelle service utilisateur. Si les deux sont instrumentés avec OpenTelemetry, vous obtiendrez une trace complète de la demande de l'utilisateur sautant entre eux. OpenTelemetry gère automatiquement la propagation du contexte de trace via les en-têtes HTTP. Vous n'avez pas à passer manuellement les ID de trace entre les services. Ajouter des espaces personnalisés pour la logique d'affaires Parfois, l’auto-instrumentation ne suffit pas. Par exemple, si vous voulez suivre une requête DB ou un appel API externe: 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();
 }
});
 Cela est très utile lorsque vous voulez suivre la performance d'une logique d'affaires spécifique. Best Practices We've Learned the Hard Way 1.  Use Semantic Conventions Au lieu d'inventer vos propres noms d'attributs, tenez-vous aux conventions sémantiques d'OpenTelemetry.Ceux-ci rendent vos traces plus faciles à comprendre et compatibles avec des outils tels que Grafana, Tempo, etc. Exemple : JavaScript
span.setAttribute("http.method", req.method);
span.setAttribute("http.route", req.path);
 2. Sample Wisely Si vous suivez chaque requête, votre système se noyera dans les données. utilisez l'échantillonnage de trace (par exemple, 10%, ou seulement des erreurs). par JavaScript const sdk = new NodeSDK ({
 sampler: new TraceIdRatioBasedSampler (0.1), // 10% sampling
});
 3. Use OpenTelemetry Collector in Production Ne pas exporter les données de télémétrie directement à partir de vos services vers votre backend. Route-le à travers l'OpenTelemetry Collector - il vous donne bufflement, batch, retries et conversion de format. 4. Don't Log PII in Spans Soyez très prudent de ne pas stocker les noms d'utilisateur, les e-mails, les informations de carte de crédit, etc. dans des attributs ou des journaux. Où cela nous a le plus aidé Débogage des problèmes de latence : voir des traces complètes sur 4 à 5 microservices nous a permis d’identifier les lacunes en quelques minutes. Identification des tempêtes de retraite: Nous avons remarqué un service en appelant un autre dans une boucle avec des retraites, quelque chose que nous n'aurions pas capturé via les journaux. Régression de déploiement: Comparer les traces d'une version à l'autre nous a montré exactement ce qui a changé. Bonus : Suivi dans une pile multilingue Nous utilisons Node.js pour certains services, Go pour d'autres. OpenTelemetry a facilité l'instrumentation des deux et l'envoi de toutes les données à un seul endroit - Jaeger pour dev, Grafana Cloud dans staging/prod. Pas de verrouillage du vendeur. Pas de défaillance dans les formats de trace. Seule la visibilité pure. Conclusion: If You're Building Microservices, Start with Observability Les microservices nous donnent de l'échelle et de la flexibilité, mais ils apportent aussi de la complexité. OpenTelemetry est devenu une partie essentielle de notre architecture, non seulement pour le débogage, mais pour l’optimisation des performances, de la fiabilité et, en fin de compte, de l’expérience utilisateur. Même une configuration de base avec Jaeger et quelques services vous fera vous demander comment vous avez jamais vécu sans elle.

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

Cet audio est produit dans la langue originale de l'histoire !

Observabilité des microservices : tirer parti de l’OpenTelemetry dans les systèmes du monde réel par Gajinder Sharma

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps