Trazas | OpenTelemetry

The content of this page may be outdated and some links may be invalid. A newer version of this page exists in English.More information ...To see the changes to the English page since this page was last updated: visit GitHub compare 860f5141..6bf06ddb9 and search for content/en/docs/concepts/signals/traces.md.
To see the changes to the English page since this page was last updated: visit GitHub compare 860f5141..6bf06ddb9 and search for content/en/docs/concepts/signals/traces.md.
Las trazas nos dan una visión general de lo que ocurre cuando se hace una solicitud a una aplicación. Ya sea que tu aplicación sea un monolito con una sola base de datos o una sofisticada malla de servicios, las trazas son esenciales para entender la “ruta” completa que una solicitud toma en tu aplicación.
Exploremos esto con tres unidades de trabajo, representadas como Spans:
Los siguientes ejemplos en JSON no representan un formato específico, y especialmente no representan OTLP/JSON, que es más verboso.
Este es el span raíz, que denota el principio y el final de toda la operación. Observa que tiene un campo trace_id que indica la traza, pero no tiene un parent_id. Así es como sabes que es el span raíz.
Span hello-greetings:
Este span encapsula tareas específicas, como saludar, y su padre es el span hello. Ten en cuenta que comparte el mismo trace_id que el span raíz, lo que indica que es parte de la misma traza. Además, tiene un parent_id que coincide con el span_id del span hello.
Span hello-salutations:
Este span representa la tercera operación en esta traza y, al igual que el anterior, es un hijo del span hello. Eso también lo convierte en un span hermano del span hello-greetings.
Estos tres bloques de JSON comparten el mismo trace_id, y el campo parent_id representa una jerarquía. ¡Eso lo convierte en una traza!
Otra cosa que notarás es que cada span parece un log estructurado. ¡Eso es porque, en cierto modo, lo es! Una forma de pensar en las trazas es que son una colección de logs estructurados con contexto, correlación, jerarquía y mucho más incorporado. Sin embargo, estos “logs estructurados” pueden provenir de diferentes procesos, servicios, máquinas virtuales, centros de datos, etc. Esto es lo que permite que el trazado represente una vista de extremo a extremo de cualquier sistema.
Para entender cómo funciona el trazado en OpenTelemetry, veamos una lista de los componentes que desempeñarán un papel en la instrumentación de nuestro código.
Un Proveedor de Trazas (a veces llamado TracerProvider) es una factoría para Tracers. En la mayoría de las aplicaciones, un TracerProvider se inicializa una vez y su ciclo de vida coincide con el ciclo de vida de la aplicación. La inicialización del TracerProvider también incluye la inicialización de Resource y Exporter. Suele ser el primer paso en el trazado con OpenTelemetry. En algunos SDK de lenguaje, ya se inicializa un Tracer Provider global para ti.
Un Tracer crea spans que contienen más información sobre lo que está sucediendo en una operación dada, como una solicitud en un servicio. Los Tracers se crean a partir de los Proveedor de Trazas.
Los exportadores de trazas envían trazas a un consumidor. Este consumidor puede ser la salida estándar para la depuración en tiempo de desarrollo, el OpenTelemetry Collector, o cualquier backend de código abierto o de proveedores de tu elección.
La propagación de contexto es el concepto central que habilita el trazado distribuido. Con la propagación de contexto, los spans pueden correlacionarse entre sí y ensamblarse en una traza, independientemente de dónde se generen. Para saber más sobre este tema, consulta la página sobre Context Propagation.
Un span representa una unidad de trabajo u operación. Los spans son los bloques de construcción de las trazas. En OpenTelemetry, incluyen la siguiente información:
Los spans pueden anidarse, como se insinúa por la presencia de un ID de span padre: los spans hijos representan sub-operaciones. Esto permite que los spans capturen de forma más precisa el trabajo realizado en una aplicación.
El contexto de span es un objeto inmutable en cada span que contiene lo siguiente:
El contexto de span es la parte de un span que se serializa y propaga junto con el Contexto Distribuido y el Baggage.
Debido a que el contexto de span contiene el ID de traza, se usa al crear Links de Span.
Los atributos son pares clave-valor que contienen metadatos que puedes usar para anotar un span y llevar información sobre la operación que está rastreando.
Por ejemplo, si un span rastrea una operación que añade un artículo al carrito de compras de un usuario en un sistema de eCommerce, puedes capturar el ID del usuario, el ID del artículo a añadir al carrito y el ID del carrito.
Puedes añadir atributos a los spans durante o después de su creación. Es preferible añadir atributos al crear el span para que estén disponibles para el muestreo del SDK. Si tienes que añadir un valor después de la creación del span, actualiza el span con el valor.
Los atributos tienen las siguientes reglas que cada SDK de lenguaje implementa:
Además, existen Atributos Semánticos, que son convenciones conocidas de nomenclatura para los metadatos que suelen estar presentes en operaciones comunes. Es útil usar la nomenclatura de atributos semánticos siempre que sea posible para que los tipos comunes de metadatos estén estandarizados en todos los sistemas.
Un evento de span puede considerarse como un mensaje de log estructurado (o anotación) en un span, que se usa típicamente para denotar un punto significativo y singular en el tiempo durante la duración del span.
Por ejemplo, considera dos escenarios en un navegador web:
Un span es la mejor opción para el primer escenario porque es una operación con un inicio y un final.
Un evento de span es la mejor opción para rastrear el segundo escenario, ya que representa un punto significativo y singular en el tiempo.
Dado que los eventos de span también contienen atributos, la pregunta de cuándo u