Elysia Tools
Navigation mobile
Workflow Playbook
Recensez les anciens attributs, migrez les conventions, vérifiez la propagation et examinez une trace réelle avant de déployer l’instrumentation.
Dossiers
Ce parcours aide les responsables d’un service à mettre à niveau les conventions sémantiques OpenTelemetry. Il ne remplace pas une enquête d’incident. Réunissez un extrait de journal antérieur, la configuration d’instrumentation ou du Collector et une requête traversant au moins deux services. Assainissez les données personnelles et les secrets avant tout partage. structured-log-analyzer révèle les attributs présents ; pour un journal logfmt, logfmt-to-json-structured-log-bridge rend visibles les valeurs entre guillemets et les clés en double. Un JSON déjà structuré n’a pas besoin de conversion. Le parcours pii-log-redaction couvre l’examen approfondi des données sensibles.
Lancez otel-semantic-convention-migration-tool sur une copie du code, de la configuration ou des requêtes de tableaux de bord. Conservez la version de départ et celle d’arrivée, les renommages proposés, les suppressions et les cas non couverts. Le résultat est un projet de migration, pas un déploiement. http.target peut demander une séparation explicite entre chemin et requête plutôt qu’un simple renommage. Faites arbitrer ce cas, puis déployez selon votre procédure. Vérifiez les recherches des tableaux de bord : le nombre d’attributs renommés ne révèle pas les anciennes références restantes.
Soumettez des exemples d’en-têtes W3C traceparent, tracestate, baggage et OTLP à opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator. Le service suivant doit conserver l’identifiant de trace et émettre un identifiant de span différent. Des en-têtes corrects ne prouvent toutefois pas qu’un span a été exporté. Avec distributed-trace-decoder-waterfall-visualizer, comparez l’exportation postérieure aux services, liens parent-enfant, erreurs et durées attendus. Notez tout span manquant au lieu de présumer qu’il existe.
Si une cible de latence est prévue, utilisez api-latency-budget-planner pour confronter les durées observées aux allocations par étape. Une trace peut orienter une analyse, mais ne mesure pas le P99. La décision de déploiement doit garder les versions, le diff d’attributs, le contrôle des en-têtes, l’exportation et les écarts restants. Pour un incident actif ou une reproduction de requête API, passez plutôt à observability-debugging ou api-request-replay-and-debugging.
Guide de workflow
Analysez un extrait assaini d’avant la modification. Convertissez logfmt en JSON uniquement si cela aide à voir les valeurs citées et clés répétées.
Réécrivez les attributs pris en charge depuis v1.20, examinez le diff et isolez les champs supprimés ou sans correspondance.
Contrôlez traceparent, tracestate, baggage et les en-têtes OTLP sur un passage représentatif, y compris l’identifiant de trace partagé.
Décodez une exportation JSON OTel, Jaeger ou Zipkin postérieure et confrontez services, parents, erreurs et durées au trajet attendu.
Convertissez logfmt si les guillemets ou des clés répétées masquent des champs ; analysez directement un JSON déjà typé.
Examinez les attributs supprimés ou non couverts, notamment http.target, avant d’appliquer une règle de renommage au Collector.
Testez les en-têtes pour le contexte, la trace exportée pour les spans réellement liés et le budget seulement si un objectif existe.
Calculateurs, outils numériques, logique de dates, statistiques et finance
Si un objectif existe, rapprochez les durées de spans des allocations convenues et notez les étapes qui dépassent le budget.