Grafana: Soporte de alertas para consultas usando variables de plantilla

+1

1. ¿Cuál sería la diferencia en comparación con solo usar todo?

+1
Sería bueno poder agregar alertas en el servidor con un tiempo de vida bajo (AWS auto scaling), registrar automáticamente el servidor en grafana es fácil con las plantillas, pero es triste no poder poner alertas en ellos

@bergquist no es práctico usar todos, por ejemplo, cuando tiene más de una docena de hosts.

Si, por ejemplo, solo algunos de ellos están fallando (digamos 5), es muy útil recibir un correo electrónico para cada alerta que falla. De esta manera, también es mucho más fácil integrarse con otras herramientas que, en general, esperan una alerta por métrica.

Sin embargo, el enfoque actual (utilizar todos) es bastante bueno cuando hay menos instancias o cuando está alertando a nivel de servicio (por ejemplo, número de trabajos en cola).

lo que dijo @calind , tengo múltiples variables $host que funcionan bien con influxDB pero no con las alertas

+1 también.

Solo un pensamiento, dado que puede consultar con una variable de plantilla, ¿no podría simplemente hacer la misma consulta con las métricas de alerta y tal vez iterar a través de los resultados para ver cuáles cumplen con los criterios de alerta?

@NotSoCleverLogin Sería posible. Pero, ¿le gustaría cambiar el comportamiento de la regla de alerta según el valor de plantilla seleccionado?

Usar la opción all para la plantilla es la única forma que tiene sentido para mí.

+1

Tengo una configuración de entornos X con los mismos componentes en cada entorno. Actualmente estamos usando Prometheus para alertar, por ejemplo, sobre el uso de la CPU/uso del disco, etc. Allí especificamos una alerta para una consulta, y cuando se activa la alerta, solo indicará desde qué entorno se activó la alerta.

Si hiciéramos esto con la variable Todo, eso funcionaría hasta cierto punto. Pero, usando el ejemplo de @calind , la captura de pantalla se llenaría con la tendencia de todas las CPU de todos mis entornos, y no solo el entorno en el que me gustaría estar informado sobre dicho problema. El gráfico se oscurecerá (o puede) con información de otros entornos. En algunos escenarios podría ser interesante comparar cpu en otros entornos, pero no hay garantías de que lo que sucede en un entorno de prueba suceda en nuestro entorno de producción, etc.

También estamos investigando la creación de paneles que puedan ser utilizados por operaciones, mostrando anotaciones para alertas en el panel de información general "estándar". Dado que usamos variables de plantilla 'env' para este tipo de tableros, no es realmente posible para nosotros hacerlo con la forma en que se implementa en este momento. Tendría que generar manualmente (al menos hasta cierto punto) un panel "sombra" donde se activan las alertas (lo que me hace perder las anotaciones en el panel de información general).

Otra cosa que creo que las variables de plantilla pueden ayudarlo a hacer es enrutar las alertas (si decide implementar dicha característica) a diferentes fuentes (algunas a operaciones si están en producción, a control de calidad/desarrolladores si están en entornos de prueba, etc.).

+1 para alertas de soporte en consultas con plantilla.

@bergquist , algunos tableros no tienen la opción _Todos_. Por ejemplo métricas del sistema por collectd (https://grafana.net/dashboards/24). Tener una opción _Todos_ ciertamente no sería práctico para, digamos, 10 o más servidores. Por eso es necesario iterar a través de variables de plantilla.

Permitir el uso de Todo es un buen y bienvenido comienzo.

En Prometheus, las consultas deben escribirse de forma diferente para permitir Todo:

some.metric{hostname=~"$Hostname"}

Fíjese en la tilde extra que hay allí, lo que permite la búsqueda de expresiones regulares (y el comodín en Todo).

No he evaluado el posible impacto en el rendimiento de pasar de una consulta directa a una consulta de búsqueda de expresiones regulares, pero al menos por ahora aparentemente resolvería nuestros problemas.

+1

+1

No estoy seguro de cómo debería implementarse, solo sé que es necesario.

+1
Usamos Prometheus como fuente de datos para monitorear nuestra infraestructura de Kubernetes para nuestros clústeres K8S locales y nuestros clústeres K8S de AWS.
Todos nuestros tableros usan variables con plantilla para la fuente de datos ($Entorno), $Instancia/Nodo, $Espacio de nombres y $Pod.
Debido a la forma en que es la estructura de consulta de Prometheus; todas las consultas tienen variables con plantilla; lo que impide que las reglas de alerta permitan guardar.
Me encantaría ver consultas variables con plantilla agregadas a las alertas.

+1

+1
Usamos paneles de plantillas para entornos de servidores múltiples, que es la forma lógica (y mucha gente lo usa), por lo que no podemos usar alertas con grafana en este momento. La única forma es tener un panel de control separado sin plantillas o configurar alertas con Prometheus, lo cual no es fácil.

tal vez si hubiera una opción o una forma simple de guardar/exportar un tablero con las variables de la plantilla respaldadas/renderizadas previamente en todos los campos... este sería quizás un buen punto intermedio hasta que se encuentre otra solución.

+1 para alertas de soporte en consultas con plantilla. Actualmente usamos plantillas en todos nuestros tableros, por lo que no podemos aprovechar esta característica realmente genial.

+1, tenemos muchos tableros con plantillas, y no podemos usar alertas por ahora, tenemos que deduplicar los tableros para tener alertas, y perdemos el poder de las plantillas

+1, casi todos nuestros tableros usan variables de plantilla (y variables de plantilla anidadas).

Nos gustaría poder configurar alertas en paneles repetidos para obtener alertas individuales por grupo de variables de plantilla si es necesario. Además, esto significa que las alertas son dinámicas y no supermanuales como ahora.

PELIGRO: en teoría, será bueno tener variables, pero debemos tener en cuenta que si alguien ingresa a su tablero y cambia el valor y guarda, las alertas resultantes se verán afectadas. No sé si ese comportamiento está bien o no, será complicado.

+1

Cuando se trabaja con grafana, parece que se fomentan las plantillas en todas partes y se siente mal crear un conjunto adicional de gráficos que no usen variables solo para usar la función de alerta ...

+1 para alertas de soporte en consultas con plantilla.
Además, descubrimos que cuando usamos el nombre de la regla en chino o el título en chino, recibimos un correo electrónico anormal con la regla activada. Por ejemplo, esperábamos la alerta “个股分时线接口请求时间(getTimeTrend)” pero recibimos "个股分ae—¶çº¿æŽ¥å £è¯·æ±‚时间( getTimeTrend) alert", tal vez el conjunto de caracteres no sea correcto.

+1 para implementar vars con plantilla en alertas

+1

+1 obtendría una gran adición

+1

+1 para implementar vars con plantilla en alertas

+1

+1 espero con ansias

+1

+1

+1

+1

¡Por favor, deja de escribir +1 !
Todos los que se hayan suscrito a este número recibirán un correo electrónico...

Hay una función de github solo para deshacerse de esos comentarios de +1 :
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick Hay un enlace en el correo electrónico donde puede silenciar el hilo y no recibir ningún correo electrónico. Pero entiendo que es posible que desee recibir una notificación cuando la función esté completa, pero también me gusta solucionar el problema para que, con suerte, se solucione antes :)

