Práctica integral de observabilidad de puertas de enlace nativas en la nube

Observabilidad

La observabilidad se refiere a la capacidad de monitorear, comprender y depurar efectivamente el estado operativo, el rendimiento y el comportamiento de un sistema, aplicación o servicio.

A medida que la arquitectura del sistema evoluciona de una arquitectura única a una arquitectura de clúster y luego a una arquitectura de microservicio, las empresas se vuelven más grandes y complejas. En el contexto de la era nativa de la nube, con el surgimiento de nuevas tecnologías como microservicios, Service Mesh y Serverless, la complejidad de los negocios ha superado rápidamente los límites personales y la observabilidad se ha convertido en un factor importante en el diseño y operación de las redes distribuidas modernas. sistemas cada vez más importantes. Los métodos tradicionales de seguimiento y alerta a menudo solo se centran en algunos indicadores básicos del sistema, ignorando información y contexto más detallados. El objetivo de la observabilidad es proporcionar conocimientos más profundos y completos a través de la recopilación y el análisis de datos integrales, lo que permite a las operaciones y a los desarrolladores comprender mejor el comportamiento del sistema, solucionar problemas, predecir cuellos de botella en el rendimiento y responder a las fallas.

Los registros, las métricas y el seguimiento distribuido se conocen como los tres pilares de la observabilidad:

  1. Registro: El registro es un registro de eventos e información generada durante la operación del sistema. Al registrar los registros de la aplicación, puede comprender el estado operativo, los errores y la información de excepciones del sistema, lo que facilita la resolución de problemas y el análisis del sistema. Los sistemas de registro comunes incluyen ELK (Elasticsearch, Logstash, Kibana) y Splunk, etc.
  2. Métricas: Las métricas son métricas que se utilizan para medir el rendimiento de varios aspectos del sistema. Al recopilar y registrar datos indicadores, se puede monitorear el funcionamiento del sistema en tiempo real, incluido el uso de la CPU, el uso de la memoria, el tiempo de respuesta de la solicitud, etc. Los sistemas de indicadores más utilizados incluyen Prometheus e InfluxDB.
  3. Seguimiento distribuido: el seguimiento distribuido es una tecnología utilizada para rastrear y monitorear la ruta y el rendimiento de las solicitudes en sistemas distribuidos. Al pasar un identificador único entre solicitudes entre diferentes componentes del sistema, se puede rastrear el proceso y el consumo de tiempo de la solicitud, lo que ayuda a analizar y optimizar el rendimiento del sistema. Los sistemas de seguimiento distribuido comunes incluyen Zipkin y Apache Skywalking.

Al proporcionar una observabilidad integral y precisa, el personal de desarrollo y operación y mantenimiento del sistema puede descubrir problemas más rápidamente, comprender el comportamiento del sistema y tomar las optimizaciones y decisiones correspondientes, mejorando así el rendimiento, la estabilidad y la confiabilidad del sistema.

Sistema observable de puerta de enlace nativa en la nube

La puerta de enlace nativa en la nube de MSE se basa en los productos en la nube existentes de Alibaba Cloud (servicio de registro SLS, servicio de monitoreo de aplicaciones en tiempo real ARMS) y un buen soporte para software de código abierto para construir un sistema observable rico, que proporciona a los usuarios registros, monitoreo y enlaces potentes. Las funciones de seguimiento y alarma son las siguientes:

La capacidad de observabilidad de la puerta de enlace está dedicada a ayudar a los clientes a desarrollar una experiencia de confiabilidad del producto, brindándoles la capacidad de detectar y localizar fallas, reducir la ocurrencia de fallas y reducir el impacto de las fallas. Con base en las funciones de monitoreo y administración de alarmas de la puerta de enlace, las fallas se pueden descubrir y notificar a los clientes de manera oportuna; con base en el monitoreo y los registros, las fallas se pueden localizar rápidamente; y con base en el seguimiento de enlaces, la resolución de la causa raíz de todas las fallas de los enlaces. se puede realizar en función de las llamadas de solicitud.

Práctica observable de puerta de enlace nativa en la nube

