Sistema de monitorización-prometheus

Sistema de monitorización-prometheus

[Parte de la imagen muestra un problema, como que la lectura de impacto puede ser el lugar para el sistema de monitoreo -prometheus ]

1. Introducción

1.1 Introducción oficial

Prometheus es un ex ingeniero de Google desde 2012 en Soundcloud en forma de kit de herramientas de monitoreo y alerta de sistemas de desarrollo de software de código abierto, desde entonces, muchas empresas y organizaciones han adoptado Prometheus como herramienta de monitoreo de alarmas. La comunidad de desarrolladores y usuarios de Prometheus es muy activa, ahora es un proyecto de código abierto independiente que se puede mantener independientemente de cualquier empresa. Para demostrarlo, Prometheus en mayo de 2016 se unió a la Fundación CNCF , convirtiéndose en Kubernetes después de los segundos proyectos gestionados por CNCF.

La imagen es relativamente antigua y ahora se ha actualizado a la versión 2.25.

1.2 Principales funciones / ventajas

• Modelo de datos multidimensional (la serie de tiempo se compone de nombre de métrica y etiquetas k / v)
• Potente declaración de consulta ( PromQL )

如以下案例：查询实例为10.224.192.\d{3}:9100的机器，用户近30s平均cpu使用率。
avg(rate(node_cpu_seconds_total{instance=~"10.224.192.\\d{3}:9100", mode="user"}[30s]))*100

• Sin dependencia de almacenamiento, soportando diferentes modelos de local y remoto. Un solo nodo de servicio tiene autonomía
• Use el protocolo http, use el modo de extracción para extraer datos, simple y fácil de entender. También puede utilizar una puerta de enlace intermedia para enviar datos
• Objetivo de supervisión, puede utilizar el descubrimiento de servicios o la configuración estática
• Admite una variedad de modelos de datos estadísticos, gráficamente amigables

1.3 Comparación de sistemas de seguimiento

Aquí hay una comparación de cuatro sistemas de monitoreo
Zabbix y Nagios, los cuales son sistemas de monitoreo veteranos.
Open-falcon es un sistema de monitoreo de código abierto de Xiaomi.

1. Desde la perspectiva de la madurez del sistema, tanto Zabbix como Nagios son sistemas de monitoreo veteranos con funciones de sistema relativamente estables y alta madurez. Tanto Prometheus como Open-Falcon nacieron en los últimos años, y las funciones aún se actualizan de forma iterativa.
2. Escalabilidad: Prometheus puede expandir las capacidades de recolección del sistema a través de varios exportadores y expandir las soluciones de almacenamiento a través de interfaces, que se presentarán más adelante.
3. En términos de actividad: la comunidad Prometheus es la más activa y también cuenta con el apoyo de CNCF;
4. En términos de rendimiento, la principal diferencia radica en el almacenamiento: Prometheus usa una base de datos de series de tiempo de alto rendimiento, Zabbix usa una base de datos relacional y tanto Nagios como Open-Falcon usan almacenamiento de datos RRD.
5. En términos de soporte de contenedores: Zabbix y Nagios aparecieron antes, y los contenedores aún no han nacido, por lo que el soporte para contenedores es relativamente pobre. Open-Falcon tiene soporte limitado para el monitoreo de contenedores. El mecanismo de descubrimiento dinámico de Prometheus admite la supervisión de varios clústeres de contenedores y actualmente es la mejor solución para la supervisión de contenedores.

1.4 En resumen

• Prometheus es una plataforma integral de monitoreo y alarma con pocas dependencias y funciones completas.

• Prometheus admite la supervisión de la nube o el contenedor, y otros sistemas supervisan principalmente el host.

• Las declaraciones de consulta de datos de Prometheus son más expresivas, con funciones estadísticas integradas más potentes.

• Prometheus no es tan bueno como InfluxDB, OpenTSDB y Sensu en términos de escalabilidad y durabilidad del almacenamiento de datos.

• Escena aplicable

  Prometheus es adecuado para grabar series de tiempo en formato de texto y es adecuado tanto para el monitoreo centrado en la máquina como para el monitoreo de arquitectura orientada a servicios altamente dinámica. En el mundo de los microservicios, tiene ventajas especiales para la recopilación de datos multidimensionales y el soporte de consultas. Prometheus está diseñado para mejorar la confiabilidad del sistema. Puede diagnosticar rápidamente problemas durante cortes de energía. Cada servidor Prometheus es independiente entre sí y no depende del almacenamiento en red ni de otros servicios remotos. Cuando la infraestructura falla, puede localizar rápidamente el punto de falla a través de Prometheus sin consumir muchos recursos de infraestructura.

