Si se produce una señal anormal en un determinado punto de prueba durante la prueba, ¿cómo determinar el punto de falla?

Se producen anomalías en el entorno de prueba: las alertas permanecen activas a través de la interfaz HTTP de Thanos Ruler, pero desde el lado de AlertManager, la alerta parece estar resuelta. Según el diseño de la plataforma DMP, la desactivación de la alarma significa que la hora de finalización establecida en la alarma ha excedido la hora actual. Hay tres posibilidades para que una alerta enviada a AlertManager esté en estado resuelta: 1. La alerta se resuelve manualmente 2. La alerta se genera solo una vez y la alerta resuelta se envía cuando las reglas de alerta se calculan por segunda vez 3. La alerta recibida por AlertManager es Hay un tiempo de resolución automática, y si el tiempo de resolución automática aún no ha llegado, el tiempo se restablecerá a 24 horas. En primer lugar, porque sabemos que el entorno de prueba no ha resuelto manualmente ninguna alerta de excepción, se descarta el primer escenario. En segundo lugar, debido a que la alerta siempre está activa, no recibirá alertas en el estado resuelto porque la alerta solo se genera una vez; Por lo que se descarta el segundo caso; finalmente, la diferencia entre el tiempo de generación de la alerta y el tiempo de resolución automática no es de 24 horas, por lo que se descarta el tercer caso. Entonces, ¿cuál es el problema?

Análisis

Comencemos analizando el problema. Según la descripción de la primera parte, nuestra suposición preliminar es que el tiempo de procesamiento en algunas etapas antes de que la alerta llegue al AlertManager es demasiado largo, lo que hace que la alerta llegue al AlertManager después del tiempo de resolución automática. Comencemos analizando el flujo de alertas a través de la plataforma para descubrir qué etapa del proceso de manejo de alertas lleva demasiado tiempo. En primer lugar, la generación de alertas requiere la cooperación de dos aspectos:

Datos métricos

Reglas de alerta

Los datos métricos se ingresan en las reglas de alerta para su cálculo. Si se cumplen las condiciones Se genera una alerta.

La plataforma DMP integra componentes relacionados con Thanos y el suministro y el cálculo de datos están separados. La plataforma DMP integra componentes de Thanos, y el suministro y el cálculo de datos están separados por Prometheus Server, y el cálculo de las reglas de alarma lo maneja Thanos Rule (en lo sucesivo, Ruler). Aquí es donde se ubican los componentes de Ruler en el clúster:

Parece que para comprender el flujo entre la generación de alertas y AlertManager, es necesario comprender la mecánica general de Ruler. La documentación oficial describe Ruler de la siguiente manera: Puede pensar en Rule como un Prometheus simplificado que no requiere descargas laterales ni raspado ni evaluación PromQL (sin QueryAPI). .

No es difícil para nosotros entender que Ruler agrega una capa basada en Prometheus y proporciona algunas funciones adicionales. Por observación, creemos aproximadamente que Ruler utiliza la biblioteca proporcionada por Prometheus para calcular reglas de alerta y proporcionar algunas funciones adicionales. El siguiente es el proceso de alerta en Ruler:

Haga clic para ingresar la descripción de la imagen

Primero, cada regla de alerta en la imagen tiene una cola activa (en lo sucesivo, cola local). ), Se utiliza para guardar alertas activas bajo una regla de alerta.

En segundo lugar, antes de que la alerta se tome de la cola local y se envíe al AlertManager, se colocará en la cola de reglas de Thanos (en lo sucesivo, la cola de búfer), que tiene dos propiedades:

capacidad (el valor predeterminado es 10000): controla el tamaño de la cola del búfer;

maxBatchSize (el valor predeterminado es 100): controla el número máximo de alertas que se pueden enviar al AlertManager en una vez

Después de comprender el proceso anterior y observar el código fuente de Ruler, descubrimos que antes de que la alerta se coloque en la cola del búfer, se establecerá en la hora de resolución automática predeterminada (hora actual 3 m), lo que afectará a la hora de inicio de la resolución automática de la alerta.

