Grafana: [Solicitud de función] Múltiples alertas por gráfico

Caso de uso concreto: he instrumentado mi aplicación para registrar un histograma en Prometheus para cada función principal (por ejemplo, donde se lleva a cabo una llamada HTTP externa o E/S de disco) y me gustaría recibir una alerta cuando cualquiera de estos se vuelve lento.

Actualmente tengo que definir gráficos ficticios para esto debido a la relación 1:1 entre el gráfico y la alerta. Sería mucho más lógico mantener las alertas definidas en el mismo lugar que el propio gráfico.

¿Y no puedes definir eso en una consulta?

No; una cadena de condiciones OR es tosca y el nombre único de la alerta no puede identificar claramente el motivo exacto de la alerta. Definitivamente no quiero enviar alertas Some part of service X is failing ; los ingenieros de guardia no serían mis amigos...

entonces tiene más sentido tener paneles separados para las alertas, si desea un nombre y mensaje de regla de alerta separados, etc.

Sí, eso es exactamente lo que estoy haciendo en este momento. ¿Existe alguna posibilidad de implementar múltiples alertas por gráfico en un futuro cercano para poder dejar de usar esta solución alternativa?

es muy poco probable

tal vez si hay una gran demanda :)

jaja Está bien, veré si puedo reunir a una multitud enojada;) En serio, gracias por la honestidad.

Ok, tenemos una multitud de dos :-) Estoy graficando los niveles de combustible en varios tanques y quería configurar una alerta de combustible bajo para cada tanque.

y cada tanque tiene diferentes umbrales o notificaciones?

Exactamente. Uno es un tanque de aceite de calefacción de 285 gal. Quería configurar una alerta de "bajo nivel de aceite de calefacción" cuando el tanque baje de 70 galones. El otro es un tanque de propano de 500 gal, para eso quería una alerta de "propano bajo" cuando baja de 100 gal. Configuré singlestats para cada uno, pero las alertas no están disponibles en un singlestat.

Tengo un gráfico con una mediana y una métrica de percentil 90. Me gustaría recibir una alerta sobre cada uno. Para hacer esto, tengo que crear un gráfico para cada uno. Luego, si quiero advertencias y alertas críticas para cada uno, tengo que crear un segundo gráfico para cada uno.

Tengo 30 o 40 servicios para monitorear, cada uno con 2 a 5 métricas clave. Tengo gráficos en los que represento gráficamente la misma métrica para varios clientes, y aunque no tengo que generar alertas por cliente (todavía), se suma a la cantidad de métricas sobre las que me gustaría recibir alertas. La cantidad de trabajo para crear docenas de gráficos se expande muy rápidamente. Sería muy útil en mi entorno de producción actual (y en mis entornos de producción anteriores) tener advertencias y alertas críticas, y mostrar múltiples métricas en un solo gráfico y alertar sobre ellas.

También me gustaría ver esta función. Un buen ejemplo es una alerta si una métrica se sale de un umbral y otra alerta si los datos no se actualizan. Es decir, si un valor sube demasiado o si los valores no se informan. Esto podría usarse para mostrar que lo que sea que esté informando los datos ha encontrado un problema que impide la comunicación con grafana (o cualquier backend).

¡Hola Torkelo!

¡Obtuve varios "me gusta" para la función! ¿Entraremos en el próximo lanzamiento =)?

@rmsys tal vez en algún momento, resolverlo desde la perspectiva de UX y la complejidad del código (y la complejidad de UX) llevará tiempo, aún no está en ninguna hoja de ruta, pero tal vez el próximo año a medida que el motor de alerta madure más y se trabaje en un diseño de UX para esto fuera

Otro buen caso de uso para múltiples alertas es tener diferentes umbrales de gravedad con diferentes acciones. Si un servidor comienza a mostrar ralentizaciones, un correo electrónico podría ser suficiente, pero si las ralentizaciones se vuelven extremas, podría valer la pena llamar al administrador.

Tengo un gráfico que devuelve una métrica con el valor de valid y invalid . Esto sería útil para mí porque podría usar un solo gráfico que contiene dos consultas para crear alertas que se activan cuando valid son demasiado bajos y los invalid son demasiado altos.

Además, no siempre se prefiere el seguimiento de estados separados de una alerta (ya que el usuario final necesitaría conocer los detalles detrás de los estados individuales) en lugar de solo saber si se activa la alerta.

No estoy seguro de entender lo que quieres decir con esto. ¿Puedes elaborar?

¿Puede describir cómo funcionarían y se verían varias alertas por gráfico? ¿Qué dirían las anotaciones y el corazón verde/rojo al lado del título del panel (si, por ejemplo, 2/5 reglas de alerta se disparan)?

¿Le gustaría compartir algo entre las reglas de alerta o estarían completamente aisladas (además de vivir en el mismo panel de gráficos y posiblemente hacer referencia a las mismas consultas).

¿Cómo visualizaría los umbrales cuando tiene varias reglas de alerta? ¿Aparecerían como reglas separadas en la página de reglas de alerta y en el panel de lista de alertas? Luego, necesita una forma de navegar a una instancia específica de una regla y no solo a la pestaña de alerta.

Grafana es una herramienta visual y hemos optado por vincular una regla de alerta a un gráfico para que el estado de la regla de alerta se pueda visualizar fácilmente (a través de las métricas, los umbrales y el historial de estado de alerta). Me temo que hacer que cada gráfico pueda representar múltiples reglas de alerta complicará esto en gran medida y no estoy seguro de la necesidad de esto.

@rssalerno tener soporte para reglas de alerta en el panel singlestat parece no estar relacionado con este problema.

@ alex-phillips Su escenario parece que se puede resolver haciendo que las reglas de alerta individuales sean más flexibles.

¿Alguien tiene algunos ejemplos concretos donde esto sería bueno? Simplemente no ver un escenario en el que terminaría en un gráfico confuso con 2-5 umbrales que no sabe se relacionan con qué métricas y anotaciones de historial de alertas que tampoco sabe de qué regla de alerta provienen (sin pasar el mouse).

¿Puede describir cómo funcionarían y se verían varias alertas por gráfico? ¿Qué dirían las anotaciones y el corazón verde/rojo al lado del título del panel (si, por ejemplo, 2/5 reglas de alerta se disparan)?

Creo que varias reglas de alerta se anotarían individualmente. Los corazones pueden estar codificados por colores. Sería necesario nombrar las reglas para diferenciarlas en alertas/paneles.

¿Le gustaría compartir algo entre las reglas de alerta o estarían completamente aisladas (además de vivir en el mismo panel de gráficos y posiblemente hacer referencia a las mismas consultas).

