Observabilidad de servicios para Kubernetes habilitado para Azure Arc

  • Artículo

La observabilidad es una característica de aplicación que hace referencia a lo bien que se pueden entender las condiciones internas o el estado de un sistema a partir de sus salidas externas. Medimos los sistemas informáticos observando el tiempo de CPU, la memoria, el espacio en disco, la latencia, los errores y otras métricas. Cuanto más observable sea un sistema, más fácil resulta comprender lo que está haciendo viéndolo.

La observabilidad de un sistema tiene un efecto significativo en su costo operativo. Los sistemas observables ofrecen datos significativos y procesables a sus operadores, lo que les permite lograr resultados favorables y tener menos tiempo de inactividad. Más información no se traduce necesariamente en un sistema más observable. De hecho, a veces la cantidad de información generada por un sistema puede dificultar la identificación de señales de estado valiosas a partir del ruido generado por la aplicación.

La observabilidad del servicio es importante porque le ayuda a comprender el rendimiento y las incidencias de los sistemas distribuidos y en la nube en función de las arquitecturas dinámicas.

La implementación de una solución para lograr la observabilidad de los servicios puede ayudarle a:

  • Garantizar que los usuarios finales pueden consumir la aplicación y que se cumplan las expectativas empresariales.
  • Comprender todo el sistema y cómo funciona conjuntamente con un único panel de vidrio.
  • Establecer una línea base para el sistema y comprender cómo afectan las diferentes circunstancias al rendimiento del sistema.
  • Generar elementos de acción a partir de escenarios y comportamientos inesperados.

Kubernetes habilitado para Azure Arc proporciona dos opciones de extensión integradas para ayudarle a lograr la observabilidad de los servicios: Open Service Mesh y puerta de enlace de API Management autohospedada. Estas opciones se tratan con más detalle en las secciones de consideraciones sobre el diseño siguientes.

Architecture

En el diagrama siguiente se muestran los tres pilares de la observabilidad de servicios que afectan al volumen de datos.

A diagram depicting Services Observability Pillars.

En el diagrama siguiente se muestran varios componentes de Open Service Mesh que se ejecutan en un clúster de Kubernetes habilitado para Arc. También muestra una aplicación de ejemplo habilitada en la malla de servicio, que se configura automáticamente con un contenedor sidecar de Envoy.

A diagram depicting Open Service Mesh running in Azure Arc-enabled Kubernetes.

Consideraciones de diseño

Los tres pilares de observabilidad son métricas, registros y seguimientos. Incorpórelos a su estrategia de observabilidad para ayudar a que el sistema sea observable.

  • Las métricas son valores numéricos que describen algún aspecto de un sistema en un momento determinado y siempre se recopilan a intervalos regulares.

En la captura de pantalla siguiente se muestra una visualización de una métrica de solicitud HTTP de ejemplo para un servicio. La métrica de este ejemplo se muestra como tasa de solicitudes HTTP por minuto durante un período de tiempo especificado.

A screenshot showing H T T P request metric for a service.

  • Los registros pueden almacenar varios tipos de datos que tienen sus propias estructuras. Un registro contiene detalles sobre las transacciones que pueden permitirle obtener un caso más completo para un evento determinado. Los registros de aplicación suelen incluir marcas de tiempo, niveles de registro y cualquier información necesaria para comprender el contexto de un evento. Los registros se recopilan y envían a un servicio de registro para su almacenamiento y el análisis.

  • El seguimiento distribuido es una técnica de diagnóstico que ayuda a los usuarios a localizar errores y problemas de rendimiento dentro de las aplicaciones, especialmente cualquiera que se distribuya en varios equipos o procesos. Esta técnica realiza el seguimiento de las solicitudes mediante una aplicación que pone en correlación el trabajo realizado por diferentes componentes de la aplicación y separándolo de otro trabajo que la aplicación podría estar realizando para solicitudes simultáneas.

En la captura de pantalla siguiente se muestra una visualización de una transacción de un extremo a otro mediante Application Insights. Este objeto visual permite comprender fácilmente los tiempos de respuesta, los códigos de respuesta y las excepciones que se producen entre las solicitudes en una cadena de transacciones.

A screenshot showing end-to-end transaction trace.

Los tres pilares de métricas, registros y seguimiento distribuido están interconectados. Las métricas se almacenan como valores numéricos en una base de datos de serie temporal. También son mucho más pequeñas que los registros, lo que facilita su evaluación y utilidad para alertas casi en tiempo real. Los registros capturan y transmiten mucha más información que las métricas, lo que hace que sean útiles para una depuración más profunda. Los seguimientos tienen un ámbito de solicitud y son útiles para obtener visibilidad de una solicitud a medida que atraviesa varios componentes de un sistema distribuido.

En la tabla siguiente se muestra el impacto en la recopilación de los tres pilares.

Característica de la colección Métricas Registros Seguimiento distribuido
Cuentas para cada transacción Sí. Sí. no (muestreado)
Inmune a incidencias de cardinalidad no sí Sí.
Coste low high low