Gran progreso en las alertas en general.
Para las variables de plantilla en las alertas, también me falta. +1 :D

=
Además de eso, podría haber un error en la forma en que Grafana detecta si la métrica utilizada en query usa las variables de plantilla.

Cuando tiene una serie que usa las variables de plantilla indirectamente, Grafana no le impide agregar esa serie como una alerta. La alerta obviamente no funciona correctamente.

Vea el #K (usa #D, que usa #A y #A usa templ. var):

Todavía podría seleccionarlo:

Plantillas en todas partes, lo que significa alertar en ninguna parte.
No estoy seguro de cómo se implementaron las alertas, pero para un gráfico simple, la consulta se "traduce", las variables de plantilla se sustituyen por valores, antes de realizar una llamada a la fuente de datos, ¿verdad? Entonces, ¿por qué no en este caso? De todos modos, como dije antes, tener casi todas las consultas usando variables de plantilla, las alertas son completamente para mí. Por favor, ¿podrían implementarlo para que no tengamos que movernos alertando fuera de Grafana? ¡Muchas gracias!

Creo que debemos reconocer que las alertas con plantillas no son triviales y creo que TODAS las opciones es el camino a seguir porque no queremos que nuestras alertas cambien cuando alguien está usando el tablero.
Pero grafana aún tendría que crear nuevas alertas si la consulta de la plantilla devuelve nuevos resultados... lo que sucede con frecuencia a medida que escalamos nuestras aplicaciones.
Esto genera más problemas si está utilizando InfluxDB, ya que muchos de nosotros estamos usando etiquetas/valores de etiquetas, supongo, y no hay un filtro de tiempo para ellos... por lo que grafana crearía alertas para todos los servicios que alguna vez existieron en cualquier host... .

+1

Solo permitir especificar la fuente de datos en las alertas estaría bien para mí. No romperá ninguna lógica, y puedo especificar al menos entornos de producción y puesta en escena para observar.

TODO es una opción, seguro. Más flexible sería reconocer las variables de la plantilla en la consulta y permitir que el usuario establezca los valores en la configuración de la condición de alerta. Lo mejor, aunque complicado, supongo, sería tener múltiples alertas (de la misma manera que hay múltiples consultas) para que se pueda configurar una alerta diferente para valores de variables de plantilla diferentes en la consulta. Esto permitiría al administrador configurar diferentes condiciones de alerta para diferentes hosts, por ejemplo.

Múltiples perfiles de alerta serían geniales, pero para un pase inicial, solo proporcionar los mismos selectores de plantilla que están disponibles en el tablero en el panel de alertas resolvería muchos problemas.

También creo que debería haber un conmutador para que cada variable agregue los resultados de esa variable en una sola notificación, esto probablemente solo esté habilitado para variables de plantilla que tengan habilitada la selección múltiple. Esto proporciona un método simple pero efectivo para controlar la verbosidad de las notificaciones: es posible que desee notificar solo una vez para varias métricas relacionadas, pero notificar para cada host donde falla alguna métrica. O bien, es posible que desee notificar solo una vez por una métrica que falla, sin importar cuántos hosts se vean afectados.

¿Tenemos algún hito específico para este error?

Tuve algunos problemas con las alertas sobre consultas complicadas y consultas de variables de plantilla. Descubrí una solución fácil, que tal vez no sea agradable, pero funciona para mi caso de uso.
Simplemente extrae la consulta después de que la creaste, por lo que no hay variables de plantilla ni referencias #ROW. Esto podría ser obvio para ti, no hay ciencia espacial, pero para mí fue un cambio de vida.

