Preguntas frecuentes sobre métricas y registros

Puede recopilar datos de telemetría sobre Istio utilizando Prometheus. Y luego usar la API HTTP de Prometheus para consultar esos datos.

La telemetría en el proxy (también conocida como v2) reduce el costo de los recursos y mejora el rendimiento del proxy en comparación con el enfoque de telemetría basada en Mixer (también conocida como v1), y es el mecanismo preferido para mostrar la telemetría en Istio. Sin embargo, existen algunas diferencias en la telemetría informada entre v1 y v2 que se enumeran a continuación:

• Faltan etiquetas para el tráfico fuera de la mesh La telemetría en el proxy se basa en el intercambio de metadatos entre los proxies de Envoy para recopilar información como el nombre de el workload del par, el namespace y las labels. En la telemetría basada en Mixer , esta funcionalidad la realizaba Mixer como parte de la combinación de los atributos de la solicitud con los datos de la plataforma. Este intercambio de metadatos lo realizan los proxies de Envoy agregando un encabezado HTTP específico para el protocolo HTTP o aumentando el protocolo ALPN para el protocolo TCP como se describe aquí. Esto requiere que los proxies de Envoy se inyecten tanto en los workloads del cliente como del servidor, lo que implica que a la telemetría informada cuando un par no está en la mesh le faltarán atributos del par como el nombre de el workload, el namespace y las labels. Sin embargo, si ambos pares tienen proxies inyectados, todas las labels mencionadas aquí están disponibles en las métricas generadas. Cuando el workload del servidor está fuera de la mesh, los metadatos de el workload del servidor todavía se distribuyen al sidecar del cliente, lo que hace que las métricas del lado del cliente tengan los metadatos de el workload del servidor labels completadas.

• El intercambio de metadatos TCP requiere mTLS El intercambio de metadatos TCP se basa en el protocolo ALPN de Istio que requiere que el TLS mutuo (mTLS) esté habilitado para que los proxies de Envoy intercambien metadatos con éxito. Esto implica que si mTLS no está habilitado en su cluster, la telemetría para el protocolo TCP no incluirá información del par como el nombre de el workload, el namespace y las labels.

• No hay mecanismo para configurar depósitos personalizados para métricas de histograma La telemetría basada en Mixer admitía la personalización de depósitos para métricas de tipo histograma como la duración de la solicitud y los tamaños de bytes de TCP. La telemetría en el proxy no tiene tal mecanismo disponible. Además, los depósitos disponibles para las métricas de latencia en la telemetría en el proxy están en milisegundos en comparación con los segundos en la telemetría basada en Mixer. Sin embargo, hay más depósitos disponibles de forma predeterminada en la telemetría en el proxy para las métricas de latencia en los niveles de latencia más bajos.

• No hay vencimiento de métricas para métricas de corta duración La telemetría basada en Mixer admitía el vencimiento de métricas por el cual las métricas que no se generaban durante un período de tiempo configurable se daban de baja para la recopilación por parte de Prometheus. Esto es útil en escenarios, como trabajos únicos, que generan métricas de corta duración. Dar de baja las métricas evita la notificación de métricas que ya no cambiarían en el futuro, lo que reduce el tráfico de red y el almacenamiento en Prometheus. Este mecanismo de vencimiento no está disponible en la telemetría en el proxy. La solución alternativa para esto se puede encontrar aquí.

Las métricas de corta duración pueden afectar el rendimiento de Prometheus, ya que a menudo son una gran fuente de cardinalidad de labels. La cardinalidad es una medida del número de valores únicos para una label. Para gestionar el impacto de sus métricas de corta duración en Prometheus, primero debe identificar las métricas y labels de alta cardinalidad. Prometheus proporciona información de cardinalidad en su página /status. Se puede recuperar información adicional a través de PromQL. Hay varias formas de reducir la cardinalidad de las métricas de Istio:

