Monitoreo de Istio con Elastic Observability

Istio es una malla de servicios open source que los desarrolladores y operadores pueden usar para controlar, asegurar y conectar servicios con éxito entre sí en el mundo de los microservicios distribuidos. Si bien Istio es una herramienta poderosa para los equipos, también es importante para los administradores tener visibilidad total de su estado. En este blog, veremos cómo monitorear Istio y sus microservicios con Elastic Observability.

Como se menciona en los documentos de Istio:

Istio facilita la creación de una red de servicios desplegados con balanceo de carga, autenticación servicio a servicio, monitoreo y más, con pocos o ningún cambio de código en el código de servicio. Agregas el soporte de Istio a los servicios desplegando un proxy de sidecar especial en todo tu entorno que intercepta toda comunicación de red entre microservicios, después configuras y gestionas Istio usando su funcionalidad de plano de control, que incluye lo siguiente:

• Balanceo de carga automático para tráfico HTTP, gRPC, WebSocket y TCP
• Control detallado del comportamiento del tráfico con reglas de enrutamiento completas, reintentos, conmutaciones por error e inserción de fallas
• Una API de configuración y capa de políticas conectable que soporta controles de acceso, límites de tasa y cuotas
• Métricas, logs y rastreos automáticos de todo el tráfico en un cluster, incluidos el ingreso y egreso del cluster
• Comunicación segura servicio a servicio en un cluster con autenticación y autorización sólidas basadas en identidad

Antes de la versión 1.5, Istio estaba creado con una arquitectura de microservicios, y su plano de control y componentes de gestión consistían en varios microservicios: Pilot, Mixer, Galley y Citadel.

Metricbeat contaba con soporte para monitorear estos microservicios, pero en la versión 1.5 Istio cambió su arquitectura a un enfoque monolítico, y el plano de control ahora incluye una sola aplicación denominada istiod. Pilot, Galley y Citadel ahora son parte de istiod, mientras que la funcionalidad de Mixer (responsable de recopilar métricas de tráfico de los proxies Envoy) ahora la proporcionan directamente los proxies de Istio. La arquitectura actual de Istio se ve así:

Creación de una solución de monitoreo con Elastic

Si bien los varios conjuntos de métricas del módulo de Metricbeat de Istio ya soportaban las versiones anteriores a la 1.5, en este blog nos enfocaremos más en el soporte de las versiones más nuevas en relación con Istio ejecutándose en Kubernetes.

Métricas del plano de control

Como se muestra en la ilustración anterior de la arquitectura de Istio, solo tenemos un recurso del que podemos recopilar métricas del plano de control. Istiod proporciona un exportador de Prometheus desde el cual podemos recopilar métricas de Prometheus.

Para consumir métricas del endpoint de Prometheus, necesitamos un conjunto de métricas que recopile dichas métricas de forma adecuada, las filtre y las almacene correctamente. Esto se puede lograr fácilmente con la creación de un conjunto de métricas ligero basado en el módulo de Prometheus, aprovechando opciones poderosas como filtrado de métricas y usando histogramas y tipos.

Veamos la definición de este nuevo conjunto de métricas ligero:

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /metrics 
    metrics_filters: 
      include: ["citadel_*", "galley_*", "pilot_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

Esto define la ruta desde la cual el conjunto de métricas recopilador extraerá y filtrará las métricas que no necesitamos, y habilitará tasas y tipos para que los datos se almacenen correctamente en Elasticsearch, lo que nos permite aprovecharlos al máximo.

La forma de configurar este conjunto de métricas al desplegar Metricbeat en un cluster de Kubernetes se ve así:

- module: istio 
  metricsets: ['istiod'] 
  period: 10s 
  hosts: ['istiod.istio-system:15014']

Donde istiod es el nombre del servicio de Kubernetes que expone el Pod Istiod, e istio-system es el espacio de nombre en el que se despliega.

Eso es todo. Ya tenemos el conjunto de métricas de istiod para recopilar las métricas de istiod, que también incluye un dashboard prediseñado que proporciona una visión general del plano de control de la malla de servicios, completa con varias visualizaciones que puedes usar en tus propios dashboards customizados:

Métricas del plano de datos

Ahora que estamos recopilando métricas del plano de control con el conjunto de métricas de istiod, podemos ampliar nuestro monitoreo recopilando métricas del plano de datos. Esto nos dará una visión general poderosa del tráfico entre los servicios gestionados por Istio.

Como ya mencionamos, Mixer era el microservicio responsable de recopilar y proporcionar estas métricas del plano de datos. Pero después de la versión 1.5, estas métricas se recopilan y exponen directamente de los proxies de Istio con un exportador de Prometheus.

Todo lo que necesitamos hacer es especificar otro conjunto de métricas ligero, similar a lo que hicimos con istiod, para recopilar estas métricas adicionales:

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /stats/prometheus 
    metrics_filters: 
      include: ["istio_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

Como antes, definimos metrics_path, y solo mantenemos las métricas que deseamos y las almacenamos usando tipos. 

Sin embargo, falta una pieza: no sabemos cómo llegar a estos contenedores de proxy porque no conocemos sus direcciones IP. Incluso si conociéramos las IP de estos contenedores antes de desplegar Metricbeat, no podríamos recopilar datos de servicios que se desplieguen después de que Metricbeat se haya iniciado. Necesitamos una forma de identificar automáticamente estos contenedores y comenzar a recopilar métricas a medida que se inicien; el trabajo perfecto para la característica de detección automática de Metricbeat. Esto significa que definimos una condición de detección automática para identificar estos contenedores y, cuando se detecte un nuevo contenedor de sidecar de proxy de Istio, Metricbeat habilitará automáticamente el conjunto de métricas de proxy y comenzará a recopilar datos de este.

Aquí hay un ejemplo de esta configuración de detección automática:

metricbeat.autodiscover: 
  providers: 
    - type: kubernetes 
      node: ${NODE_NAME} 
      templates: 
        - condition: 
            contains: 
              kubernetes.annotations.prometheus.io/path: "/stats/prometheus" 
          config: 
            - module: istio 
              metricsets: ["proxy"] 
              hosts: "${data.host}:15090"

Y listo. Estamos recopilando métricas de todos los contenedores de sidecar de Istio que se ejecutan en el cluster y podemos identificar cualquiera nuevo sobre la marcha. Este es el conjunto de métricas de proxy del módulo de Istio, que también incluye un dashboard prediseñado:

Además, podemos aprovechar la analítica de grafo en Kibana para explorar las correlaciones entre nuestros datos y los servicios. Por ejemplo, en el grafo siguiente, podemos ver una visión general de la conexión que existe entre nuestros servicios y qué tan sólida es su relación con los códigos de estado http. Un servicio con una relación sólida con un código de estado 500 indicaría un problema que debemos investigar.

Monitoreo de Istio en la actualidad

Si deseas comenzar a monitorear tu malla de servicios de Istio, descarga Metricbeat 7.11 y comienza a explorar tus métricas de forma eficiente con Elasticsearch y Kibana. La forma más rápida de desplegar tu cluster es activando una prueba gratuita de Elasticsearch Service. Y si tienes preguntas, recuerda que nos complace ayudarte en los foros de debate.