Vista general del proceso

Este artículo comenzará con los módulos funcionales marcados en la figura siguiente para ayudar a los lectores a experimentar las capacidades de observabilidad de la puerta de enlace en el descubrimiento y localización de fallas.

El proceso general se muestra en la siguiente figura:

  1. El usuario recibe una alarma desde la puerta de enlace.
  2. Los usuarios verifican el monitoreo de Prometheus para encontrar rutas y servicios problemáticos.
  3. Los usuarios pueden ver los registros de SLS para obtener información de errores más detallada.
  4. Los usuarios rastrean la causa raíz de la solución de problemas a través de enlaces

Descripción general de la arquitectura del entorno de prueba

Este artículo implementa una serie de servicios Springboot en el clúster ACK. La relación de llamada es como se muestra en la figura anterior, donde Spring SVC 4-2 falló. Acceda al clúster ACK a través de la puerta de enlace y cree la ruta de la siguiente manera:

Durante el proceso de prueba, se accederá a la puerta de enlace a través de las siguientes tres solicitudes:

  1. Para solicitudes normales, la puerta de enlace se dirige a httpbin.
  2. Se devuelve una solicitud incorrecta en la puerta de enlace. Este artículo utiliza una solicitud que no puede llegar a la ruta.
  3. Después de que el servicio ascendente devuelve una solicitud incorrecta, la puerta de enlace se dirige a Spring SVC 1

En este momento, la tasa de error de la puerta de enlace aumentará significativamente.

Proceso de descubrimiento y localización de fallos.

Descubra fallas rápidamente a través de estrategias de alarma

Primero, configure la política de alarma de la puerta de enlace y establezca las reglas de alarma y la política de notificación en la granularidad de la instancia de la puerta de enlace. Este artículo utiliza notificaciones por correo electrónico, además de llamadas telefónicas, mensajes de texto, etc. En la siguiente figura se muestra un ejemplo de configuración de una política de alarma:

Puedes saber que el gateway está defectuoso a través del siguiente mensaje de correo electrónico:

Monitorear y localizar inicialmente problemas a través de Arms Prometheus

A continuación, consulte la sección de descripción general de la información de error de Gateway Observation Analysis->Business Monitoring->Global Dashboard. La información de monitoreo actual es la siguiente:

Según el contenido de la figura, se puede obtener la siguiente información:

  1. En el panel "Tasa de fallas granulares de la puerta de enlace", la tasa de falla general de la puerta de enlace es mayor que la tasa de fallas del servicio ascendente. Esto significa que algunas solicitudes devuelven códigos de error en la puerta de enlace y algunas solicitudes devuelven códigos de error en el servicio ascendente. .
  2. En el panel "Tasa de fallas de granularidad de ruta", puede ver que solo la ruta con el nombre de ruta "primavera" tiene una tasa de fallas distinta de 0.
  3. En el panel "Tasa de fallas de granularidad del servicio ascendente", puede ver que solo la tasa de fallas del servicio con el nombre de servicio "springboot-svc-1.app-system.svc.cluster.local" no es 0

Haga clic en el nombre de la ruta o el nombre del servicio en "Clasificación de solicitudes de enrutamiento fallidas" o "Clasificación de solicitudes de servicio ascendentes fallidas" en la figura para ver información detallada sobre la ruta o el servicio.

La información de monitoreo de ruta con el nombre de ruta "primavera" se muestra en la siguiente figura:

La información de monitoreo del servicio del nombre del servicio "springboot-svc-1.app-system.svc.cluster.local" se muestra en la siguiente figura:

La figura anterior muestra que el código de error devuelto por la ruta y el servicio erróneos es 5xx. En este punto, el problema se localizó inicialmente: el servicio ascendente "springboot-svc-1.app-system.svc.cluster.local" señaló por la ruta "primavera" "algo anda mal".

Sin embargo, aún quedan dos problemas por resolver:

  1. ¿Qué causa que se devuelvan solicitudes incorrectas en la puerta de enlace?
  2. ¿Cuál es la causa del error en el servicio "springboot-svc-1.app-system.svc.cluster.local"?

