Independencia con OpenTelemetry en Elastic

illustration-scalability-gear-1680x980_(1).jpg

El impulso de servicios más rápidos y escalables está en aumento. Nuestra vida cotidiana depende de apps, desde una app de entrega de comidas que te permite recibir tu plato favorito hasta la app del banco para gestionar tus cuentas e incluso apps para agendar  citas con el médico. Estas apps deben poder crecer no solo desde el punto de vista de las características, sino también en términos de capacidad de usuarios. La escala y la necesidad de un alcance global impulsa cada vez más complejidades para estas aplicaciones en el cloud de alta demanda.

A fin de mantener el ritmo de la demanda, la mayoría de estos servicios y apps en línea (por ejemplo, aplicaciones móviles, páginas web, SaaS) están migrando a una arquitectura basada en microservicios distribuida y Kubernetes. Una vez que hayas migrado la app al cloud, ¿cómo gestionas y monitoreas la producción, el escalado y la disponibilidad del servicio? OpenTelemetry se está convirtiendo rápidamente en el estándar de facto para la instrumentación y recopilación de datos de telemetría de aplicaciones para aplicaciones de Kubernetes.

OpenTelemetry (OTel) es un proyecto open source que proporciona un conjunto de herramientas, API y SDK que pueden usarse para generar, recopilar y exportar datos de telemetría (métricas, logs y rastreos) para entender el comportamiento y el rendimiento de software. Recientemente, OpenTelemetry se convirtió en un proyecto de incubación de CNCF y tiene un gran crecimiento de la comunidad y soporte de proveedores.

Si bien OTel proporciona una forma estándar de instrumentar aplicaciones con un formato de telemetría estándar, no proporciona ningún componente de analíticas o backend. Por lo tanto, el uso de bibliotecas de OTel en aplicaciones, infraestructura y monitoreo de la experiencia del usuario proporciona flexibilidad para elegir la herramienta de observabilidad preferida y adecuada. Ya no hay bloqueo de proveedores para el monitoreo de rendimiento de aplicaciones (APM).

Elastic Observability brinda soporte de forma nativa para OpenTelemetry y su protocolo OpenTelemetry (OTLP) a fin de ingestar rastreos, métricas y logs. Todas las capacidades de APM de Elastic Observability están disponibles con los datos de OTel. Por lo tanto, las capacidades siguientes (y más) están disponibles para los datos de OTel:

  • Mapas de servicios
  • Detalles de servicios (latencia, rendimiento, transacciones con errores)
  • Dependencias entre servicios
  • Transacciones (rastreos)
  • Correlaciones de ML (específicamente para latencia)
  • Logs de servicios

Además de la vista unificada de datos de telemetría y el APM de Elastic, ahora podrás usar las capacidades poderosas de machine learning de Elastic para reducir el análisis y las alertas para ayudar a reducir el MTTR.

Dado su legado open source, Elastic también brinda soporte para otros proyectos basados en CNCF, como Prometheus, Fluentd, Fluent Bit, Istio, Kubernetes (K8S) y muchos más.  

En este blog se mostrará:

  • Cómo configurar una app de demostración instrumentada de OTel popular (HipsterShop) para ingestar en Elastic Cloud con unos pocos pasos sencillos
  • Resaltará algunas de las características y capacidades de APM de Elastic relacionadas con los datos de OTel y qué puedes hacer con estos datos una vez que están en Elastic

En los blogs siguientes, detallaremos cómo usar el machine learning de Elastic con los datos de telemetría de OTel, cómo instrumentar las métricas de aplicación de OTel para lenguajes específicos, cómo podemos brindar soporte a la ingesta de Prometheus con el recopilador de OTel y más. ¡Mantente atento!

Requisitos previos y configuración

Si tienes pensado seguir este blog, estos son algunos de los componentes y detalles que usamos para configurar los ajustes:

  • Asegúrate de tener una cuenta en Elastic Cloud y un stack desplegado (consulta las instrucciones aquí).
  • Usamos una variante de la aplicación de demostración siempre tan popular HipsterShop. Originalmente, la escribió Google para mostrar Kubernetes en una gran cantidad de variantes disponibles, como la app de demostración de OpenTelemetry. Para usar esta aplicación, dirígete aquí y sigue las instrucciones de despliegue.
  • Además, estamos usando una versión instrumentada manualmente de OTel de la aplicación. Ninguna instrumentación automática de OTel se usó en la configuración de este blog.
  • Ubicación de nuestros clusters. Si bien usamos Google Kubernetes Engine (GKE), puedes usar la plataforma de Kubernetes que prefieras. 
  • Aunque Elastic puede ingestar telemetría directamente de los servicios instrumentados de OTel, nos enfocaremos en el despliegue más tradicional, que usa el recopilador de OpenTelemetry.
  • Prometheus y FluentD/Fluent Bit (usados tradicionalmente para extraer todos los datos de Kubernetes) no se usan aquí en comparación con agentes de Kubernetes. Esto se mostrará en blogs siguientes.

