Componentes
OpenTelemetry está compuesto por varios componentes principales:
- Especificación
- Collector
- Implementaciones de API y SDK específicas del lenguaje
- Operador de Kubernetes
- Elementos de Función como Servicio
OpenTelemetry te permite reemplazar la necesidad de SDKs y herramientas específicas de proveedores para generar y exportar datos de telemetría.
Especificación
Describe los requisitos y expectativas multilenguaje para todas las implementaciones. Más allá de la definición de términos, la especificación define lo siguiente:
- API: Define tipos de datos y operaciones para generar y correlacionar datos de trazas, métricas y logs.
- SDK: Define requisitos para una implementación específica del lenguaje de la API. La configuración, procesamiento de datos y conceptos de exportación también se definen aquí.
- Datos: Define el Protocolo de OpenTelemetry (OTLP) y convenciones semánticas neutrales que un backend de telemetría puede soportar.
Para más información, consulta las especificaciones.
Collector
El Collector de OpenTelemetry es un proxy neutral que puede recibir, procesar y exportar datos de telemetría. Soporta recibir datos de telemetría en múltiples formatos (por ejemplo, OTLP, Jaeger, Prometheus, así como muchas herramientas comerciales/proprietarias) y enviar datos a uno o más backends. También permite procesar y filtrar datos de telemetría antes de exportarlos.
Para más información, consulta el Collector.
Implementaciones de API y SDK específicas del lenguaje
OpenTelemetry también cuenta con SDKs específicos para cada lenguaje que te permiten usar la API de OpenTelemetry para generar datos de telemetría en el lenguaje de tu elección y exportarlos a un backend preferido. Estos SDKs también permiten incorporar librerías de instrumentación para librerías y frameworks comunes, que puedes utilizar para conectar la instrumentación manual en tu aplicación.
Para más información, consulta Instrumentación.
Librerías de instrumentación
OpenTelemetry soporta una amplia gama de componentes que generan datos de telemetría relevantes desde librerías y frameworks populares para los lenguajes soportados. Por ejemplo, las solicitudes HTTP entrantes y salientes desde una librería HTTP generan datos sobre esas solicitudes.
Un objetivo aspiracional de OpenTelemetry es que todas las librerías populares estén diseñadas para ser observables por defecto, para que no se requieran dependencias separadas.
Para más información, consulta Instrumentación de librerías.
Exportadores
Send telemetry to the OpenTelemetry Collector to make sure it’s exported correctly. Using the Collector in production environments is a best practice. To visualize your telemetry, export it to a backend such as Jaeger, Zipkin, Prometheus, or a vendor-specific backend.
The registry contains the list of language specific exporters.
Among exporters, OpenTelemetry Protocol (OTLP) exporters are designed with the OpenTelemetry data model in mind, emitting OTel data without any loss of information. Furthermore, many tools that operate on telemetry data support OTLP (such as Prometheus, Jaeger, and most vendors), providing you with a high degree of flexibility when you need it. To learn more about OTLP, see OTLP Specification.
Instrumentación sin código
Si aplica, una implementación específica de OpenTelemetry en un lenguaje proporciona una forma de instrumentar tu aplicación sin tocar el código fuente. Aunque el mecanismo subyacente depende del lenguaje, la instrumentación sin código añade las capacidades de API y SDK de OpenTelemetry a tu aplicación. Adicionalmente, puede añadir un conjunto de librerías de instrumentación y dependencias de exportador.
Para más información, consulta Instrumentación sin código.
Detectores de recursos
Un recurso representa la entidad que produce telemetría como atributos de tipo recurso. Por ejemplo, un proceso que produce telemetría y que se está ejecutando en un contenedor en Kubernetes tiene el nombre del Pod, un nombre del namespace y posiblemente un nombre del Deployment. Puedes incluir todos estos atributos como tipo recurso.
Las implementaciones específicas de OpenTelemetry para cada lenguaje
proporcionan detección de recursos desde la variable de entorno
OTEL_RESOURCE_ATTRIBUTES y para muchas entidades comunes, como el runtime del
proceso, servicio, host o sistema operativo.
Para más información, consulta Recursos.
Propagadores entre servicios
La propagación es el mecanismo que transfiere datos entre servicios y procesos. Aunque no está limitado a las trazas, la propagación permite que las trazas construyan información causal sobre un sistema a través de servicios distribuidos arbitrariamente entre fronteras de procesos y redes.
Para la gran mayoría de los casos, la propagación de contexto ocurre a través de librerías de instrumentación. Si es necesario, puedes utilizar propagadores tú mismo para serializar y deserializar intereses compartidos, como el contexto de un span y el equipaje.
Muestreadores
El muestreo es un proceso que restringe la cantidad de trazas generadas por un sistema. Cada implementación específica de OpenTelemetry para un lenguaje ofrece varios muestreadores de cabecera.
Para más información, consulta Muestreo.
Operador de Kubernetes
El Operador de OpenTelemetry es una implementación de un Operador de Kubernetes. El operador gestiona el Collector de OpenTelemetry y la auto-instrumentación de las aplicaciones usando OpenTelemetry.
Para más información, consulta el Operador K8s.
Elementos de Función como Servicio
OpenTelemetry soporta varios métodos de monitoreo para Function-as-a-Service proporcionados por diferentes proveedores de servicios en la nube. La comunidad de OpenTelemetry proporciona capas Lambda prefabricadas capaces de auto-instrumentar tu aplicación, así como la opción de una capa Lambda de Collector independiente que puede usarse al instrumentar aplicaciones manual o automáticamente.
Para más información, consulta Funciones como Servicio.
Comentarios
¿Fue útil esta página?
Thank you. Your feedback is appreciated!
Please let us know how we can improve this page. Your feedback is appreciated!