• Escenarios no aplicables

  Prometheus concede gran importancia a la confiabilidad, incluso en caso de falla, siempre puede ver la información estadística disponible sobre el sistema. Si necesita una precisión del 100%, como la facturación basada en el número de solicitudes, entonces Prometheus no es adecuado para usted, porque los datos que recopila pueden no ser detallados y completos. En este caso, será mejor que utilice otros sistemas para recopilar y analizar datos para la facturación y utilizar Prometheus para supervisar el resto del sistema.

2. Diseño de arquitectura

2.1 Arquitectura general

[Error en la transferencia de la imagen del enlace externo. El sitio de origen puede tener un mecanismo de enlace anti-sanguijuela. Se recomienda guardar la imagen y subirla directamente (img-QWpDeuaA-1617093666707) (https://raw.githubusercontent.com/1458428190/ prometheus-demo / main / images /prometheus.svg)]

Prometheus contiene varios componentes clave, es decir, la parte amarilla de la figura anterior: servidor Prometheus, Pushgateway, Alertmanager y webui relacionado.

El servidor de Prometheus hará que el nodo de destino extraiga datos del descubrimiento de servicios o la configuración estática, y luego extraiga y almacene periódicamente los datos del nodo de destino. El nodo de destino aquí puede ser una variedad de exportadores que exponen directamente los datos a través de la interfaz http , o puede. Es una puerta de enlace dedicada a recibir datos push.

Prometheus también puede configurar varias reglas y luego consultar datos con regularidad. Cuando se activa la condición, enviará la alerta al administrador de alertas configurado.
Finalmente, alertmanager recibe una advertencia. Alertmanager puede agregar, desduplicar, reducir el ruido de acuerdo con la configuración y finalmente enviar una advertencia.

Prometheus admite la recopilación de información de otras instancias de prometheus. Si hay varios centros de datos, puede implementar una instancia de promeheus separada en cada datos a través de un clúster federado y luego usar un servidor central de Prometheus para agregar los datos de monitoreo de varios centros de datos.

2.2 Módulos principales

2.2.1 servidor prometheus

[Error en la transferencia de la imagen del enlace externo. El sitio de origen puede tener un mecanismo de cadena anti-sanguijuelas. Se recomienda guardar la imagen y subirla directamente (img-mJfwjY0Q-1617093666708) (https://raw.githubusercontent.com/1458428190/ prometheus-demo / main / images /prometheus-server.svg)]

De acuerdo con el principio de funcionamiento, el propio prometheus primero descubre el nodo de destino a través del administrador de descubrimiento de Scrape, luego usa el administrador de Scrape para raspar los indicadores
y luego almacena los datos en el almacenamiento local correspondiente o en el almacenamiento remoto a través de una capa de agente de almacenamiento. .

Almacenamiento local: use un formato de almacenamiento personalizado para guardar los datos de muestra en el disco local, pero el almacenamiento local en sí es menos confiable y solo se recomienda su uso en escenarios con bajos requisitos de persistencia de datos.

Almacenamiento remoto: para expandirse de manera flexible, Prometheus define dos interfaces estándar (remote_write / remote_read) para que los usuarios puedan almacenar datos en cualquier servicio de almacenamiento de terceros basado en estas dos interfaces.

RuleManager es responsable de la consulta regular de las reglas configuradas. Cuando se activa la condición, escribirá el resultado en el almacenamiento y enviará la información de alerta que debe activarse al alertmanager a través del notificador.

2.2.2 exportador

Solo necesita implementar el exportador (hay muchas bibliotecas oficiales y de terceros, o puede implementarlo usted mismo), puede recopilar muchos datos de indicadores comunes, como indicadores de base de datos, indicadores de hardware ... consulte el sitio web oficial para detalles.

2.2.3 administrador de alertas

2.2.3.1 Introducción

La capacidad de alarma se divide en dos partes independientes en la arquitectura Prometheus. Al definir AlertRule en el servidor de Prometheus, Prometheus calculará periódicamente la regla de alerta y, si se cumple la condición de activación de la alerta, enviará información de alerta a Alertmanager.

La composición de una regla de alerta:

• Nombre de la alarma

  El usuario debe nombrar la regla de alarma. Por supuesto, para nombrar, debe poder expresar directamente el contenido principal de la alarma.

• Reglas de alerta

  PromQL define realmente la regla de alarma, y ​​su significado real es cuándo el resultado de la consulta de la expresión (PromQL) dura cuánto tiempo (durante) se activará la alarma

  Alertmanager, como componente independiente, es responsable de recibir y procesar información de alerta de Prometheus Server (u otros programas cliente). Alertmanager puede realizar un procesamiento adicional de esta información de alerta, como deduplicación, agrupación y enrutamiento. En la actualidad, Prometheus tiene soporte integrado para múltiples métodos de notificación como correo electrónico y Slack. Otros métodos de notificación, como popo o notificación por SMS, se pueden implementar a través de Webhook.

  Aquí está el conocimiento previo. Las alertas en el ecosistema de Prometheus se calculan y generan en el servidor de Prometheus. Las llamadas reglas de alerta se ejecutan realmente periódicamente durante un período de PromQL, y se registrará el resultado de la consulta. La serie de tiempo ALERTAS utilizadas para alarmas {alertname = "", <etiqueta de alerta>} se utiliza para alarmas posteriores. Cuando Prometheus Server calcula algunas alarmas, no tiene la capacidad de notificar estas alarmas, solo puede enviar las alarmas a Alertmanager y Alertmanager las envía. Esta segmentación, por un lado, se debe a la consideración de responsabilidad única, por otro lado, porque el envío de alarmas no es realmente una cosa "simple" y se necesita un sistema especial para hacerlo bien. Se puede decir que el objetivo de Alertmanager no es simplemente "enviar una alerta", sino "enviar una alerta de alta calidad".

2.2.3.2 Funciones

Además de proporcionar capacidades básicas de notificación de alertas, Alertmanager también proporciona funciones de alerta como agrupación, supresión y silencio:

• Agrupación: el mecanismo de agrupación puede combinar información de alarma detallada en una notificación

  El mecanismo de agrupación puede combinar información de alarma detallada en una notificación. En algunos casos, por ejemplo, debido al tiempo de inactividad del sistema, se activa una gran cantidad de alarmas al mismo tiempo. En este caso, el mecanismo de agrupación puede combinar estas alarmas activadas en una notificación de alarma para evitar recibir una gran cantidad de notificaciones de alarma en una vez. Localice rápidamente el problema.

  Por ejemplo, cuando hay cientos de instancias de servicio en ejecución en el clúster y se establecen reglas de alarma para cada instancia. Si ocurre una falla en la red en este momento, es posible que una gran cantidad de instancias de servicio no puedan conectarse a la base de datos y, como resultado, se enviarán cientos de alarmas a Alertmanager. Como usuario, es posible que solo desee poder ver qué instancias de servicio se ven afectadas en una notificación. En este momento, las alarmas se pueden agrupar según el grupo de servicios o el nombre de la alarma, y ​​estas alarmas se pueden agrupar para formar una notificación.

  La agrupación de alarmas, la hora de la alarma y el método de recepción de alarmas se pueden configurar a través del archivo de configuración de Alertmanager.

• Supresión: cuando se envía una alarma, puede dejar de enviar repetidamente otras alarmas causadas por el mecanismo de alarma

  La supresión se refiere a un mecanismo que puede dejar de enviar otras alarmas causadas por esta alarma repetidamente después de que se envía una determinada alarma.

  Por ejemplo, cuando se activa una alarma cuando el clúster es inaccesible, todas las demás alarmas relacionadas con el clúster se pueden ignorar configurando Alertmanager. Esto puede evitar recibir una gran cantidad de notificaciones de alarma que no están relacionadas con el problema real. El mecanismo de supresión también se establece a través del archivo de configuración de Alertmanager.

  • Silencio: proporciona un mecanismo simple para manejar de forma rápida y silenciosa alarmas basadas en etiquetas. Si la alarma recibida coincide con la configuración silenciosa, Alertmanager no enviará una notificación de alarma

    Silence proporciona un mecanismo simple para manejar de forma rápida y silenciosa alarmas basadas en etiquetas. Si la alarma recibida coincide con la configuración silenciosa, Alertmanager no enviará una notificación de alarma. La configuración silenciosa debe establecerse en la página Werb de Alertmanager.

2.2.3.3 Arquitectura

[Error en la transferencia de la imagen del enlace externo. El sitio de origen puede tener un mecanismo de enlace anti-sanguijuela. Se recomienda guardar la imagen y subirla directamente (img-Ee2TYGsR-1617093666711) (https://raw.githubusercontent.com/1458428190/ prometheus-demo / main / images /alertmanager.svg)]

1. Comenzando desde la parte superior izquierda, se configura una regla de alarma en el servidor de prometheus. De forma predeterminada, estas reglas de alarma se calculan cada minuto. Si se cumplen las condiciones de activación, se generará un registro de alarma y se enviará al administrador de alertas a través de la API.
2. Alertmanager recibe el registro de alerta a través de API, luego verifica, convierte y finalmente almacena la información de alerta en AlertProvider. La implementación actual aquí se almacena en la memoria, y otros métodos de almacenamiento se pueden implementar por sí mismo a través de la interfaz.
3. Dispatcher siempre escuchará y recibirá nuevas alarmas, y enrutará las alarmas al grupo correspondiente según la configuración del árbol de enrutamiento, de manera de facilitar la gestión unificada de aquellas alarmas con la misma información de atributo [a través de group_by ** para definir el reglas de agrupación. Basado en la etiqueta contenida en la alarma]. Esto puede reducir en gran medida la tormenta de alarmas.
4. Cada grupo realizará periódicamente el procesamiento del proceso de la canalización de notificaciones con el tiempo de ciclo configurado;
5. Este proceso de canalización de notificaciones en realidad ejecuta la lógica de supresión, la lógica silenciosa, la espera de la recopilación de datos, la deduplicación, la lógica de envío y reintento, y finalmente se da cuenta de la alarma. Una vez completada la alarma, el registro de notificación se sincronizará con el clúster y, posteriormente, se utilizará para silencio entre clústeres. Y deduplicación

• Supresión de alarma

  Puede evitar que el usuario reciba una gran cantidad de otras notificaciones de alarma causadas por el problema después de que se genere una determinada alarma de problema. Por ejemplo, cuando el clúster no está disponible, es posible que el usuario solo desee recibir una alarma que le indique que hay un problema con el clúster en este momento, en lugar de una gran cantidad de notificaciones de alarma, como aplicaciones anormales en el clúster y middleware anormal. servicios.

  inhibit_rules:
  - source_match:
      alertname: NodeDown
      severity: critical
    target_match:
      severity: warning
    equal:
    - node
  

  Por ejemplo, cuando un determinado nodo de host en el clúster está anormalmente inactivo, se activa la alarma NodeDown y el nivel de alarma gravedad = crítico se define en la regla de alarma. Debido al tiempo de inactividad anormal del host, todos los servicios y middleware implementados en el host no estarán disponibles y activarán una alarma. De acuerdo con la definición de reglas de supresión, si hay un nuevo nivel de alarma de severidad = crítico, y el valor del nodo de etiqueta en la alarma es el mismo que el de la alarma NodeDown, significa que la nueva alarma es causada por NodeDown , y el mecanismo de supresión se inicia para dejar de enviar al receptor.

• Alerta de silencio

  El usuario bloquea temporalmente notificaciones de alarma específicas a través de la configuración de fondo o API. Al definir la regla de coincidencia (cadena o expresión regular) de la etiqueta, si la nueva notificación de alarma cumple con la configuración de la regla silenciosa, deje de enviar la notificación al receptor.

  

2.2.4 puerta de entrada

Su existencia permite que los trabajos por lotes y de corta duración expongan sus métricas a Prometheus. Dado que el ciclo de vida de estos trabajos puede no ser lo suficientemente largo, Prometheus no tendrá tiempo suficiente para rastrear sus métricas. Pushgateway les permite enviar sus métricas a Pushgateway, y Pushgateway luego expone estas métricas a Prometheus para que las rastree.

Las principales razones para usarlo son:

• Prometheus utiliza el modo de extracción. Es posible que Prometheus no pueda extraer directamente los datos de destino debido a que no se encuentran en la misma subred o cortafuegos.
• Al monitorear los datos comerciales, Prometheus debe agregar y recopilar diferentes datos.
• Recolección de datos para tareas temporales

Desventajas:

• Agregue datos de múltiples nodos a pushgateway. Si pushgateway falla, el impacto será mayor que múltiples objetivos.
• Prometheus pull state upsolo para pushgateway, no puede ser efectivo para cada nodo.
• Pushgateway puede conservar todos los datos de supervisión que se le envían.

Por lo tanto, incluso si su supervisión está fuera de línea, prometheus seguirá extrayendo los datos de supervisión antiguos y deberá limpiar manualmente los datos que no son necesarios para pushgateway.

3. Cómo integrar

Vea otro artículo para más detalles ~ https://juejin.cn/post/6943406808513904654