Esta es la configuración que realizaremos en este blog:

Configuración para ingestar datos de OpenTelemetry usada en este blog

Configuración general

En los próximos pasos, lo guiaremos por lo siguiente:

  • Cómo obtener una cuenta en Elastic Cloud
  • Cómo activar un cluster de GKE
  • Cómo activar la aplicación
  • Cómo configurar el configmap del recopilador de OTel de Kubernetes para que apunte a Elastic Cloud
  • Cómo usar el APM de Elastic Observability con los datos de OTel para una mayor visibilidad

Paso 0: Crear una cuenta en Elastic Cloud

Sigue las instrucciones para dar los primeros pasos en Elastic Cloud.

Paso 1: Activar un cluster de K8S

Usamos Google Kubernetes Engine (GKE), pero puedes usar la plataforma de Kubernetes que prefieras.

No hay requisitos especiales para que Elastic recopile datos de OpenTelemetry desde un cluster de Kubernetes. Cualquier cluster de Kubernetes normal en un cluster conforme a GKE, EKS, AKS o Kubernetes (autodesplegado y gestionado) servirá.

Paso 2: Cargar la aplicación HipsterShop en el cluster

Obtén tu aplicación en un cluster de Kubernetes en el servicio del cloud que prefieras o plataforma de Kubernetes local. La aplicación que usamos está disponible aquí.

Una vez que tu aplicación esté activa en Kubernetes, tendrás los siguientes pods (o alguna de sus variantes) ejecutándose en el nombre de espacio default.

kubectl get pods -n default

La salida debería ser similar a lo siguiente:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-f9bf94d56-5kt89                1/1     Running   0          41h
cartservice-54d5955c59-7lrk9             1/1     Running   0          41h
checkoutservice-57b95c78bb-qqcqv         1/1     Running   0          41h
currencyservice-6869479db8-7tsnj         1/1     Running   0          43h
emailservice-7c95b8766b-mp5vn            1/1     Running   0          41h
frontend-5f54bcb7cf-kxwmf                1/1     Running   0          41h
loadgenerator-bfb5944b6-2qhnw            1/1     Running   0          43h
paymentservice-5bc8f549c8-hkxks          1/1     Running   0          40h
productcatalogservice-665f6879d6-kv29f   1/1     Running   0          43h
recommendationservice-89bf4bfc5-ztcrr    1/1     Running   0          41h
redis-cart-5b569cd47-6wt59               1/1     Running   0          43h
shippingservice-768b94fb8d-8hf9c         1/1     Running   0          41h

En esta versión, solo activamos todos los services y loadgenerator. Verás que el recopilador de OpenTelemetry aún no se activó. (Consulta el paso siguiente).
Si observas los yaml de servicio individuales, verás que apuntan al recopilador de OpenTelemetry en el port 4317.

        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otelcollector:4317"

Port 4317 es el puerto predeterminado que escucha OpenTelemetry para la telemetría de los servicios.  Por lo tanto, todos los servicios deberían apuntar al recopilador de OTel.

Paso 3: Activar el recopilador de OpenTelemetry que apunta a Elastic

Como verás en el archivo otelcollector.yaml , en /deploy-with-collector-k8s, existen dos variables específicas que deben configurarse en la sección configmap.

    exporters:
      otlphttp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

OTEL_EXPORTER_OTLP_ENDPOINT es el APM Server de Elastic.

OTEL_EXPORTER_OTLP_ENDPOINT proporciona tu autorización.

Para obtener más detalles sobre las variables, revisa la documentación de Elastic sobre la configuración del recopilador de OTel.

¿Dónde obtienes estos valores? 

En la UI de Elastic Observability, en APM, +add data, se mostrará la siguiente pantalla. 

Ve a OpenTelemetry:

Verás valores en las variables OTEL_EXPORTER_OTLP_ENDPOINT (tu endpoint de APM Server de Elastic) y la autorización de OTEL_EXPORTER_OTLP_HEADERS.

Al configurar el recopilador de OTel con el endpoint de APM Server de Elastic, hay dos opciones: gRPC y http.

En otelcollector.yaml aquí, los exporters se configuran con http

Si deseas enviar con el puerto gRPC al servidor de APM, debes modificar los exportadores como tales:

    exporters:
      otlp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