En general, creo que no, aunque sospecho que los grupos deberían tener un umbral compartido y un nombre si se implementaron (según https://github.com/grafana/grafana/issues/6557#issuecomment-324363795).

¿Cómo visualizaría los umbrales cuando tiene varias reglas de alerta? ¿Aparecerían como reglas separadas en la página de reglas de alerta y en el panel de lista de alertas? Luego, necesita una forma de navegar a una instancia específica de una regla y no solo a la pestaña de alerta.

Si las reglas toman un parámetro de color adicional, los umbrales se pueden representar usando eso, y diferenciarse como tal, probablemente también desee una información sobre herramientas. Ser capaz de alternar reglas sería útil, y creo que un parámetro para representar una regla específica se encarga de esto último.

@rssalerno tener soporte para reglas de alerta en el panel singlestat parece no estar relacionado con este problema.

Creo que encontrará que se refería al siguiente gráfico, aunque como tiene paneles separados para cada tanque, las alertas de estadísticas únicas pueden resolver su problema para ese tablero específico.

¿Alguien tiene algunos ejemplos concretos donde esto sería bueno? Simplemente no ver un escenario en el que terminaría en un gráfico confuso con 2-5 umbrales que no sabe se relacionan con qué métricas y anotaciones de historial de alertas que tampoco sabe de qué regla de alerta provienen (sin pasar el mouse).

Principalmente, me gustaría que esto sea compatible con #6557 y #6553, y para múltiples umbrales, similar a @alex-phillips. Por ejemplo, un caso de uso que tenemos para #6557 es alertar de manera diferente para diferentes entornos ( production , beta , dev , etc.), combinado con múltiples umbrales que resolver la mayoría de nuestros problemas. Si hay una mejor manera de hacerlo sin reglas múltiples, no es obvio para mí.

@torkelo

¿Puede describir cómo funcionarían y se verían varias alertas por gráfico? ¿Qué dirían las anotaciones y el corazón verde/rojo al lado del título del panel (si, por ejemplo, 2/5 reglas de alerta se disparan)?

Me gusta el enfoque sugerido por @pdf

Además, el enfoque para mostrar anotaciones sería el mismo que en el caso actual, donde tiene una regla de alerta con > 1 condición (cada una con un umbral diferente). Y el corazón verde/rojo al lado del título del panel se mostraría en rojo (si hay al menos una alerta activa), similar al escenario actual donde al menos una condición de una regla de alerta se evalúa como verdadera). Y probablemente también muestre el número (2/5) junto con el corazón rojo en el título.

¿Le gustaría compartir algo entre las reglas de alerta o estarían completamente aisladas (además de vivir en el mismo panel de gráficos y posiblemente hacer referencia a las mismas consultas).

En la mayoría de nuestros casos de uso, estas reglas no compartirían nada entre ellas y las consultas también son diferentes.

¿Cómo visualizaría los umbrales cuando tiene varias reglas de alerta? ¿Aparecerían como reglas separadas en la página de reglas de alerta y en el panel de lista de alertas? Luego, necesita una forma de navegar a una instancia específica de una regla y no solo a la pestaña de alerta.

Aparecerían como reglas separadas en la página de alertas. La pestaña Alerta, probablemente tendría una lista de alertas definida. Correcto, necesitaríamos resaltar/expandir la regla de alerta específica en esta pestaña, cuando se acceda a la URL de la regla de alerta (debe capturar la identificación o el índice de la alerta) desde la notificación. Parece ser fácilmente solucionable.

En el panel de la lista de alertas, no habría ningún cambio. Los muestra a todos por separado. Semánticamente, cada alerta es independiente. Solo que se ha colocado en el mismo panel.

¿Alguien tiene algunos ejemplos concretos donde esto sería bueno? Simplemente no ver un escenario en el que terminaría en un gráfico confuso con 2-5 umbrales que no sabe se relacionan con qué métricas y anotaciones de historial de alertas que tampoco sabe de qué regla de alerta provienen (sin pasar el mouse).

Teniendo en cuenta que mucha gente ha votado a favor de esta característica, definitivamente sería una característica útil. Si tenemos soporte para múltiples alertas, creo que dependería de la percepción de cada usuario si es confuso o no. En mi humilde opinión, aquellos que piensan que es confuso optarían por el enfoque actual de paneles separados para cada gráfico y para aquellos que piensan que la utilidad/conveniencia de tener el mismo panel utilizado para visualización y alerta supera la confusión percibida, optarán por múltiples alertas. . Seguro que cambiaría un poco la UX

En Splunk tenemos alertas altas/bajas. Si hay varias alertas disponibles en grafana, solo usaríamos la misma búsqueda, solo son umbrales diferentes contra la misma búsqueda.

+1 para esta función.

+1 por esto. Nuestro caso de uso es el siguiente: queremos definir un gráfico con, digamos, el uso de la CPU para todos nuestros servidores. Luego, en ese mismo gráfico, crearemos dos métricas ocultas, una para el uso de la CPU en los servidores de producción y otra para el uso de la CPU en los servidores que no son de producción. Cada una de esas métricas tendría su propia alerta, con diferentes canales de notificación. No queremos tener que crear múltiples gráficos, paneles o tableros para lograr esto.

+1 para esta función.

Vine aquí leyendo algunos de los otros problemas relacionados con categorías y gravedades. Acepto que todas las alertas deben ser procesables. Pero hay una diferencia entre una alerta de "arreglar esto a primera hora de la mañana" y una alerta de "llamar al asesor de $400/hora lo antes posible".

Como muchos han mencionado, esto se resuelve más comúnmente mediante umbrales de advertencia y críticos.

Técnicamente, esto podría implementarse de varias formas, etiquetas, varias alertas por panel, varios umbrales por alerta, etc.

Con respecto a la confusión si la categorización es demasiado compleja, una configuración de Advertencia/Crítico puede simplemente usar Rojo/Amarillo. El rojo anula al amarillo.

Para configuraciones más complejas, otra opción además de pasar el mouse para ubicar la serie de tiempo infractora podría ser una línea/área/lo que sea que parpadee. Eso podría llamar la atención sobre la serie temporal correcta fácilmente.

Sin embargo, creo que la mayoría de los usuarios estarían satisfechos con una separación Warn/Crit bastante simple.

Esta es una necesidad absoluta para un software de alerta, especialmente para el monitoreo del servidor. Espacio en disco, memoria, uso de la CPU, temperatura, promedio de carga... todos los principales ejemplos en los que uno querría configurar múltiples alertas con diferentes mensajes con diferentes umbrales. Tome el espacio en disco, por ejemplo. Se necesita una alerta para el uso del disco superior al 70 % y otra para el uso del disco superior al 90 %.

Un poco complicado, pero estamos usando las alertas para notificarnos si un producto no se ha vendido en unos días. Tenemos cada producto como una métrica, lo que a su vez significa que solo recibimos una alerta cuando una de las métricas ingresa al umbral de alerta. Idealmente, nos gustaría recibir una alerta si la alerta muestra que alguna métrica adicional también ha ingresado al umbral de alerta.

También estamos utilizando variables de plantilla para repetir un gráfico para cada producto seleccionado con dos métricas superpuestas (volumen y margen bruto) en el eje y izquierdo y derecho. Esto elimina cualquier posibilidad de usar alertas ya que la consulta de alerta no está seleccionando la variable de lista $sku para nuestro IN ($sku) .