• Deshabilitar la reserva del encabezado del host. La label destination_service es una fuente potencial de alta cardinalidad. Los valores para destination_service se establecen de forma predeterminada en el encabezado del host si el proxy de Istio no puede determinar el servicio de destino a partir de otros metadatos de la solicitud. Si los clientes utilizan una variedad de encabezados de host, esto podría dar como resultado una gran cantidad de valores para destination_service. En este caso, siga la guía de personalización de métricas para deshabilitar la reserva del encabezado del host en toda la mesh. Para deshabilitar la reserva del encabezado del host para una workload o un namespace en particular, debe copiar la configuración de EnvoyFilter de estadísticas, actualizarla para que la reserva del encabezado del host esté deshabilitada y aplicarla con un selector más específico. Este problema tiene más detalles sobre cómo lograrlo.
• Eliminar labels innecesarias de la colección. Si no se necesita la label con alta cardinalidad, puede eliminarla de la colección de métricas a través de la personalización de métricas usando tags_to_remove.
• Normalizar los valores de las labels, ya sea a través de la federación o la clasificación. Si se desea la información proporcionada por la label, puede usar la federación de Prometheus o la clasificación de solicitudes para normalizar la label.

Mixer fue eliminado en la versión 1.8 de Istio. La migración es necesaria si todavía depende de los adaptadores integrados de Mixer o de cualquier adaptador fuera de proceso para la extensión de la mesh.

Para los adaptadores integrados, se proporcionan varias alternativas:

• Las integraciones de Prometheus y Stackdriver se implementan como extensiones de proxy. La personalización de la telemetría generada por estas dos extensiones se puede lograr a través de la clasificación de solicitudes y la personalización de métricas de Prometheus.
• La funcionalidad de limitación de velocidad global y local (adaptadores memquota y redisquota) se proporciona a través de la solución de limitación de velocidad basada en Envoy.
• El adaptador OPA se reemplaza por la solución basada en ext-authz de Envoy, que admite la integración con el agente de políticas de OPA.

Para los adaptadores personalizados fuera de proceso, se recomienda encarecidamente la migración a extensiones basadas en Wasm. Consulte las guías sobre el desarrollo de módulos Wasm y la distribución de extensiones. Como solución temporal, puede habilitar el soporte de la API de registro de acceso gRPC y ext-authz de Envoy en Mixer, lo que le permite actualizar Istio a versiones posteriores a la 1.7 sin dejar de usar Mixer 1.7 con adaptadores fuera de proceso. Esto le dará más tiempo para migrar a extensiones basadas en Wasm. Tenga en cuenta que esta solución temporal no ha sido probada en batalla y es poco probable que reciba correcciones de parches, ya que solo está disponible en la rama 1.7 de Istio, que está fuera de la ventana de soporte después de febrero de 2021.

Puede usar docker-compose para instalar Prometheus.

Puede habilitar el seguimiento para determinar el flujo de una solicitud en Istio.

Además, puede usar los siguientes comandos para saber más sobre el estado de la mesh:

• istioctl proxy-config: recupera información sobre la configuración del proxy cuando se ejecuta en Kubernetes:

  # Recuperar información sobre la configuración de arranque para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  
  # Recuperar información sobre la configuración del cluster para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  
  # Recuperar información sobre la configuración del listener para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  
  # Recuperar información sobre la configuración de la ruta para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  
  # Recuperar información sobre la configuración del endpoint para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  
  # Pruebe lo siguiente para descubrir más comandos de proxy-config
  $ istioctl proxy-config --help

• kubectl get: obtiene información sobre diferentes recursos en la mesh junto con la configuración de enrutamiento:

  # Listar todos los virtual services
  $ kubectl get virtualservices

Sí. Prometheus es un sistema de monitoreo de código abierto y una base de datos de series de tiempo. Puede usar Prometheus con Istio para registrar métricas que rastrean la salud de Istio y de las aplicaciones dentro de la service mesh. Puede visualizar métricas usando herramientas como Grafana y Kiali. Consulte Configuración para Prometheus para comprender cómo habilitar la recopilación de métricas.

Algunas notas:

• Si el pod de Prometheus se inició antes de que el pod de istiod pudiera generar los certificados requeridos y distribuirlos a Prometheus, el pod de Prometheus deberá reiniciarse para poder recopilar de los destinos protegidos con TLS mutuo.
• Si su aplicación expone las métricas de Prometheus en un puerto dedicado, ese puerto debe agregarse a las especificaciones del servicio y la implementación.