Obtenga información detallada a través de los registros de la puerta de enlace SLS

A continuación, obtenga información más detallada a través de los registros SLS en el centro de registros de la puerta de enlace.

Primero haga clic en código_respuesta y se generará automáticamente una solicitud de consulta. Puede ver que solo hay tres códigos de respuesta para la puerta de enlace durante este período: 200, 404, 500. En la página de solución de problemas de la puerta de enlace, ingrese el código de respuesta para ver las posibles causas del código de error:

Puede ver que la razón por la que se devuelve el código de respuesta 404 es que la ruta no se alcanza. De manera similar, cuando el código de respuesta es 500, puede ver el nombre de ruta y el nombre del servicio correspondientes, como se muestra en la siguiente figura:

A través de la herramienta de resolución de problemas, podemos ver que el error es causado por el servicio backend:

Hasta ahora, sólo queda una pregunta: ¿Cuál es la causa raíz del error en el servicio "springboot-svc-1.app-system.svc.cluster.local"?

Analice la cadena de llamadas a través del seguimiento de enlaces de Arms xtrace

Con la ayuda de la tecnología de seguimiento de enlaces, se puede obtener información de error más detallada. Con solo una configuración simple, la puerta de enlace se puede conectar a Arms xtrace:

Las aplicaciones Java en el clúster ACK se configuran de acuerdo con el siguiente documento: Instalación de sondas para aplicaciones Java de Container Services Kubernetes Edition [1] .

Encuentre el traceid de una solicitud incorrecta en el registro de SLS y busque el enlace de llamada correspondiente en la página de seguimiento de enlaces según el traceid para analizar la causa raíz del error del enlace de llamada:

A juzgar por los resultados del rastreo de enlaces, la causa raíz de la falla es el error del servicio springboot-svc-4-2. En este punto, se ha completado un descubrimiento completo y una localización de fallas.

Resumir

En este proceso práctico de descubrimiento y localización de fallas a través de la observabilidad de la puerta de enlace nativa de la nube, la falla primero se notificó al usuario a través de la política de alarma de la puerta de enlace, y luego la ruta y el servicio defectuosos se localizaron inicialmente a través del servicio de monitoreo Prometheus proporcionado por Arms. , se consultaron y analizaron los registros estructurados de la puerta de enlace proporcionada por el servicio de registro SLS, y se encontró que algunos errores fueron causados ​​por errores en la ruta de solicitud del cliente. Finalmente, el enlace de la llamada de servicio se analizó mediante el seguimiento del enlace y la causa raíz del La falla fue localizada exitosamente.

Enlaces relacionados:

[1] Instalar sondas para la versión Kubernetes del servicio de contenedor de aplicaciones Java

https://help.aliyun.com/zh/arms/application-monitoring/getting-started/install-arms-agent-for-java-applications-deployed-in-ack?spm=a2c4g.11186623.0.i6#arms- cs-k8s-java

Autor: Yu Cheng

Haga clic para probar el producto en la nube de forma gratuita ahora y comenzar su viaje práctico en la nube.

Enlace original

Este artículo es contenido original de Alibaba Cloud y no puede reproducirse sin permiso.

JetBrains lanza Rust IDE: RustRover Java 21 / JDK 21 (LTS) GA Con tantos desarrolladores de Java en China, debería nacer un marco de desarrollo de aplicaciones de nivel ecológico .NET 8. El rendimiento ha mejorado enormemente y está muy por delante de . NET 7. PostgreSQL 16 es lanzado por un ex miembro del equipo de Rust. Lo lamento profundamente y pedí cancelar mi nombre. Ayer completé la eliminación de Nue JS en el front-end. El autor dijo que crearé un nuevo ecosistema web. NetEase Fuxi respondió a la muerte de un empleado que fue "amenazado por RR.HH. debido a un ERROR" Ren Zhengfei: Estamos a punto de entrar en la cuarta revolución industrial, Apple es el nuevo producto "v0" del maestro de Huawei Vercel: genera código de interfaz de usuario basado en texto
{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/yunqi/blog/10112255
Recomendado
Clasificación