Para evitar esto, intenté tener otra consulta B que simplemente ejecuta la consulta de plantilla para buscar todos los skus que nos interesan y lo coloca directamente en la consulta de alerta IN (SELECT skus from interested_product_table) . Sin embargo, esto comienza a enviarnos alertas para cada gráfico para todas las métricas en cada gráfico, lo que significa que obtenemos:

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

Por ejemplo, que es bastante spam.

Totalmente de acuerdo en que la función es imprescindible y totalmente en desacuerdo con que TODAS las notificaciones deberían ser accionables.

El ejemplo más simple es que puede tener alertas que recibe y necesita realizar alguna acción lo antes posible, como a la mañana siguiente, mientras que hay otros tipos de alertas que deberían despertarlo incluso en medio de la noche para arreglar los servidores de producción.

Aportando mis dos centavos, me encantaría tener esta función.

Ni siquiera necesito corazones diferentes o corazones de diferentes colores (el rojo para cualquier alerta en el gráfico está bien), son las notificaciones de correo electrónico para las que quiero nombres diferentes.

Agregue esta función. para un caso de uso como este,
de un solo gráfico
si valor > X --> holgura
si Valor > X+Y --> PD

Aquí tenemos una política de alertas procesables, donde la alerta debe especificar la acción a tomar si es posible. Tenemos diferentes acciones para tomar en función de que las métricas sean demasiado bajas o demasiado altas.

Por ejemplo: CPU RDS demasiado baja? verifique el comportamiento de la otra pila aquí. ¿Demasiado alto? Escale la instancia.

Al igual que con otros, también nos gusta tener diferentes tipos de alertas en diferentes umbrales.

Al igual que @jdblack , quiero tener un nivel de advertencia de agua alta y un nivel de emergencia de agua alta. Sé que puedo hacerlo con dos consultas, pero no es tan intuitivo ni hábil.

Estaba pensando en usar Grafana como una forma de señalar un sistema de escalado automático. Si la métrica es demasiado baja, envíe un webhook con un mensaje para reducir la escala; si es demasiado alta, envíe un webhook con un mensaje para escalar. Sin alertas múltiples, no creo que esto no sea posible. También estoy de acuerdo con otros en el hilo en que el caso de uso para una "advertencia" y luego un umbral "crítico" es común.

¿Quizás debería revisarse la idea de acoplar las alertas a un gráfico? Tal vez las alertas deberían crearse por separado, con un buen gráfico de vista previa al crear la alerta. Este desacoplamiento podría hacer que funcione mejor al cambiar una métrica de gráfico, pero al menos tendría más flexibilidad para generar múltiples alertas.

He estado tratando de usar Grafana + Influx para redes de sensores. Los paneles funcionan bastante bien, a excepción de las alertas. Necesito recibir una alerta cuando Sensor123 supere cierto umbral. No necesito un gráfico para eso, solo una alerta. Además, necesito tener potencialmente miles de sensores. Puedo configurar una alerta si "cualquier" sensor excede el umbral, pero necesito saber cuál(es) está(n) alertando. Tengo una configuración de paneles con variables de plantilla para ver un sensor específico, pero no puedo agregar una alerta para una variable de plantilla. Para las pruebas, solo configuro un puñado de alertas para un puñado de sensores en un tablero adicional que nadie mira, pero en el futuro necesito una solución diferente para las alertas.

@torkelo , Casi un año después de cualquier comentario oficial sobre esto, solo me preguntaba si hay alguna actualización que se pueda compartir ahora que el sistema de alerta ha estado en funcionamiento durante algún tiempo.

@MakoSDV debería considerar usar kapacitor para ese caso de uso.

+1 por esta característica; sería muy útil también para alertas de dos niveles (por ejemplo: algo > X = alerta amarilla, algo > Y = alerta roja)

+1 por hacer que las alertas sean más flexibles

Superviso los gráficos de temperatura en una caldera de calefacción, el umbral de temperatura baja es trivial y necesita ir a un canal de notificación no crítico, pero la temperatura alta es urgente y necesita zumbar a través del canal urgente. Múltiples reglas de alerta tendrían mucho sentido aquí.

Es una pena que este tema parezca abandonado. ¿Alguien sabe cómo podemos llamar la atención del desarrollador?

Parece que en cuanto a la interfaz de usuario, sería comparativamente fácil implementar alertas de la forma en que se implementan las anulaciones, para permitir una o más alertas sin muchos cambios en la interfaz de usuario.

@Gaibhne escribió:

¿Alguien sabe cómo podemos llamar la atención de los desarrolladores?

¿Pagar por el apoyo tal vez? Parece que no ha habido ningún recurso disponible para ninguna de las deficiencias graves relacionadas con las alertas, aunque se han mantenido como los problemas más valorados por los usuarios de Github durante años.

+1 por esta solicitud.

Tenemos un contador configurado en nuestra aplicación para cuando una solicitud a un servicio externo que integramos con tiempos de espera para los que hemos creado un gráfico en Grafana.

Si hay un par de tiempos de espera que nos gustaría saber para que podamos buscar el servicio externo al respecto más tarde, si hay muchos tiempos de espera, significa que es probable que nuestra aplicación se haya visto afectada para la mayoría de los clientes, por lo que debemos responder. y tratar con él inmediatamente.

+1 para esto también.

Actualmente intento configurar dos alertas separadas para un gráfico:

1. Mensaje de holgura para los datos que alcanzan un nivel de _advertencia_
2. Alerta de servicio de buscapersonas para datos que alcanzan un nivel _crítico_

Actualmente, según tengo entendido, tendría que crear dos gráficos separados de los mismos datos para lograr esto. Tendría más sentido para mí tener múltiples alertas diferentes actuando en el mismo gráfico.

@torkelo , ¿hay alguna actualización sobre los planes para esto en 2019?

+1

Tenemos tableros que monitorean los mismos microservicios para múltiples clientes/entornos usando una variable para cambiar entre el entorno mostrado.

Nuestro dolor actual podría reducirse si pudiéramos usar variables en el título/texto de la alerta para que podamos identificar el cliente/entorno, pero a más largo plazo realmente nos gustaría tener la capacidad de crear alertas separadas con diferentes umbrales usando el mismo gráfico.

Sería genial incluso si requiriera usar una consulta diferente para cada alerta y simplemente configurar la consulta para que no sea visible en el gráfico.

Lo que está describiendo @itonlytakeswon también parece estar relacionado con https://github.com/grafana/grafana/issues/6557 , por lo que es posible que también desee realizar un seguimiento de ese :)

¿Cómo es que esto no es una característica ya?

@ jsterling7 describe perfectamente nuestro caso de uso deseado.

@torkelo Cualquier versión de función

Múltiples alertas o permitir valores de etiqueta en el título/cuerpo de la alerta en algún lugar resolvería esto para nuestro uso. Tenemos un solo gráfico que muestra una métrica etiquetada con varias fuentes independientes y queremos saber cuál cae por debajo del umbral. En este momento estoy haciendo los 10 gráficos separados que necesitaré para lograr esto, pero se siente como una característica faltante y pobre para el mantenimiento a largo plazo de mi parte.

Parece que hay mucha demanda, soy uno de los que necesita este tipo de característica. Casi amo la grafana y de repente esta limitación me apaga.

Mi caso de uso es similar a otros a los que se hace referencia aquí y al problema #6557. Tenemos múltiples clústeres de elasticsearch monitoreados en un solo tablero de plantilla. Me gustaría activar alertas para ellos individualmente y, tal como está ahora, no puedo simplemente crear un gráfico con las consultas codificadas, sino que tengo que crear un gráfico para cada grupo, para que estas alertas funcionen...

+1, ¡esto sería de gran ayuda para nuestro medio ambiente! Incluso solo una configuración de dos alertas de 'corazón' amarilla/roja por gráfico, donde si se activa el rojo, anula el amarillo.

+1 esto sería genial, preguntándome cuán trivial sería permitir que cada condición tenga una notificación de alerta configurable opcional y, si no fuera por una condición específica, puede recurrir a un mensaje de notificación predeterminado... la forma más rápida de hacerlo realidad creo ?

+1 sería muy útil para nosotros también. Tenemos muchos tableros con plantillas en múltiples variables, sería genial tener una sustitución de plantillas tanto en el nombre de la alerta como en la notificación de la alerta.

+1, en mi opinión, esto debería estar presente en todos los sistemas de monitoreo... hay muchas situaciones en las que necesita identificar la gravedad de la alerta y reaccionar en consecuencia, lo que significa múltiples alertas con diferentes umbrales en el mismo tablero.

+1 de mí también - ¡me sorprende que esto no exista ya!

+1

Creo que esta función va de la mano con la limitación de la compatibilidad con consultas de plantilla.

He configurado algunos gráficos alimentados por Prometheus con consultas que tienen plantillas en la instancia y etiquetas de tipo. Resuelvo el problema de la plantilla creando consultas invisibles para los valores de la plantilla.

Me gustaría recibir alertas separadas para cada valor de plantilla, pero estoy limitado a una sola alerta con un mensaje y acción genérico único para todos. Puedo usar una lista OR larga para alertar sobre todas mis consultas, pero esto se siente crudo.

Una alternativa es hacer un tablero separado con toneladas de paneles que nadie mire, solo para servir como fuente de alerta.

Agregar soporte para alertas múltiples parece ser potencialmente el primer paso para admitir alertas de consulta de plantilla.

+1. ¡Esta es una necesidad!

+1 Esto es extremadamente útil

@torkelo "entonces tiene más sentido tener paneles separados para las alertas, si desea un nombre y mensaje de regla de alerta separados, etc."

Esto no tiene ningún sentido. Requerir que los usuarios visualicen el mismo panel varias veces solo para que puedan enviar mensajes de alerta útiles no genéricos no es una solución. Es un truco para algo que debería ser una característica y agrega ruido que degrada la utilidad del producto.

@torkelo "entonces tiene más sentido tener paneles separados para las alertas, si desea un nombre y mensaje de regla de alerta separados, etc."

Esto no tiene ningún sentido. Requerir que los usuarios visualicen el mismo panel varias veces solo para que puedan enviar mensajes de alerta útiles no genéricos no es una solución. Es un truco para algo que debería ser una característica y agrega ruido que degrada la utilidad del producto.

Exactamente. +1 para múltiples alertas por panel

En nuestra situación, estamos midiendo voltajes de celda en baterías (16 celdas por batería). Graficamos la serie 16 en un solo panel para comparar y tenemos un panel diferente para cada batería.

Una sola alerta para el panel (gráfico) no es muy útil. Realmente necesitamos la capacidad de configurar al menos una alerta por celda para que el correo electrónico de alerta indique qué celda(s) está(n) fuera de rango en términos de voltaje.

Dado que, en nuestro caso, el rango de voltaje aceptable es el mismo para cada celda, sería genial poder definir un límite superior e inferior y relacionar los rangos de celdas individuales con esos límites definidos.

Por el momento, tenemos que programar 16 sentencias OR para la serie de celdas y (re)definir los límites para cada celda en el proceso, algo doloroso de configurar y una pesadilla de mantenimiento para modificar.

Idealmente, también deberíamos programar eventos críticos y de advertencia para cada una de las celdas en el panel de gráficos.

Creo que ya es hora de que se modifique la estructura de alerta para abarcar los requisitos que los usuarios han identificado. Estos requisitos se implementan comúnmente en los sistemas SCADA que también generan alertas. Es realmente solo un motor lógico, ¿no?

¿Algún avance en esto? Siento que esta función es imprescindible para implementaciones más grandes. Especialmente porque nos gustaría tener un solo gráfico, por ejemplo, que muestre el uso del almacenamiento, queremos una alerta para el 70 %, 80 %, etc., que no debería ser una gran cantidad de gráficos.

Acabo de encontrarme con esto y estoy muy sorprendido de que no haya forma de hacerlo todavía D:

Veo aquí https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 que esto no se implementará en el futuro y parece que las alertas se eliminarán por completo de los paneles.

¿Cómo afectará esto al modelo json del tablero? ¿Alguien puede hablar de cuándo habrá más noticias sobre esto?

Esta era una característica muy necesaria. ¿Alguna actualización sobre la próxima situación?

+1 para múltiples alertas por panel

+1 para esta función.

Esta era una característica muy necesaria. ¿Alguna actualización sobre la próxima situación?

Necesita esta función.

3 años después... ¿Alguien puede decirnos por qué esto no se implementa (a pesar de la cantidad de solicitudes)?
¿Se debe a una limitación técnica para implementarlo? ¿Es rechazado? ¿Está pendiente?
Como dije anteriormente, parece una 'característica básica'.
Ejemplo: tengo un tablero y una serie con 200 servidores, si agrego una alerta:
Uno de los 200 servidores está muerto: genial. Recibo la alerta con el nombre.
Oups, un nuevo servidor está muerto: no hay alerta (o necesita actualizar el panel o esperar el recordatorio 24 horas después...)
¿Esto no es posible agregar como una casilla de verificación para marcar para que podamos ser alertados por fila en la serie (en lugar de por la serie 'completa')?
Si alguien del equipo de dev, grafana puede responder por una retroalimentación...

¿Le importaría probar con Prometheus para alertar y dejó Grafana para hacer tableros?

@beastea Si tiene que configurar otra herramienta solo para que Grafana funcione, no tiene sentido usar Grafana. Nos mudamos a Datadog porque esta funcionalidad existe allí y es solo una herramienta.

