Este artículo presenta las mejores prácticas de gestión unificada de alarmas para ayudar a las empresas a enfrentar mejor los desafíos y problemas que plantean los sistemas de monitoreo heterogéneos.
Información de contexto
En la era nativa de la nube, la escala de la infraestructura de TI empresarial es cada vez más grande y cada vez se implementan más sistemas y servicios en el entorno de la nube. Para monitorear estos entornos de TI complejos, las empresas generalmente optan por utilizar sistemas de monitoreo heterogéneos, como Prometheus, Grafana, Zabbix, etc., para obtener datos de monitoreo más completos, a fin de comprender mejor la salud y el rendimiento de su infraestructura de TI.
Sin embargo, este sistema de monitorización heterogéneo también trae algunos problemas, el más notable de los cuales es la dispersión de la información de alarma. Dado que diferentes sistemas de monitoreo pueden generar información de alarma diferente, la información puede estar dispersa en varios sistemas, lo que dificulta que las empresas comprendan completamente el estado de alarma de sus sistemas de TI. Esto hace que sea más difícil responder a las alertas, al mismo tiempo que aumenta la complejidad y la carga de trabajo de la gestión manual.
Para resolver estos problemas, las empresas necesitan una solución de gestión de alarmas más unificada y centralizada para garantizar que la información de alarma llegue a las personas adecuadas de manera oportuna para que puedan tomar rápidamente las medidas necesarias para abordar los posibles problemas.
Puntos débiles de la gestión de alarmas
Escenario 1: después de que la empresa migre a la nube, las alarmas de los productos en la nube son inconsistentes
En una arquitectura típica de implementación de aplicaciones comerciales nativas de la nube, generalmente se usan los siguientes productos ACK, ECS y RDS.La aplicación se implementa en el ECS de Alibaba Cloud a través de Kubernetes y accede al RDS en la nube. En esta arquitectura, los siguientes productos de monitoreo se utilizan generalmente para monitorear el sistema.
- Supervise la infraestructura ECS y RDS de Alibaba Cloud a través de CloudMonitor y envíe una alarma cuando los recursos sean anormales.
- Supervise Kubernetes y Pods implementados en Kubernetes a través de Prometheus y envíe una alarma cuando Kubernetes sea anormal.
- Supervise las aplicaciones implementadas en Kubernetes a través de ARMS, incluida la cadena de llamadas directas de la aplicación. Alertas cuando la aplicación es anormal.
- El registro generado por la aplicación se supervisa a través de SLS y se emite una alarma cuando el registro es anormal.
En tal escenario, dado que se utilizan múltiples productos en la nube para monitorear todo el sistema, los usuarios deben configurar repetidamente las configuraciones de operación y mantenimiento, como contactos, métodos de notificación y en servicio en múltiples productos. Además, las alarmas entre diferentes sistemas no se pueden combinar orgánicamente, y cuando ocurre un problema, las alarmas relacionadas en diferentes sistemas de alarma no se pueden asociar rápidamente.
Escenario 2: bajo la arquitectura de nube híbrida y multinube, las alarmas del sistema de monitoreo heterogéneo no están unificadas
Cuando la aplicación de una empresa se implementa en un entorno de múltiples nubes o en un entorno de nube híbrida, las alarmas generadas por el sistema de monitoreo pueden ser más dispersas y complejas, lo que genera grandes desafíos para la operación y el mantenimiento de la empresa. Debido a las diferencias entre las diferentes plataformas en la nube y las arquitecturas de nube privada, los métodos de recopilación y procesamiento de los datos de monitoreo también pueden ser diferentes. Por lo tanto, la información de alarma generada por los diferentes sistemas de monitoreo también puede mostrar diferencias, lo que traerá una serie de problemas.
En primer lugar, la información de alarma generada por diferentes sistemas de monitoreo está dispersa en diferentes lugares, y el personal de operación y mantenimiento necesita dedicar más tiempo y energía para procesar esta información. En segundo lugar, es difícil gestionar y analizar la información de alarmas generada por diferentes sistemas de forma unificada, lo que dificulta el diagnóstico y la resolución de problemas. Además, la gestión y el procesamiento de la información de alerta de diferentes sistemas pueden volverse más complejos porque puede haber información de alerta duplicada o contradictoria.
Escenario 3: sistema de monitoreo de desarrollo propio, acceso a alarma de eventos personalizado
En el proceso de desarrollo, operación y mantenimiento de aplicaciones, a medida que la escala del sistema se expande y la complejidad aumenta, los códigos de pegamento en cada esquina aumentan gradualmente. Aunque estos códigos son un vínculo importante que conecta diferentes módulos y sistemas, una vez que ocurre un problema, es difícil encontrarlo y tratarlo de inmediato porque está disperso en diferentes lugares. Esto dificulta que las empresas garanticen una alta disponibilidad y estabilidad del sistema. Cómo acceder de manera flexible y rentable a las alarmas generadas por esta parte del código también se ha convertido en uno de los puntos débiles de la operación y el mantenimiento de aplicaciones empresariales.
Gestión unificada de alarmas
En el proceso de creación de una plataforma unificada de gestión de alarmas, diferentes sistemas de monitoreo tienen diferentes definiciones de alarmas y procedimientos de procesamiento, y con frecuencia existen los siguientes problemas:
- Los formatos de alarma generados por diferentes sistemas son diferentes y los costos de acceso son altos.
- Después de conectar las alarmas entre diferentes sistemas, es difícil unificar la lógica de procesamiento debido al formato inconsistente.
- Diferentes sistemas de alarma tienen diferentes definiciones de niveles de alarma.
- Los diferentes sistemas de alarma tienen diferentes métodos de procesamiento para la recuperación automática de alarmas. Algunos sistemas de alarma admiten la recuperación automática, mientras que otros no.
La integración, el flujo de procesamiento de eventos, la estrategia de notificación y otras funciones diseñadas por la gestión de alarmas ARMS [ 1] están especialmente dirigidas al escenario de la gestión unificada de alarmas y resuelven muchos problemas encontrados en el proceso de gestión unificada.
¿Cómo accede la gestión de alarmas ARMS a las alarmas en diferentes formatos?
Las alarmas tradicionales generalmente incluyen el siguiente contenido: esta alarma estructurada generalmente solo se aplica a una sola fuente de alarma. Cuando los datos de múltiples fuentes de alarma se agregan, generalmente genera un conflicto en la estructura de datos. Por lo tanto, ARMS utiliza datos semiestructurados para almacenar alarmas.
Formato de datos de alarma de monitoreo en la nube de Alibaba:
Formato de datos de alarma Zabbix:
Formato de datos de alarma de Nagios:
Estructura de datos de alarma semiestructurada
[
{
"labels": {
"alertname": "<requiredAlertNames>",
"<labelnames>": "<labelvalues>",
...
},
"annotations": {
"<labelnames>": "<labelvalues>",
},
"startsAt": "<rfc3339>",
"endsAt": "<rfc3339>",
"generatorURL": "<generator_url>"
},
...
]
- etiquetas (labels): metadatos de alerta, un conjunto de etiquetas identifica de forma única un evento, todos los eventos con la misma etiqueta son el mismo evento, se fusionarán los informes repetidos, por ejemplo: alertname: nombre de alerta.
- anotaciones: las anotaciones son descripciones adicionales de eventos de alarma, y las anotaciones no pertenecen a los metadatos. Por ejemplo: mensaje: contenido de alarma. Las etiquetas del mismo evento que ocurre en diferentes momentos son las mismas, pero las anotaciones pueden ser diferentes. Por ejemplo, la anotación del contenido de la alarma puede ser diferente, por ejemplo: "El uso de la CPU del host i-12b3ac3*** ha sido superior al 75 % durante tres minutos y el valor actual es del 82 %".
- empieza a las (hora de inicio de la alarma): la hora de inicio del evento de alarma.
- termina en (hora de finalización de la alarma): la hora de finalización del evento de alarma.
- generatorUrl (dirección URL del evento): dirección URL del evento de alarma.
Como se muestra en el código anterior, ARMS se refiere a la definición de alarma de código abierto de Prometheus [ 2] y utiliza una estructura de datos semiestructurada para describir las alarmas. Las alarmas se describen a través de pares clave-valor altamente escalables, de modo que el contenido de la alarma se puede expandir de manera muy flexible para acceder a las alarmas generadas por diferentes fuentes de datos.
Capacidad de acceso a alarmas definida por el usuario en cualquier formato JSON
Las alarmas ARMS brindan la capacidad de acceder a cualquier formato JSON (integración personalizada [ 3] ). Siempre que la estructura de datos de la alarma cumpla con el formato JSON, se puede acceder a ella. Como se muestra en la figura siguiente, el acceso personalizado a la alarma debe cargar primero los datos JSON de la alarma en el centro de alarmas de ARMS y, a continuación, asignar la información clave del contenido de la alarma a la estructura de datos de la alarma de ARMS editando la asignación de campos en la página. .
ARMS define campos clave como nombre de alerta. Para campos más extensos, los usuarios pueden configurarlos agregando campos extendidos en la integración. Todos los campos de extensión se pueden utilizar en la lógica de procesamiento de alarma posterior. La figura siguiente es un ejemplo para asignar el campo de nombre de host en el mensaje de alarma original al campo de nombre de host ampliado y asignar el campo de información de host al campo de información de host ampliada.
Capacidad de acceso rápido de alarma de herramienta de monitoreo de uso común
De forma predeterminada, ARMS proporciona la capacidad de acceso a alarmas de varios sistemas de monitoreo dentro y fuera de la nube. Puede consultar la descripción general de la integración [ 4] para un acceso rápido.
¿Cómo unifica la gestión de alarmas ARMS los niveles de alarma?
En ARMS, las alarmas se dividen en cuatro niveles: P1, P2, P3 y P4. Al configurar la tabla de mapeo, varios tipos diferentes de grados se normalizan a cuatro grados P1-P4. Como se muestra en la figura a continuación, los tres niveles de alarma con diferentes descripciones de alarmas L1, críticas y graves se asignan a alarmas P1, de modo que se pueden unificar las diferentes definiciones de niveles de alarma en diferentes sistemas.
¿Cómo unifica la gestión de alarmas ARMS la lógica de procesamiento de alarmas en diferentes formatos?
Dado que las alarmas ARMS utilizan una estructura de datos semiestructurada, las etiquetas se pueden utilizar para unificar la lógica de procesamiento de alarmas. Normalmente necesitamos al menos 2 etiquetas para unificar la lógica de procesamiento de la alarma. Se utiliza una etiqueta para determinar quién debe ser notificado de la alarma, como una etiqueta comercial (servicio, negocio). Se utiliza otra etiqueta para determinar cómo se notificará y actualizará la aplicación de alarma. Como se muestra en la siguiente tabla, la severidad de la alarma generalmente se usa para definir el SLA del manejo de alarmas.
ARMS ha diseñado dos estrategias, la estrategia de notificación y la estrategia de escalamiento, para cumplir con los requisitos de procesamiento de diferentes niveles de alarmas. Puede consultar las mejores prácticas de estrategia de notificación [ 5] para la configuración.
Principios de diseño de etiquetas
Cuando diseñamos etiquetas comerciales para el procesamiento de alarmas, debemos cumplir con los siguientes principios:
- Principio de exclusión mutua: se refiere a evitar el uso de dos o más claves de etiqueta para el mismo recurso. Por ejemplo: si se ha utilizado el servicio de clave de etiqueta para identificar la empresa, no use claves de etiqueta similares, como biz o business.
- Principio colectivo exhaustivo: todos los recursos deben estar vinculados a la clave de etiqueta planificada y su valor de etiqueta correspondiente. Por ejemplo, si una empresa tiene 3 negocios y la clave de la etiqueta es servicio, debe haber al menos 3 valores de etiqueta que representen los 3 negocios respectivamente.
- El principio de valor limitado: se refiere a retener solo los valores de etiquetas centrales para los recursos y eliminar los valores de etiquetas redundantes. Por ejemplo: una empresa tiene 5 negocios en total, por lo que debe haber y solo etiquetas para estos 5 negocios para facilitar la gestión.
Además de las etiquetas comerciales, también se pueden definir otras etiquetas para la gestión de alarmas, como el uso de etiquetas de entorno para distinguir las alarmas de los entornos de desarrollo y prueba. Estas etiquetas deben cumplir con los principios de diseño anteriores, que pueden simplificar la complejidad de la configuración de la gestión de alarmas.
Etiquete la alarma a través del flujo de procesamiento de eventos (enriquezca la alarma)
Cómo marcar las alarmas de diferentes fuentes de alarma después de diseñar la etiqueta. En la gestión de alarmas ARMS, se diseña un flujo de procesamiento de eventos de código bajo [ 6] , y la capacidad de etiquetar alarmas (alarmas enriquecidas) se puede realizar a través de la configuración de arrastrar y soltar.
Escenario 1: etiquetar una alarma después de coincidir con una condición específica
Cierta empresa xx utiliza un sistema de monitoreo de desarrollo propio. Después de que las alarmas de desarrollo propio se conectan a la gestión de alarmas ARMS a través de la integración personalizada, estas alarmas deben marcarse uniformemente con la etiqueta comercial xx. El flujo de procesamiento de eventos se configura de la siguiente manera:
a. Inicie sesión en la consola ARMS [ 7 ] , seleccione Gestión de alarmas en la barra de navegación izquierda y luego haga clic en Nuevo flujo de procesamiento.
b. Cree un flujo de procesamiento de eventos en el panel emergente, edite la condición de activación para que coincida con el nombre de la integración personalizada como "xx sistema de monitoreo de desarrollo propio".
c. Agregue la acción Establecer etiqueta de servicio y establezca "xx" como el valor de la etiqueta de servicio (servicio).
Escenario 2: cortar cadenas y extraer etiquetas
Todos los hosts en un sistema de alarma de desarrollo propio se nombran usando un formato fijo, el formato de nomenclatura es env−env−{env}-{biz}-app−app−{app}-{group}-${index}, que necesita ser extraído El campo biz se usa como una etiqueta comercial. Después de configurar las condiciones de activación correctas, use la operación de contenido dividido para dividir el nombre de host de acuerdo con el carácter '-' y complete el contenido dividido en los campos env, service, app y group a su vez.
Escenario 3: Enriquecimiento de alarmas consultando tablas de Excel
Una plataforma de monitoreo de aplicaciones solo notifica el ID de la aplicación cuando ocurre una alarma, y necesita asociar información como el nombre de la aplicación y el responsable de la aplicación según la tabla de Excel.
a. Cree una fuente de datos de Excel y cargue el archivo app_cmdb.xlsx.
b. Configure el flujo de procesamiento de eventos, agregue operaciones de enriquecimiento de campos y seleccione la fuente de datos como la fuente de datos creada en el primer paso. Edite el campo coincidente como appId y complete otros campos en la tabla de Excel en los campos de extensión appName, propietario y propietarioTeléfono respectivamente.
**
**
Escenario 4: Enriquecimiento de alarmas llamando a servicios externos a través de Serverless (FunctionCompute)
Como en el tercer escenario anterior, cuando los datos que faltan en la alarma deben obtenerse de sistemas externos como CMDB, la alarma puede enriquecerse a través de la fuente de datos de tipo API.
a. Cree una aplicación informática funcional [ 8] , desarrolle un servicio HTTP, reciba parámetros de entrada como appId y devuelva parámetros de salida como appName, propietario, propietarioTeléfono y otros parámetros. Las siguientes capturas de pantalla son solo códigos de muestra.
b.Cree una fuente de datos del tipo API, y la dirección URL es la función desarrollada en el primer paso.
c. Configure el flujo de procesamiento de eventos, agregue operaciones de enriquecimiento de campos y seleccione la fuente de datos como la fuente de datos creada en el paso anterior. Edite el campo coincidente como appId y complete otros campos en la tabla de Excel en los campos de extensión appName, propietario y propietarioTeléfono respectivamente.
¿Cómo configurar la recuperación automática de alarmas en la gestión de alarmas ARMS?
Los diferentes sistemas de monitoreo tienen diferentes lógicas de procesamiento para la recuperación automática de alarmas. Por ejemplo, la alarma de Prometheus no enviará una alarma de recuperación en un formato específico, y solo se usa la hora de la alarma para identificar si la alarma ha terminado. El estado de restauración de la alarma en Alibaba Cloud Monitoring [ 9] se fusiona con el nivel de alarma, como se muestra a continuación.
- Parámetros: triggerLevel
- Tipo de dato: Cadena
- El nivel en el que se dispara la alarma esta vez. Valor:
<!---->
-
- CRÍTICO: grave
- ADVERTENCIA: advertencia
- INFORMACIÓN: información
- bien: normal
Las alarmas en diferentes escenarios pueden tener diferentes lógicas de procesamiento para recuperarse o no. Como la alarma de tipo de umbral, cuando el valor de monitoreo no cumple con la condición de umbral, se espera que restaure la alarma de inmediato. Sin embargo, para alarmas importantes del tipo de evento, la alarma ocurre solo por un momento y no hay proceso de recuperación. El personal de operación y mantenimiento debe confirmar manualmente que el impacto del evento se eliminó antes de que se pueda restablecer la alarma.
Escenario 1: Para las alarmas que no se recuperarán, configure el tiempo de recuperación automática y las alarmas se recuperarán automáticamente de acuerdo con el tiempo
Para las alarmas de tipo evento, normalmente es necesario confirmar manualmente el rango de impacto del evento antes de procesar la alarma. En este momento, la recuperación automática de la alarma puede provocar que el evento que se necesita procesar no se procese manualmente. En vista de esta situación, es necesario no recuperarse automáticamente después de recibir la alarma, o al menos no recuperarse automáticamente dentro de un período prolongado, y dar al personal de procesamiento una cierta cantidad de tiempo para confirmar el impacto de la alarma.
Captura de pantalla del tiempo de recuperación automática de alarma de configuración de integración personalizada de ARMS:
Escenario 2: Configure el campo de alarma de recuperación y recupere la alarma después de recibir el evento de recuperación
En la integración de alarmas de ARMS, puede configurar el campo de recuperación de alarma. Cuando el valor de un determinado campo en el contenido de la alarma cumple las condiciones, se considera una alarma de recuperación. Encuentre la alarma correspondiente según el contenido de otros campos de la alarma y restáurela. El diagrama esquemático de la recuperación activa de alarma es el siguiente:
Captura de pantalla del método de configuración de la consola ARMS:
La recuperación de alarma debe cumplir los dos puntos siguientes para recuperar correctamente la alarma correspondiente.
- Si el campo de deduplicación no está definido, las etiquetas de la alarma y la alarma de recuperación deben ser completamente consistentes para recuperar la alarma correctamente.
- Si se define el campo de deduplicación, el campo de deduplicación de la alarma y la alarma de recuperación deben ser completamente consistentes para recuperar la alarma correctamente.
Nota: Cuando se configura un campo como (estado) para completar el campo de recuperación de alarma, no agregue este campo a la regla de mapeo de alarma. Esto generalmente da como resultado una discrepancia entre los campos de alerta y alerta de restauración, y la restauración falla.
Información adicional
Función Calcular código de muestra:
# -*- coding: utf-8 -*-
import logging
import json
def handler(environ, start_response):
context = environ['fc.context']
request_uri = environ['fc.request_uri']
body_str = get_request_body(environ)
id = json.loads(body_str).get('appId')
# 这一行为伪代码，示例通过查询cmdb获取应用详细信息, 获取到的app格式如下
# {"appId":"b38cdf95-2526-4d7a-9ea9-ffe7b32*****", "appName": "iot-iam", "owner":"王五", "ownerPhone": "130xxxx1236"}
app = cmdb.getApp(id)
ret = json.dumps(app)
status = '200 OK'
response_headers = [('Content-type', 'text/plain')]
start_response(status, response_headers)
return [ret.encode('utf-8')]
def get_request_body(environ):
try:
request_body_size = int(environ.get('CONTENT_LENGTH', 0))
except (ValueError):
request_body_size = 0
request_body = environ['wsgi.input'].read(request_body_size)
return request_body
Enlaces relacionados:
[1] Gestión de alarmas ARMS
[2] Definición de alarma Prometheus
https://prometheus.io/docs/alerting/latest/clients/#sending-alerts
[3] Integración personalizada
https://help.aliyun.com/document_detail/251850.htm?spm=a2c4g.2362717.0.0.18906bf4Pry1jD#task-2021669
[4] Descripción general de la integración
[5] Mejores prácticas de política de notificación
https://help.aliyun.com/document_detail/456953.htm?spm=a2c4g.2362717.0.0.1890951awN1Sbk#task-2249792
[6] Flujo de procesamiento de eventos
https://help.aliyun.com/document_detail/311905.htm?spm=a2c4g.2362717.0.0.18901c8dwhrptl#task-2114624
[7] Consola ARMS
[8] Aplicación de cómputo de funciones
https://help.aliyun.com/document_detail/51783.htm?spm=a2c4g.2362717.0.0.189070368lSswF#multiTask782
[9] Monitoreo de la nube en la nube de Alibaba
https://help.aliyun.com/document_detail/60714.htm?spm=a2c4g.2362717.0.0.18904bf99bofq7#task-2151109
En la actualidad, el servicio de monitoreo en tiempo real de la aplicación ARMS ofrece una prueba de 15 días con todas las funciones, y los desarrolladores pueden experimentar completamente la capacidad de alarma. Haga clic aquí para obtenerlo.