Introducción a la trazabilidad distribuida y OpenTelemetry en Openshift | Openshift Commons Gathering

Introducción a la trazabilidad distribuida y OpenTelemetry

«Hoy discutiremos sobre la trazabilidad distribuida y OpenTelemetry en OpenShift.»

• El presentador, Jose, es un gerente de producto en el área de observabilidad en OpenShift, enfocado en la trazabilidad distribuida y OpenTelemetry.
• Se plantea la importancia de cómo llegamos a este punto y qué significa en el contexto actual.
• En las sesiones, se buscará explicar qué se puede hacer con OpenShift en este ámbito, además de responder preguntas de los asistentes.

La evolución de la observabilidad moderna

«La observabilidad moderna ha cambiado drásticamente con la adopción de la nube.»

• En el pasado, la observabilidad era más sencilla en entornos monolíticos debido a la homogeneidad de los códigos y lenguajes.
• Con el cambio a arquitecturas en la nube, las aplicaciones ahora pueden estar desarrolladas en múltiples lenguajes, creando complejidades en la resolución de problemas.
• Un problema común ahora es la dificultad para identificar y resolver errores debido a la gran cantidad de información que se genera.

La necesidad de herramientas de observabilidad

«No podemos depender solo de la obtención de logs para resolver problemas complejos.»

• En un entorno con múltiples lenguajes de programación y un volumen elevado de solicitudes, el simplemente mirar logs no es suficiente.
• La combinación de aplicaciones modernas y legadas requiere una solución más robusta que permita ver el panorama completo.
• Se habla de la necesidad de invertir en herramientas que no bloqueen al usuario, garantizando estándares abiertos y flexibilidad.

Pilar de la observabilidad moderna: señales

«La observabilidad se basa en tres pilares: logs, métricas y trazabilidad.»

• Para identificar y resolver problemas de manera efectiva, es necesario tener acceso a estas tres señales críticas.
• Las métricas ayudan a alertar sobre problemas, mientras que la trazabilidad ofrece contexto sobre dónde se originan los errores.
• La instrumentación del código es esencial para asegurar que se pueda detectar y analizar adecuadamente cualquier problema que surja.

La Importancia del Contexto en las Solicitudes

«El contexto es el concepto importante aquí, y con este contexto podremos propagarlo de un span a otro.»

• Entender el contexto es crucial para solucionar problemas con solicitudes de servicio. Hay que identificar por qué una solicitud falla mientras que otra, que parece similar, no lo hace.
• Dado que se procesan miles de solicitudes por segundo, es esencial obtener información detallada sobre cómo están interactuando los diferentes servicios.
• Con un buen contexto, se puede construir un seguimiento del proceso, lo que permite identificar dónde podría estar el error, apoyándose en trazas que representan operaciones con una dimensión temporal.

Representación de Vistas de Trazas

«Esta es la representación que podremos ver, y recuerda que representa una operación en la dimensión del tiempo.»

• Se muestra un gráfico que ilustra cómo una operación se desarrolló a lo largo del tiempo, destacando los diferentes spans que se producen en el proceso.
• Al abrir una traza, se pueden observar los diferentes servicios y funciones involucradas, así como el tiempo que cada uno gasta en su tarea.
• Si hay un error, por ejemplo al llamar a la base de datos, se puede examinar el registro correspondiente, lo cual es clave para entender lo que ocurrió.

Interfaz de Usuario de Jager y Trazas Distribuidas

«Lo que vemos aquí es un conjunto de trazas generadas, y ahora podremos ver todo este contexto siendo propagado.»

• La interfaz de usuario de Jager es una de las más utilizadas para observar trazas, permitiendo a los desarrolladores hacer clic en diferentes trazas y explorar los detalles de cada servicio y función.
• La interfaz permite filtrar por servicio, lo cual es útil cuando se desea analizar el rendimiento de un servicio específico.
• Este enfoque es útil porque algunas empresas optan por centrarse primero en el trazado, ya que proporciona información significativa sin requerir grandes inversiones en registros o métricas.

Estrategia de Observabilidad y Arquitectura de Trazado