@ anne-nelson, debe configurar el recopilador de métricas, el almacenamiento de métricas y, para la configuración adecuada, jugar con HA a su alrededor para que Grafana funcione, ¿verdad?
Datadog no es solo una herramienta, solo la oculta y hace un buen trabajo, además, aún puede usar grafana con datadog: https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea No estoy seguro de cuáles son esas herramientas, así que no creo que las estemos usando. Nuestras métricas se envían a Influx, solo las enviaremos a Datadog en lugar de a Grafana. ¿Por qué debería enviar cosas a Datadog a través de Grafana cuando puedo enviarlas directamente? Quiero utilizar el menor número de herramientas posible.

@anne-nelson, puede implementar la inserción de métricas en su aplicación, pero a veces es muy útil tener algunas de las métricas del sistema impulsadas también para que pueda saber qué está pasando con sus discos y otras cosas. A esto me refiero con recopilador de métricas, un demonio local que hace cosas como Telegraf, Collectd o Fluentd.
Afluencia en su configuración: es algo que almacena métricas y brinda una gran capacidad para realizar búsquedas a través de grafana como una interfaz de interfaz de usuario web para los datos sin procesar que le brinda la oportunidad de usar algún lenguaje de consulta de afluencia interna para manipular sus datos.
En caso de tener Datadog en lugar de Influx, funciona exactamente de la misma manera. Grafana here -es una interfaz de usuario para acceder a los datos. En un montaje general. Por lo tanto, no hace nada con sus datos, solo los presenta en gráficos. Así que de todos modos los envías directamente.
En caso de que, como describió, esté trabajando con inlux, por qué no está considerando usar kapacitor o flux para resolver el problema que describió, ya que proporcionaron muchas capacidades de alcance, entonces grafana puede ofrecerle y aún son del mismo proveedor y como el mismo entorno. Flux es incluso una parte del paquete de envío de entrada.

Será realmente útil.

@beastea , entonces, ¿probablemente sea mejor eliminar la función de 'alertas' en grafana y migrar las personas a otra herramienta (para evitar una fábrica de gas de múltiples herramientas)?
Quiero decir, está bien, podemos usar kapacitor, prometheus, etc. Pero la función de alerta ya existe en Grafana, por lo que no tiene sentido en mi caso.

Por cierto, ¿qué impide agregar esta casilla de verificación para tener una alerta por fila? Probablemente una explicación pueda ayudar a entender.

@beastea Parece realmente extraño que estés tratando de convencer a alguien de que no use Grafana.

Como señaló anthosz, siempre que las alertas sean una función en Grafana, es razonable esperar la capacidad de agregar múltiples alertas a un gráfico. Si cree que no deberíamos usar Grafana para alertar, entonces Grafana no debería tener alertas como una función. Está claro que mucha gente quiere esta función y que muchos productos de la competencia ya la ofrecen. Sinceramente, no entiendo por qué hay tanto retroceso en esto.

@ anne-nelson No estoy tratando de convencer a nadie de que no haga lo que le gustaría hacer. Estoy tratando de dar un consejo para echar un vistazo en la dirección diferente que ya podría ofrecerle una solución hoy.
No estoy dictando qué debe usar para qué, estoy ofreciendo alternativas que podrían darle una solución hoy mismo. No te estoy presionando, te estoy dando un consejo. Si cree que mi consejo no es útil, es una pena, pero esto es todo. Lamento que sientas que te estoy molestando y que soy demasiado insistente con mis consejos.
Que la pases bien.

@beastea Asumí debido a tu actitud defensiva que trabajabas para Grafana. Esta función es relevante para muchas personas, y sugerir productos alternativos en una solicitud de función no es útil y descarrila esta discusión. Esto no es un desbordamiento de pila.

¿Todos pueden dejarlo? Estás enviando spam potencialmente a cientos de personas, esto no es productivo.

Lo siento por el ruido adicional de todos.

@torkelo , ¿le importaría mucho darnos una actualización sobre esta solicitud de función? Este tema ha estado abierto durante varios _años_ y, como puede ver, todavía tiene interés. Como mínimo, puede ayudar a reducir las disputas y la charla innecesaria sobre este tema para obtener algún tipo de respuesta "oficial" sobre si esto está incluido o no en la hoja de ruta actual. Salud.

Este y el #6041 que es similar se ignoran por completo. Me pregunto porque.

Para nosotros tiene sentido, ya que nuestro equipo de operaciones registra nuevas integraciones en nuestra plataforma. Automáticamente comenzamos a enviar métricas a Graphite. Y solo un panel en grafana mira todo esto.

Cuando fallan varios sistemas, solo recibimos la alerta del primero. Y tampoco muy explicativo.

Cuando uno está caído y el segundo también se apaga, la alerta no vuelve a dispararse.

El caso de uso que tengo para esto es para definir alertas de tasa de quemado de ventanas múltiples a través de Prometheus y Grafana. Esta es una práctica estándar para tener alertas de este tipo para monitorear los SLO como se define en el manual de SRE de Google en https://landing.google.com/sre/workbook/chapters/alerting-on-slos/

Imprescindible, por favor sigue esto...

¡También pasé de Prometheus alerting a Grafana Alerting y estoy deseando que llegue esto!

¿Puede alguien que haya trabajado antes en Grafana enumerar los desafíos conocidos para abordar esto?

Hola @torkelo , ¡quizás puedas iluminarnos sobre este asunto!

Es decepcionante ver que 7.x no tuvo ninguna mejora en las alertas: la sugerencia anterior de que las alertas debían eliminarse por completo no me llena de esperanza, pero si este fuera el caso, seguramente eliminarlas en 7.x hubiera sido ¿lógico dada la escala de la renovación?

Sería genial obtener algún tipo de actualización sobre por qué esto es tan difícil de implementar, solo para que podamos entender _por qué_ este problema ha estado abierto durante tanto tiempo.

@torkelo hola.
Tengo la misma necesidad: múltiples alertas para una sola métrica en un solo gráfico pero con múltiples servidores monitoreados.
Tengo ~100 servidores con una métrica definida de espacio libre en la partición '/' (por ejemplo, ya que tengo decenas de tales métricas). Y necesito recibir una única notificación de alerta única en CADA servidor si el espacio libre en '/' será inferior al 20%.
Actualmente, eso no sucederá si, por ejemplo, el servidor 2 lanza una alerta y mientras los muchachos están trabajando para resolver el problema, el servidor 4 lanza la misma alerta; no se nos notificará. ¿O me estoy perdiendo alguna funcionalidad?

La forma de multiplicación de paneles por servidor por métrica no es la forma.
¿Podría alguien darme un consejo, cómo hacer esto posible?
¿Debo actualizar mi Grafana (la versión actual es 6.3.5)? ¿Agregar algunas extensiones? ¿Complementos? ¿Algo más?

Agradezco y agradezco a todos los que puedan aconsejar o ayudar.

@torkelo hola.
Tengo la misma necesidad: múltiples alertas para una sola métrica en un solo gráfico pero con múltiples servidores monitoreados.
Tengo ~100 servidores con una métrica definida de espacio libre en la partición '/' (por ejemplo, ya que tengo decenas de tales métricas). Y necesito recibir una única notificación de alerta única en CADA servidor si el espacio libre en '/' será inferior al 20%.
Actualmente, eso no sucederá si, por ejemplo, el servidor 2 lanza una alerta y mientras los muchachos están trabajando para resolver el problema, el servidor 4 lanza la misma alerta; no se nos notificará. ¿O me estoy perdiendo alguna funcionalidad?

La forma de multiplicación de paneles por servidor por métrica no es la forma.
¿Podría alguien darme un consejo, cómo hacer esto posible?
¿Debo actualizar mi Grafana (la versión actual es 6.3.5)? ¿Agregar algunas extensiones? ¿Complementos? ¿Algo más?

Agradezco y agradezco a todos los que puedan aconsejar o ayudar.

Este problema está abierto desde 2017 (Y la respuesta de @torkelo es 🤡 "tiene más sentido tener paneles separados para las alertas" 🤡 (muy bueno crear un panel por servidor/alerta cuando tenemos 600 servidores) 🤡).

Parece que la única forma es migrar de Grafana a otra solución o crear una fábrica de gas con múltiples herramientas para mantener.

@anthosz - muchas gracias. El problema es que el medio ambiente no es nuestro sino de los clientes, por lo que sería una tarea muy difícil para mí insistir en esto para mi liderazgo y para que él supere el "no pagará por esto" de los clientes. .
Sin embargo, al menos tengo algunos hechos que dicen 'no hay posibilidad de organizar tales disparadores/alarmas, de esta manera'.

Gracias de nuevo.

_join(voz, coro)_
Tengo un sensor de corriente en un circuito que supervisa una bomba de aire de 1,5 amperios nominales y una bomba de efluentes de 10 amperios nominales. La bomba de aire funciona las 24 horas del día, los 7 días de la semana, la bomba de efluentes funciona según la demanda según los niveles del tanque. Cuando todo está bien, la corriente (I) es de 1,5 A cuando la bomba de efluentes está apagada o de 11,5 A cuando la bomba de efluentes está encendida.

La primera falla común es que la bomba de aire se quema, lo cual es alertado por (Imax < 0.5A o Iavg entre 9A y 11A) que detecta que no hay corriente o que la bomba de efluentes está funcionando cuando la bomba de aire ha muerto. Esto se debe abordar dentro de las 48 horas para evitar fallas en el sistema. Los datos son 1 punto por minuto, alertas después de 90 minutos.

La segunda alerta deseada en el mismo gráfico es (Imax > 14A o Iavg entre 2A y 9A) que indica que la bomba de efluentes está obstruida o que hay aire en la línea cuando debería estar bombeando. Esta es una alerta mucho más urgente que puede necesitar ser abordada dentro de las 3 horas, por lo que la alerta después de 5 minutos sería ideal.

Ambas alertas provienen del mismo sensor de corriente remoto que envía datos a través de LoRa. Múltiples alertas simplificarían que no tenga que duplicar una consulta del tablero para el mismo sensor.

Los gráficos múltiples de @torkelo simplemente no son escalables para muchos usuarios. Esto parece algo tan simple de agregar y tengo curiosidad por qué ustedes no lo están considerando.

tal vez si hay una gran demanda :)

Hola @torkelo , ¿qué consideras como una gran demanda? 96 comentarios y 250 "me gusta" en tu comentario es enorme? Es la octava solicitud de función abierta más comentada y solo una solicitud de función cerrada tiene más comentarios que eso. También es la tercera solicitud de función abierta con más :+1: reacciones. ¿Qué se necesita para entrar en la hoja de ruta?

@torkelo Tengo un escenario de caso muy simple.

Necesito una alerta diferente si el valor cae por debajo del umbral, que la alerta cuando el valor supera un umbral (diferente).

Aquí hay un escenario diferente. Cuando superviso el recuento de servidores en buen estado, necesito diferentes alertas cuando pierdo 1 servidor (el reinicio legítimo no es un problema a menos que tarde más de 10 minutos), en lugar de perder 5 servidores.

Aquí hay otro escenario. Me gustaría establecer una alerta diferente si la tasa de aumento en una cola supera un umbral, y una alerta diferente si el tamaño de la cola supera un umbral.

En términos de visualización, creo que la comunidad estaría contenta con cualquier solución para empezar. por ejemplo, solo visualice la primera alerta (por lo que no se necesitan cambios en la interfaz de usuario). Visualice todas las alertas con líneas verticales que, cuando se desplazan, le indican qué alerta se activó. Solo muestre umbrales/alertas cuando pase el mouse sobre una serie en particular, etc.

Sólo mis 2 centavos.

¡Hola!

Quería participar aquí, nosotros (Spotify) también necesitamos esto.

Actualmente ejecutamos nuestras propias alertas de abastecimiento de motor de alertas de Grafana y alertas por series temporales. Actualmente, empujamos las anotaciones de alerta por serie temporal de vuelta a grafana.

Entonces, en términos de la interfaz de usuario, las primeras series de tiempo en alertar hacen que el panel/alerta entre en estado de "Alerta", y cada alerta subsiguiente simplemente se acumula (el historial de estado mostrará múltiples actualizaciones "para" alertar y, de la misma manera, múltiples cambios volver a "bien")

"Necesitamos" esto, ya que así es como siempre hemos hecho las alertas, por lo que alejarse de las alertas por serie de tiempo sería un gran cambio social, para alertas de ~ 10K. Nos gustaría mucho usar y adoptar las alertas nativas de Grafana y actualizar nuestra fuente de datos para admitirlo.

Quería participar aquí, nosotros (Spotify) también necesitamos esto.

¿Usaste también la empresa Grafana? Tal vez pueda ayudar/motivar a los desarrolladores =)

También nos encantaría ver esta función, la capacidad de activar múltiples alertas desde el mismo gráfico. Brindar la capacidad de activarse en un estado "abajo" y "arriba", y tener la posibilidad de tener lo que sería efectivamente una advertencia ámbar antes de una violación de umbral más importante

Actualmente ejecutamos nuestras propias alertas de abastecimiento de motor de alertas de Grafana y alertas por series temporales. Actualmente, empujamos las anotaciones de alerta por serie temporal de vuelta a grafana.

@sjoeboo un poco fuera de tema aquí, pero ¿hay algo disponible públicamente?

@vbichov todavía no, queremos abrir el motor de alertas, aunque el marco de tiempo está cambiando. Estoy seguro de que podría compartir un parche que tenemos en nuestra bifurcación interna (difícilmente ideal) para habilitar el seguimiento de alertas por serie de tiempo a través de anotaciones.