Observa el cambio de otlphttp a otlp. Una vez que hagas los cambios necesarios como se detalló antes, crea el otelcollector:

kubectl create -f otelcollector.yaml

Asegúrate de que funcione correctamente.

mycomputer% kubectl get pods | grep otelcollector
otelcollector-5b87f4f484-4wbwn          1/1     Running   0            18d

Paso 4: Abrir Kibana y usar el mapa de servicios de APM para ver tus servicios instrumentados de OTel

En la UI de Elastic Observability, en APM, selecciona servicemap para ver tus servicios.

Si ves esto, el recopilador de OpenTelemetry está enviando datos a Elastic:

Felicitaciones, instrumentaste los servicios de la aplicación de demostración de HipsterShop para el rastreo usando OpenTelemetry e ingestaste los datos de telemetría correctamente en Elastic.

Cómo configurar entornos específicos

APM de Elastic te permite la ingesta de varias aplicaciones con la capacidad de filtrar por Environment. Por lo tanto, si tienes dev team 1 y dev team 2 ambos usando la UI, tendrás que configurar la variable environment correctamente. 

La configuración de la variable Environment para esta aplicación se realiza mediante la variable deployment.environment en los yaml de servicio.

Si deseas cambiar esto, deberás cambiar OTEL_RESOURCE_ATTRIBUTES en cada uno de los yaml de servicio en el git de la aplicación para este blog.

Cambia:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=MY-DEMO"

A:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=XXX"

Para hacerlo en todos los servicios, ejecuta lo siguiente:

sed -i `s/MY-DEMO/XXX/g` *.yaml

Paso 5: ¿Qué me puede mostrar Elastic?

Ahora que los datos de OpenTelemetry se ingestan en Elastic, ¿qué puedes hacer?

Primero, puedes ver el mapa de servicio de APM (como se muestra en el paso anterior); esto te brindará una visión completa de todos los servicios y de los flujos de transacciones entre servicios.

A continuación, puedes echar un vistazo a servicios individuales y las transacciones que se recopilan.

Como puedes ver, se incluyen los detalles de frontend. Todo lo relacionado con: 

  • Latencia de servicio promedio
  • Rendimiento
  • Transacciones principales
  • Tasa de tracciones con error
  • Errores
  • Dependencias

Vayamos al rastreo. En la pestaña de transacciones, puedes revisar todos los tipos de transacciones relacionados con el servicio de frontend:

Si seleccionamos las transacciones /es/cart/checkout, podemos ver el rastreo completo con todos los intervalos:

Latencia promedio para esta transacción, rendimiento, cualquier falla y, por supuesto, el rastreo.

No solo puedes revisar el rastreo, sino que también puedes analizar qué se relaciona con una latencia más alta que la habitual para /es/chart/checkout.

Elastic usa el machine learning para ayudar a identificar cualquier problema de latencia potencial en todos los servicios a partir del rastreo. Es tan simple como seleccionar la pestaña Latency Correlations y ejecutar la correlación.

Esto muestra que las transacciones del cliente 10.8.0.16 potencialmente tengan una latencia anormal para esta transacción.

Luego puedes explorar en los logs directamente desde la vista de rastreos y revisar los logs asociados con el rastreo para ayudar a identificar y detectar problemas potenciales.

Analizar los datos con machine learning (ML) de Elastic

Una vez que las métricas de OpenTelemetry se encuentren en Elastic, comienza a analizar tus datos a través de las capacidades de ML de Elastic.

Puedes encontrar una buena revisión de estas características aquí: cómo correlacionar la telemetría de APM para determinar la causa raíz en transacciones.

Y hay muchos más videos y blogs en el Blog de Elastic.

Haremos un seguimiento con blogs adicionales sobre cómo aprovechar las capacidades de machine learning de Elastic para los datos de OpenTelemetry.

Conclusión

Esperamos que hayas podido apreciar cómo Elastic Observability puede ayudarte a ingestar y analizar datos de OpenTelemetry con las capacidades de APM de Elastic.

Un breve resumen de las lecciones y demás:

  • Cómo configurar una app de demostración instrumentada de OTel popular (HipsterShop) para ingestar en Elastic Cloud con unos pocos pasos sencillos
  • Resaltar algunas de las características y capacidades de APM de Elastic relacionadas con los datos de OTel y qué puedes hacer con estos una vez que están en Elastic

¿Listo para comenzar? Regístrate para Elastic Cloud y prueba las características y capacidades antes descritas para obtener el mayor valor y visibilidad de tus datos de OpenTelemetry.