«Este es el aspecto que tenemos cuando instalamos el trazado distribuido en un stack.»

• Se envían spans a un colector de OpenTelemetry que luego agregará la información para crear una traza y almacenarla en Tempo, el backend elegido.
• Tempo es más eficaz y escalable que alternativas anteriores, lo que permite una mejor integración con otros sistemas en el ecosistema de Regular.
• La arquitectura de observación implica diferentes etapas: recolección de datos, almacenamiento y visualización, lo que requiere diferentes tecnologías para cada fase del proceso.

Expansión de OpenTelemetry y Contribuciones de la Comunidad

«OpenTelemetry es un proyecto que ha crecido tanto que ahora tiene capacidades para métricas, registros y trazas.»

• OpenTelemetry surgió de la fusión de tecnologías de trazado y ha evolucionado para incluir una amplia gama de funciones, convirtiéndose en un proyecto muy activo en la CNCF.
• Las contribuciones provienen de numerosos proveedores de tecnología, lo que enfatiza la importancia de un enfoque abierto y colaborativo para resolver problemas de observabilidad.
• A medida que se desarrollan nuevas capacidades, OpenTelemetry permite a las empresas instrumentar su código de manera efectiva y ayudarlas a recolectar, transformar y exportar datos.

Mantenimiento del código y SDK desacoplado

«El mantenimiento del código es uno de los aspectos más difíciles en la vida del desarrollo de software.»

• El proceso de mantenimiento del código puede ser un reto, y por eso es preferible establecer estructuras que puedan mantenerse sin necesidad de cambios frecuentes.
• Para facilitar esto, se recomienda utilizar un SDK que esté desacoplado del resto de la cadena de software. Esto permite instrumentar el código y, al final del proceso, decidir el exportador de métricas a utilizar.
• Con este enfoque, los desarrolladores pueden adaptar su código a nuevas necesidades sin tener que reescribirlo. Por ejemplo, si en el futuro se presenta un nuevo protocolo para métricas, solo será necesario modificar la parte final del código donde se define el exportador.

Comunidad activa y soporte para múltiples lenguajes

«La comunidad es muy activa y eso significa que si surge un problema, es probable que sea solucionado pronto.»

• La comunidad detrás de Open Telemetry es inclusiva, buscando proporcionando un SDK para diferentes lenguajes de programación, lo que permite que todos puedan comunicarse eficientemente.
• Abordar la diversidad de métricas en un solo protocolo facilita que los desarrolladores no tengan que saltar de uno a otro, reduciendo la complejidad en la gestión de datos entre diferentes pilas tecnológicas.
• Si bien puede haber retos con sistemas heredados o modernos, el protocolo es extensible, permitiendo así incorporar nuevas herramientas o métodos de forma sencilla.

Aspectos técnicos y recolección de datos

«El Open Telemetry Collector ayuda a recolectar señales de una manera eficiente y modular.»

• Se cuenta con un colector que actúa como un bloque grande para recolectar datos en un clúster, facilitando la definición de cómo recibir, procesar y exportar información.
• La arquitectura modular del colector se compone de receptores, procesadores y exportadores que permiten personalizar cómo se gestionan los datos.
• Además, es posible incluir mecanismos de autorización y almacenamiento de archivos como parte de la infraestructura de datos, mejorando así la funcionalidad general del sistema.

Definición y Adaptación de Canalizaciones en OpenTelemetry

«Esto te ayuda a evitar o a cambiar fácilmente algo en tus canalizaciones de observabilidad.»

• El proceso comienza transformando los datos en un formato conveniente para facilitar su manejo y adaptación dentro de las canalizaciones de observabilidad.
• Esto es crucial para realizar modificaciones de manera eficiente, permitiendo definir lo que se conoce como un servicio o canalización dentro de un recolector OpenTelemetry.
• Se describen las canalizaciones como líneas que determinan cómo se procesarán los datos que se recopilan, permitiendo establecer diferentes flujos de trabajo para distintos tipos de señales como trazas, métricas y registros.

Ejemplos de Canalizaciones y Conectores

«Desde Jaeger, haces algunos cambios, añades atributos de Kubernetes y limitas la memoria para exportarlas a Tempo.»