una nota, el motor de alertas, en este momento, es específico de nuestra TSDB (https://github.com/spotify/heroic)

+1 para esta función. esto es algo así como una advertencia/crítica. Queremos recibir una advertencia antes de que la vida empeore. Entonces deberíamos recibir alertas críticas para tomar medidas inmediatas.

Me sorprende que esto no se haya implementado después de 3 años de solicitudes de los usuarios.

Tener que crear múltiples paneles (uno para cada alerta) termina obstruyendo un tablero y hace que agregar nuevas alertas sea mucho más complicado de lo que debería ser.

Siempre me pregunto por qué se muestra un 1 en la pestaña de alertas si no puede definir más de una alerta por panel. En la pestaña de consultas, este número también muestra el número de consultas definidas. Así que siempre pensé que esto sería posible y estoy bastante sorprendido de que aún no esté disponible.

Es interesante que esto todavía no se implemente. Estoy de acuerdo en que el "recuento" en la pestaña de alerta es engañoso, ya que hace creer que puede haber varios. Además, tener un panel por regla de alerta es un poco ridículo, ya que eso significa que tengo un tablero "inútil" que no es más que paneles para alertas. Seguro que es un tablero desordenado, pero es la única forma de implementarlo. Principalmente, es para que pueda tener diferentes reglas para nombres y/o combinaciones de puntos finales de notificación. Es complicado por decir lo menos.

¿Se ha hecho esto?
Grafana versión = 4.x

Ahora la versión de Grafana va a 7.x y no vi esta característica

¿Se ha hecho esto?
Grafana versión = 4.x

Ahora la versión de Grafana va a 7.x y no vi esta característica

Tan ingenuo 😁

+1 para esta función.
En una sola métrica me gustaría

1. Una alerta de advertencia para indicar que un componente no se está comportando como se esperaba y necesita una estrecha supervisión por parte del soporte de segunda línea.
2. Una alerta de error para indicar que un componente está fallando y desencadenar llamadas a ingeniería de tercera línea.
   Duplicar la métrica es torpe y hace que nuestros tableros sean confusos para el monitoreo.

Este grupo niega constantemente tantas funciones simples, verifique las muchas otras solicitudes de funciones ... esto parece algo básico.

Daré otro ejemplo.

Ejecuto una synology y me gustaría alertar sobre ella. Raid Status tiene un valor normal de 1. Sin embargo, también tiene un valor Degradado de 11 y un valor Bloqueado de 12. Degradado significa que aún se puede acceder a los datos. Crashed significa alta probabilidad de pérdida de datos.

Quiero enviar una advertencia si el Raid se degrada y una alarma crítica si el Raid se bloquea.
Tengo varios volúmenes y grupos de almacenamiento, y la necesidad de varios gráficos para cada uno no es escalable.

Esto también se puede aplicar a algo tan simple como el uso del espacio en disco.
Quiero enviar una advertencia si el uso del disco alcanza el 80 % y una alarma crítica si el uso del disco alcanza el 90 %. Hacer varios gráficos para CADA uno de mis discos no es una petición razonable.

Y no entiendo el comentario de que esto es difícil en la interfaz de usuario. Ya tienes algo similar que es una lista de Dashboards. Cuando hace clic en la pestaña Alerta, debe mostrar una lista de reglas de alerta por nombre con un botón "Crear nueva alerta" en la parte inferior. Cada regla de alerta debe tener una opción de "editar", "deshabilitar" o "eliminar" a la derecha. Al hacer clic en la alerta, o en el botón de edición, debería llevarlo a la página de edición existente que se muestra pero para esa regla de alerta específica.

Hacer varios gráficos para CADA uno de mis discos no es una petición razonable.

Puede usar la API para automatizar la creación/actualización de paneles y sus alertas. Si lo desea, puede crear un programa que consulte a Prometheus (o cualquier fuente que tenga) ejecutando consultas periódicamente para obtener un servicio que descubra los objetivos y cree alertas automáticamente para ellos.

Increíble que esta función aún no se haya implementado, con la gran cantidad de comentarios que tiene este problema.

Utilizo Grafana como nuestro motor de visualización y alertas en los telescopios Magellan. Si tengo varios subsistemas que comparten características que ameritan que estén todos en 1 trama, cuando surge un problema y uno comienza a comportarse mal, mis usuarios deben recibir una advertencia críptica y buscar cuál está fallando.

La creación de gráficos ficticios es una solución temporal, no una solución. ¡Esto parece básico!

+1 característica necesaria

+1

Exactamente la misma situación que el OP. Característica básica que ya debería haber sido implementada.

¿Pueden las personas dejar de enviar spam a este problema de hilo sin agregar nada de valor?

Use las reacciones en la parte superior del tema para señalar interés.

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc es infinitamente más útil para un mantenedor para afirmar qué problemas son "populares" que las personas que envían spam todos envían bandejas de entrada por correo electrónico y notificaciones de github con información que ya está clara con solo mirar la descripción del problema.

Si es tan básico, tal vez alguien de todos los que se quejan y que solo esperan que otras personas trabajen gratis para ellos deberían implementarlo ellos mismos y hacer una solicitud de extracción o mantener su propia bifurcación si los mantenedores no la quieren en sentido ascendente.

@thomasf "¿Pueden las personas dejar de enviar spam a este problema sin agregar nada de valor?" - ¿Igual que tú?

Si los mantenedores todavía están en el hilo, los nuevos comentarios al menos se lo recordarán. En este punto, parece un poco inútil, no hay forma de que los mantenedores lo implementen después de tanto tiempo y la gente realmente debería pasar a mejores herramientas como Datadog donde los mantenedores realmente se preocupan, pero cientos de comentarios (particularmente cuando tienen escenarios reales ) tiene mucho más impacto que solo un pulgar hacia arriba.

Si los mantenedores todavía están en el hilo, los nuevos comentarios al menos se lo recordarán. En este punto, parece un poco inútil, no hay forma de que los mantenedores lo implementen después de tanto tiempo y la gente realmente debería pasar a mejores herramientas como Datadog donde los mantenedores realmente se preocupan, pero cientos de comentarios (particularmente cuando tienen escenarios reales ) tiene mucho más impacto que solo un pulgar hacia arriba.

O tal vez los mantenedores cancelaron la suscripción a la notificación sobre este problema debido al correo no deseado, que no es el único con muchos +1/mensaje sin actualización. No compare Grafana y DataDog (éramos usuarios de ambos, no hay forma de volver a DataDog)

La mejor manera de conseguirlo es contribuir (o probablemente pagar Grafana Entreprise)

Estás muy muy equivocado. Gratis o no, no puedes poner un
forum/slack/github/feedback channel y luego ignóralo. Si lo crees
poner un software en una licencia de código abierto significa "sin quejas" y "gente
desarrollará para sus funciones de forma gratuita", está nuevamente muy, muy equivocado. En
mi caso les explique que con estas caracteristicas puedo vender grafana a diez
clientes míos. El me ignoró, significa que se enojó con un cliente. Estupendo
mudarse probablemente hacen "bastante" dinero y no quieren mas, estoy feliz
para ellos....

El martes 14 de octubre de 2020 hasta las 15:35 Thomas Frössman <
[email protected]> ha escrito:

¿Pueden las personas dejar de enviar spam a este problema de hilo sin agregar nada de
¿valor?.

Use las reacciones en la parte superior del tema para señalar interés.

Si es tan básico tal vez alguien de todos los quejosos que solo espera
otras personas para que trabajen gratis para ellos deben implementar esto ellos mismos
y hacer una solicitud de extracción o mantener su propia bifurcación si el
los mantenedores no lo quieren en upstream.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

La cantidad de dinero que estoy dispuesto a gastar en _cualquier_ software es directamente proporcional al nivel de servicio al cliente que puedo anticipar que recibiré por mi inversión. Ya sea que se trate de un producto de código abierto que ofrece "soporte pagado" o un producto comercial, en realidad no importa.

El hecho de que este problema permanezca abierto tanto tiempo sin que los mantenedores del proyecto lo miren, desafortunadamente se extrapola a un sentimiento razonable de duda sobre si algo sería diferente gastando dinero. Si está tratando de vender software, probablemente sea conveniente considerar esto.

hacer una solicitud de extracción o mantener su propia bifurcación

Si hubiera incluso una pista de los desarrolladores sobre por dónde empezar, estoy seguro de que no estoy solo al decir que consideraría esto, independientemente de si creo que debería hacerlo o no, simplemente debido a la gran cantidad de valor que tendría. proveer. Lamentablemente, ese no parece ser el caso y tengo poco interés en tratar de aplicar ingeniería inversa al producto para una característica que a los mantenedores parece no importarles realmente.

Por último, a menos que el hilo esté cerrado/bloqueado, no veo ninguna razón para que uno no diga lo que piensa. Se le permite darse de baja si eso no le conviene. De hecho, disfruto leyendo a la gente lamentándose por lo relativamente absurdo de esto. 😁

Alerting NG (NextGen) Las alertas planificadas para 8 admitirán múltiples instancias de alerta desde una sola definición de alerta. Entonces, algo como host=* con un sistema como Prometheus creará alertas por host.

Alguna información general sobre esto en el contexto de estadísticas individuales agregadas a https://github.com/grafana/grafana/issues/6983#issuecomment -712915673

Todavía estamos diseñando y creando prototipos, pero para responder a algunos pensamientos iniciales sobre las cosas:

Múltiples alertas por gráfico

La definición de alertas serán sus propias entidades, por lo que no estarán vinculadas a un panel. Las definiciones de alerta pueden convertirse en múltiples instancias de alerta. Luego, un panel puede suscribirse a instancias o definiciones. Sin embargo, me imagino que aún querremos una buena ruta de UX desde el panel del Tablero para crear alertas, porque ese es un buen flujo.

Además, no siempre se prefiere el seguimiento de estados separados de una alerta (ya que el usuario final necesitaría conocer los detalles detrás de los estados individuales) en lugar de solo saber si se activa la alerta.

Una vez que se permiten muchas alertas de una definición, la forma en que deben agruparse se convierte en un problema (ya que se puede acceder a muchas alertas). Actualmente veo dos caminos sobre cómo funcionaría esto con Alerting NG:

1. Use alertas NG con un IRM como pagerduty o alertmanager que puede manejar la agrupación de instancias de alerta.
2. Cambie su consulta para agrupar por una dimensión de alcance más grande. Entonces, por ejemplo, si consulta cluster=* en lugar de host=*,cluster=* (o agrupa por fuentes de datos similares a sql). Alternativamente, tengo la intención de agregar funcionalidad a las expresiones del lado del servidor (que vienen con alertas ng) para permitir operaciones de grupo/por pivote si la fuente de datos no hace esto. Este sería el caso cuando no se usa un IRM y se envía directamente a servicios como email/slack.

advertencia/crítico

Este es más complicado. Para el diseño WIP, lo eliminé como una función (al menos para una definición de alerta, tal vez tenga una forma de duplicar la definición de alerta, cambiarla y, de alguna manera, etiquetarla/etiquetarla con gravedad)

Esto es difícil, porque en muchos casos es muy útil:

• Para mí, advertencia/crítico tiene usos claros: acercarse a roto/roto, o degradado/roto.
• Sin ellos, muchas configuraciones terminarán repitiendo una buena cantidad de alertas para diferentes niveles de gravedad.

Entonces, ¿por qué decidir no tenerlos? Agrega bastante complejidad no obvia:

• Suponiendo que desea respaldar sus umbrales provenientes de otra métrica (o que sus umbrales sean diferentes rangos de tiempo de consulta, no valores), ahora hay dos condiciones para ejecutar.
• Para los estados de instancias de alerta, como mínimo quiero apoyar:
  
  
  
  • Desconocido: una instancia desapareció
  
  
  • Error: La consulta que habría descubierto que hay un problema con las instancias está rota
  
  
  • Alerta: la condición es verdadera
  
  
  • Normal. La condición no es cierta.
  
  
• También queremos seguir teniendo FOR como expresiones. Al agregar más estados, el diseño que no tiene aleteo, ya sea como resultado de notificaciones perdidas o ruido, es complicado. En general, las máquinas de estado a lo largo del tiempo son muy propensas a errores y son difíciles de corregir (busque TLA/Lógica temporal de acciones para obtener más información si le gusta ese tipo de cosas). Por lo tanto, agregar niveles de gravedad aumenta el espacio de estado más de lo que uno podría imaginar. Lo que significa que es más probable que tengamos comportamientos no deseados, o comportamientos para los que es más difícil tener un modelo mental.
• Al buscar integrarse con otro sistema o IRM, tener nociones específicas sobre la gravedad podría complicar la integración.

(al menos para una definición de alerta, tal vez tendrá una forma de duplicar la definición de alerta, cambiarla y, de alguna manera, etiquetarla/etiquetarla con gravedad

Esta es una solución alternativa perfectamente aceptable para la diferenciación crítica/advertencia. Estoy más que feliz de mantener umbrales separados. Sería bueno tener un umbral combinado de advertencia/crítico, pero no es un factor decisivo.

luego, cómo deben agruparse se convierte en un problema (ya que uno puede recibir muchas alertas)

Depende del usuario administrar su propio volumen de tickets y la generación de alarmas. Si está configurando alarmas, cada una debe ser un correo electrónico o notificación por separado. Piénselo de esta manera, si crea un sistema automatizado para generar tickets en función de la activación de alarmas, agrupar varias alarmas en un solo correo electrónico, por ejemplo, haría que esto fuera difícil o simplemente desagradable. Además, la aparición de múltiples alarmas en un correo electrónico significa que cada alarma no puede tener su propio hilo de correo electrónico, los usuarios tendrían que separarlas manualmente y abrir nuevos hilos. En su lugar, cada activación de alarma debe tener su propia notificación para que los hilos puedan estar contenidos en esa alarma específica.

Con suerte, esto simplifica el diseño alarmante, ya que no debería preocuparse por la agrupación. Eso depende del usuario para manejar.