Después de este tiempo, hay dos etapas que pueden afectar el procesamiento de alertas: 1. Etapa de cola de búfer 2. Fuera de la cola de búfer a la etapa AlertManager (afectada por el retraso de la red) Dado que el entorno de prueba es un entorno LAN y no hay red. Se encuentran problemas relacionados en el medio ambiente. Inicialmente descartamos el impacto de la segunda etapa y nos centraremos en la cola del búfer a continuación. A través del código fuente relevante, encontramos que el proceso de procesamiento de alarmas en la cola del búfer es aproximadamente el siguiente: si hay una alarma en la cola local y la distancia de su última transmisión excede 1 m (valor predeterminado, se puede modificar), la alarma se colocará en la cola del búfer, subirá a las alarmas maxBatchSize y las enviará a AlertManager. En otras palabras, si se genera una gran cantidad de alertas duplicadas durante un período de tiempo, la cola del búfer se enviará con menos frecuencia. Demasiados productores y muy pocos consumidores en la cola harán que se acumulen alarmas en la cola. Por lo tanto, no es difícil adivinar que la causa del problema probablemente sea que la frecuencia de envío de la cola del búfer se vuelve baja y la cantidad de alertas enviadas a la vez es demasiado pequeña, lo que hace que la cola del búfer se acumule. A continuación, verificamos la conjetura anterior a través de dos aspectos: primero, podemos encontrar que la cola ha sido empujada aproximadamente 2000 veces en aproximadamente 20,000 segundos, es decir, un empuje cada 10 segundos en promedio. Combinado con las propiedades especiales de la cola de búfer, una alerta en la cola tarda aproximadamente (capacidad/tamaño de lote máximo) * 10 s = 16 m, y AlertManager ha excedido el tiempo de resolución automática predeterminado (3 m) después de recibir la alerta. En segundo lugar, Ruler proporciona 3 valores de indicador para monitorear el funcionamiento de la cola del búfer:

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

Al observar thanos_alert_queue_alerts_dropped_total El valor de, puede ver el número total de alertas perdidas, puede ver el número total de alertas perdidas, lo que también confirma que la cola del búfer estuvo llena en algún momento.

Resolver el problema A través del análisis anterior, básicamente hemos determinado la causa raíz del problema: la acumulación de la cola de búfer incorporada del componente Ruler provocó el retraso en el envío de alertas. Para resolver este problema, elegimos ajustar el valor maxBatchSize de la cola. Aquí se explica cómo establecer el valor. Dado que se intenta enviar a la cola del búfer cada vez que se calcula una regla de alerta, queremos estimar el número máximo de alertas para obtener el valor mínimo en el que se puede establecer maxBatchSize. Supongamos que el número de entidades que el sistema empresarial debe monitorear es x1, x2, x3...xn, y el número de reglas de alarma en las entidades es y1, y2, y3..., yn, entonces el número máximo de alarmas que se pueden generar al mismo tiempo El número de veces es (x1 * y2 x2 * y2 x3 * y3... xn * yn), y se puede aumentar hasta (y1 y2 y3... yn) veces. yn) veces, por lo tanto, para evitar que la cola del búfer se acumule, maxBatchSize debe satisfacer: maxBatchSize gt = (x1 * y2 x2 * y2 x3 * y3... xn * yn) / (y1 y2 y3... yn), suponiendo que x = max(x1, x2,...,xn), el lado derecho de la desigualdad se amplía adecuadamente a x, es decir, en otras palabras, puede establecer maxBatchSize en el mayor número de tipos de entidades de monitoreo en el sistema, para la plataforma DMP, que suele ser una instancia de MySQL.

Notas

El proceso de cálculo anterior es solo una idea de referencia. Si el valor es demasiado grande, es probable que ejerza presión sobre AlertManager y pierda la función de la cola del búfer. por lo que aún es necesario analizar la situación real. Dado que DMP integra la regla en su propio componente, es fácil modificar este valor. Si está utilizando el componente Ruler como se describe en la documentación oficial, deberá personalizar los archivos fuente.