Hay diferentes maneras de lograr la observabilidad del servicio. Puede usar una malla de servicio para hacerlo en el nivel de plataforma, donde la aplicación no se da cuenta y no cambia. También puede instrumentar una aplicación con una biblioteca, que normalmente se realiza mediante una herramienta de supervisión del rendimiento de aplicaciones (APM), como Application Insights. Las puertas de enlace de API proporcionan observabilidad en el tráfico vertical de arriba a abajo, pero carecen de observabilidad en la comunicación entre pods y facilidad de configuración a escala.

En las secciones siguientes se explica cómo puede usar una malla de servicio y la puerta de enlace de API autohospedada disponible para Azure Arc para lograr la observabilidad de los servicios.

Malla de servicio

Una malla de servicio proporciona a las cargas de trabajo funcionalidades como administración del tráfico, resistencia, aplicación de directivas, seguridad de identidades y observabilidad. La aplicación se desacopla de estas funcionalidades operativas; la malla del servicio las retira de la capa de la aplicación, bajándolas al nivel de infraestructura. Esto se hace a través de un proxy de alto rendimiento que actúa de mediador con todo el tráfico entrante y saliente al servicio.

  • Kubernetes habilitado para Azure Arc admite Open Service Mesh (OSM), un proyecto de Cloud Native Computing Foundation (CNCF), que se implementa como una extensión. Open Service Mesh es una malla de servicio nativa ligera, extensible y en la nube que permite a los usuarios administrar de forma uniforme características de observación para entornos de microservicios muy dinámicos, así como protegerlas y conseguirlas de inmediato.
  • Otras mallas de servicio populares que requieren compatibilidad con proveedores incluyen Istio, Consul Conectar y Linkerd.
  • Dependiendo de las características que use al implementar una malla de servicio, es posible que se deposite una responsabilidad adicional en los operadores de aplicación para definir una configuración para cada servicio (como reglas de acceso y servicios de incorporación). Además, los operadores de clúster deben administrar y tener en cuenta el controlador de malla de servicio. Debido a la forma en que la malla de servicio usa el patrón Sidecar, se necesitan registros de acceso desde el plano de control de la malla de servicio y el sidecar al depurar la salida y la entrada.

Observabilidad de malla de servicio

La observabilidad es una funcionalidad importante entre las muchas que proporcionan las mallas de servicio. Elija un servicio de malla que cumpla los requisitos mínimos de observabilidad para reducir la cantidad de complejidad y componentes con los que la malla de servicio puede tener y que deben configurarse. Evalúe las siguientes características comunes y casos de uso de observabilidad que las mallas de servicio proporcionan:

  • Generación de métricas, incluidas las cuatro señales de oro: latencia, tráfico, errores y saturación.
  • El método RED (tarifas-llamadas/s, errores, latencias de duración-llamada), que es un subconjunto de las cuatro señales de oro y se usa para medir los servicios. La malla de servicio debe proporcionar una manera estandarizada de recopilar métricas RED, seguimientos, etc.
  • Aumento de la observabilidad, desde el aumento de la amplitud de la cobertura a todos los servicios que forman parte de la malla de servicio.
  • Características que aumentan la adopción de la observabilidad mediante la instrumentación automática de todos los servicios.
  • Sólida integración con pilares de observabilidad de servicio. La malla de servicio debe ser capaz de extraer métricas y recopilar registros que se muestran en la solución de supervisión. Asegúrese de que la recopilación de telemetría de la malla de servicio admita las necesidades empresariales y se integra bien con la solución de supervisión existente.

En el diagrama siguiente se muestra un ejemplo de la funcionalidad de proxy de malla de servicio del reenvío y la recopilación de datos.

A diagram depicting an example observability with a Service Mesh Proxy.

Puerta de enlace autohospedada de API Management

Con la integración entre Azure API Management y Azure Arc en Kubernetes, puede implementar el componente de puerta de enlace de API Management como una extensión en un clúster de Kubernetes habilitado para Azure Arc. Esto permite que una versión en contenedor de puerta de enlace de API Management se ejecute en el clúster. Todas las puertas de enlace autohospedadas se administran desde el servicio de API Management con el que están federadas, lo que proporciona visibilidad y una experiencia de administración unificada en todas las API internas y externas.

La configuración de la puerta de enlace autohospedada para aceptar el tráfico entrante para dirigir a los servicios requiere la creación de directivas. Su administración puede ser más compleja a medida que crece la escala del servicio.

Para más información, consulte la introducción a la puerta de enlace autohospedada.

Observabilidad de puerta de enlace autohospedada de API Management

La puerta de enlace autohospedada emite métricas, registros stdout y registros stderr. Las métricas emitidas se pueden configurar mediante ConfigMap en el clúster. Para información sobre la supervisión avanzada con API Management, consulte Supervisión avanzada.

La observabilidad de puerta de enlace autohospedada tiene en cuenta el tráfico externo (vertical de arriba a abajo) que entra en el clúster, pero no proporciona ninguna observabilidad para el tráfico de entre pods dentro del clúster (horizontal de derecha a izquierda).