• Un ejemplo de canalización es la recolección de trazas desde Jaeger, donde se puede transformar la información antes de enviarla a Tempo, utilizando un protocolo estándar como OTP.
• También se menciona que, aunque no se cuente con una solución específica para almacenamiento, es posible instrumentar el código con OpenTelemetry y exportar datos a Prometheus.
• Una característica interesante son los conectores, que permiten la creación de métricas en el recolector basadas en los spans recibidos, eliminando la necesidad de instrumentar el código específicamente.

Cambios en la Comunidad y Gobernanza

«La comunidad decidió cambiar, dividirlo en un par de repositorios, uno es el recolector y el otro es el contribuyente.»

• La comunidad ha decidido organizar el código en repositorios separados: uno para las funcionalidades centrales (el recolector) y otro para las contribuciones, facilitando así la participación y el desarrollo colaborativo.
• Este cambio permite que los componentes contribuidos se evalúen antes de ser incluidos en el núcleo, lo que asegura un nivel de seriedad y soporte en la implementación.
• Se está pidiendo retroalimentación activa de los clientes, lo que abre la puerta a la inclusión de nuevas funciones si son requeridas.

Expansión y Nuevas Capacidades en OpenTelemetry

«Estamos añadiendo más capacidades, incluyendo métricas de eventos de Kubernetes y estadísticas de clúster.»

• OpenTelemetry está en expansión, integrando capacidades que permiten observar plataformas como Kubernetes, lo que incluye la recolección de métricas de eventos y estadísticas de clúster.
• Aunque estos componentes ya existen en la comunidad, su inclusión en la distribución de OpenTelemetry busca ofrecer un paquete integral para la trazabilidad y la observabilidad.
• Se reconoce que este proceso lleva tiempo y se está trabajando con los usuarios para asegurar que la evolución del producto se alinee con sus necesidades.

Instrumentación y Recursos Personalizados

«A menudo, no construyes todo desde cero; utilizas bibliotecas que ya están instrumentadas.»

• La instrumentación en OpenTelemetry se basa en el uso de bibliotecas que ya implementan capacidades de rastreo, permitiendo a los desarrolladores beneficiarse de la observación sin tener que configurar todo manualmente.
• Este enfoque facilita que los desarrolladores que utilizan lenguajes como Python integren observación en sus aplicaciones sin mayores complicaciones, dependiendo de la instrumentación preexistente.
• Se mencionan casos de uso, indicando que se están realizando esfuerzos para mejorar las interacciones entre OpenTelemetry y otros sistemas de observación, tomando en cuenta la retroalimentación continua de los usuarios.

Necesidades y Soluciones en la Observabilidad

«Necesitamos este componente que actualmente no existe.»

• En la discusión, surge la necesidad de un componente específico que actualmente no está disponible. El enfoque se centra en encontrar soluciones viables para este desafío, destacando la importancia de trabajar en conjunto para identificarlas.
• Se menciona que se está utilizando la plataforma OpenShift, lo que sugiere que es necesaria la colaboración y la búsqueda de información para obtener respuestas efectivas.

Casos de Uso de la Observabilidad en la Aerolínea IND Theo

«Querían una solución que ayudara a observar y gestionar datos eficientemente.»

• IND Theo Airlines tiene un caso de uso en el que necesitan observar múltiples instancias de datos, lo que implica una gestión más allá de la simple recogida. La aerolínea busca no solo almacenar información, sino también tomar decisiones más inteligentes basadas en esos datos.
• Se menciona la importancia de utilizar estándares abiertos, lo que permitirá que las soluciones evolucionen y se adapten a las necesidades futuras sin quedar atrapadas en tecnologías específicas.

Construcción de un Data Lake para Análisis Futuro

«Están alimentando un lago de datos con señales e información.»

• Se discute cómo la aerolínea está construyendo una solución basada en Open Telemetry, alimentando un lago de datos que les permitirá analizar y extraer valor de la información recogida en el futuro.
• Esta estrategia no solo proporciona una visión del rendimiento actual, sino que también fomenta un proceso de toma de decisiones más rápido y eficaz basado en datos observacionales.