Lo que hago es preparar una consulta:

luego extráigalo usando las herramientas de desarrollo de Chrome (copie el valor del parámetro de destino):

Póngalo en otra fila (cambie primero al modo de edición):

Configure las alertas:

¡Voila!

@siteshbehera Esto no es un error. Es una solicitud de función.

Pero no. No tenemos un hito para esto actualmente.

El complemento de grafana de inteligencia artificial debe incluirse en la confirmación de esta función.

Esperando plantillas en Alertas también +1

También estoy muy a favor de lo que Calind proporcionó como posible implementación en la publicación inicial. Parece encajar perfectamente en cuántos (incluido yo) usan tableros con plantilla, donde tiene un tablero, pero cambia/limita algunas variables para mirar manualmente cosas específicas. Creo que el ejemplo de la variable "servidor" podría ser el más apropiado. Allí, la variable de la plantilla (sin _all_-value) se convertiría en algo parecido a una "_tab_" en mi tablero; puedo cambiar entre ellos para ver diferentes conjuntos de datos. Entonces es fácil suponer que, al configurar una alerta, la alerta existiría para cada "_tab_" posible por separado.

En espera de plantillas de soporte en Alertas +1

Como usuario anterior de Librato donde las alertas eran parcialmente capaces de esta plantilla, me gustaría participar con una solución igualmente parcial. En Librato, cada métrica viene con una variable de "fuente", y las alertas en un gráfico serían automáticamente por fuente.

Creo que una solución igual satisfaría las necesidades aquí planteadas. Al crear una alerta, debe poder elegir un único valor de plantilla como 'fuente' y esta fuente se menciona en la alerta, todas las demás se establecen en 'todos'. Esta solución al menos evita el problema de combinatoria que se obtiene al permitir el uso de múltiples variables de plantilla.

Yo solo configuro un gráfico máximo o mínimo invisible sobre los datos que me interesan y hago la alerta sobre él, no es tan poderoso pero sigue siendo una solución funcional hasta que se resuelva este problema.

Hola, definitivamente estoy buscando esta función ya que, en la mayoría de los casos anteriores, todos mis tableros usan consultas con plantillas para admitir múltiples entornos (al menos).

¿Hay algún lugar donde se esté rastreando la hoja de ruta de grafana? ¿O alguna forma en que podamos ver si las características (como esta) se implementarán en un futuro (cercano o no tan cercano) sin molestar a los mantenedores en github? :)

Increíble realmente ansiosamente esperando este

+1

+1

Todavía no estamos seguros de cómo hacer esto.

Creo que reutilizar la variable de plantilla seleccionada para alertar sería peligroso, ya que las personas pueden optar por ver solo una opción y luego olvidarse de volver a cambiar a All o algo más amplio. No me sentiría seguro con tal comportamiento. Las reglas de alerta deben ser extremadamente fáciles de entender y razonar. Reglas explícitas > reglas mágicas.

Una solución para este problema sería tener dos valores para cada variable de plantilla. Uno para visualización en el tablero y otro para alertas. Esto haría posible tener siempre la opción más amplia de alerta y aun así seleccionar solo algunas opciones en los gráficos. La conexión de esos valores debería ser posible, pero no el comportamiento predeterminado.

Esa solución sería una característica bastante grande y compleja.

Tengo dos propuestas de solución.

1. Una propuesta a corto plazo es agregar una opción de alerta para que en el gráfico renderizado (el que se envía por correo electrónico) solo se muestren las métricas que están alertando. Esto resolvería el desorden cuando el gráfico de alerta contiene docenas de métricas.

2. Una solución a largo plazo sería iterar a través de las variables de plantilla, de modo que tenga una alerta distinta para cada combinación de valor de plantilla.

Como mencioné en noviembre. Para los usuarios de Prometheus, usar 'Todos' como valor variable es suficiente si las consultas se escriben correctamente ( some.metric{hostname=~"$Hostname"} ).

Probablemente también debería ser muy fácil de implementar.

@bergquist Creo que la opción 2 va en la dirección correcta (una implementación parcial de lo que sugerí en https://github.com/grafana/grafana/issues/6557#issuecomment-272588490), no parece demasiado complejo, ya que el código para manejar la selección de var de plantilla ya existe para el tablero, y no hay necesidad de duplicar la configuración de var, solo la selección. No creo que me moleste en conectar la selección del tablero con las alertas en el primer intento de esta función.

Lo resolví creando una nueva consulta de métrica solo para la alerta, sin las variables de plantilla y la deshabilité (para excluirla del gráfico) en Grafana versión v4.1.1.

+1 para implementar vars con plantilla en alertas

+1 para implementar vars con plantilla en alertas

¿Afecta esto a _todas_ las versiones de Grafana? ¿O era una característica que estaba disponible antes? Esto es un factor decisivo para mí y no me importaría instalar una versión anterior.

Se agregó la alerta de @alejandroandreu en la versión 4, nunca ha funcionado con plantillas.

+1 para implementar vars con plantilla en alertas

Me gustaria poder seleccionar/ingresar las combinaciones que deben evaluar las alertas, ya que algunos de los ambientes que ejecuto no son ambientes de produccion, hay dos formas de implementar esto, la primera es mas explicita, la segunda es más fácil de configurar.

Ingrese todas las combinaciones deseadas manualmente

• Esta configuración debe mostrarse en el panel de configuración de alertas

Por ejemplo, si tengo 3 variables de plantillas: cloud , region y type , llenaría una tabla que se ve así:

| nube | región | tipo |
|-------|------------|------|
| aws | nosotros-este-1 | producto |
| aws | nosotros-oeste-1 | producto |
| azur | Centro de EE. UU. | producto |

La tabla debe tener una fila adicional para insertar nuevas filas y un botón de eliminación para cada fila.

Ingrese los valores posibles y Grafana calculará el producto cartesiano

• Nota: Esta configuración se puede ingresar en el panel de configuración de variables de plantilla

| nube | región | tipo |
|-------|------------|------|
| aws | nosotros-este-1 | producto |
| azur | nosotros-oeste-1 | |
| | Centro de EE. UU. | |

Las combinaciones que se crearán para esta entrada son:

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

Pero Grafana puede manejar esta situación "ingresando" la primera variable ( cloud ) y luego filtrando los valores disponibles de la segunda variable ( region ) hasta encontrar todas las combinaciones posibles (nota: debe hacerse iterativamente para todas las variables). Esto es posible cuando las personas usan consultas en las etiquetas como esta:

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

Y en este caso, las combinaciones producidas estarán bien (que es lo mismo que la tabla en la primera opción):

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

Espero que mis sugerencias sean útiles.

Tenemos este problema (fuente de datos OpenTSDB) en un contexto ligeramente diferente: si usa una variable de plantilla para seleccionar un intervalo de reducción de muestreo en la métrica, la consulta de alerta falla con el error 400. Entiendo las dificultades para implementar una solución general, pero estamos tendrá que rediseñar varios paneles existentes para habilitar las alertas.

@dbcook suena como un problema distinto para el que probablemente debería presentar un problema por separado.

La creación de plantillas es realmente una característica increíble, al igual que las alertas. Será mejor que trabajen juntos sin problemas en lugar de cualquier solución incómoda.

@tomekit Gracias por la solución alternativa, parece prometedor mientras esperamos la implementación real. Sin embargo, no puedo encontrar dónde extraer la consulta con las herramientas de desarrollo de Chrome y, por lo tanto, no puedo copiar el valor del parámetro de destino para la nueva consulta. Intenté "Inspeccionar elemento", pero tengo dificultades para encontrar "Nombre", "Encabezados" o "Datos de formulario" que ha mostrado en la captura de pantalla.

¿Serías capaz de ilustrar los pasos para hacerlo? ¡Tu ayuda será altamente apreciada!

Gracias

@mathurj Es la pestaña Red -> XHR. ¿Ayuda ahora?

Luego haga clic en la solicitud "renderizar".

Gracias @tomekit , puedo ver esta página ahora, sin embargo, no puedo ver ninguna solicitud llamada "renderizar". Sin embargo, hay otra solicitud sobre la consulta que estoy ejecutando, pero no tiene ningún parámetro de "objetivo".

¿Alguna pista sobre cómo realizar la solicitud de "renderización"?

@mathurj Recibo la solicitud de "renderizar", una vez que miro uno de los gráficos en mi tablero y hago clic en actualizar (esquina superior derecha).

Lo intenté, todavía no hay una solicitud de "renderización" para mí :( Y tampoco un parámetro de "objetivo". Gracias de todos modos por su ayuda @tomekit . Supongo que tendré que esperar la implementación real, que podría llevar un tiempo por lo que parece. @bergquist @torkelo ?

bien trabajando con
some.metric{nombre de host=\~"$nombre de host"}
en la consulta en sí está bien,
pero es mi fuente de datos que es la plantilla aquí...

entorno=\~"$entorno"
no parece funcionar... alguna forma de que esto funcione ¿me perdí algo? o debo deshacerme de la plantilla :decepcionado:

+2

¡Esta función es especialmente útil cuando se utiliza Prometheus como fuente de datos!

Necesito esto también, por razones similares a las mencionadas anteriormente. Espero que esto funcione como para cada bucle en toda la colección que define la plantilla.

¡¡¡Necesitamos esto!!! :) 👍

Personalmente, también estoy a favor de esta característica. Estamos probando más de un sistema con un conjunto de pruebas de carga que generan métricas de retraso. En lugar de tener un tablero, estamos usando una variable para cambiar entre las fuentes de datos que contienen los datos de los distintos sistemas para tener que mantener un solo tablero y no escribirlos.
Por lo tanto, sería muy apreciado un soporte para plantillas en alertas.

+1
también necesitamos esto

+1
también necesitamos esto

+1
también necesitamos esto

¿Puedo preguntar por qué hay tantos chicos "pulgar hacia abajo" esas respuestas +1?

@skygragon es esencialmente spam inútil cuando existe la opción de hacer +1 en la publicación original. Simplemente haga clic en el icono de pulgar hacia arriba en la primera publicación.

Las variables de plantilla y las alertas son 2 de las mejores características de Grafana.
Aunque es triste ver que son mutuamente excluyentes...

+1

@bergquist , ¿podría su equipo discutir esto nuevamente y, con suerte, marcar un hito en esto? Es la función más solicitada desde hace casi 2 años y apuesto a que muchos usuarios estarían contentos con esta función.

Aún no se ha propuesto una buena solución y todavía estamos bastante seguros de que es una mala idea, ya que está mezclando dos características que sirven para diferentes propósitos. Las variables de plantilla se utilizan para tableros dinámicos y exploración. Las reglas de alerta ya se pueden hacer dinámicas con consultas de expresiones regulares/comodines. Mezclar estos dos parece una idea terrible, al menos de una manera comprensible y predecible.

Sin embargo, hay algunas buenas razones para admitirlo de alguna manera limitada, pero no estoy seguro de que valga la pena la complejidad extrema que agregaría y el costo de desarrollo. Pero estamos abiertos a ideas, sugerencias y relaciones públicas.

El problema es que tengo bastantes servidores que superviso Y se crean dinámicamente a través de Amazon, por lo que en un momento dado no sé cuántos servidores hay activos.

Tengo un gráfico con plantilla que muestra la CPU para cada servidor (por ejemplo), por lo que también me gustaría recibir alertas allí.

¿Pero estás diciendo que podría lograr lo mismo usando comodines?

@ yesman85 bueno, por supuesto, depende de su tienda de series temporales. pero la mayoría admite alguna forma de sintaxis de consulta glob/regex para apuntar a múltiples métricas que siguen un patrón de nomenclatura.

@torkelo creo que esta es la primera vez que esta posición se ha declarado públicamente. Creo que tal vez haya algún malentendido aquí: no creo que los usuarios quieran que los valores de plantilla seleccionados para la salida del tablero afecten las alertas, sino que tengan las mismas selecciones de plantilla disponibles al configurar alertas.

Sugerencias de implementación relevantes de este hilo:
https://github.com/grafana/grafana/issues/6557#issuecomment-272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641 (opción 2)

Además, temas relacionados:
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

Estas limitaciones nos han impedido poder usar Grafana para alertar sobre la ira, porque las únicas formas de hacerlo actualmente son agregar un montón de consultas ocultas separadas para alertar o crear paneles separados para alertar vs mostrar . Ambas opciones son una pesadilla de mantenimiento, y más bien limitan el gran potencial que tiene Grafana para una fácil configuración e interpretación de la monitorización por parte de los usuarios.

Creo que mi sugerencia anterior, inspirada en las alertas basadas en fuentes de Libratos, brinda una solución limitada, comprensible y predecible que parece cubrir casi todos los problemas mencionados anteriormente.

En grafana se traduciría en poder usar una y solo una variable de plantilla para alertar y cada valor en esa variable generaría su propia alerta. También podría agregar una expresión regular para filtrar dentro/fuera de cuáles desea crear alertas.

@pdf Estoy de acuerdo en que https://github.com/grafana/grafana/issues/6041 es una gran limitación, una que definitivamente queremos solucionar pero que no está relacionada con este problema. Es malo que aún no lo hayamos arreglado. Estoy de acuerdo, hemos estado un poco escasos de personal en el lado de las alertas durante los últimos meses, ¡pero eso cambiará pronto!

@danhallin eso no es lo mismo, ¿parece que se traduciría en una consulta en Grafana que apunta a muchas series usando comodines o expresiones globales en su consulta o solo filtros en un conjunto limitado de etiquetas? Las reglas de alerta de Librato se definen por separado de los tableros, ¿no es así? ¿Cómo se puede traducir en una función de filtrado de datos para todo el tablero?

La forma de hacerlo actualmente es agregar un montón de consultas ocultas separadas para alertar, lo cual es una pesadilla de mantenimiento.

Comprenda que mezclar reglas de alerta en sus gráficos con plantilla de esa manera es una pesadilla. Pero piense que admitir variables de plantilla en las alertas podría ser una pesadilla aún mayor. Probablemente sea una pregunta estúpida, pero ¿no puede crear paneles y gráficos enfocados en alertar? y dejar los tableros con muchas variables de plantilla para exploración y solución de problemas? Sé que probablemente haya muchos casos en los que serían similares, por lo que se siente como un trabajo duplicado :( El problema con las reglas de alerta en el contexto de un tablero con un par de variables de plantilla es cómo debería funcionar y ser comprensible, y cómo puede incluso implementarse en absoluto.

Digamos que una consulta usa 2 variables de plantilla, $A y $B, cada una tiene 50 valores. ¿Resultaría esto en evaluar la regla de alerta 2500 veces? Quiero decir, si las variables son de "valor único", es decir, las consultas están diseñadas para funcionar solo si $A y $B tienen un valor único, entonces tendríamos que hacerlo. Tal vez no sea un problema, tendríamos que explicar que solo se admiten variables de valores múltiples. Probablemente haya muchas más limitaciones y detalles problemáticos que harán que esta función sea muy difícil de implementar, usar y comprender.

Pero no estoy 100% en contra, creo que podría haber una manera de hacerlo de forma limitada (como solo apoyando a uno
variable de varios valores). También existe el caso de uso de tener múltiples fuentes de datos y poder apuntar a una variable de fuente de datos en su regla de alerta para reutilizar esas reglas de alerta en muchos centros de datos/entornos (que tienen TSDB separados) ese caso de uso tendría que ser resuelto el uso de una variable de plantilla de fuente de datos como una consulta de métrica con comodines no puede resolverlo.

pero, ¿no puede crear tableros y gráficos que se centren en las alertas? y dejar los tableros con muchas variables de plantilla para exploración y solución de problemas? Sé que probablemente haya muchos casos en los que serían similares, así que se siente como un trabajo duplicado :(

De hecho, edité mi comentario para hacer referencia a esta opción (y agregué un par de otros problemas de puntos débiles relacionados con las alertas). Sin embargo, como ha identificado, esto significa multiplicar la creación del tablero/panel (y el mantenimiento, si todas esas consultas necesitan una actualización) por la cantidad de variaciones de plantilla sobre las que desea alertar, y también segrega las anotaciones de alerta de la ubicación en la que pueden estar. más útil en: un tablero con plantilla con anotaciones de alerta puede ser muy útil para hacer correlaciones, pero no tanto si tiene que intentar explorar varias pestañas del navegador y tratar de alinear las cosas.

Digamos que una consulta usa 2 variables de plantilla, $A y $B, cada una tiene 50 valores. ¿Resultaría esto en evaluar la regla de alerta 2500 veces? Quiero decir, si las variables son de "valor único", es decir, las consultas están diseñadas para funcionar solo si $A y $B tienen un valor único, entonces tendríamos que hacerlo. Tal vez no sea un problema, tendríamos que explicar que solo se admiten variables de valores múltiples. Probablemente haya muchas más limitaciones y detalles problemáticos que harán que esta función sea muy difícil de implementar, usar y comprender.

Hay dos cuestiones separadas aquí, creo. Uno _está_ (creo) estrechamente relacionado con el #6041, en el sentido de que puede haber un deseo de evaluar las condiciones de alerta individualmente por serie/valores de plantilla (la alternancia agregada que mencioné en un comentario anterior). Si dejamos eso a un lado por ahora, creo que la forma ideal de resolver la mayor parte de este problema es permitir múltiples configuraciones de alerta por panel, y simplemente hacer la interpolación de variables exactamente de la misma manera que para la salida del tablero: permitir a los usuarios seleccionar solo- o valores de plantilla de valores múltiples al configurar consultas de alerta; las consultas se ejecutarán una vez por configuración de alerta, con los valores seleccionados completados; y los resultados se interpretarán exactamente de la misma forma en que se interpretan actualmente. A menos que esté malinterpretando algo gravemente, no veo esto como un aumento significativo en la complejidad, y debería ser bastante fácil de usar.

La capacidad de seleccionar valores de plantilla para simplemente limitar el alcance de las alertas seguiría siendo útil sin múltiples configuraciones de alertas (si ayuda a desarrollar esta funcionalidad en ese orden), pero sería exponencialmente más valiosa con múltiples configuraciones.

También existe el caso de uso de tener múltiples fuentes de datos y poder apuntar a una variable de fuente de datos en su regla de alerta para reutilizar esas reglas de alerta en muchos centros de datos/entornos (que tienen TSDB separados) ese caso de uso tendría que ser resuelto el uso de una variable de plantilla de fuente de datos como una consulta de métrica con comodines no puede resolverlo.

Múltiples configuraciones/consultas de alerta por panel proporcionarían un método para manejar múltiples TSDB, y una opción podría ser permitir agrupar consultas de alerta, de modo que las transiciones de estado ocurran en función del resultado de todas las consultas en el grupo (similar a cómo funcionan las cosas actualmente para la serie). No parece demasiado complicado.

Esta es definitivamente una necesidad popular. Ahora, para lograr Alertar, tuvimos que movernos
lejos de Grafana y crea nuestra solución personalizada usando Graphite's Render
Datos sin procesar de API. No creo que admita alertas en dinámicas / plantillas.
los datos son complejos al menos usando Graphite..

Un pensamiento más es,. Por qué Grafana tiene la sección Alertas como parte del tablero
config si esto se considera complejo. Puedes alejarlo para separarlo.
Vista de alertas donde los usuarios solo pueden ingresar/configurar su consulta dinámica,
intervalo, condición de evaluación allí.. Puede ser que esto podría significar que
no tener tableros duplicados. ¿Tiene sentido?

BR,
Vishwa..

El 23 de agosto de 2017 a las 8:01 a. m., "Peter Fern" [email protected] escribió:

pero, ¿no puede crear tableros y gráficos que se centren en las alertas?
y deje los tableros con muchas variables de plantilla para exploración y
¿solución de problemas? Sé que probablemente hay muchos casos en los que serían
similar, así que se siente como un trabajo duplicado :(

De hecho, edité mi comentario para hacer referencia a esta opción (y agregué un par
de los otros problemas de punto de dolor relacionados con alertas). Sin embargo, como has identificado,
esto significa multiplicar la creación de tableros/paneles (y el mantenimiento, si todo
esas consultas necesitan una actualización) por la cantidad de variaciones de plantilla que desea
para alertar, y también segrega las anotaciones de alerta de la ubicación
pueden ser más útiles en: un tablero con plantilla con anotaciones de alerta
puede ser muy útil para hacer correlaciones, pero no tanto si hay que
intente y explore a través de múltiples pestañas del navegador e intente alinear las cosas.

Digamos que una consulta usa 2 variables de plantilla, $A y $B, cada una tiene 50
valores. ¿Resultaría esto en evaluar la regla de alerta 2500 veces? quiero decir
si las variables son de "valor único", es decir, las consultas están diseñadas para funcionar únicamente
si $A y $B tienen un solo valor, entonces tendríamos que hacer eso. no es un espectáculo
tapón tal vez, tendríamos que explicar que solo las variables de valores múltiples son
soportado. Probablemente hay muchas más limitaciones y detalles problemáticos
eso hará que esta función sea muy difícil de implementar, usar y comprender

Hay dos cuestiones separadas aquí, creo. Uno es (creo) de cerca
relacionado con #6041 https://github.com/grafana/grafana/issues/6041 , en
que puede haber un deseo de evaluar las condiciones de alerta individualmente por
valores de serie/plantilla (la alternancia agregada que mencioné en un artículo anterior)
comentario). Si dejamos eso de lado por ahora, creo que la forma ideal de resolver
la mayor parte de este problema es permitir múltiples configuraciones de alerta por panel, y
solo haga la interpolación variable exactamente de la misma manera que para el tablero
salida: permite a los usuarios seleccionar valores de plantilla de uno o varios valores cuando
configurar consultas de alerta; las consultas se ejecutarán una vez por alerta
config, con los valores seleccionados poblados; y los resultados serán
interpretados exactamente de la misma manera que en la actualidad. A menos que sea groseramente
malinterpretando algo, no veo esto como un aumento significativo en
complejidad, y debe ser bastante fácil de usar.

La capacidad de seleccionar valores de plantilla para simplemente limitar el alcance de las alertas
seguir siendo útil sin múltiples configuraciones de alerta (si ayuda a desarrollar
esta funcionalidad en ese orden), pero sería exponencialmente más valioso
con múltiples configuraciones.

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin eso no es lo mismo, ¿parece que se traduciría en una consulta en Grafana que apunta a muchas series usando comodines o expresiones globales en su consulta o solo filtros en un conjunto limitado de etiquetas? Las reglas de alerta de Librato se definen por separado de los tableros, ¿no es así? ¿Cómo se puede traducir en una función de filtrado de datos para todo el tablero?

Ahora veo que lo que estoy discutiendo es básicamente una copia de: https://github.com/grafana/grafana/issues/6041

Estoy a favor de esa solicitud de función sobre esta.

Ponemos en marcha los servidores regularmente y tenemos paneles con plantillas que miden cosas comunes en todos los hosts (mem, hd, cpu, etc.). Hacer un tablero de "alertas" que tenga gráficos para cada combinación posible es demasiado tedioso, muchas de las alertas deseadas se pueden generalizar en todos los hosts. AFAIKT, este problema solicita una forma de hacer posible este caso de uso y no se resolvería en # 6041. A menos que me esté perdiendo algo.

Hacer un gráfico y una alerta para cada combinación no es lo que estamos proponiendo, solo que su consulta de alerta use comodines o expresiones regulares para que cubra todos los hosts, etc. Entonces tiene una alerta y un gráfico que se puede ajustar para alertar y no competir con requisitos para la resolución de problemas y el filtrado dinámico.

Para nuestro caso de uso, tenemos una cantidad de instancias (potencialmente) efímeras que brindan procesamiento de eventos en tiempo real: necesitaríamos recibir una alerta si ciertas métricas generadas por la aplicación caen a 0. Sin embargo, si las instancias se eliminan o detienen, seguirán teniendo una métrica con nombre asociado con ellos que aparece en una búsqueda directa con comodines que conduce a alertas generadas falsamente.

He solucionado esto mediante el uso de una variable de varios valores con plantilla (establecida en Todos) generada a partir de una "fuente de datos JSON simple" que contiene una fuente de verdad para las instancias que deberían ejecutarse, todo funcionando perfectamente. Por desgracia, tan pronto como intenté habilitar las alertas, recibí esta solicitud de función :)

No estoy seguro de cuán único es nuestro caso de uso particular, pero no estoy seguro de otra forma de alertar sobre esto sin el uso de plantillas; por ahora, tendremos que seguir alertando sobre estos problemas fuera de Grafana (lo cual es una pena - ¡Somos grandes usuarios de Grafana!)

+1

Entonces, un caso en el que no tenemos ninguno de estos problemas es donde la variable de plantilla es un tipo constante. Por ejemplo, tenemos múltiples tableros que se basan en una variable constante para limitar los datos en ese tablero a un recurso en particular (la razón por la que no usamos una variable de valores múltiples es porque cada tablero es lo suficientemente diferente como para justificar diferentes configuraciones pero lo suficientemente cerca para justificar un cuadro de mando "plantilla"). Al menos en este caso (variables constantes) no es necesario cambiar nada sobre el comportamiento de alerta actual.

¿Alguna novedad sobre este tema?

Hola,

¿Hay alguna esperanza de obtener esta característica? Me pregunto cómo otros sistemas tienen estas funciones, ya que también deben usar una especie de plantilla, ya que cuando instalamos el agente, aparece automáticamente en el portal y también se pueden configurar alertas para eso. (Esta es mi experiencia con New Relic).

@vishwanathh me gustó el enfoque de tener una sección separada para alertas (si es complicado tenerlo en el panel de gráficos) donde podemos ingresar nuestras consultas solo para alertas. ya que de esta manera nuestros usuarios no verán el panel de marcador de posición (usado para alertar).

Perdón por el ruido adicional, pero esta sería una característica realmente genial para tener en Grafana.

+1, característica muy muy importante!

Además, si me permite modificar la expresión de consulta de métrica de Prometheus para eliminar la variable de plantilla, esto no es factible en absoluto. Entonces, ¡creo que esta característica es la más importante para que Prometheus+grafana llegue a la producción!

De todos modos, por favor, el equipo puede considerar la prioridad, ¡gracias!

Con 5.0 saliendo por la puerta en breve, me encantaría ver un enfoque significativo en las alertas durante la próxima serie de lanzamientos. Al observar las reacciones de Github, las deficiencias relacionadas con las alertas parecen tener, de lejos, el mayor interés de los usuarios.

Sé que ha habido cierta renuencia a abordar estas cosas debido a problemas de complejidad de UI/UX, sin embargo, no estoy convencido de que estas preocupaciones estén necesariamente justificadas. ¿Hay algo que nosotros, como usuarios, podamos hacer que pueda ayudar a planificar/diseñar o hacer avanzar estos problemas, aparte de las solicitudes de extracción con el código real?

@torkelo Esto me ha ayudado a configurar alertas para todos mis hosts usando etiquetas y ahora cada gráfico de alertas contiene múltiples series formadas por la combinación de etiquetas. Todo parecía estar funcionando bien. Pero al revisar los documentos y otros problemas, me di cuenta de que si alguna de las series dentro del gráfico ya ha tomado el estado de alerta, entonces las alertas para otras series no se activarán si también cruzan el límite.

Eso vuelve a ser limitaciones.

Gracias.

¿Alguna noticia sobre esta función?

¿Cuál es el esfuerzo de un nuevo colaborador para agregar esta función?

+1

Permita que se utilicen variables de plantilla para notificaciones de alerta.
+1

+1

Esperamos que se resuelva.

+1

No quiero vencer a un caballo muerto aquí, pero estamos teniendo el mismo problema y quiero proporcionar un contexto sobre por qué las propuestas existentes no funcionan en todas las circunstancias. También tengo un par de ideas para soluciones alternativas, pero por qué necesitamos _algunas características_ para ayudar a que las soluciones alternativas sean suficientes.

Para todos los escenarios a continuación, estamos usando una única variable con plantilla: $env

"¿Por qué no simplemente crear paneles de alerta?"

Queremos alertar sobre un par de entornos diferentes, no solo de producción. Por lo tanto, ahora necesitaríamos tener la misma métrica en _al menos_ 3 lugares diferentes (el panel de solución de problemas con todas las métricas, no solo la métrica para la que alertamos; el panel de alertas de producción; el panel de alertas de integración). Esto puede salirse de control bastante rápido y es propenso a errores del usuario.

Igualmente importante, esto anula gran parte de la ganancia de las anotaciones automáticas de las alertas. Si tengo que ir y venir de mi panel exploratorio a mi panel de alertas para ver las anotaciones de cuándo comenzó un evento y cuándo finalizó, será bastante tedioso.

Intento de solución

Lo que hemos hecho para tratar de evitar esto es que hemos agregado métricas duplicadas _específicamente para alertar_ a nuestros tableros. Entonces, si hay una métrica sobre la que queremos alertar, vamos al panel y agregamos métricas explícitas para esas alertas (y las ocultamos).

Nuestra lista de series para un panel determinado que necesita alertar se verá en la línea de:

Con la serie sin plantilla marcada como oculta. Luego, en la pestaña de alertas, establecemos umbrales para _estas_ series, no para la serie variable.

Problemas con esta solución

Sin embargo, esto no funciona muy bien. Por ejemplo:

Como puede ver, el panel Alertas no nos permite especificar _qué entorno_ está alertando, por lo que tenemos que profundizar en la alerta para averiguar qué entorno está dañado en este momento. Sin embargo, una solución fácil para esto podría ser permitir que la descripción sea tan detallada como el panel Historial de alertas que muestra las transiciones de estado:

Esto es al menos algo útil, pero incluso en este panel no hay indicación de qué alerta ha vuelto a Healthy (la descripción de la captura de pantalla anterior se derivó del alias que configuramos en la serie si alguien se pregunta cómo para al menos obtener tanto para aparecer).

Cosas que ayudarían hasta que se resuelva este ticket específico

• Permita la opción para mostrar el alias de la serie en lugar de una descripción escrita para la alerta (de esta manera, el alias puede al menos especificar la variable $ para la que está alertando)
• Permita que la transición de estado vuelva a ser saludable para mostrar también el alias de la serie (en la captura de pantalla de Historial anterior)
• Permitir un valor de leyenda para alertas activas (usando el alias de serie que asumo) para un panel determinado

Cosas que no estoy seguro de cómo arreglar

Anotaciones en gráficos que tienen alertas configuradas para múltiples entornos/variables:

Con esto, realmente no podemos saber qué alerta se está disparando sin entrar en el panel. La sugerencia de leyenda podría ayudar a aclarar esto, pero no hace mucho por la anotación si no se selecciona el $env correcto (en la imagen de arriba, int está alertando, pero prod es la variable seleccionada en el tablero, por lo que estamos mostrando anotaciones de la alerta int en la parte superior del gráfico usando prod .

+1

mas uno :)

Deja de hacer +1 en este problema. Genera correos electrónicos no deseados innecesarios. La capacidad de agregar una reacción a un comentario de un problema de github existe desde hace un tiempo, y más de 429 personas han descubierto cómo hacer clic en Me gusta en el comentario inicial en lugar de enviar spam a todos los que están suscritos.

Por favor, realmente necesitamos esta función, nos gustaría usar plantillas, pero en nuestro caso es más importante tener un sistema de alerta claro. Entonces, para solucionar esto, estamos evitando las plantillas en nuestro tablero... es un desastre.

Estoy de acuerdo y esta característica nos ayudará mucho !!!!

+1 por favor

necesitamos esto

+1 por favor Es realmente necesario.

@bergquist @torkelo , ¿podemos bloquear este problema para detener el spam de +1?