Métricas y registros en la nube: las métricas se emiten a Azure Monitor de forma predeterminada. Log Analytics permite recopilar y ver registros de contenedor de puerta de enlace autohospedado mediante Azure Monitor para contenedores. Para más información, consulte Configuración de los registros y las métricas locales para la puerta de enlace autohospedada de Azure API Management.

Métricas y registros locales: las métricas y los registros de la puerta de enlace autohospedada se pueden integrar con las herramientas de supervisión locales o emitidas por ConfigMap. Las métricas se pueden configurar para publicar en servidores de métricas. Los registros de puerta de enlace se emiten de forma predeterminada a stdout y stderr. Para más información, consulte Configuración de los registros y las métricas locales para la puerta de enlace autohospedada de Azure API Management.

Tabla de comparación de tecnologías

En la tabla siguiente se muestran las diferencias entre las opciones de implementación para ayudarle a elegir un método para obtener la observabilidad de los servicios.

Capacidad Malla de servicio Supervisión de rendimiento de aplicaciones Puerta de enlace de API autohospedada
Tráfico horizontal de derecha a izquierda admitido Sí. sí no
Funcionalidad de métricas Sí. sí Sí.
Funcionalidad de registro Sí. Sí. implementación personalizada
Funcionalidad de seguimientos distribuidos Sí. sí Sí.
Capa de implementación red application red
Protocolos admitidos http(s), tcp, gRPC N/D http(s), websockets
Responsabilidad de configuración Operadores de clúster Desarrolladores de aplicaciones Operadores de aplicación y de clúster
Complejidad de la configuración para la observabilidad low high medio

Recomendaciones de diseño

Implemente Open Service Mesh para obtener observabilidad en el estado y el rendimiento de los servicios. Open Service Mesh usa proxies sidecar insertados como un contenedor independiente en los mismos pods que las cargas de trabajo para obtener datos de telemetría. Estos proxies interceptan todo el tráfico HTTP entrante y saliente a las cargas de trabajo y notifican los datos a Open Service Mesh. Con este sistema, los desarrolladores de servicios no necesitan instrumentar su código para recopilar datos de telemetría.

Habilite Open Service Mesh mediante la funcionalidad de extensión de clúster de Kubernetes habilitado para Azure Arc, que permite a Microsoft administrar automáticamente el plano de control. Para más información, consulte Open Service Mesh habilitado para Azure Arc.

Para maximizar la disponibilidad y el rendimiento de las aplicaciones y los servicios, habilite Información del contenedor de Azure Monitor. Ofrece una solución completa para recopilar, analizar y actuar en la telemetría desde los entornos local y en la nube. Open Service habilitado para Azure Arc Mesh se integra profundamente con Azure Monitor, lo que proporciona un método perfecto de visualización y respuesta a KPI críticos proporcionados por métricas de OSM y registros de contenedor de aplicaciones. Puede habilitar las métricas de OSM siguiendo estos pasos. Para el seguimiento distribuido, se recomienda Jaeger, que se puede integrar con el plano de control de OSM.

Open Service Mesh también proporciona integraciones de observabilidad documentadas para métricas con Prometheus y Grafana, seguimiento con Jaeger y reenvío de registros con Fluent Bit. Estas integraciones proporcionan opciones alternativas si no usa soluciones de supervisión de Azure. Puede usar estas integraciones para ampliar a otras herramientas de supervisión interna según sea necesario.

Como mínimo, debe definir las tres métricas RED siguientes y medirlas para todos los servicios:

  • Tasa de solicitudes: número de solicitudes que recibe el servicio por segundo.
  • Errores: número de solicitudes con error o tasa de solicitudes con error por segundo.
  • Duración: cantidad de tiempo que un servicio tarda en controlar una solicitud.

Open Service Mesh proporciona varios libros de servicio preconfigurados en Azure Monitor para que no tenga que configurar manualmente paneles y gráficos. Esta telemetría detallada le permite observar el comportamiento del servicio, así como solucionar problemas de las aplicaciones y mantener y optimizar estas. El uso del libro de supervisión de OSM en Azure Monitor le permite:

  • Obtener información general sobre todos los servicios de la malla y obtener métricas críticas de nivel de servicio para tres de las cuatro señales de oro de la supervisión: latencia, solicitudes y errores.
  • Definir, revisar y establecer alertas para los objetivos de nivel de servicio (SLO), que resumen el rendimiento visible para el usuario del servicio.
  • Ver gráficos de métricas para servicios individuales para que pueda analizarlos profundamente mediante filtrado y desgloses, filtrado de datos por código de respuesta, protocolo, pod de destino, origen de tráfico, etc.

Use visualizaciones de la interfaz de usuario de Jaeger para:

  • Observar una visualización del gráfico de topología que muestra qué microservicios se comunican entre sí, dónde van las solicitudes y cuánto tiempo tardan.
  • Inspeccionar las solicitudes y respuestas específicas para ver cómo y cuándo se producen para supervisar sistemas distribuidos y solucionar los problemas de estos.

La observabilidad de los servicios es solo una materia de la estrategia de supervisión en la nube. Para más información sobre las materias de administración, revise el área de diseño crítico de las materias de administración.

Pasos siguientes

Para más información sobre el recorrido de nube híbrida y multinube, consulte los siguientes artículos: