Grafana: edificio sistema de alerta para grafana

¡Me encantaría ayudar con esto! Mi sugerencia sería seguir las pautas de estilo nagios. De esa manera, las herramientas podrían usarse fácilmente con otras herramientas de monitoreo. por ejemplo, Nagios, Zenoss, Icinga, etc.

Lo más importante de esta función es que la arquitectura básica sea la correcta.

Algunas preguntas que me gustaría explorar
1) Qué componentes son necesarios, cómo se ejecutan (en proc en grafana, fuera de proc),
2) ¿Cómo deben coordinarse las cosas?
3) ¿Deberíamos ignorar las alertas "in stream" (solo enfocarse en las basadas en pull)?

Profundizando en 1)
Me preocupa convertir grafana-server en un monolito. Me gustaría encontrar una manera de separar grafana-server en servicios que estén más aislados entre sí (y que se puedan ejecutar en proceso o como procesos separados). Este era el plan con la abstracción del autobús. Otra opción sería que el componente de alerta solo hable con grafana a través de la API HTTP, podría limitar la integración, no estoy seguro.

Estoy de acuerdo con torkelo. En mi experiencia con otros proyectos con todo "integrado", la resolución de problemas puede resultar bastante engorrosa. Me gusta la idea de que el servicio se ejecute externamente, pero una bonita página de configuración en grafana que habla con el servicio a través de la API HTTP para manejar la gestión de todas las alertas. Además, para implementaciones a gran escala, esto probablemente terminaría siendo un requisito, ya que el rendimiento eventualmente se degradaría (al menos tendría esto como una opción de configuración).

¿Nos integramos con la configuración actual de umbrales de grafana graph (que actualmente son solo para visualización, no para procesamiento)? si la expresión es una verificación de umbral, podríamos mostrar automáticamente una línea de umbral

Creo que ese podría ser un buen punto de partida. Alerta si está configurado, no lo hagas si no lo está.

Volviendo al número 1. Creo que si el servicio de contramaestre pudiera ejecutarse por separado pero aún así tuviera la capacidad de configurar todo completamente a través de grafana eso sería, en mi opinión, ideal.

Sigan con el increíble trabajo.

El único defecto que he visto con bosun son las fuentes de datos que puede utilizar. Si pudiera aprovechar el lenguaje para expresar alertas de contramaestre, pero también integrarlo con fuentes de datos existentes que se configuran a través de la interfaz de usuario de grafana normal, sin duda sería ideal.

Ser capaz de representar umbrales de alerta, cuando está cerca de ellos, así como enviar anotaciones automáticamente para cuando se han activado en mi mente, hace que la interfaz de usuario de un solo panel sea ideal.

¡Esperamos con ansias el trabajo que se realizará aquí!

1. Debe utilizar los umbrales definidos en el Tablero para alertar sobre
   Hagámoslo simple; si el Tablero muestra el color de advertencia, debería estar alertando.
2. Es probable que esto sea algo fuera del proceso de grafana-server en sí.
   ... Algo que usaría el resto de la API para raspar los paneles y sus configuraciones y representarlos y alertar usando un comando externo.
3. Nivel de alerta; solo un cuadro para colocar en el editor que este Tablero debe ser monitoreado; y debe comprobarse cada minuto. Si no hay datos, debería permanecer durante un período de tiempo. ¿Debería seguir alertando? (caja)

Finalmente; como dependemos más de Grafana, admito que estoy dispuesto a decir 2. podría ser algo por lo que estaría dispuesto a pagar.

Tengo curiosidad por saber por qué la gente piensa que esto debería incluirse en Grafana.
Grafana no recibe ni almacena esos datos reales, sino que "solo" los visualiza. En su lugar, cualquier sistema de alerta debería basarse en los datos del almacén de métricas.
Si esto está realmente integrado en Grafana, espero que se pueda desactivar porque aquí ya usamos Icinga para alertar, por lo que cualquier tipo de alerta en Grafana solo saturaría más la GUI aunque no se usaría en absoluto.

Absolutamente correcto @dennisjac; Grafana solo renderiza cosas.

Pero a medida que hemos movido las cosas del lado del servidor, ya no es solo la representación del cliente; las posibilidades de un proceso de trabajo que pueda verificar sus métricas y alertar; es menos difícil.

Los datos están en una base de datos; siempre que esté rociado con los datos que le indiquen que verifique la métrica ...

Algunas personas pueden estar de acuerdo o en desacuerdo en que no debemos cruzar los arroyos y hacer que Grafana haga más que visualizarlo (aproximadamente), pero yo no soy ellos.

Realmente no me opongo a la función para las personas que desean que se integre, pero espero que sea opcional para las personas que ya tienen disponibles sistemas de monitoreo / alerta.

El nuevo proyecto Telegraf (recopilador de métricas de los chicos de influxdb) también está buscando características de monitoreo / alerta que no les gustan por la misma razón. Expliqué esto aquí:
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

Creo que torkelo ha hecho un muy buen trabajo al brindarnos funciones en Grafana2 que no tenemos que habilitar.

En cuanto a influxdb, tendrán que ganar algo de dinero de alguna manera; ya sea fuera del soporte de influxdb y servicios o productos profesionales para él.

Esto último suena mucho más viable

Otro ángulo sobre esto. Parece que próximamente habrá soporte para elasticsearch como almacenamiento de métricas para grafana. Bosun ahora puede consultar elasticsearch para obtener datos de registro.

¿Tendría sentido al diseñar el sistema de alerta permitir también alertas de los datos de registro? Quizás no sea una característica de la primera versión, pero algo que se pueda implementar más adelante.

También estoy de acuerdo con la idea de dividir los procesos. Tenga Grafana la interfaz para ver y crear alertas, tenga algo más que maneje las alertas. Tener la parte de alerta basada en API también permitiría que otras herramientas interactúen con ella.

+1 a las alertas. Fuera del uso de DevOps, las aplicaciones creadas para usuarios finales deben proporcionar alertas definidas por el usuario. Es bueno tenerlo en la herramienta de visualización ...

+1 esto cerrará el ciclo: la propuesta de obtener métricas.

+1 a las alertas de Grafana + un backend de escala horizontal de InfluxDB los convertirá en el estándar a superar para las configuraciones de alertas de métricas

+1 Me encantaría el escalado horizontal de las alertas en varios nodos grafana.

Sería genial si uno pudiera asociar un comportamiento similar al de "rebote" con una alerta. Por ejemplo, quiero disparar una alerta solo si el umbral definido excede X durante N minutos.

He visto esto con algunas de las herramientas de alerta, desafortunadamente, actualmente estamos usando Seyren, que no parece ofrecer esa opción. Estamos utilizando Grafana para el desarrollo de nuestro tablero y estamos ansiosos por llevar las alertas a Grafana también. Sigan con el buen trabajo.

Tenemos dos casos de uso:

• El equipo de infraestructura crea alertas a través de herramientas de provisión como de costumbre en la pila de monitoreo común (verificación común del clúster o verificaciones del sistema en el sistema compatible con nagios)
• los desarrolladores de software crean métricas de aplicaciones a través de Grafana

Nos encantaría tener un sistema de alerta unificado que maneje alertas, detección de flaps, escalado y contactos. Eso nos ayuda a registrar y correlacionar eventos / operaciones en la misma fuente de verdad. Muchos sistemas han resuelto el problema de las alertas. Espero que Grafana pueda hacerlo mejor en esto a largo plazo; a corto plazo, no reinventar los sistemas existentes sería útil en términos de entregables.

Una sugerencia es que Grafana puede proporcionar API para extraer la definición de monitoreo (estado de alerta), un tercero puede contribuir con complementos de exportación de configuración. Esto sería muy ideal en nuestro caso de uso exportando la configuración de nagios.

Más importante aún, ¡me encantaría ver alguna solución integrada de detección de anomalías también!

El 15 de julio de 2015, a las 17:40, Pierig Le Saux [email protected] escribió:

+1 Me encantaría el escalado horizontal de las alertas en varios nodos grafana.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Estoy de acuerdo con @activars. Realmente no veo por qué una solución de tablero debería manejar las alertas, que es un problema más o menos resuelto por muchas otras herramientas, en su mayoría bastante maduras. Haz una cosa y hazla bien.

En mi humilde opinión, tendría más sentido centrarse en la parte _integración_.

Ejemplo: Defina umbrales dinámicos de advertencia / crítica en grafana (por ejemplo, como en el ejemplo de @Dieterbe anterior) y proporcione una API (¿REST?) Que devuelva el estado (normal, advertencia, crítica) de exactamente este gráfico. Un nagios, icinga, bosun, etc. podría solicitar todos los gráficos habilitados para "monitoreo" (otra característica de la API), iterar a través de los estados individuales y hacer las alertas necesarias.

En nuestro caso, los catálogos de servicios y las acciones definidas son la parte difícil: qué servicio es crítico para el negocio, a dónde enviar correos electrónicos, aleteo, etc. lugar central (AD, LDAP, Crowd, etc.) e integrado con el sistema de alerta.

También debemos considerar que, a diferencia de una solución de tablero, los requisitos de calidad para una herramienta de alerta pueden considerarse mucho más altos en términos de confiabilidad, resistencia, estabilidad, etc., lo que crea un esfuerzo (de prueba) que no debe subestimarse.

Además, ¿qué pasa con las comprobaciones no relacionadas con la serie temporal, como llamar a un servicio web, hacer ping a una máquina, ejecutar scripts personalizados ... también querría eso en grafana? Supongo que la adopción del contramaestre proporcionaría todo esto, pero no estoy familiarizado con eso.

Por otro lado, puedo imaginarme cómo un sistema de alerta simple haría felices a muchos usuarios que no tienen una buena alternativa, pero esto podría resolverse con algunos patrones de integración de ejemplo para otras herramientas de alerta.

Por mucho que quiera que Grafana resuelva todos mis problemas, creo que falkenbt dio en el clavo con este.

Una API para exponer los datos mencionados, algo de plomería en contramaestre y algunos patrones de integración con plataformas de alerta comunes tiene mucho sentido.

¡Felicitaciones por su nuevo trabajo en raintank @Dieterbe! He estado leyendo su blog por un tiempo y tiene algunas ideas realmente sólidas sobre el monitoreo, particularmente con respecto a las métricas y su lugar en las alertas. Estoy seguro de que encontrará una buena manera de implementar las alertas en grafana.

Como probablemente esté de acuerdo, la gente detrás de Bosun está alertando de la manera correcta. Lo que falta con Bosun son realmente las visualizaciones. Me gustaría ver a Bosun detrás de la interfaz de usuario de Grafana. Combinar el tablero de Grafanas y los jefes que alertan detrás de la misma interfaz sería una solución de monitoreo increíble y completa.

También creo que sería una pena fragmentar aún más la comunidad de monitoreo de código abierto, sus ideas sobre el monitoreo parecen ser realmente compatibles con las ideas de las personas detrás de Bosun. Si se unieran, estoy seguro de que el resultado sería excelente.

Donde trabajo, usamos Elastic para registros / eventos y acabamos de comenzar a usar InfluxDB para métricas. Hemos estado explorando diferentes soluciones para el monitoreo y actualmente nos estamos inclinando hacia Bosun. Ya estamos usando Grafana para paneles, pero nos gustaría acceder a toda nuestra información de monitoreo a través de la misma interfaz, sería genial si Grafana pudiera convertirse en esa interfaz.

¡Sigan con el buen trabajo y buena suerte!

En una tangente relacionada, conseguimos que la parte de alerta funcione, alertando en funcionamiento mediante la integración de grafana con riemann. Fue un buen ejercicio conocer los aspectos internos de grafana :).

Esto fue más fácil con riemann ya que la configuración es solo código clojure. Imagino que esta integración será más difícil en Bosun.

Aquí hay un par de capturas de pantalla en acción.

Los cambios en la parte de grafana incluyeron agregar un punto final "/ alertas" y un punto final "/ subscriptions" y hacer que hable con otra pequeña API que se encuentra en la parte superior para que riemann haga la basura.

Lo bueno es el hecho de que los cambios en las definiciones de alerta se reflejan inmediatamente sin tener que enviar un SIGHUP a riemann. Entonces, habilitar / deshabilitar ajustes de período de tiempo para cambios de estado es solo una cuestión de cambiarlo en la interfaz de usuario y hacer que ese cambio se propague a riemann.

Todavía no he evaluado esta integración, pero no creo que vaya a ser tan mala. Escribiré en un blog sobre ello después de limpiar el código y una vez que se publique.

La razón por la que hicimos esto fue porque la gente puede simplemente seguir adelante y configurar estas alertas y notificaciones desde una interfaz de usuario muy familiar y no molestarnos en escribir configuraciones de riemann :).

@sudharsh, tu implementación suena realmente interesante. ¿Estás planeando lanzar esto a la naturaleza?

muchas buenas ideas, gracias a todos.
Inspirándonos en algunos de los comentarios y en el proyecto https://github.com/pabloa/grafana-alerts de @pabloa , decidimos centrarnos principalmente en la interfaz de usuario y la experiencia de usuario para configurar y gestionar las reglas de alerta como parte del mismo flujo de trabajo de editar cuadros de mando y paneles. Grafana guardaría esas reglas en algún lugar y proporcionaría un fácil acceso a ellas para que otros scripts o herramientas puedan obtener las reglas de alerta.
Quizás a través de un archivo, una llamada a la API, una sección en la configuración del tablero o una entrada en la base de datos.
(Me gusta la idea de tenerlo como parte de la definición del tablero en sí, de modo que los proyectos de código abierto puedan venir con archivos json del tablero de grafana para ellos, que tendrían reglas de alerta incluidas, aunque no necesariamente activas de forma predeterminada. una base de datos parece más robusta)
De cualquier manera, queremos proporcionar un acceso fácil para que pueda generar la configuración para cualquier otro sistema que desee utilizar que realmente ejecute las reglas de alerta y procese los eventos. (de aquí en adelante me referiré a esto como un "manejador").
Tal manejador podría ser nagios, sensu o contramaestre, una herramienta que usted escribe o el programador-ejecutor de alertas tornasol, que es un manejador que puede compilar en grafana, que proporciona una integración agradable y simple respaldada por contramaestre, pero realmente queremos asegúrese de que puede utilizar el sistema que desee.

Siempre que su controlador admita la consulta del almacén de datos que usa. Comenzaríamos con un umbral estático simple, pero luego también queremos facilitar la elección de funciones de reducción, expresiones booleanas entre múltiples condiciones, etc.

@sudharsh, ese es un enfoque muy agradable. Me gusta cómo su solución puede comunicarse directamente con una API remota, omitiendo el paso intermedio descrito anteriormente (por supuesto, esto implica que solo funciona para 1 backend determinado que intentamos evitar), y que puede volver a cargar automáticamente la configuración. (tiene razón, bosun actualmente no lo admite, podría hacerlo en el futuro. FWIW, el manejador de tornasol maneja esto bien y usa el mecanismo de evaluación de expresión de bosun). Realmente nunca me metí mucho en Riemann. Sobre todo, me ha preocupado agregar un lenguaje tan diferente a la pila que no muchas personas entienden o pueden depurar cuando las cosas van mal. Pero tengo mucha curiosidad por aprender más sobre su sistema y sobre el código CLJ de Riemann. (Me encantaría si mis sospechas son incorrectas)

@dennisjac sí, sería opcional.
@elvarb hay un ticket para ES como fuente de datos . de hecho, el objetivo es que si grafana admite la representación de datos de una fuente de datos determinada, también debería admitir la redacción de reglas de alerta para ella. En cuanto a la ejecución de consultas, esto depende, por supuesto, del controlador que decida utilizar. (para el controlador de tornasol comenzaremos con los más populares como grafito y influxdb)
@rsetzer : de acuerdo, es bueno poder especificar cuánto tiempo se debe exceder un umbral antes de activar
@falkenbt : Creo que muchas cosas se pueden expresar como un problema de consulta de series temporales (por ejemplo, el ejemplo de pings). Pero tienes razón, algunas cosas no están realmente relacionadas con la serie temporal y están fuera del alcance de lo que estamos tratando de construir aquí. Y creo que está bien: queremos proporcionar la mejor manera de configurar y administrar las alertas en series temporales y apuntar a la integración con otros sistemas que quizás estén más optimizados para el caso de "scripts misceláneos" (como nagios, icinga, sensu, .. .). En cuanto a preocupaciones como la confiabilidad de la entrega, escaladas, etc., podría conectarse a un servicio como pagerduty.
@activars & @falkenbt, ¿esto parece coincidir con sus expectativas o qué cree que podría mejorarse específicamente?
@jemilsson ¡ gracias! y así es exactamente como yo lo veo: Bosun es excelente para alertar, pero no para visualizar. Grafana es excelente en visualización y UX, pero no tiene alertas. Estoy tratando de impulsar una colaboración que crecerá con el tiempo, creo

¿Alguien tiene alguna idea sobre qué tipo de contexto enviar en notificaciones como correos electrónicos?
Como mínimo, la notificación debe contener una visualización de los datos sobre los que está alertando, pero en mi humilde opinión debería ser posible incluir otros gráficos relacionados. Aquí podríamos usar el backend de renderizado png de grafana al generar el contenido de la notificación. También estoy pensando en aprovechar la función de instantáneas de grafana. como cuando se activa una alerta, tome una instantánea de un panel determinado para el contexto.
y tal vez esa instantánea (página html) podría incluirse en el correo electrónico, o podría ser demasiados datos / complejidad. Además, las funciones de JavaScript no estarían disponibles en los clientes de correo de todos modos (por lo que no podría hacer zoom en los gráficos en un correo electrónico). Quizás podríamos vincular desde el correo electrónico a una instantánea de panel alojada.

Me gusta el enfoque general de Docker: baterías incluidas, pero extraíbles. Por lo tanto, una implementación de alerta básica que se pueda intercambiar sería un buen enfoque en mi humilde opinión.

influxdb será compatible para las alertas? o solo grafito?

Una cosa que me gustaría ver es la idea de árboles de alerta jerárquicos. Simplemente se están monitoreando demasiadas facetas y los estados de alerta independientes tienen una cardinalidad inmanejable. Con un árbol de jerarquía, puedo definir todas estas alertas de bajo nivel que se acumulan en alertas de nivel medio que se acumulan en un nivel alto ...

Como tal, cada alerta acumulada asume automáticamente la gravedad alta de todos los niños debajo de ella. De esa manera, puedo tener una impresión de [y administrar] el estado del sistema con precisión con una superficie de análisis mucho menor.

Este es un ejemplo que tomé prestado de un documento antiguo que escribí hace un tiempo. Sí, por favor ríase entre dientes ante el uso de la palabra "Struts". Es VIEJO, ¿vale? Esto presenta una jerarquía muy simple para un servidor.

En algún momento, el servidor experimenta un uso sostenido de la CPU del 75%, por lo que esto activa estas alertas en un estado de advertencia: CPU- # -> CPU -> Host / OS -> System

Si uno realmente se aplicara, podría vigilar todo un centro de datos con un solo indicador. (sí, en realidad no, pero esto sirve como ejercicio de pensamiento)

¿Por qué no utilizar baliza de grafito ? Creo que puedes fusionar grafito-baliza que es muy ligero con grafana.

@felixbarny Me gusta esa terminología. probablemente adoptemos esa redacción.
@JulienChampseix sí, el controlador estándar admitirá / admitirá influxdb
@nickman eso es interesante. en realidad, se ajusta al objetivo final que tenemos en mente, de poder crear alertas de muy alto nivel que pueden incluir o depender de reglas e información de alerta más precisas. bosun ya hace esto y, a largo plazo, queremos que esta funcionalidad esté disponible a través de una interfaz más fácil de usar, pero tenemos que comenzar de manera más simple que esto.
@amirhosseinrajabi parece un proyecto genial y creo que convertir graphite-beacon en un controlador para las alertas configuradas a través de la interfaz de usuario de grafana tendría mucho sentido.

@Dieterbe ¿ es posible tener una actualización del estado actual? para sistema de alerta
para saber qué sistema es compatible (grafito / influxdb)?
¿Qué suscripción está disponible? ¿Qué tipo de alerta está disponible?
gracias por tu actualizacion.

actualmente estamos creando un prototipo de UX / UI. así que estamos bastante lejos de que esto sea utilizable.

Hola @Dieterbe

¿Hay alguna actualización sobre el progreso del sistema de alerta?

¡Sería genial tener alertas en Grafana! Esperando esta característica. ¿Alguna actualización ahora?

@mattttt, ¿ puede proporcionar una actualización sobre su trabajo de UX?

Si, absolutamente. Subirá algunas pantallas / flujos de usuarios mañana.

Necesitamos alertas: interfaz de usuario para la definición de reglas, API para la definición de reglas y API para notificaciones de alerta. Observaré este hilo con interés. Tenemos un sistema multiinquilino y nos encanta la interfaz de usuario y el back-end de Grafana.

Sí, también estoy muy interesado e impaciente por ver esta nueva función.
¡Muchas gracias Matt! ;)

2015-08-27 6:49 GMT + 02: 00 andyl [email protected] :

Necesitamos alertas: interfaz de usuario para la definición de reglas, API para la definición de reglas y API
para notificaciones de alerta. Observaré este hilo con interés.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295.

Hay muchos elementos que encajan en su lugar internamente, pero no quería dejar este hilo descuidado.

Aquí está una de las maquetas de un panel en el que he estado trabajando. Esto ilustra el estado histórico a lo largo del tiempo, incorporando el estado en la información sobre herramientas y utilizando los umbrales existentes definidos en la configuración del panel para configurar las alertas.

En este ejemplo, se trata de una alerta sobre una sola consulta con varias series. La información sobre herramientas se amplía para mostrar el estado en el tiempo de desplazamiento.

_Un par de pequeñas preguntas pendientes _: ¿Cuánta información sobre la notificación de alerta debe incluirse en la información sobre herramientas, si corresponde, o se debe acceder a esta información en otro lugar en una vista más detallada? Creo esto último en este momento, pero vale la pena preguntarlo en voz alta.

La configuración, las pantallas de alerta, los flujos de usuarios se acercan lentamente. Mucho por venir.

@mattttt agradable!

¡Me encanta la línea verde y roja debajo del gráfico!

Eso se relaciona con los cálculos de tiempo de actividad, me encantaría poder ver eso como un número en alguna parte. Totales para todas las consultas y para cada métrica.

Acerca de la descripción emergente, ¿estás hablando de las estadísticas que aparecen cuando pasas el cursor sobre las líneas?

Maldita sea @mattttt, eso se ve increíble. Ni siquiera me preocuparía por poner nada en la descripción emergente. La línea de umbral y la barra de estado de alerta en la parte inferior son más que suficientes.

¡No puedo esperar a ver esto cuando esté listo!

¡Estoy emocionado de ver que esto está progresando bien!

Actualmente usamos Grafana + Bosun + OpenTSDB como nuestra pila de monitoreo y alerta. Definitivamente estoy de acuerdo en que sería increíble tener el poder de Bosun con la gran experiencia de usuario de Grafana.

Aquí hay un ejemplo de dónde la UX de configuración de Grafana es mejor que la de Bosun:

Contexto

Nuestra pila de monitoreo se comparte entre varios equipos y sus servicios. Se implementa un conjunto diferente de servicios en diferentes clústeres / sitios según las especificaciones del proyecto. Cada equipo / servicio debe asumir la responsabilidad de sus propios paneles / alertas.

Comparación

Con la API HTTP de Grafana, los equipos pueden PONER sus propios paneles de control cuando implementen su servicio. Bosun actualmente solo tiene un único archivo para almacenar la configuración; esto hace que sea difícil compartir entre diferentes equipos y entre diferentes proyectos.

@mattttt @torkelo @Dieterbe ¿ alguna idea para un lanzamiento de la pieza de alerta (o lanzamiento beta)?

echo ^. ¿Es una versión beta o alfa para esto? Estoy investigando soluciones de alerta, pero me encantaría tener algo integrado en grafana. Podría proporcionar muchos comentarios sobre las pruebas.

La función de alerta aún está dentro de algunos meses, todavía estamos creando un prototipo de la interfaz de usuario y pensando en diferentes formas de implementarla, pero el progreso debería avanzar más rápidamente en los próximos 2 meses, por lo que sabremos más.

@mattttt , ¿tiene la intención de configurar los colores de la barra de salud histórica? El verde y el rojo no van muy bien con los daltónicos;)

Con respecto a las alertas: estoy bastante interesado en cómo se desarrolla esto. Hemos estado recopilando y visualizando datos durante un tiempo, y las alertas es algo que estamos tratando de averiguar. Grafana podría tener un lugar agradable allí, especialmente porque las visualizaciones ya están en su lugar. Sin embargo, lo que sí me pregunto: ¿cuánto debería Grafana ser más consciente de las 'entidades' en lugar de las series métricas para las alertas? Me imagino a mí mismo queriendo alternar automáticamente un cambio de estado visual (falla la verificación de ping o http) o manualmente (haciendo mantenimiento) para lo que en mi caso sería un servidor, además de alertas basadas en métricas.

Es interesante ver a dónde van las alertas en Grafana, pero para aquellos de ustedes que necesitan algo ahora, hay complementos de nagios como https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details que pueden activar alertas cuando se cruzan los umbrales.

@baaym

Sin embargo, lo que sí me pregunto: ¿cuánto debería Grafana ser más consciente de las 'entidades' en lugar de las series métricas para las alertas? Me imagino a mí mismo queriendo alternar automáticamente un cambio de estado visual (falla la verificación de ping o http) o manualmente (haciendo mantenimiento) para lo que en mi caso sería un servidor, además de alertas basadas en métricas.

esta es una buena pregunta y también algo de lo que hemos estado hablando un poco.
la solución a la que queremos ir a corto plazo (y posiblemente también a largo plazo) es hacer que grafana no sea consciente de conceptos de nivel superior. es decir, como usuario, tiene el poder de establecer alertas en series de métricas, y a partir de esas reglas de alerta, se generarán resultados de alerta (que probablemente incluyan atributos o etiquetas de los nombres de las series) a partir de los cuales podrá construir las entidades que desee. esto es algo en lo que tenemos que pensar un poco más, pero por ejemplo

digamos que establece una alerta en la línea de movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn . esto verificaría el umbral en todos sus servidores web en el clúster dado y generaría alertas para cualquier violación como movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! .
posiblemente podríamos permitirle decir "el primer campo es el nombre del clúster, el segundo es el nombre de host", etc., para que las alertas puedan contener información más agradable.
pero el caso es que el _resultado_ de alerta contiene la información que necesita para identificar qué entidad tiene problemas, pero queda fuera del alcance de grafana. Grafana sería más la fuente de la configuración de las reglas de alerta, y los paneles de grafana podrían configurarse para cargar anotaciones y lo que sea para visualizar el estado de las alertas, pero no tendría una noción de conceptos de alto nivel como hosts o racimos. Creo que esto es algo que podría manejarse en los controladores de alerta.

@Dieterbe

Hay dos tipos de preocupaciones de usuarios / organizaciones al crear una función de alerta:

• Startup, donde generalmente no tienen tiempo para construir su propia solución de alerta. Todo dependería de Grafana para alertar sobre métricas
• Organización de ingeniería establecida, tienen herramientas de alerta existentes creadas internamente, las alertas para reglas comerciales se crean en base a otras señales de alerta granulares (Grafana sería una de ellas).

Grafana debe trabajar con las prácticas operativas existentes y bien establecidas, tenerlo fuera del ciclo es ignorar el objetivo de alertar: tener una visión clara de la salud de las entidades críticas para el negocio. Es mejor centralizar las alertas para permitir la creación de un estado claro del medio ambiente. Sería fundamental permitir que los usuarios avanzados que utilizan la API de grafana (o cualquier otra solución) exporten las reglas de alerta a otros sistemas.

Cuando se dice operativo, cada alerta debe contener opcionalmente un campo de documentación / enlace para explicar el propósito de las alertas y el comportamiento histórico.

@activars creo que estoy de acuerdo con todo eso. En mi opinión, estamos adoptando un enfoque que fomenta la conexión de grafana con el resto del entorno (principalmente gracias a la separación de preocupaciones, con controladores enchufables). ¿cree que el diseño propuesto se puede mejorar de alguna manera?

Creo que @ deebs031 hace un buen punto que no se ha abordado mucho "las aplicaciones creadas para usuarios finales necesitan proporcionar alertas definidas por el usuario".
En mi humilde opinión, el graal es un monitoreo basado en métricas de autoservicio , en mi caso, Grafana es el front-end principal para las personas que desean ver las métricas, tendría sentido permitirles crear alertas para ellos mismos dentro de la misma interfaz de usuario, seamos sinceros, IMPRESIONANTE.
Personalmente, he realizado alertas de Sensu basadas en métricas, pero proporcionarlas como autoservicio realmente no es pan comido en comparación con lo perfecto que sería si se integrara con Grafana. También miré a Cabot porque tenía capacidades de visualización, pero no se había creado pensando en el autoservicio, por lo que no podía usarlo tal como está.
Estoy en el lado de "hacer una cosa bien", pero creo que en el caso particular de las alertas de autoservicio basadas en métricas, esa capacidad con la capa de visualización de métricas tiene mucho sentido:

• El usuario ya está familiarizado con la interfaz de usuario.
• El usuario está autenticado para que pueda crear alertas para sí mismo o para cualquier esquema de permisos que habilite la autenticación.
• El usuario puede ver los gráficos que suelen ser bastante útiles al crear esas alertas basadas en métricas.

diapositivas de mi presentación de grafanacon sobre alertas:
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
son un poco difíciles de entender sin contexto, el video debería estar en línea en aproximadamente una semana, lo publicaré cuando esté listo.

ahora hemos comenzado a crear prototipos de formas de implementar los modelos de alerta / UI / definiciones / etc. tenemos una idea bastante clara del flujo de trabajo principal, aunque un punto importante que todavía estamos tratando de averiguar es cómo debería ser la integración con controladores de alertas de terceros.
Nuestro pensamiento actual es que podrá utilizar grafana para establecer umbrales / reglas de alerta / definir notificaciones y visualizar el estado histórico y actual de las reglas de alerta.

la suposición es que desea utilizar el software de alerta de su elección (bosun / cabot / sensu / nagios / ...)
por lo que habría una herramienta separada que consulta a grafana a través de su API http para recuperar todas las reglas de alerta. esa herramienta podría actualizar su configuración de bosun / cabot / sensu / nagios / ..., de modo que pueda usar el software de alerta de su elección para ejecutar y ejecutar las alertas y enviar las notificaciones.
pero queremos poder visualizar correctamente el estado actual e histórico, por lo que su programa de alerta debería poder llamar a un script o un webhook o algo para informar a grafana del nuevo estado, o grafana tendría que consultarlo. (lo que parece asqueroso, dado que la mayoría de las herramientas no parecen tener grandes api)
Todo esto es un poco complicado, pero tendría que ser así para apoyar a las personas para las que es importante que sigan siendo capaces de utilizar el software de alerta de su elección, mientras utilizan grafana para definir las reglas de alerta y visualizar el estado.

¿Es importante para usted que pueda utilizar la herramienta de alerta que elija?

la otra cosa que nos gustaría hacer, es también escribir un simple ejecutor de alertas nosotros mismos, que consulta la api de grafana en busca de alertas, las programa y las ejecuta, realiza las notificaciones (admitiría correo electrónico, holgura, pagerduty, un script personalizado y probablemente algunos otros) y actualiza el estado en grafana nuevamente.
sería bastante fácil de escribir para nosotros, fácil de usar para usted y podríamos tener una gran interoperabilidad.

¿Es el ejecutador de alertas integrado (ver arriba) algo que cree que sería suficiente para manejar todas las reglas de alerta que configuró en grafana?

¿También desea poder utilizar varios controladores de alerta? cuales ?

@jaimegago amen;)

Para mí, el número 2 parece mejor porque realmente puede minimizar la cantidad de cosas que tiene que configurar para que todo funcione sin problemas. En nuestra configuración actual iríamos con eso.

Así se ha dicho si todos los demás no están de acuerdo;)

Edición rápida: diapositivas impresionantes. Si el producto final se ve la mitad de bueno que eso, entonces es increíble.

+1
¡Estoy de acuerdo en que el controlador de notificaciones interno con estas integraciones es perfecto! para el caso de uso más común.

Estaré feliz de ser Beta Testing :) ¡y las diapositivas serán increíbles!

Creo que la última publicación de @Dieterbe aclara un poco las cosas, pero quería publicar este diagrama rápido para aclarar aún más.

Las alertas en Grafana son realmente dos cosas, la configuración de alertas de autoservicio (gracias @jaimegago , no podría haberlo dicho mejor) y el controlador en sí.

Enviaremos un controlador de alertas de Grafana, pero también proporcionaremos el marco para integrarlo con el software de alerta de su elección:

+1 para construir una especie de puente a otros sistemas de alerta (tal vez podríamos pensar en implementar algún sistema de complemento de alerta genérico :-))

También puede agregar Prometheus en la parte "Controladores de alertas externos". La primera versión de alertmanager de Prometheus está en producción en varias empresas y actualmente se está trabajando en una reescritura completa. SoundCloud puede usar Grafana para configurar alertas, pero ciertamente solo si el administrador de alertas de Prometheus se usa como controlador de alertas.

@grobie , buena captura, corregido en el comentario original.

@mattttt @Dieterbe ¡ eso es genial! Parece que estás en el camino de las "baterías incluidas pero extraíbles", que en mi humilde opinión es lo mejor de ambos mundos. ¿Ya ha pensado en cómo pasará los datos de autorización al gestor de alertas? Estoy pensando en una historia como esta:
Como usuario de Grafana, me gustaría recibir una alerta a través de _email_ y / o _pagerduty_ y / o _foo_ cuando (alguna condición creada a través de la interfaz de usuario de alerta de Grafana) ocurra.
Ese usuario solo debería poder enviar alertas al sistema de notificaciones para el que está autorizado, este es un requisito para el autoservicio y deberá abordarse de alguna manera. Desde Grafana 2, tenemos un backend SQL + autenticación / autorización de usuarios con integración LDAP, por lo que no parece demasiado descabellado tener esa capacidad desde el primer día de alerta.
Con Sensu (que es la herramienta que estaría conectando), pasar el objetivo de la alerta (por ejemplo, la dirección de correo electrónico) a través del controlador debería ser bastante sencillo, no puedo decir sobre los demás.

Hola a todos,
Me alegra ver que este lujo está avanzando, ya que me encanta el enfoque de configuración de alertas de autoservicio.

Personalmente, no necesito un manejador de alertas específico. Me gustaría ver un controlador HTTP POST genérico, que se activa tan pronto como se lanza una alerta. Creo que la mayoría de los administradores pueden construir rápidamente algo que sea capaz de aceptar HTTP y luego hacer lo que necesiten hacer con él (enviarlo a nagios, riemann, younameit). Así que estaría contento con un controlador HTTP que envía toda la información sobre una alerta como datos JSON.

Hablando de alertas a través de grafana, ¿planeas agregar algo como detección de aleteo? ¿O es algo de lo que debería ocuparse el sistema de monitorización externo?

¡Sigan con el buen trabajo chicos!

Salud

Me gustaría ver un controlador HTTP POST genérico, que se activa tan pronto como se lanza una alerta. Creo que la mayoría de los administradores pueden construir rápidamente algo que sea capaz de aceptar HTTP y luego hacer lo que necesiten hacer con él (enviarlo a nagios, riemann, younameit)

así que si se dispara una alerta (digamos "¡web123 tiene cpu crítica inactiva !, valor 1 inferior al umbral 15") y hacemos una publicación http de esos datos, ¿cómo manejarías eso en nagios? ¿Quiere decir que nagios lo tomaría como una verificación de servicio pasiva y luego nagios enviaría las notificaciones?

Hablando de alertas a través de grafana, ¿planeas agregar algo como detección de aleteo? ¿O es algo de lo que debería ocuparse el sistema de monitorización externo?

esto también es algo en lo que debemos pensar más. Esto puede ser complicado y si las personas usan algo como pagerduty o flapjack, pueden usarlo para agregar eventos / suprimir duplicados, por lo que estamos buscando evitar implementar eso en el controlador grafana, aunque es posible que tengamos que hacerlo. Tenga en cuenta también que, dado que podrá establecer alertas en expresiones de consulta de métricas arbitrarias, tendrá mucho poder para tener en cuenta datos pasados ​​en la expresión real y, por lo tanto, podrá crear una señal más sólida en la expresión que no cambia de estado con tanta frecuencia.

así que si se dispara una alerta (digamos "¡web123 tiene cpu crítica inactiva !, valor 1 inferior al umbral 15") y hacemos una publicación> http de esos datos, ¿cómo manejarías eso en nagios? ¿Quiere decir que nagios lo tomaría como una verificación de servicio pasiva, y luego nagios enviaría las notificaciones?

Mas o menos. De hecho, estoy deseando que grafana advierta para deshacerme de nagios. Usando el controlador HTTP, necesita configurar comprobaciones pasivas para que nagios pueda enviar los resultados allí. Pero me gustaría tener grafana como la única fuente donde puede configurar las alertas. En nuestro caso, las personas que pueden agregar alertas son el administrador de sistemas real que también configuraría las comprobaciones en nagios.

Con el manejador http grafana tendría todo lo que necesitamos para eso: un tablero para monitoreo en tiempo real, una API, configuración de alertas fácil y un manejador http donde podemos reenviar alertas a nuestro sistema de notifcación interno.

Salud

Aunque puedo ver la lógica en esta estrategia de integración, no puedo evitar pensar que es un poco exagerado. Por lo que entiendo (y lo que pude leer en el hilo), la única razón por la que la mayoría de los usuarios de Grafana siguen usando una tecnología de alerta independiente es que Grafana no propone una. Por lo tanto, no sería más "sencillo" centrarse primero en la parte de alertas de Grafana y desarrollarlo como un componente que se comunica con el resto de la pila a través de la API, de modo que otros contribuyentes puedan imitar el comportamiento y crear adaptadores específicos más tarde?

tl; dr: al enfocarse en construir sus propias "baterías" primero, Grafana tendría un sistema de alerta con todas las funciones, que luego puede evolucionar hacia un servicio para la integración con herramientas de alerta de terceros.

Preocupación menor, si esto no se ha abordado. El sistema de alerta tradicional no se adapta bien a la infraestructura de la nube, porque los recursos son muy dinámicos (aprovisionados y destruidos). Las alertas sobre métricas deben admitir funciones tentadoras o de agrupación (con excepciones anuladas, a veces las cargas de trabajo son diferentes). Una alerta con plantilla o agrupada debería poder descubrir un nuevo conjunto de grupos.

¡Gracias por la actualización! En mi caso de uso, las alertas integradas en Grafana es todo lo que necesito en este momento. He estado esperando pacientemente con impaciencia la alerta de Grafana.

Como prometí en IRC, aquí está nuestro caso de uso para esto:

Tenemos una aplicación Rails heredada que searches our logs por patterns y tiene una
HTTP API para responder si cierto pattern ha cruzado es thresholds y
por tanto, tiene un estado de {OK,WARNING,CRITICAL} .

Threshold puede ser:

• a status de CRITICAL si pattern existe.
• que status es WARNING si pattern se encuentra más de X veces
  y status es CRITICAL si se encuentra más de Y veces.
• si pattern tiene menos de 1 hora, entonces status es OK ,
  menos de 3 horas status es WARNING y de lo contrario status es
  CRITICAL .

Si entiendo esta función correctamente, Grafana admitirá este uso
patrón (a través de Logstash y Elasticsearch, por supuesto) cuando esta función y
la fuente de datos de Elasticsearch está completamente implementada?

@Dieterbe @mattttt, ¡ tus diapositivas y maquetas se ven absolutamente increíbles! Esto es realmente un cambio de juego.
Para mí, el gestor de alertas interno de Grafana se adaptaría mejor a nuestras necesidades.
Razones:

• Autoservicio: muy importante . Nuestros usuarios dijeron alto y claro que quieren crear ellos mismos alertas de un extremo a otro dentro de Grafana.
• Flujo de trabajo unificado: quiero minimizar las piezas móviles, no aumentarlas. Como señaló @Dieterbe , un controlador de alertas de terceros requeriría al menos 4 pasos donde un controlador de alertas interno requeriría solo 1 (¿tal vez 2 si necesita definir el método de notificación para cada umbral? No estoy seguro de la presentación).
• Estrecha integración y sin dependencia de la infraestructura de alerta de terceros.

Algunas preocupaciones:

• ¿Cuáles son los umbrales de verificación de frecuencia?
• ¿Cómo maneja la frecuencia de sondeo que es demasiado rápida para recuperar los datos? ¿Registrado, alertado y en cola o descartado?
• Para el escalado, me preocupa que Grafana no pueda mantenerse al día con la gran cantidad de verificaciones, la frecuencia rápida y especialmente con la latencia entre las fuentes de datos que probablemente necesitemos agregar / escalar los servidores de Grafana para admitir alertas internas. Lo sé porque ahora necesitamos varias instancias de controladores de alertas de terceros. En este caso, ¿cómo podríamos asignar o poner en cola comprobaciones de umbral sin problemas entre un clúster de servidores Grafana, especialmente si las comprobaciones son de la misma fuente de datos? Desde una experiencia de usuario, me gustaría que los usuarios crearan umbrales sin problemas a través de un clúster de servidores Grafana con equilibrio de carga sin que los usuarios vayan a una instancia "asignada" particular de Grafana para una verificación en particular.
• Para las notificaciones, ¿esto admitiría algún tipo de arquitectura de complemento para que las notificaciones se puedan desarrollar e integrar fácilmente? En general, necesitamos algo que pueda realizar HTTP POST. Esto es más común con los gustos de PagerDuty, xMatters, VictorOps, Opsgenie, etc. Cada uno requiere un formato, autenticación, etc. ligeramente diferente. Como se mencionó anteriormente en este hilo, quizás un controlador HTTP POST genérico funcionaría que enviaría a un servicio HTTP personalizado capaz de hacer lo que quieras con él. Alternativamente, también debería funcionar una capacidad de secuencia de comandos personalizada.
• Supongo que los umbrales se pueden establecer, recuperar y obtener infracciones a través de una API. Creo que esto seria de ayuda

Creo que es ideal poder integrar las alertas en los sistemas de alerta existentes. Hay algunos problemas difíciles y desagradables, como la detección de colgajos, como se mencionó, que se han solucionado y parece un desperdicio reinventar todo desde el principio. Odiaría ver esto enterrado bajo el peso de las características.

Pero no creo que esto realmente deba ser una integración estrecha en todos estos controladores de alertas. Una API buena y bien documentada debería permitir que las personas familiarizadas con estos sistemas se integren con poco esfuerzo. Entonces, la diapositiva con 'grafana api -> handler' es lo que me parece atractivo.

Scott

Hola a todos: llego tarde a esta discusión, pero tengo cierta experiencia en este tema y soy el desarrollador principal de una de las herramientas que ha intentado resolver el problema de las alertas. Nuestra herramienta, StatsAgg , es comparable a programas como Bosun. StatsAgg tiene como objetivo cubrir alertas flexibles, suspensiones de alertas y notificaciones y es bastante maduro / estable en este momento (aunque la API no está lista).

De todos modos, algunas reflexiones sobre el tema de las alertas:

• Alerta por métricas individuales apesta. Trabajo en una empresa que administra miles de servidores, y tener que crear / configurar / administrar alertas separadas para cada serie métrica de '% de espacio libre en disco' es logísticamente inviable. Las herramientas de supervisión empresarial a menudo unen varias series de métricas con expresiones regulares (o simplemente expresiones con comodines). StatsAgg se construyó sobre la misma premisa; se unen varias series de métricas, y luego el grupo de métricas tiene las verificaciones de umbral de alerta ejecutadas en su contra por una sola 'alerta'. A escala, este tipo de capacidad es una necesidad.
• Si uno acepta mi afirmación anterior de que una herramienta de alerta no debería alertar sobre métricas individuales, se deduce que la herramienta debe tener un mecanismo para obtener rápidamente una lista de métricas calificadas y de los valores de las métricas. Muchas herramientas dependen de los almacenes de datos de consulta para obtener la lista de métricas y valores de métricas, y esta solución, francamente, no funciona muy bien a escala. La lógica de alerta, por su naturaleza, debe ejecutarse con frecuencia (cada X segundos, o cuando llega cada nuevo punto de datos calificado). Los almacenes de datos (grafito, opentsdb, influxdb, etc.) simplemente no se crearon para manejar consultas constantes de 'dame la lista actual de métricas que se ajustan a este patrón' y 'muéstrame los últimos valores X para estas métricas Y'. O no tienen el lenguaje de consulta / API apropiado, o simplemente no pueden manejar la carga. Para ser claros, estoy hablando de escalas de ejecución de lógica de alerta contra 10,000 series de métricas cuando hay 10,000,000 de series de métricas disponibles en el almacén de datos. Este no es el caso de uso de todos, pero es el de mi empresa.
• Descubrí que abordar el problema a través del procesamiento de transmisión es la única forma viable de abordar los problemas planteados por mi último punto. Es por eso que StatsAgg se creó para sentarse frente al almacén de datos. La lógica de alerta puede ejecutarse en función de las métricas sin tocar el almacén de datos, y las métricas simplemente pasan al almacén de datos. Las principales premisas de este enfoque son que 1) las alertas recién creadas no pueden / no usarán valores de métrica antiguos / archivados para la evaluación de alertas 2) si el programa de procesamiento de transmisión (ex- StatsAgg) falla, entonces los puntos de datos no lo hacen en el almacén de datos 3) los valores métricos necesarios para la evaluación de alertas se almacenan en la memoria, lo que podría ser un problema de estabilidad del servidor. 4) el programa de procesamiento de flujo debe poder deconstruir y reconstruir las métricas entrantes (que InfluxDB no ha facilitado durante el último año ...). Incluso con estas ideas, esta solución ha funcionado muy bien para mi empresa y a gran escala. A veces, hemos tenido más de 200,000 series de métricas en vivo, promedios de más de 30k métricas entrantes / seg, cientos de alertas que evalúan miles de series de métricas y un servidor que ejecuta StatsAgg que apenas comienza a sudar. Mientras tanto, el almacén de datos no recibe ninguna consulta.

Esas son las principales cosas que quería mencionar. También hay muchos otros aspectos importantes para las alertas (notificaciones, suspensiones, etc.), pero esas soluciones son fáciles de incorporar una vez que se ha resuelto la arquitectura del problema central. Me doy cuenta de que la escala de nuestras necesidades no es la misma que la del usuario promedio, pero espero que todos puedan apreciar esta perspectiva.

Me gustaría sugerir el lanzamiento con un controlador de notificaciones que pueda enviar datos a Alerta: https://github.com/guardian/alerta

Alerta tiene una API REST muy sana para recibir notificaciones.

¡Prefiero una implementación lean grafana!
Creo que vale la pena volver a evaluarlo después de que todos hayan tenido experiencia con esta función en la típica experiencia de usuario fantástica de Grafana.

Habrá muchos casos complejos y / o sistemas backend personalizados con los que la gente querrá integrarse. Puede ver muchos en este hilo, en su mayoría de código abierto, ¡pero también hay tantos productos comerciales! No se moleste con los manipuladores individuales: será una rata completa y siempre estará en modo de captura

Recomiendo encarecidamente implementar solo dos tipos de controladores. Uno es definitivamente HTTP POST, será la herramienta más versátil y flexible. El otro es el scripting personalizado, por lo que los usuarios pueden implementar la integración con la herramienta específica que elijan. El modelo de complemento no es malo, pero obliga a usar un lenguaje de complemento específico que es limitante. Las secuencias de comandos externas son mejores, siempre que le pase a una secuencia de comandos todos los detalles, la secuencia de comandos se puede escribir en cualquier idioma: secuencia de comandos de shell, Python, etc.

Estoy con @ 007reader

Estoy de acuerdo. Siempre que se proporcionen métodos de integración comunes, la implementación personalizada puede ser un proyecto o implementación independiente.

Por ejemplo, la reciente versión de CloudWatch es decente, sin embargo, me encantaría convertirlo en un proyecto separado solo con métricas seleccionadas sincrónicas para el almacenamiento alternativo. Nos dará una retención completa en lugar de solo 2 semanas de datos.

Hola a todos,
¡Mi video de presentación de grafanacon está en línea!
está en https://www.youtube.com/watch?v=C_H2ew8e5OM
Creo que se aclarará mucho, aunque como puede ver. los detalles de las integraciones aún están por resolverse y también era un tema que mucha gente quería discutir. (aunque hubo tiempo limitado y le pedí a la gente que continuara la conversación aquí para que todos puedan participar)

@simmel sí exactamente. usaría una consulta ES y establecería una regla al respecto.
@activars sobre agrupación y descubrimiento, creo que mucho de eso dependerá de su fuente de datos, pero los requisitos más comunes deben abordarse si usa algo como grafito o ES que sé que son muy buenos en el "descubrimiento automático" de métricas / series nunca antes vistas. / documentos que coinciden con la expresión dada (con comodines) para grafito o consulta (para ES). no estoy seguro de las otras fuentes. su comentario sobre la necesidad de aplicar excepciones a las reglas es más complicado, probablemente tendremos que abordarlo en algún momento, pero creo que puede esperar hasta que las cosas estén más claras y más tranquilas. tal vez podamos evitar necesitar eso de alguna manera.
La frecuencia de fuentes de datos demasiado lentas, todavía no estoy seguro. pero no lo hagas ;-). también depende del manejador. La implementación escalable debería ser posible, también con el controlador incluido, así que estamos bastante seguros de que lo veremos. pero tal vez no sea una prioridad para el primer lanzamiento. sí, los complementos de notificación serán clave y nos aseguraremos de que pueda usar lo que quiera / necesite. re api: sí :)
@sknolin, si lo entiendo correctamente, en su opinión, grafana haría la programación de la alerta, la ejecución, activará los ganchos de notificación, etc., incluso cuando use otro sistema como nagios / bosun. entonces cuál sería exactamente el rol del sistema externo (nagios / bosun / ...). esto también parece similar a lo que estaba hablando @Crapworks .
@ jds86930 StatsAgg parece bastante interesante. Creo que aquí también tendría sentido una integración con grafana. Creo que el procesamiento de secuencias es un enfoque válido que tiene un lugar como alternativa a las consultas repetidas. pero este último es más sencillo para empezar y, en general, creo. Pero ambos deberían ser apoyados. Entonces, sí, en grafana podrá configurar patrones / consultas que coincidan con un espectro de datos y, potencialmente, cubrir nuevas series / datos a medida que se publiquen. Sin embargo, en nuestra opinión, simplemente aprovecharía cualquier funcionalidad que tenga su fuente de datos (por ejemplo, el grafito es bastante bueno en esto con sus comodines, expresiones globales, etc., y datos enriquecidos de búsqueda elástica y modelo de consulta), o si alguien usara grafana + StatsAgg, podrían solo usa StatsAgg para resolver eso. ¿Estás diciendo que la propia grafana debería hacer algo específico aquí? Creo que si su fuente de datos no es lo suficientemente rápida, resuelva el problema de la fuente de datos. obtenga algo más rápido, que tenga almacenamiento en caché para metadatos métricos, tal vez un servidor de memoria al frente o procesamiento de flujo. pero de cualquier manera en lo que respecta a Grafana, ¿no cambiaría mucho en lo que puedo pensar?
@blysik sí parece interesante. Tantas herramientas de alerta con las que deberíamos integrarnos :) para ser claros, ¿te gusta la idea de administrar las reglas de alerta y visualizarlas en grafana de la forma en que se ha presentado hasta ahora, pero quieres usar alerta para encargarte de las notificaciones? ? alerta sería el lugar principal al que ir para ver el estado de sus alertas (que parece una cosa razonable), pero quiero asegurarse de que entiendo completamente cómo ve la integración.

@ 007reader , @shanielh , @activars solo para ser claros, esta integración a través de una publicación HTTP genérica o un script, cuál sería el objetivo. para decirle al sistema externo "hay una nueva regla, aquí está la consulta, los umbrales, la frecuencia, etc. ahora, por favor, ejecútela"? ¿O sería grafana lo que ejecuta las reglas y luego actualiza los sistemas externos con un nuevo estado?

@blysik sí parece interesante. Tantas herramientas de alerta con las que deberíamos integrarnos :) para ser claros, ¿te gusta la idea de administrar las reglas de alerta y visualizarlas en grafana de la forma en que se ha presentado hasta ahora, pero quieres usar alerta para encargarte de las notificaciones? ? alerta sería el lugar principal al que ir para ver el estado de sus alertas (que parece una cosa razonable), pero quiero asegurarse de que entiendo completamente cómo ve la integración.

Correcto. Alerta se perfila como nuestro centro de notificaciones. Todo tipo de cosas que le envían alertas. Por ejemplo: scripts personalizados, Cabot, Zenoss, vCenter y tal vez Grafana. Eso le da a las operaciones un solo lugar para ver todas las alertas. Y ese es el único lugar que envía las notificaciones al ingeniero de llamadas.

@sknolin https://github.com/sknolin si entiendo correctamente, en su
vista, grafana haría la programación, ejecución, activación de la alerta
ganchos de notificación, etc., incluso cuando se usa otro sistema como
nagios / contramaestre. Entonces, ¿cuál sería exactamente el papel del sistema externo?
(nagios / contramaestre / ...). esto también parece similar a lo que @Crapworks
https://github.com/Crapworks estaba hablando.

Supongo que no lo expliqué bien. Eso no es lo que yo querría, grafana no
haciendo todas esas cosas. @Crapworks (que es divertido de escribir) está hablando de forma pasiva
verificaciones de servicio, solo usaría sondeo activo.

Entonces, todo lo que querría es una API donde pueda leer el estado de las alertas de Grafana.
Los sistemas externos hacen todo lo demás.

Eso no significa que si no se convirtió de alguna manera en un gran general
herramienta de alerta que no la usaría. Justo lo que haría ahora.

Scott

@sknolin

Entonces, todo lo que querría es una API donde pueda leer el estado de las alertas de Grafana.

¿Cómo se actualizaría ese estado en grafana? ¿Qué proceso sería ejecutar alertas y actualizar el estado en grafana?

Cada vez que se realiza un sondeo, grafana actualiza el estado de alerta, con algún tipo de intervalo de almacenamiento en caché para hacer frente a múltiples sistemas que lo sondean.

Veo el punto de que esto todavía requiere que Grafana haga lógica para las alertas y las presente. Pensándolo bien, no, no necesito alertas de ningún tipo.

Creo que podría hacer cualquier alerta necesaria si pudiera recuperar el valor actual de una métrica en un panel gráfico. Por ejemplo, cuando derivamos una tasa de la suma de varias métricas de contador y la graficamos, sería bueno sondear el valor actual con el sistema de monitoreo. Tal vez eso sea totalmente factible ahora y solo estoy siendo obtuso.

Scott

@Dieterbe El último:

Grafana sea lo que ejecute las reglas y luego actualice los sistemas externos con un nuevo estado

@Dieterbe Estoy de acuerdo en que sondear la fuente de datos (Graphite, OpenTSDB, etc.) utilizando la sintaxis de consulta nativa de la fuente de datos es más simple / fácil y es probablemente la forma más rápida de obtener alguna forma de alerta de forma nativa en Grafana. Para mucha gente, este tipo de solución satisfará sus necesidades, y creo que esta es la mejor solución para la implementación inicial de Grafana (en mi opinión). Mi punto principal fue que hay un límite en la configurabilidad y el rendimiento de las alertas que será difícil superar con el modelo de 'sondeo de la fuente de datos'.

En cuanto a las direcciones que Grafana podría tomar para las soluciones de alerta a largo plazo, pude ver algunas opciones:

• Trabaje con los encargados del mantenimiento del almacén de datos para crear API más rápidas y mejores diseñadas específicamente para el caso de uso de alertas. No me gusta esta opción porque muchos de esos proyectos avanzan a un ritmo más lento (meses o años) y es posible que no acepten algunas o todas las solicitudes de mejora. Probablemente también querrán codificar en el idioma nativo de sus almacenes de datos, que no siempre son lenguajes rápidos (por ejemplo, Graphite en Python).
• Cree capas de procesamiento de transmisión / almacenamiento en caché para cada almacén de datos como proyectos independientes de raintank. Creo que, en última instancia, esto tendría un mejor resultado que intentar convencer a los diversos encargados del mantenimiento del almacén de datos para que creen soluciones para sus proyectos. Esto también le permitiría continuar ampliando el trabajo que ya está haciendo (utilizando los mecanismos de consulta del almacén de datos existentes). Incluso podría crear sus propias API personalizadas en las capas de procesamiento de transmisión / almacenamiento en caché que podrían simplificar la sintaxis de consulta de Grafana al almacén de datos.
• Cíñete a la solución nativa en la que estás trabajando y haz que funcione bien. Las herramientas de terceros como StatsAgg, bosun, etc. estarán disponibles para casos de uso que son más exigentes / especializados / complejos. Tener a Grafana integrado con estas herramientas definitivamente sería un beneficio adicional para el usuario, pero agregaría una complejidad no trivial a Grafana. Dicho esto, parece que puede terminar haciendo esto de todos modos (estoy viendo 'Alerting Backends' en la diapositiva 35 de su presentación en este momento). Personalmente, estoy dispuesto a implementar un conjunto de API compatibles con Grafana en StatsAgg; solo tendríamos que averiguar qué son las API y obtener un borrador de la documentación del protocolo API. No dude en enviarme un mensaje / correo electrónico si desea discutir algo de eso.

Hola a todos,

@Dieterbe Acabo de ver tu presentación y el material se ve increíble. Realmente aprecio que esté tratando de construir un sistema de alerta de la manera "correcta", ¡utilizando muchos aportes de la comunidad! ¡Gracias!

También quiero dejar mi punto un poco más claro, ya que no creo que fuera obvio lo que estaba tratando de decir. _NO_ necesito que grafana esté al tanto de cualquier otro sistema de monitoreo como Nagios, Icinga, Bosun, etc. En realidad, solo necesito esto:

• La increíble interfaz de usuario que mostró en su presentación o lo que sea que parezca cuando está completamente terminada
• Un controlador HTTP POST genérico (como también sugirieron algunas otras personas aquí) que es completamente configurable (le daré un ejemplo más adelante)

El flujo de eventos en el que estoy pensando:

• Visualizas tus datos en grafana
• Agrega umbrales para alertas en grafana
• Tan pronto como se excede un umbral, se activa el controlador HTTP POST
• A partir de ese momento se hace el trabajo de grafanas

Como mencionan @mgravlin y @ 007reader , la mayoría de los servicios de notificación y alerta utilizan HTTP POST, requiriendo diferentes tipos de datos. Entonces, lo más genérico que se me ocurre es dejar que el usuario defina sus datos POST y sus encabezados, para que pueda alimentar varios sistemas con un solo controlador, utilizando diferentes plantillas. Ejemplo de pseudocódigo:

"notificator": {
    "httppost": {
        "data": {
            "host": "$hostname",
            "alert": "$alertname",
            "state": "$state"
        },
        "header": {
            "content-type": "application/json"
        }
    }
}

Darle al usuario suficientes variables para usar aquí, será lo suficientemente poderoso como para alimentar una tonelada de backends.

Y nuevamente, con ese tipo de controlador, cualquier administrador de sistemas con algún conocimiento de codificación puede construir su propio receptor de publicaciones http y transformar cómo le gusta, por ejemplo, alimentar backends que no entienden las publicaciones http.

Dado que esto es apátrida, también se amplía. Simplemente coloque un equilibrador de carga frente al backend / api / lo que sea y estará listo para comenzar.

Al menos, esto resolvería la mayoría / casi todos mis problemas;)

Salud

Gracias por crear esta función. ¿Tiene una fecha aproximada de lanzamiento?

torkelo dijo BRUTAMENTE 3 meses en el IRC.
Si lo entendí correctamente, esa es una estimación muy aproximada y debería tratarse como tal.

Estoy emocionado por la capacidad de hacer alertas con grafana. Creo que esta es la única característica que impide que Grafana sea la herramienta de monitoreo definitiva.

Si tiene una versión alfa / beta anticipada, me encantaría probar y dar retroalimentación temprana con datos de producción.

++

Yo 2 lol

+1

Em seg, 16 de noviembre de 2015 às 21:03, Jing Dong [email protected]
escreveu:

Si tiene una versión alfa / beta anticipada, me encantaría probarla y ofrecerla con anticipación.
retroalimentación con datos de producción.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
Si tiene una versión alfa / beta anticipada, me encantaría probar y dar retroalimentación temprana con datos de producción.

+1 yo 2

2015-11-21 14:44 GMT-02: 00 notificaciones de [email protected]:

+1
Si tiene una versión alfa / beta anticipada, me encantaría probarla y ofrecerla con anticipación.
retroalimentación con datos de producción.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279.

+1

es genial ver todos los +1, pero FWIW no son realmente necesarios. ya sabemos que es la nueva característica más esperada, y una vez que tengamos un progreso tangible, el código aparecerá en una rama separada con la que cualquiera puede jugar. Por cierto, también estamos trayendo más personas para trabajar a tiempo completo en grafana, así que estad atentos a todos :)

Sí, por favor, hay 484 personas "viendo" este problema. Cada vez que haces "+1" en él, 484 personas reciben una notificación por correo electrónico. Simplemente suscríbase a la notificación y será una indicación de su interés en el tema.

+1>; PAG

El lunes, 30/11/2015 a las 10:33:52 -0800, Vadim Chekan escribió:

Sí, por favor, hay 484 personas "viendo" este problema. Cada vez que haces "+1" en él, 484 personas reciben una notificación por correo electrónico.

Sory, sé que están trabajando muy duro en esto. ¿Existe algún plazo para el primer lanzamiento?

Estaría más que feliz de poder configurar métricas y umbrales de alerta (ya sea a través de la interfaz web o API) y un cronjob / daemon de Grafana que verifica estas métricas y hace un HTTP POST con JSON o invoca un script con JSON en stdout. Sería _extremadamente_ sencillo para las personas escribir un script de Python simple que transmita esta información a Pagerduty, Slack, IRC, SMS, correo electrónico o lo que sea.

Si bien agradecería mucho la conveniencia, no creo que sea el trabajo de Grafana integrarse estrechamente con herramientas de terceros, y preferiría ver una implementación minimalista antes que una bien desarrollada más tarde.

Estoy completamente de acuerdo con @anlutro . Proporcione algo simple para comenzar. Lo más interesante para mí es permitir que las personas establezcan ellos mismos alertas simples (autoservicio). Grafana no debería intentar reemplazar las soluciones de alerta / escalada existentes.

También estoy de acuerdo con @anlutro . Pero en lugar de simplemente proporcionar una API simple, la parte de alerta puede manejar complementos personalizados que interactúan con la API. De esa manera, el paquete base podría incluir correo electrónico, pagerduty y algunos otros, luego la comunidad podría agregarlo según sea necesario. Similar a cómo se manejan los complementos de Logstash ahora.

+1

¿Alguna novedad sobre el sistema de alerta? ¿Alguna estimación?

+1

+1
Vale la pena mencionar que el mecanismo de aciertos e histéresis funciona en las alertas recopiladas como un concepto a considerar.

¿Ha pensado en funciones de alerta avanzadas como detección de anomalías, detección de correlación, detección de causa raíz, etc.?

+1. Alerta como subsistema de complementos: esta sería la solución más flexible. No es necesario agregar tantas funciones dentro de grafana si hay muchos proyectos que pueden hacer esto mejor en el backend.

@Dieterbe @torkelo Sería genial tener una "estimación aproximada" sobre esto. Personalmente, he estado aguantando desde que las alertas de autoservicio basadas en métricas son una característica muy necesaria en mi caso y estoy convencido de que Grafana es la interfaz de usuario adecuada para ello. El problema es que ya han pasado 6 meses y no ha habido una actualización de ETA o incluso un comentario de uno de ustedes durante bastante tiempo, así que estoy empezando a tener pensamientos contraproducentes de "Voy a tener que piratear algo". ..Si pudiera saber si serán otros 6 meses en lugar de unas pocas semanas más, podría tomar una decisión mucho mejor informada.

¡Gracias!

+1
El 18 de enero de 2016 a las 21:54, "Jaime Gago" [email protected] escribió:

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo Sería genial tener incluso un muy duro
"estimar" sobre esto. Personalmente he estado aguantando desde métricas
La alerta de autoservicio basada es una característica muy necesaria en mi caso y estoy
convencido de que Grafana es la interfaz de usuario adecuada para ello. El problema es que es ahora
Han pasado 6 meses y no ha habido ninguna actualización de ETA o incluso un comentario de uno de los
durante bastante tiempo, así que estoy empezando a tener "Voy a tener que
hackear algo "pensamientos contraproducentes ... Si pudiera saber si es
van a ser otros 6 meses en lugar de unas pocas semanas más, podría ganar mucho
decisión mejor informada.

¡Gracias!

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684.

+1

+1

@jaimegago realmente lo siento por no actualizar aquí sobre nuestro progreso o falta de progreso en este tema. Pensamos que tendríamos tiempo para dedicarlo a esto, pero siempre terminaba siendo empujado porque algo con mayor prioridad se interponía en el camino.

En septiembre comencé a trabajar en el soporte de la fuente de datos de Elasticsearch, que se convirtió en la base de una versión 2.5 centrada en la fuente de datos, después de eso, el problema mejor calificado en Grafana desde la v1 era un panel de tabla, y especialmente después del soporte de Elasticsearch, sentí un pequeño lanzamiento con una tabla. El panel era más importante que alertar, por lo que se convirtió en la base de 2.6.

Últimamente tenemos muchos usuarios y empresas que desean integrarse más con Grafana, lo que nos ha llevado a trabajar para mejorar la API y las capacidades del complemento, lo que resultó en otro aplazamiento para este problema. Lamento mucho que hayamos comunicado esto tan mal. Siempre tuvimos la ambición de empezar PRONTO, pero PRONTO nos presionaron una y otra vez :(

¡Pero hay esperanza! Hemos ampliado el equipo centrado en Grafana a tiempo completo, en diciembre @bergquist se unió y en febrero

@torkelo Gracias por la actualización; No puedo decir que esté feliz, pero al menos sabemos dónde estamos.

Una pregunta que queda es si 2.x obtendrá más lanzamientos puntuales o si 3.x será el próximo lanzamiento. ;)

@RichiH con respecto a otra versión puntual, no estoy seguro, pero es probable que en febrero se lance otra versión puntual antes de la 3.0.

@torkelo Muchas gracias por tomarse el tiempo para proporcionar una actualización detallada.

tal vez esto ya esté en la hoja de ruta, de lo contrario, considere agregar el "POST" a partir de la notificación.
Entonces podemos enviar la alerta a un sistema diferente para procesarlos, como kafak

+1 para notificaciones SNMP!

+1 Creo que esta es la principal característica que falta en Grafana para convertirla en una herramienta de monitoreo viable (y la mejor en su clase) para la producción.

+1

¿Algún administrador (@Dieterbe?) Disponible para bloquear los comentarios sobre este problema por parte de un no colaborador? Así que solo obtendremos contenido interesante sobre el avance de la función, y no los inútiles +1 ...

En caso de que no conozca esta función, aquí está el enlace al documento ad hoc de GitHub .

Gracias corazon:

@Mayeu uh, como uno de los "no colaboradores" que ha contribuido con más de un +1 a este problema y en otros lugares no creo que bloquear este problema a los colaboradores sea el camino a seguir. Simplemente cree un filtro inteligente en su correo electrónico ;-).

También creo que los +1 cumplen un propósito, mostrando la cantidad y la extensión del interés para esto (y otros lugares).
Lo que falta, quizás, es un botón +1 en la interfaz de usuario que cumpliría la misma función, pero sin todas las notificaciones para todos los suscriptores ... así que una solicitud de función para @github.

Nos estamos desviando del tema y esta es la primera y última vez que escribiré sobre esto.

Cualquier persona interesada en este tema debe suscribirse en la parte superior derecha; lo mantendrá informado y no enviará correos electrónicos a todos.

En cuanto a un sistema de votación para evitar la acumulación de +1, consulte https://github.com/dear-github/dear-github - 27 días obsoleto y sin reacción de GitHub.

+1

Alguna noticia sobre esto ?

No creo que todavía haya noticias sobre este tema. Pero algo bueno sobre el próximo lanzamiento de Grafana es:

Grafana podrá administrar aplicaciones / complementos personalizados. Luego, podemos escribir nuestros propios complementos / aplicaciones de alerta personalizados e importarlos a Grafana. Escribir estas pequeñas aplicaciones / complementos será una ganancia rápida mientras espera una gran función de alerta.

Me gusta la idea de configurar alertas en el mismo lugar que visualizar. Simulacros increíbles en https://www.youtube.com/watch?v=C_H2ew8e5OM, pero ¿hay alguna fecha sobre cuándo se lanzará?

buen video, gracias!

algunos comentarios.

Estoy satisfecho con la idea de umbrales lineales simples y consultas personalizadas avanzadas.

notificadores más útiles:

• exec: podría usar algo como ssh o sendmail
• webhooks: el usuario puede colocar un webcgi para recoger web-hooks para hacer cosas ...
• correo electrónico: envíe un correo electrónico simple con un volcado json de los datos de notificación.
• complementos ... no es realmente necesario

api para extraer el estado de las alertas ... parece una mala idea,
sin embargo, la API para extraer la configuración de alerta en un formato json básico podría ser bueno.
este volcado json podría transformarse en algo que otros sistemas podrían encontrar útil para transformar.

No estoy seguro de si esto está mal visto o no. No pude encontrar un enlace de donación en ninguna parte, pero qué tipo de contribución sería necesaria para obtener esto en la versión 3 antes de fin de mes. Realmente podríamos usar esta función, pero nuestros recursos. están atados cajero automático

+1

+1

Esta es una característica muy necesaria para nosotros aquí en Work Market.

¿Se lanzan las alertas destacadas?

No
El jueves 25 de febrero de 2016 a las 11:13 p.m., kskaran94 [email protected] escribió:

¿Se lanzan las alertas destacadas?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056.

¿Sería seguro asumir que la función de alertas se lanzará en el verano?

_suspense intensifica_
El 26 de febrero de 2016 a las 10:23 a. M., "Ian Ha" [email protected] escribió:

¿Sería seguro asumir que la función de alertas se lanzará en el
¿verano?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869.

¿Alguna noticia sobre esto?

+1

+1 sería bueno tenerlo ya, la gente ya está esperando todo el año o incluso más.

: +1: me gusta. Gracias por el video y la presentación, @Dieterbe. ¿Está disponible para pruebas / primeros usuarios?

@torkelo Has anunciado

Queremos que esta característica sea la característica principal de Grafana 3.0

Pero al mirar el registro de cambios de la rama 3.0 no publicado (1) no se menciona la alerta, ¿debería comenzar a llorar o el plan aún es tener alertas de la función de título 3.0?

(1) https://github.com/grafana/grafana/blob/master/CHANGELOG.md

Tomamos la decisión de desarrollar el sistema de complementos para grafana 3 para poder lanzar grafana 3 y luego comenzar a trabajar en las alertas, en lugar de posponer innecesariamente grafana 3.

@Dieterbe No puedo decir que esté feliz, pero tiene sentido. El seguimiento obvio es si hay algo similar a ETA para alertar; y si es una característica confirmada y comprometida para 3.1.

Además, como solución temporal, http://alerta.io/ hace parte de lo que quiero que Grafana haga; las personas que esperan esta función pueden querer probarla.

¿Existe alguna especificación para el complemento? Podría ser bueno construir algo en el
comunidad para manejar las alertas para que coincidan con el lanzamiento de la versión 3?

Beth
El 16 de marzo de 2016 a las 8:44 a. M., "Richard Hartmann" [email protected]
escribió:

@Dieterbe https://github.com/Dieterbe No puedo decir que estoy feliz, pero eso
tiene sentido. El seguimiento obvio es si hay algo similar a ETA para
alertando y si es una característica confirmada y comprometida para 3.1.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe Creo que también sería bueno tener la capacidad de crear notificaciones en el lado del cliente. Por ejemplo, mensajes de voz en un monitor público con panel, por lo que no necesita mirar el panel para saber que hay algún problema. Como las alertas de sonido de Zabbix. Para este propósito, escribí un código JavaScript simple que escanea un panel en particular y, si hay algún problema, me notifica usando Web Speech API . Por ahora me funciona muy bien.

¿Qué hay de usar kapacitor como backend para alertas, su risa de scripting es simple y realmente poderosa? O qué hay del soporte para múltiples backends de alerta y tener abstracción sobre eso.

Ahora que está disponible la versión 3.0, estoy muy emocionado de tener la alerta en grafana. Las alertas convertirán a grafana en la herramienta definitiva.

Hola @Dieterbe ,

Como puedo ver en esta versión https://github.com/raintank/grafana (que dijiste que tiene el paquete de alerta), el repositorio ahora está en desuso y dice que todo el nuevo desarrollo va en https: // github. com / raintank / worldping-api. Eso me hace preguntarme si esta función de alerta aún se está desarrollando o si se ha planificado y cambiado para otra cosa (como worldPing, que no se parece a lo que hemos estado discutiendo aquí).

Hola @minhdanh , el objetivo siempre ha sido agregar alertas "correctamente" en grafana, no solo como un truco en una bifurcación específica de raintank, que es el repositorio al que te refieres (y que solo cubría un dominio muy estrecho de todos modos, aunque puede tener sentido reutilizar parte de ese código una vez que comencemos a trabajar en un programador / ejecutor, que tenía ese repositorio). Por eso hemos estado trabajando duro para hacer que grafana sea tan conectable para la próxima versión de grafana 3. (y como resultado de eso, nos permitió trasladar nuestras propias necesidades a una aplicación independiente, que es la worldping-api a la que te refieres).
Ha quedado muy claro que, como primer paso, debemos simplemente crear la interfaz de usuario para administrar las reglas desde el interior de sus paneles y paneles de grafana y exponerlas a través de algún tipo de API, para que los complementos puedan usarlas para ejecutarlas. Esta será la forma más rápida de activar las alertas. el "programador / ejecutor con pilas incluidas" vendría más tarde y podría reutilizar parte del código al que se refirió.

de todos modos, primero haremos la interfaz de usuario de administración en grafana y expondremos las reglas a través de la API, y lo tomaremos desde allí.

Gracias @dieterbe.

Como siempre, existe la cuestión de una línea de tiempo aproximada, incluso si solo es "no
antes de X ".

Entiendo lo molesta que puede ser esta pregunta, por lo que la redacción del
segunda parte. Espero que entiendas lo frustrante que es esperar al otro
lado de la cerca puede ser.

Ricardo

Enviado por móvil; disculpe mi brevedad.

Hola a todos,

Espero que esté bien que raintank lo diga aquí, pero recientemente ordenamos casi un mes de horas de codificación dedicadas por raintank para trabajar en las alertas. Entonces, ¿por qué esto no dará como resultado la función de alerta final? Deberíamos ver algo pronto para sentar las bases para las alertas en grafana. Si otras empresas siguieran nuestro enfoque o también individuos que invirtieran algo de efectivo en este asunto, eso debería acelerar las ideas y las prioridades aún más.

@flyersa , ¡

Jon

Hola a todos,

Sé que muchos están ansiosos por esta función y me complace informar que el equipo ha comenzado a trabajar en ella. Explicamos nuestras razones del retraso en el

Lanzaremos alertas en dos fases. La primera fase permitirá a los usuarios definir sus alertas y umbrales dentro de la interfaz de usuario de Grafana. Grafana también expondrá estas definiciones de alerta a través de una API HTTP a programadores de terceros y backends de alerta. En la segunda fase, brindaremos el servicio backend para consumir y actuar sobre estas definiciones, para una solución completamente integrada.

Esperamos que la primera fase se lance en cuestión de semanas.

Estamos tratando de equilibrar la rentabilidad con la velocidad, y apreciamos GRANDEMENTE el apoyo comercial de nuestros clientes como @flyersa. Si otros desean apoyar el desarrollo de esta función y Grafana en general, considere comprar un plan de soporte . Nos ayudará a desarrollar un gran software 100% de código abierto.

Trabajaremos en estrecha colaboración con todos los clientes admitidos a medida que implementemos la función y nos aseguraremos de que satisfaga bien sus necesidades.

-raj dutt | ceo / cofundador | raintank

Hola @ nopzor1200 ,

Gracias por tu actualizacion. ¿Tiene una estimación de cuándo estarán disponibles las alertas?

Obviamente, es imposible comprometerse en una fecha concreta, pero se agradecerá mucho un marco de tiempo (semanas, meses, etc.).

10x!

Hola chicos, muy emocionado por esto. Así es como me imagino usar esto, si alguien puede verificar que es un patrón estándar / compatible, lo agradecería.

• Cada host que quiero monitorear emite "Cheques". Un "cheque" consiste en:
  
  
  
  • el nombre de host
  
  
  • la marca de tiempo
  
  
  • el estado, que es 0 = OK, 1 = WARN o 2 = CRITICAL
  
  
• Estas comprobaciones pueden provenir de una variedad de fuentes arbitrarias (scripts de shell + cron, statsd / collectd, comprobaciones de Nagios, etc.) y se acumularán en Elasticsearch. La misma verificación puede tener diferentes configuraciones en diferentes hosts, pero esto será opaco para Grafana.
• Configuraré la conexión de Grafana a Elasticsearch y alertaré cuando cualquier verificación proveniente de cualquier host tenga un valor de estado> = 1.
• Si nuevos hosts se unen al clúster, no se requiere configuración en Grafana; Grafana simplemente verá cualquier punto de datos en el estado 1 o 2, independientemente de su procedencia.
• Si un host muere repentinamente y deja de transmitir cheques, debemos detectarlo. Para manejar esto, cuando un host se inicia, registrará una verificación maestra como estado "ON", y el valor solo pasará a "OFF" cuando se detenga normalmente. De esta manera puedo buscar cualquier host "ON" que no haya emitido cheques en los últimos X segundos.
• En general, no usaré alertas basadas en umbrales en datos de series de tiempo en Graphana. En otras palabras, no voy a "verificar si el uso de CPU> 80%" dentro de Grafana mismo, sino que Grafana recibirá una verificación de "estado de uso de CPU" (0/1/2) y una alerta en el estado 1 o 2.

Hola @johnnyshields ,

Eso se ve bastante bien, pero en lugar de "0 = OK, 1 = WARN o 2 = CRITICAL", ¿por qué no usar una definición de nivel estándar? El utilizado por syslog es prácticamente un estándar de facto para estas cosas:

• Valor -> Severidad
• 0 -> Emergencia
• 1 -> Alerta
• 2 -> Crítico
• 3 -> Error
• 4 -> Advertencia
• 5 -> Aviso
• 6 -> Informativo
• 7 -> Depurar

Y tener una configuración (¿global?) Para decirle a grafana qué nivel considerar como umbral de alerta.

Dado esto, agregaría los siguientes cambios a su publicación:

• alerta cuando cualquier cheque proveniente de cualquier host tiene un valor de estado> = CONFIGURABLE_ALERT_LEVEL.
• Grafana simplemente verá cualquier punto de datos en el estado> = CONFIGURABLE_ALERT_LEVEL independientemente de dónde provenga
• Grafana recibirá un nivel de verificación de "Estado de uso de CPU" y una alerta si se configura en consecuencia.

@brunorey gracias, tiene sentido!

Los niveles y estados de registro son dos cosas diferentes. Podría tener un mensaje de registro de 6 información, pero ¿cómo puede algo estar en un estado de 6 información?

Los estados OK, WARN y CRITICAL están bien, y pueden ser demasiado buenos para aquellos que solo se preocupan por OK y CRITICAL. Agregar más estados agrega confusión a menos que su significado se entienda universalmente, y sugiero limitarlo a 3.

Con respecto a solo alertar sobre "estado de CPU> = WARN" versus "CPU> 80%", afirmo que algunas personas querrán mantener sus estados de 3 niveles en una base de datos de serie de tiempo para que puedan ver cómo el estado cambió con el tiempo. Esas personas alertarán en función de los datos de las series de tiempo de su estado. Otros querrán alertar sobre el valor bruto de la CPU que supera el 80%. El caso es que lo único que se necesita es alertar sobre los datos de series de tiempo.

La razón por la que elijo la ración de estados de registros enteros en lugar de usar los datos de la serie temporal directamente es que quiero poder controlar lo que se considera una alerta en cada nodo.

Por ejemplo, los servidores de trabajo rutinariamente tienen una CPU cercana al 100%, y no es un problema; quiero que funcionen a toda velocidad en todos los núcleos. Pero los servidores web no deben tener una CPU por encima del 20%. Entonces, si tuviera que hacer una CPU genérica> 80%, sería demasiado alto para las web y demasiado bajo para los trabajadores. (Este es solo un caso).

@johnnyshields No entiendo por qué no usaría alertas basadas en umbrales en datos de series de tiempo, en mi opinión, ahí es donde está el valor realmente fuerte (¿único?) de agregar alertas a grafana / grafito. Su estilo de "cheques" suena más adecuado para algo simple como monit. ¿Me he perdido algo aquí?

Como se explicó anteriormente, tengo muchos servidores con diferentes roles y los umbrales son diferentes por servidor. En última instancia, es una cuestión de si los umbrales se definen dentro de Grafana o en el propio servidor, creo que el servidor es más fácil en mi caso.

Además, algunas comprobaciones son "sí o no", por ejemplo, si el proceso X se está ejecutando, hace un ping al puerto Y responde, etc.

Comprendido. A veces, determinar estos estados es simple (> 80%) y, a veces, es complejo. Cuando son complejos, algún código determinará los niveles y enviará el nivel a una base de datos de TS. Esa es una práctica común, donde los datos se transforman en información. Mi punto es que no hay diferencia con un sentido de alerta.

Si necesita reglas complejas para sus alertas, no cree las reglas en el motor de alertas, compile las reglas en la canalización de TS para crear nuevos datos de TS y alerte de eso.

Simplifique el sistema de alerta. Oculte la complejidad en la canalización de TS.

El beneficio de crear nuevos datos de TS en una tubería frente a un sistema de alerta basado en reglas es que mantiene las alertas visuales y simples para las personas que configuran y reciben las alertas. Hay una visualización que se puede enviar por correo electrónico o sms que muestra solo lo que recibe la alerta, incluso si es un gráfico de estado simple en el que ven que el estado pasó de WARN a CRITICAL hace 20 minutos.

Creo que si desea controlar lo que se considera digno de alerta por host / rol, es mejor agregar lógica a lo que se considera WARN y lo que se considera CRIT, ya que agrega 8 capas de granularidad a la gravedad de la alerta.

Casi todos los demás sistemas de alerta modernos parecen haber convergido en OK / WARN / CRIT, y aunque probablemente se deba en parte a querer compatibilidad con las comprobaciones de Nagios, creo que la idea de querer mantenerlo simple es más importante. Si Grafana hace lo mismo, la integración con otros servicios de alerta / monitoreo será más fácil. Por ejemplo, en mi caso probablemente terminaría enviando alertas de Grafana a Sensu, que luego enviaría un correo electrónico, un mensaje de holgura o lo que sea. Sensu solo tiene OK / WARN / CRIT, por lo que se desperdiciaría más granularidad.

El nivel de alerta de registro de acuerdo parece una ingeniería excesiva. Bien, advertir, es probable que Crit haga el trabajo en la mayoría de los casos.

En los umbrales de alertas, me encantaría poder realizar alertas basadas en la desviación estándar. Son más útiles en la práctica en mi opinión.

El 12 de mayo de 2016, a las 8:49 a. M., RWhar [email protected] escribió:

@johnnyshields No entiendo por qué no usaría alertas basadas en umbrales en datos de series de tiempo, en mi opinión, ahí es donde está el valor realmente fuerte (¿único?) de agregar alertas a grafana / grafito. Su estilo de "cheques" suena más adecuado para algo simple como monit. ¿Me he perdido algo aquí?

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente o véalo en GitHub

Personalmente, he estado esperando recibir alertas utilizando datos de TS existentes que se introducen en el grafito como entrada, especialmente agregando estadísticas de las métricas de la aplicación desde (a través de StatsD) dentro de los rangos de tiempo especificados.

Además, sería bueno tener una opción en la que las alertas podrían activarse en el umbral e intervalos especificados más allá del umbral, por ejemplo, establecer el umbral de alerta "rpl_delay" 200 int 50 - causaría alertas en 200, 250, 300, etc. sin el necesita especificar manualmente niveles de umbral adicionales.

@johnnyshields No entiendo la diferencia entre 1 = WARN o 2 = CRITICAL. La alerta se activa o no se activa. Está por encima del 80% o no por encima del 80%. Entonces solo veo dos estados 0 y 1.
También sería bueno tener alertas más inteligentes donde pueda detectar que ha estado por encima del 80% durante 5 minutos seguidos para que no reciba alertas sobre picos temporales. Aún más avanzadas son cosas como los umbrales móviles, donde, por ejemplo, monitorea el tráfico de su sitio web y obtiene una cantidad X de tráfico y aumenta lentamente, digamos un 1% al mes, pero de repente obtiene un aumento del 10% en el tráfico en un hora. También querrá poder monitorear lo contrario, una caída repentina del tráfico. Algo similar a https://github.com/etsy/skyline ya que Skyline ya no existe.

Chicos, mi publicación aquí no se refería al número exacto de estados de alerta a usar; estaba preguntando de manera más general "¿Grafana admitirá los estados enumerados como un caso de uso de alertas?"

Dado que hay desacuerdo sobre el número óptimo (Nagios usa 3, syslog usa 7, a algunas personas les gusta 2, etc.) Grafana debería admitir un número arbitrario de estados.

Simplemente reiterando lo que dije antes de que creo que solo debería haber dos estados por cada alerta activada 1 o no activada 0. Si desea saber si se está acercando a un umbral, haga un umbral adicional para el valor más bajo.

La razón de WARN vs. CRITICAL es que las acciones que toma son diferentes. Un grupo de personas y acciones generalmente se notifican en WARN, y un grupo diferente / acciones diferentes en CRITICAL.

Esa es una diferenciación bastante valiosa, que no me gustaría irme con un sistema 0-1.

@lorenwest si desea una verificación diferente para un umbral diferente,
por lo que cada umbral es 0 o 1.
Por ejemplo, otra razón por la que desearía configurar las alertas de esta manera es cuando desea un correo electrónico cuando el umbral es superior al 70%, pero una página cuando está por encima del 80%. Justo como quieres grupos separados. WARN vs. CRITICAL tiene demasiada ambigüedad.

@doanerock eso tiene sentido. Permitir un número arbitrario de alertas en cualquier métrica o evento de TS permite la mayor flexibilidad. Eso simplifica la definición de alerta al no tener múltiples acciones para múltiples niveles.

asi que:

• las métricas pueden tener un número arbitrario de estados (incluidos los valores decimales / de serie temporal)
• las métricas pueden tener varias acciones de alerta adjuntas a la misma métrica
• cada alerta es un valor booleano verdadero o falso: se activa o no.

para dar un ejemplo:

• Tengo una determinada métrica con valores 0 = OK, 1 = WARN, 2 = CRITICAL
• Configuro 3 alertas:
  
  
  
  • si valor = 1, muestra una bandera amarilla en mi tablero
  
  
  • si valor = 2, muestra una bandera roja en mi tablero
  
  
  • si valor> = 1, envíame un correo electrónico
  
  

Hola a todos,

No sé si es el lugar adecuado para preguntar sobre este tema, pero intentaré cualquier forma con respecto al próximo módulo de alerta de Grafana.
En nuestra organización tenemos todos nuestros sensores de alertas de seguridad que alimentan Logstash / Elasticsearch para eventos y usamos Yelp / elastalert para ejecutar alertas con ciertos patrones con los siguientes criterios:

"Match where there are X events in Y time" (frequency type)
"Match when the rate of events increases or decreases" (spike type)
"Match when a certain field matches a blacklist/whitelist" (blacklist and whitelist type)
"Match on any event matching a given filter" (any type)
"Match when a field has two different values within some time" (change type)

Además, cuando detectamos criterios de alerta, ejecutamos un script de Python externo con argumentos que pasan argumentos de Elastalert al script con información como el campo de IP de origen / destino, el campo de marca de tiempo y evento, y nuestro sistema NAC se encarga de eso.

Ahora, mirando el módulo de alertas de Grafana Upcoming y con Elasticsearch como fuente de datos, me pregunto si el módulo de alertas de Grafan será posible para cooperar igual que Elastalert y eventualmente reemplazarlo con la información anterior.
por favor avise

Gracias

Sé que el equipo de grafana está trabajando duro en esto, y este hilo es largo, pero quiero señalar que Kapacitor acaba de fusionar una función que facilitará enormemente el desarrollo de aplicaciones de configuración de alertas frontend: influxdata / kapacitor # 577

Por lo que entiendo, el objetivo del lado de Grafana es hacer que el backend de alerta sea conectable (al igual que Grafana admite varias tiendas TSDB), pero quería mencionar con la esperanza de que Kapacitor obtenga un soporte de primera clase cuando se lance la funcionalidad de alerta de Grafana. Parece un gran ajuste, al igual que InfluxDB + Grafana.

@ thom-nic gracias por la sugerencia Kapacitor es exactamente lo que estoy buscando ...

Riemann también es genial y muy poderoso. telegraf -> riemann (alertando) -> influxdb <- grafana

Estamos avanzando en la rama alerting_definitions.

Ahora tenemos un modelo de reglas de alerta simple que puede definir en la interfaz de usuario y mediante la API HTTP. Puede obtener reglas, cambios de reglas, estados de reglas a través de la API HTTP. La programación simple de reglas de alerta y la ejecución de consultas y la ejecución de reglas también están comenzando a juntarse.

Una cosa que es un gran signo de interrogación para mí ahora es si el modelo de alerta actual es demasiado simple y un callejón sin salida. Con eso quiero decir que extender el modelo de reglas de alerta en el futuro requerirá cambios extensos.

Modelo de regla actual:

description
query: #A  (referencing a query in the metrics tab)
aggregation: avg
timerange:  3600   (seconds from now to look back when fetching data)
frequency: 60  (how often to execute alert rule query and evaluation rule)
critLevel: 80
warnLevel: 50

Este modelo de almacenamiento está representado en la interfaz de usuario y en la tabla de la base de datos real. Mi temor es que este simple modelo de reglas no aproveche lo suficiente los datos de las series de tiempo. No puede especificar umbrales dinámicos (donde los propios umbrales son el resultado de una consulta). Por supuesto esto
podría agregarse más tarde, pero requeriría un modelo de reglas y un motor de ejecución muy diferentes.

Entonces, mi idea es descartar este modelo simple y crear un nuevo modelo más complejo y dinámico que luego pueda admitir múltiples consultas para diferentes rangos de tiempo.

Consulta simple:

"alert": {
   "name": "CPU usage last 5min above 90%",
   "frequency": "1m",      
   "expr": "query(#A, 5m, now, avg)",
   "operator": ">",
   "critLevel": 90,
  },

// ahora a una alerta que usa un umbral dinámico basado en sus valores pasados

"alert": {
   "name": "CPU usage last 5m is 20% higher compared to last 24hours avg",
   "frequency": "1m",
   "expr": "query(#A, 5m, now, avg) => percentDiff() => query(#A, 1d, now, avg)",
   "operator": ">",
   "critLevel": 20,
  },

Ahora puede cuestionar esto indicando que estamos reinventando Graphite aquí, y que la TSDB debe manejar expresiones como esta. Pero ninguna TSDB admite cálculos con consultas para diferentes rangos de tiempo (timeShift solo cambia el mismo lapso de tiempo). Algunos problemas con los umbrales dinámicos es cómo visualizarlos. También puede hacer que la regla de alerta esté más divorciada de lo que realmente se visualiza en el panel.

No estoy seguro de cómo debería verse el GAL (Grafana Alerting Language). ¿Deberían ser solo cadenas de expresión donde cada parte puede ser una consulta que devuelve una o más series (cada serie agregada hasta un punto), y luego una función opcional de resta o porcentaje que se puede comparar con otra consulta? La expresión completa da como resultado un valor que luego se puede usar con los niveles de operador y crítico / advertencia para obtener el estado de alerta.

¿O la expresión debería contener el operador y los niveles?

Otras opciones irían al lenguaje de programación completo y harían:

expr: "
let last5mAvg = query(#A, 5m, now, avg)
let last24hAvg = query(#A, 1d, now, avg)

return percentDiff(last5minAvg, last24Avg)
"

@torkelo :

1. ¿Está diseñando esto como un componente independiente? En última instancia, está construyendo un procesador de señal similar a Kapacitor para Influxdb ** que, a su vez, emite una señal (0 = "ok", 1 = "advertir", 2 = "crit"). ¿Será posible enviar esta señal a otro lugar que no sea Grafana, por ejemplo, A) a Nagios, o B) canalizarla de regreso a la base de datos?
2. De manera similar, ¿tendrá grafana una opción para no usar su motor de señales anterior, sino recibir una señal 0/1/2 de una fuente de terceros como un complemento de Nagios, de los cuales muchos ya existen en la naturaleza?

** = concedido Kapicator usa procesamiento de flujo de series temporales mientras que tu es un motor basado en sondeos, pero aún emite una señal.

Gracias por solicitar comentarios.

Mi opinión es mantener las alertas de Grafana simples, y el mejor indicador de la simplicidad es la visualización. Si no puede visualizar la alerta como una línea en un gráfico TS existente, es demasiado complejo.

Deje la complejidad al gráfico TS. Si la alerta tiene mayores necesidades, cree otro conjunto de datos de TS en función de esas necesidades y coloque la alerta en un gráfico de esos datos.

Si solo tiene un principio rector, es requerir una visualización simple de la alerta.

El otro problema es "¿cuántas alertas debo configurar"? Este tema se ha discutido en este hilo, y soy de la opinión de que tan pronto como comience a poner múltiples alertas en una alerta (advertencia, error, advertencia alta, error bajo, etc.), comenzará a perder flexibilidad. Las advertencias y los errores son cosas diferentes: tienen diferentes niveles, diferentes personas se preocupan por ellos y tienen diferentes métodos de notificación.

Mantenga las alertas simples y permita que las personas coloquen múltiples alertas en un gráfico.

Creo que el # 3677 (Transformaciones genéricas en resultados de consultas de series temporales) sería muy útil aquí. Con esas funciones independientes de TSDB, puede crear un "gráfico de alerta" complejo en el que puede utilizar umbrales de valores fijos simples para advertencia, crítica, etc.

El modelo de regla de alerta simple sería todo lo que se necesita entonces. Entonces, la complejidad se "oculta" en la creación y combinación de los gráficos.

Estoy a favor de mantenerlo simple. No soy un desarrollador, soy más un desarrollador de operaciones ligeras y me gustaría poder entregar mi plataforma Grafana / Graphite a mi equipo de administradores para que la administre. Siendo este el caso, un generador de alertas similar al existente será mucho más fácil de usar. No se preocupe demasiado si introduce una gran cantidad de nuevas instrucciones, siempre que las reglas se puedan construir de la misma manera que las consultas para gráficos actualmente, será fácil de entender.

tl; dr, un lenguaje completamente nuevo puede ser excesivo y demasiado complejo. Construyendo reglas con mouse = bueno.

A falta de construir un lenguaje completamente nuevo, asumí que esto sería en gran medida una interfaz para las plataformas de alerta existentes como Kapacitor, Reimann y Bosun, similar a cómo Grafana proporciona una interfaz para redactar consultas de InfluxDB. por ejemplo, el trabajo pesado lo realiza un sistema de alerta de terceros y Grafana proporciona la interfaz de usuario. ¿Quizás ese no es el caso?

IIRC, Grafana quiere seguir el camino de "baterías incluidas, pero extraíbles". Es decir, debería funcionar de forma independiente con un motor de alerta incluido, pero también debería poder conectarse a las plataformas existentes.

Yo diría que debe venir con un par de métodos incorporados: correo electrónico (suministro de host SMTP) y WebAPI / Webhook. Luego, el resto puede venir con complementos, como la integración en PagerDuty.

@felixbarny, ¿ podría describir lo que quiere decir conectable a plataformas existentes? Por supuesto, las notificaciones de alerta se integrarán con muchas herramientas de alerta existentes. Pero para que otros sistemas manejen la programación y ejecución de reglas de alerta podría ser complicado, sería posible, simplemente lea las reglas de la API HTTP de Grafana. Pero requeriría mucho código para manejar la programación y ejecución de reglas. Pero, por supuesto, proporcionaremos una opción para definir solo las reglas en Grafana, y para que otro sistema lea constantemente las reglas y las ejecute.

@GriffReborn estás pensando en un nivel diferente. Los backends de alerta existentes que he mencionado _ ya_ admiten salidas como SMTP, PagerDuty, etc.
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

Estos productos _ ya_ realizan alertas complejas y dinámicas. Lo que no tienen es una interfaz visual agradable para configurar y administrar alertas, identificar visualmente qué alertas están activas, etc. Lo que me hubiera gustado tener es una interfaz de usuario de interfaz que básicamente empuja las configuraciones a, por ejemplo, sus alertas (compatibles con Grafana) sistema de elección que luego realmente hace todo el trabajo.

@ thom-nic estoy de acuerdo. El enfoque principal debe ser la creación de un panel de alertas que pueda utilizar feeds de información de alerta existentes ("independiente del feed"). Hacer un motor de procesamiento de señales ligero patrocinado por Grafana (idealmente como independiente) debería ser una preocupación secundaria.

@johnnyshields crear nuevos paneles que muestren información de los backends de alerta existentes es fácil para cualquiera que lo desee. Lo que estamos tratando de hacer es facilitar a los usuarios de Grafana la definición de reglas de alerta en sus consultas métricas que definen en los paneles de gráfico / estado único. Luego, tenga un motor de alertas en el backend de Grafana que programe, ejecute y evalúe esas reglas, actualice el estado de alerta, active notificaciones, etc.

También creo que el modelo simple debería ser suficiente y también resultará en tener la característica tan esperada tan pronto como sea posible. En absoluto, grafana es para métricas, las alertas básicas deberían ser suficientes.

@torkelo para ser honesto, no estoy muy familiarizado con plataformas de alerta como Bosun y no sé cómo se vería una integración adecuada específicamente. Me refería a las cosas que dijo @Dieterbe , por ejemplo en su presentación de Grafanacon: http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny bueno, eso es lo que planeamos hacer también. Tener API para que otros backends de alerta utilicen para leer las reglas definidas en Grafana. Pero no proporcionaremos el puente que lee las reglas de alerta de Grafana y las traduce a otro motor de ejecución de reglas.

Entonces, una idea que tenemos ahora es definir reglas simples como esta

Pero también ser capaz de tener umbrales dinámicos y comparar con otra consulta o la misma consulta pero con diferente rango de tiempo y agregación.

Otra consulta compleja de "previsión". Cuando se utiliza una consulta para obtener una línea de tendencia, pronostique eso en el tiempo y avise sobre eso.

Parece lo mejor de ambos mundos. ¡Amo esa idea! ¿Las funciones 'Evaluar contra' son parte de Grafana o son específicas de TSDB?

@felixbarny son parte del modelo de reglas de alerta de Grafana y serán procesados ​​por el motor de evaluación de reglas de alerta de Grafana.

¿Podrá adjuntar varias reglas a un solo gráfico? Me gusta la simplicidad de los niveles de advertencia / críticos en una regla, y algunos gráficos tienen umbrales altos y bajos que requerirían múltiples niveles en una alerta o múltiples alertas en un gráfico.

Y aunque me gusta la funcionalidad de las reglas complejas, todo esto se puede lograr construyendo un gráfico diferente y alertando sobre ese gráfico con una regla simple. El beneficio de mantener la complejidad fuera del sistema de alerta es que el historial de circunstancias que causaron que la regla se active se mantiene en la TSDB.

Esto le permite visualizar una alerta como una simple línea horizontal en un gráfico y ver cómo esa regla se habría disparado (o se activó) con el tiempo.

Sigue alertando de manera simple para la persona promedio, lo suficientemente compleja para todos y accesible para aquellos que entienden las cosas visualmente.

@lorenwest sí, mantendremos las cosas simples y solo permitiremos una regla de alerta por panel. Pero una regla puede usar una consulta que devuelve muchas series, lo que básicamente dividirá la regla en múltiples (por lo que puede tener una sola regla que verifique cada servidor, si la consulta devuelve una serie por servidor).

Y aunque me gusta la funcionalidad de las reglas complejas, todo esto se puede lograr construyendo un gráfico diferente y alertando sobre ese gráfico con una regla simple.

No estoy seguro de a qué te refieres aquí. Otro gráfico no resuelve en absoluto el escenario en el que desea alertar sobre una consulta en comparación con él mismo en un rango de tiempo diferente, en comparación con otra consulta por completo (tal vez la otra consulta sea otra fuente de datos que obtenga umbrales dinámicos de una base de datos). Ese escenario no se puede resolver en la TSDB o simplemente dividiendo la regla en dos reglas en dos paneles separados.

Pero nuestro objetivo principal es resolver el caso simple y hacerlo fácil e intuitivo, pero también queremos, al menos más adelante, admitir algunas reglas de alerta más complejas que realmente aprovechen el hecho de que está tratando con datos TSDB y también el hecho de que diferentes consultas pueden apuntar a diferentes fuentes de datos

Creo que el punto que @lorenwest estaba haciendo es que,

Con un modelo de alerta más complejo, ya no hay un indicador visible de dónde los umbrales darían lugar a una alerta.

Siguiendo el modelo simple, podría lograr muchos de los complejos requisitos de monitoreo siempre que la fuente de datos proporcione la capacidad. Para el "cambio porcentual en comparación con", puede crear una consulta de grafito (gráfico diferente) que compare el día actual con el anterior, y luego establecer umbrales simples en eso. Ciertamente es un proceso mucho más complicado crear alertas, pero funciona.

Me alegro de que estemos en la misma página @torkelo. Esto encaja con la descripción en la publicación original.

No me apetece crear una plataforma de alertas completamente nueva para vincularla a Grafana. Lo que espero de las alertas de Grafana es algo que reemplace a NewRelic, pero con el increíble poder que trae Grafana. Ser capaz de activar una alerta (ya sea por correo electrónico, API o lo que sea) cuando uno de mis gráficos alcanza un umbral ... eso es ORO. Cosas que cambian la vida.

Incluso las alertas de umbral simples serían una buena solución simple.

Si sigues esta única regla, serás dorado:

Nunca permita una alerta que no se pueda visualizar superponiéndola en un panel.

Si no puede visualizarlo, es demasiado complejo. Construya un gráfico que incorpore esta complejidad y alerta sobre ese gráfico. Esto nos obliga a crear visualizaciones que incorporen esa complejidad (algo bueno) al tiempo que facilita que el creador de alertas (y el consumidor) vea en qué se están metiendo.

@woodsaj Estoy de acuerdo en que queremos fomentar el vínculo entre lo que alerta y lo que ve, eso no es algo que nunca hayamos discutido sobre abandonar. Lo que estamos tratando de generar es hasta dónde llegan los umbrales estáticos de consulta única, ¿son lo suficientemente buenos para la v2 de Grafana Alerting o la v3? Y para iniciar una discusión sobre las limitaciones en el tipo de reglas de alerta que son posibles con una consulta única y umbrales estáticos.

Actualmente, las TSDB son muy inflexibles en cuanto al tipo de consultas anidadas que puede realizar (por ejemplo, compare una serie con sí misma). Graphite es el único que admite consultas anidadas. Pero incluso Graphite no puede comparar dos consultas que tienen como objetivo diferentes ventanas de tiempo (el cambio de tiempo solo cambia la misma ventana, pero no una ventana de tiempo de diferente tamaño). Pero cuanto más pienso en esto, más estoy de acuerdo en que la mayor parte de esto se puede resolver en la consulta TSDB dado que es lo suficientemente potente.

La razón principal para plantear esta discusión es hacer una lluvia de ideas sobre cómo modelar la regla, cuáles son los componentes que componen una regla, qué abstracciones contiene (consulta, ventana de tiempo, agregación, niveles, etc.). ¿Cómo podemos admitir umbrales dinámicos en v2 o más consultas de alertas ricas en funciones que pronostican tendencias en el futuro? ¿Cómo debería cambiar el motor de evaluación de modelos y reglas?

En lo que respecta a "Si las alertas se asignan a los paneles", creo que puede ser una opción útil, pero sería una mala restricción de diseño, incluso para v1.

Creo que uno de los aspectos más complicados de las alertas es el alcance, y una vez que empiezas a hablar de visualización, el problema se hace evidente.

Pienso en el alcance como el área de superficie / profundidad de un sistema que cubre una alerta como el alcance. Entonces, por ejemplo, sus alertas pueden tener un alcance:

• Servicios (métricas de la aplicación)
• Clústeres completos que componen un servicio
• Nodos individuales en un clúster
• Hosts / procesos en un clúster
• Subsistema de procesos / aplicaciones (métricas de middleware)
• Subsistemas de hosts (es decir, disco, CPU) (métricas del sistema)

No creo que haya una única respuesta "correcta" sobre la capa sobre la que uno debería alertar. A veces depende de los equipos, la importancia del servicio, la infraestructura general (es decir, nube frente a hardware, clúster frente a monolito), etc. Entonces, dados los ámbitos en capas, una jerarquía de alerta parece una buena opción. Pero no creo que la definición de esas jerarquías sea generalmente mantenible. Es mucho trabajo, cambios y, a menudo, hay relaciones que no crean árboles bonitos en los sistemas del mundo real. Agresión de libros SRE de Google:

"" "
Google SRE ha tenido un éxito limitado con jerarquías de dependencia complejas. Rara vez usamos reglas como, "Si sé que la base de datos es lenta, avise de una base de datos lenta; de lo contrario, avise de que el sitio web es lento en general". Las reglas que dependen de la dependencia generalmente pertenecen a partes muy estables de nuestro sistema, como nuestro sistema para drenar el tráfico de usuarios de un centro de datos. Por ejemplo, "Si un centro de datos está agotado, no me avise sobre su latencia" es una regla común de alerta del centro de datos. Pocos equipos de Google mantienen jerarquías de dependencia complejas porque nuestra infraestructura tiene una tasa constante de refactorización continua.
"" "

También está relacionado con el alcance el tipo de alerta (es decir, enviar un correo electrónico en lugar de registrarlo / mostrarlo en el tablero para que alguien se ocupe de él cuando esté haciendo sus rondas matutinas)

Entonces, para Grafana, mis alertas podrían asignarse a:

• Un panel
• Un grupo de paneles
• Un tablero
• Un grupo de paneles (que imagino que tendría desgloses)

A veces querré que esas alertas envíen una notificación, otras veces querré que sean solo un indicador visual en algún lugar de Grafana en uno de los ámbitos (es decir, umbral cruzado o cambios de estado como marcadores de anotación). Será diferente para diferentes empresas e incluso para diferentes grupos / servicios dentro de una empresa.

@kylebrandt toda la idea de las alertas en Grafana es vincularlas a paneles y visualizaciones. Donde puede tener gráficos y paneles que visualizan métricas con diferente alcance (como Servicios, clústeres, hosts individuales) y al tener eso puede alertar en cualquier nivel o alcance.

No ver cómo vincular una alerta a un panel y algo que se puede visualizar dejará de definir alertas en diferentes niveles. Y, por supuesto, especificarás por alerta qué notificaciones deben usarse.

@torkelo La decisión de alertar siempre se reducirá a un bool (verdadero / falso). Puede haber diferentes niveles (warn, crit, etc ...) o incluso lógica difusa pero al final es una decisión booleana. Graficar ese bool por sí solo en un solo panel no siempre será útil.

Entonces, $metric > $threshold es la alerta más básica, y devuelve verdadero si la métrica excede el umbral, por supuesto. Eso encaja muy bien en un panel (visualice la métrica y visualice el umbral dentro de un panel). Pero, para eliminar el ruido de alerta, el alcance y las condiciones tienden a crecer más allá de eso en la mayoría de los casos (cuando comenzamos a trabajar en Bosun, pensé que estos casos serían la minoría, no tanto, resulta que si quieres controlar el ruido). Entonces podrías decir algo como:

Alerta si:

• La CPU está por encima del 80% durante X minutos
• El trabajo A no se está ejecutando (sabemos que aumenta la CPU y no nos importa) y el trabajo A no se ha ejecutado durante más de una hora
• Dieter ha tomado más de 3 tazas de Starbucks en las últimas 24 horas (porque cuando tiene más hace tonterías que aumentan la CPU y no queremos alertar sobre eso)

Entonces, visualizar solo la alerta es (Verdadero / Falso) cuando hay múltiples condiciones no es tan útil. Necesitamos visualizar cada condición (y luego tal vez incluso más para la información de apoyo).

Convertir todas esas condiciones en una nueva métrica realmente no ayuda con la visualización en el momento porque sería Verdadero / Falso y lo que realmente necesita ver es toda la información subyacente. Entonces, lo que tenemos en lugar de visualizar métrica + umbral es visualizar métrica (s) + umbral (s) que podrían estar en diferentes escalas.

Entonces, en este caso, sí, la alerta _can_ se asigna a un solo panel, pero dependiendo de la visualización y la alerta, hay muchos casos en los que eso no es realmente lo que uno querría. Me gustaría un panel para cada uno de los elementos booleanos que componen la alerta, para ver cuál de ellos se disparó, pero para evitar la fatiga de la alerta, solo quiero una notificación para la combinación de todas las condiciones.

Parece que algún tipo de unión alerta con lógica booleana simple podría facilitar esto.

alert1:
  select: CPU is above 80% for X minutes
  output: null
alert2:
  select: Job A is not running
  output: null
alert3:
  select: Job A has being running for more than an hour
  output: send alert
alert4:
  select: Dieter has had more than 3 cups of starbucks in the last 24 hours
  output: null

(alert joiner does simple true/false logic and perhaps can graph it.)
alert5:
  database: alerts
  select: alert1 & alert2 &!alert4
  output: send alert

@torkelo Saco la rama
Además, encontré "alerting: enabled = false" dentro de la "Configuración del servidor" de "Administración del servidor". ¿Eso afecta la función de alerta? ¿Hay alguna marca de compilación o tiempo de ejecución que deba usar?
por favor aconséjame.

Probé con el último código (ebada26b85d8410142c2942ef7ba78b17e88313c), habilité las alertas y obtuve la interfaz de usuario.

Pero tengo toneladas de errores

EROR[06-17|14:38:23] Failed to extract alerts from dashboard  logger=alerting.extractor error="missing query.query"
EROR[06-17|14:38:23] Failed to save alerts                    logger=context userId=1 orgId=1 uname=admin error="Failed to extract alerts from dashboard"

Probé con fuentes de datos InfluxDB, en modo directo y proyy.

¿Es algo esperado?

Sí, aún no está listo para probar.

Bien, es bueno saberlo.

Seguiré las actualizaciones de vez en cuando.
¿Puede ser mejor esperar que esta rama se fusione en el maestro para que esté lista para usar?

sí, esperamos fusionarlo para dominar tal vez a mediados de julio allí sobre

¿Tiene una actualización de progreso sobre esto?
¿Todavía vas a llegar a mediados de julio?
¡Tener esta función en producción lo antes posible sería de gran ayuda!

¡Incluso una versión ligera con alertas de solo correo electrónico similares sería genial!
Una actualización de su progreso sería genial (necesito elegir entre implementar un sistema de alerta personalizado o confiar en Grafana, ¡y definitivamente prefiero la segunda opción!).
Gracias chicos

Ha llegado el invierno, también lo harán las alertas :)

El martes 12 de julio de 2016 a las 1:41 a. M., C-val [email protected] escribió:

¡Incluso una versión ligera con alertas de solo correo electrónico similares sería genial!
Una actualización de tu progreso sería genial (necesito elegir entre
implementando un sistema de alerta personalizado o confiando en Grafana, y definitivamente
¡Prefiera la segunda opción!).
Gracias chicos

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390,
o silenciar el hilo
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

Deepak

Consideraría esto como un "requisito comercial" y recomendaría que se evalúe a nivel de "arquitectura empresarial". Al aplicar _algunas_ prácticas y patrones utilizados para la Arquitectura de Software Empresarial, podrá comunicar sus ideas a través de un modelo ágil que a su vez promueve una mayor calidad de comprensión tanto para las partes interesadas como para el equipo de desarrollo.

Antes de que podamos comenzar a hablar sobre tecnología y arquitectura, debemos acordar al menos lo siguiente:

1. Pensamos en nuestras características en términos de "Gestión de procesos de negocio (BPM)"; y
2. Usamos el "Business Process Modeling Language (BPML)" para que podamos comenzar a modelar los requisitos e implementaciones en el mismo lugar con UML.
3. Definimos nuestra arquitectura con una disciplina de nivel empresarial.

¡Ahora la parte divertida! Teniendo una amplia experiencia con el monitoreo a escala global, recomiendo que tomemos en consideración lo siguiente:

• Deja a grafana en paz, ¡es la capa de presentación ! Si desea agregar un flujo de trabajo para modelar y definir reglas para generar alertas, está bien, pero déjelo así. Después de todo, es por eso que los paneles y complementos se implementaron, ¿verdad?
• Deja los datos donde estaban destinados. Las métricas que se llaman a casa deben tratarse como ciudadanos de primera clase y almacenar sus valores de manera persistente es la máxima prioridad. Ya sea en un caché, documentdb, tsdb o un servidor SQL, no importa. La tolerancia a fallas está implícita ... con las "selecciones de tecnología" correctas que se realizan para la arquitectura, por supuesto).
• Para configurarnos para la disponibilidad + escalabilidad, necesitamos usar los marcos correctos que fueron diseñados específicamente para esto: cumplir con la Arquitectura Orientada a Servicios ("SOA"). En un nivel muy alto, podemos usar el protocolo de cola de mensajes para transmitir y recibir eventos y mensajes a través del protocolo "AMQP". Olvídese de REST y HTTP ... por ahora. Al utilizar un servidor de cola de mensajes como RabbitMQ o ZeroMQ , tenemos una canalización de comunicación distribuida, tolerante a fallas y de alta disponibilidad que tanto los publicadores / remitentes de datos como los trabajadores / receptores para procesarlos pueden usar. Este es el "bus de servicios empresariales". (Consulte esta presentación de diapositivas que explica ZeroMQ).
• Utilice un lenguaje de consulta creado específicamente para modelos de datos compuestos dispares, no vinculados. Mediante el uso de una "Base de datos de gráficos" y la interfaz de consulta " SparQL ":

SPARQL permite a los usuarios escribir consultas contra lo que puede llamarse libremente datos de "valor-clave" o, más específicamente, datos que siguen la especificación RDF del W3C. Toda la base de datos es, por tanto, un conjunto de triples "sujeto-predicado-objeto". Esto es análogo al uso que hacen algunas bases de datos NoSQL del término "valor-clave del documento", como MongoDB.
[..]
Por lo tanto, SPARQL proporciona un conjunto completo de operaciones de consulta analítica como JOIN, SORT, AGGREGATE para datos cuyo esquema es intrínsecamente parte de los datos en lugar de requerir una definición de esquema separada. Sin embargo, la información del esquema (la ontología) a menudo se proporciona externamente para permitir que diferentes conjuntos de datos se unan de manera inequívoca. Además, SPARQL proporciona una sintaxis de recorrido de gráficos específica para datos que se pueden considerar como un gráfico y la fig.
..
https://en.wikipedia.org/wiki/SPARQL

Recuerde, lo que Grafana nos ha dado y que Nagios nunca hizo se reduce a un solo punto de falla: falta de escalabilidad. Grafana es "rápido" como usted dice, pero no está tomando en cuenta el hecho de que solo está almacenando y procesando datos de series de tiempo, ¡ no la (s) capa (s) de metadatos también ! Necesitamos la semántica de SparQL y el poder de Elasticache + motor (es) de base de datos gráfica.

Puede parecer complejo ... lo cual puede volverse mucho más complejo que estas dos páginas, pero te salvé de años de fuerza bruta, prueba y error y eliminé el ruido (es decir, hay 30 patrones de diseño para arquitectura empresarial, 12 para uml, etc., solo necesitamos hablar de 3 para poder eliminar esto, por ahora)

Esto debería hacer girar los engranajes. Necesito dormir un poco (pasé toda la noche) y trabajaré en la Parte 2. No dudes en enviarme un ping a @appsoa en skype o yomateo en IRC.

Algunas golosinas mientras tanto:

• Un ejemplo de arquitectura de referencia que creé usando SOA .
• Microsoft Azure Service Fabric: cree y opere aplicaciones distribuidas, escalables y siempre activas.

@talbaror Idealmente, capturaría los mensajes de registro del NAC usando un agente como con un firewall PIX y simplemente los enviaría / reproduciría a través de rsyslogd o cualquier protocolo que use el servidor de procesamiento de eventos.

Si no tiene una configuración de servicio de procesamiento de eventos, puede utilizar el procesamiento de reglas de Snort - Detector de intrusiones en la red . Hazme ping si necesitas ayuda ... Pasé 4 años en una empresa de seguridad como servicio;)

¿Puedes integrar la detección de anomalías como banshee ?
Con marcadores visuales y alertas.

@torkelo, por favor, dénos una marca de mercado en la línea de tiempo para enviar esto.

@johnnyshields Estoy trabajando en esto ahora todos los días. Es algo complicado y realmente quiero tener los fundamentos correctos para que el sistema de alerta pueda evolucionar y volverse más rico en el futuro. El modelo actual con el que estoy trabajando se ve muy bien, publicará una actualización la próxima semana sobre el nuevo modelo de reglas de alerta basado en condiciones.

Espero fusionarlo para dominarlo y tenerlo disponible (detrás de alternancia de funciones) dentro de 2 semanas si las cosas van bien. Aún no tenemos una fecha fija para la próxima versión de Grafana, ya sea una versión 3.2 en septiembre o una versión 4.0 más grande a finales de octubre.

@torkelo Espero que recibamos la alerta lo antes posible. Esperándolo.
Usando grafana para kubernetes.

Para otras personas que ya tienen statsd / graphite / grafana en su lugar y están esperando que el sistema de alertas Grafana esté listo para hacer las primeras alertas, encontré una excelente alternativa para usar mientras tanto, Seyren: https://github.com / scobal / seyren

Se integra fácilmente con PagerDuty y puede simplemente copiar los objetivos de los gráficos que ya tiene en sus paneles de grafana para alertar y especificar los umbrales de advertencia y error.

Parece que el equipo ha progresado mucho en la función de alerta. Creo en la filosofía de "hacer una sola cosa pero hacerlo bien". No estoy muy seguro de si poner toda la lógica de alerta dentro de Grafana es la mejor idea. De todos modos, acabo de escribir un pequeño demonio js de nodo "flapjack-grafana-receptor" para publicar eventos grafana en flapjack. Probablemente lo abriré. ¿Alguien interesado?

https://github.com/Charles546/flapjack-grafana-receiver

¡Progreso de la actualización!

Al menos una persona ha estado trabajando a tiempo completo en alertas desde abril, el progreso no ha sido tan rápido como nos hubiera gustado debido a muchas reescrituras. A pesar de que nuestro objetivo es contar con funciones de alerta básicas para la versión inicial, creemos que es importante obtener el modelo de reglas de alerta fundamental correctamente para poder expandir la definición de la regla de alerta y el motor de evaluación de la regla de alerta en versiones futuras sin una revisión importante.

El objetivo de comenzar con alertas muy simples nos ha llevado a algunos callejones sin salida que no se sentían bien y ha requerido algunas grandes reescrituras. Pero ahora estamos nuevamente en el camino correcto y estamos haciendo un buen progreso en un modelo de reglas basado en condiciones con el que estamos mucho más contentos.

Definición de regla

El nuevo modelo de reglas de alerta se compone de una o más condiciones. Las condiciones pueden ser de diferentes tipos. En este momento solo hay un tipo de consulta. Pero luego podemos agregar Condiciones como Time of day , o Day of week , o más interesante Other alert (para que pueda incluir el estado de otra regla de alerta como condición).

La condición de consulta se compone de una consulta y un rango de tiempo, un reductor que tomará todos los puntos de datos devueltos para cada serie que devolvió la consulta y los reducirá a un solo valor para ser utilizado en la comparación de umbral. El reductor también podría ser en el futuro un "pronóstico" que hace una regresión lineal sobre los datos y pronostica un valor futuro.

La parte de evaluación de la condición de consulta puede ser mayor que, menor que, entre, etc. Podrá arrastrar controladores en el gráfico para establecer umbrales.

El modelo basado en condiciones proporciona muchas posibilidades interesantes para hacer que las reglas de alerta sean más poderosas en el futuro sin una revisión total del motor, además, la condición de consulta tiene estos componentes conectables que permitirán la extensión (reductor con parámetros y evaluador con parámetros).

Notificaciones

¡Esta semana pasada hemos estado trabajando en notificaciones y las cosas están empezando a encajar!

Tenemos tipos de notificación por correo electrónico, webhook y holgura. La notificación de holgura se ve bastante bien :)

¿Quiero ayudar?

Ya puede probar y enviar comentarios, el código se encuentra en la rama de alerta y también debe habilitarlo en el archivo de configuración con.

[alerting]
enabled = true

Fusionar para dominar

Estamos muy cerca de fusionar esto para dominar y continuar el trabajo allí. Tenía la esperanza de hacer esto antes de mis vacaciones de verano (acaba de pasar 1 semana) pero todavía hay algunos cambios menores en el esquema SQL que me gustaría hacer antes de fusionarme con el maestro. La fusión para dominar sucederá el 19 de agosto, lo prometo :) Después de eso, las alertas estarán en la última versión 4.0 nocturna, por lo que será fácil para usted probar e informar errores y comentarios.

¿Lo que queda?

Hay una serie de características que faltan y que queremos para una versión beta.

• Más reductores y capacidad para cambiar el reductor (solo promedio ahora)
• La notificación por correo electrónico parece una mierda
• Bloquear esquema para webhook
• Diseño para página de lista de alertas
• Ver historial de alertas
• Ver el historial de alertas como anotaciones en el gráfico
• Programador de alertas y estabilidad del motor
• Mejoras en el programador de alertas para distribuir la carga (para que las alertas no se ejecuten al mismo tiempo)
• Agrupación del programador de alertas

Lamento mucho que esta función esté tardando tanto.

@torkelo , tenga la capacidad de poner las máquinas en modo de mantenimiento durante un período determinado en la versión beta.

@torkelo Gracias por la actualización. Por lo que puedo ver, esto está orientado a tener alertas dentro de Grafana. ¿Sigues siguiendo el curso modular establecido en https://github.com/grafana/grafana/issues/2209#issuecomment -149351263?

También gracias a quienes sean los elfos ocultos que trabajan en esto. Sospecho de @Dieterbe , pero no lo sé.

@RichiH no estamos seguros de cómo funcionará, hemos intentado averiguar cómo hacer un sistema como en ese comentario, pero no estamos seguros de cómo funcionará. Ahora estamos enfocados en una fuerte experiencia de alerta inmediata que puede mejorar con el tiempo. Los usuarios con un controlador de alertas existente podrían potencialmente deshabilitar el ejecutor de alertas en Grafana y hacer que Grafana envíe la alerta que debe evaluarse a otro sistema. Sin embargo, requeriría mucho trabajo en sistemas de terceros para implementar esa integración.

@torkelo Mis pensamientos estaban en la misma línea, por eso decidí preguntar.

Personalmente, me preocupan las alertas de Prometheus, pero agradecería una buena integración visual con Grafana. No me importa demasiado dónde defino las reglas siempre que Prometheus las almacene y ejecute.

@bergquist Como estará en la fiesta de graduación, sentarse y hablar sobre posibles enfoques puede tener sentido. Si quieres, preguntaré a los desarrolladores de Prometheus cuál sería la mejor hora. Puede que haya o no un momento de tranquilidad para sentarse la noche anterior y / o después de la limpieza; Puedo avisarle si quiere.

Hola @torkelo , esto se ve genial.

Acabo de retirar su rama y cuando pruebo una alarma para ElasticSearch, aparece el error

firing false
timeMs 0.225ms
error tsdb.HandleRequest() error Could not find executor for data source type elasticsearch

... ¿Significa esto que ElasticSearch no es compatible todavía?

ps en la salida del proceso obtengo esto:

EROR[08-04|09:15:00] Alert Rule Result Error                  logger=alerting.engine ruleId=1 error="tsdb.HandleRequest() error Could not find executor for data source type elasticsearch" retry=nil LOG15_ERROR="Normalized odd number of arguments by adding nil"

@ Workshop2 solo admitimos grafito para las alertas hasta ahora, pero eventualmente admitiremos Elasticsearch :) Agregaré un mensaje de error mejor para esto.

¿Cómo se comportará el sistema de alerta si la consulta no devuelve datos? ¿Activará una alerta de forma predeterminada?
Además, un simple reductor count sería genial que simplemente devuelva el número de puntos de datos devueltos por una consulta.

@bergquist Pensé que las alertas serán transparentes con respecto a la fuente de datos utilizada. ¿Cuánto tiempo antes de que podamos comenzar a obtener una vista previa / probar la función de alerta en otra fuente de datos que no sea de grafito? (Me doy cuenta de 'cuánto tiempo ...' preguntas que a nadie le gustan, lo siento)

@RichiH Una opción es crear una aplicación grafana como lo hace Bosun. https://grafana.net/plugins/bosun-app Pero eso no permite la reutilización de consultas / tableros de una manera simple. Hablemos más sobre esto en promcon. ¡Esperamos conocerte! :)

¿No hay soporte de influxdb inicialmente también?

No sabía su límite específico al grafito :( También estamos usando afluencia y
elasticsearch;)

El lunes 8 de agosto de 2016 a las 2:18 p.m., elvarb [email protected] escribió:

¿No hay soporte de influxdb inicialmente también?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

Enrico Kern

Ingeniero jefe de sistemas

glispa GmbH
Sonnenburger Straße 73
10437 Berlín, Alemania

tel: +49 30 5557130-17
fax: +49 30 5557130-50
skype: flyersaenrico. [email protected]

---

Sitz Berlin, AG Charlottenburg HRB 114678B

Solo al principio, es probable que agreguemos Prometheus antes del lanzamiento. Tal vez InfluxDB o Elasticsearch también, dado que la programación y ejecución de la alerta se lleva a cabo en el backend, el código de solicitud y respuesta se ha escrito desde cero (en Go), el código del complemento de fuente de datos del frontend (escrito en js) no se puede reutilizar.

Estamos usando influx, creo que podemos renunciar a la integración de Grafana y usar Kapacitor con una interfaz web simple para crear y administrar alertas.

+1 Alerta + InfluxDB.

El lunes 8 de agosto de 2016 a las 6:01 a. M., Thom Nichols [email protected]
escribió:

Estamos usando influx, creo que podemos renunciar a la integración y el uso de grafana.
Kapacitor con un front-end web simple para crear y administrar alertas.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

Deepak

Es lamentable que el trabajo que realizamos en la creación de complementos de fuentes de datos solo sea útil para el cliente.

Teniendo en cuenta el trabajo inmediato y a largo plazo que respalda las alertas para diferentes fuentes de datos, la creación de una arquitectura de complementos go, etc., ¿no sería casi la misma cantidad de trabajo (si no menos) construir el servidor de alertas en NodeJS, por lo que podría usar los existentes? complementos de fuente de datos?

Dejando a un lado las opiniones sobre go vs nodejs, esto podría reducir significativamente la duplicación de código para alertar sobre diferentes fuentes de datos.

Y si realmente no te gusta el nodo, apuesto a que hay un mecanismo de llamada para cargar y ejecutar JS.

Alerta +1 para ElasticSearch

Hola, hemos estado esperando el sistema de alerta para ... ¡OpenTSDB! Podemos
Espero conseguirlo pronto para OpenTSDB? (¿Quizás cuando?)

¡Muchas gracias al equipo!

2016-08-08 17:28 GMT + 02: 00 Slava Vishnyakov [email protected] :

Alerta +1 para ElasticSearch

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

Alerta +1 para ElasticSearch
¿Tendría la posibilidad de ejecutar un script en caso de alerta?

¿Tienen la rama de alerta en una imagen de Docker todavía?

1. ¿Las consultas de alerta solo funcionan para la consulta "A"? ¿Está codificado de forma rígida?
2. ¿Cuándo podemos esperar una versión de alerta completamente funcional? (19o sigue siendo el objetivo)
3. ¿Cuándo podemos esperar que Elasticsearch funcione con las alertas?

Editar:

1. ¿Puedo agregar más de una regla de alarma por gráfico?
2. ¿Puedo agregar información sobre la alarma al mensaje HTTP? (tablero / gráfico / consulta_observada / configuración_de_alarma / consulta_de_alarma / umbral / advertir_o_crítico / valor / marco de tiempo_observado / tiempo_de_ocurence)

@ DEvil0000

1) Puede cambiar a cualquier consulta que tenga en la pestaña de métricas.
2) Totalmente funcional, depende de lo que quieras decir. Planeamos fusionarlo para dominar esta semana. Luego, la gente puede comenzar a probar la compilación nocturna y dar su opinión. La versión alfa en 2-3 semanas, la versión beta y estable depende de los comentarios y de la rapidez con la que puede volverse estable
3) Elasticsearch es complicado, requiere una gran cantidad de código para consultar y analizar la respuesta en series de tiempo, por lo que probablemente vendrá después de que se agregue el soporte para Prometheus e InfluxDB

@torkelo
Soy nuevo en elasticsearch, grafana y go lang. Y creo que ya buscaste clientes, pero ¿los has visto?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
Esas bibliotecas pueden reducir el esfuerzo.

También gracias a quienes sean los elfos ocultos que trabajan en esto. Sospecho de @Dieterbe , pero no lo sé.

Las alertas ahora son principalmente @torkelo y @bergquist (y @mattttt ). He cambiado el enfoque a nuestro próximo backend de grafito, https://github.com/raintank/metrictank

Estoy muy contento de ver que esta característica avanza. Me encantaría tener soporte para OpenTSDB ya que otras soluciones de alerta (Bosun) no serían lo suficientemente fáciles de usar para su uso regular aquí.

Espero ver la alarma en la próxima versión oficial y rendir homenaje a los programadores que han trabajado duro para codificar.

Espero ver la alarma en la próxima versión oficial y rendir homenaje a los programadores que han trabajado duro para codificar.

@superbool lo siento, no puedo leer esto y la traducción de Google no fue muy útil

La fusión para dominar sucederá el 19 de agosto, lo prometo :)

@torkelo jeje la próxima vez apuesto. ¿Hay nueva fecha?

¿Podemos esperar que se programen las alertas para OpenTSDB?
(modesta) fundación para alentar a los desarrolladores.

2016-08-22 10:05 GMT + 02: 00 A. Binzxxxxxx [email protected] :

Espero ver la alarma en la próxima versión oficial y rendir homenaje a los programadores que han trabajado duro para codificar.

@superbool https://github.com/superbool lo siento, no puedo leer esto y
la traducción de google no fue muy útil

La fusión para dominar sucederá el 19 de agosto, lo prometo :)

@torkelo https://github.com/torkelo jeje la próxima vez apuesto. ¿Hay un
nueva fecha?

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -241340597,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@ DEvil0000 Espero ver que la función de alerta se pueda publicar en la próxima versión estable de Grafana, y deseo rendir un gran homenaje a todos los que desarrollan la herramienta.
Lo siento, mi inglés no es muy bueno, espero que puedas entender mis palabras

@ DEvil0000 El plan era fusionar el viernes pasado, pero debido a algunos eventos no planificados (https://twitter.com/torkelo/status/766514688997732352) tuvimos que posponerlo un poco :) Todavía tenemos algunas cosas menores por hacer.

@torkelo ¡Felicitaciones!
@bergquist @torkelo Necesito una alerta con elástico antes de octubre (alfa estaría bien para mí). ¿Puedo ayudarlos a implementarlo? Solo necesitas proporcionarme algo de información para tener un punto de partida;)

La rama de alerta ahora se ha fusionado con la maestra. : manos_alzadas:

Agradecemos todos los comentarios que hemos recibido sobre este problema. ¡Gracias a todos !
Para futuras discusiones y comentarios, publique el problema de alerta correspondiente o cree uno nuevo. Esto nos ayuda a organizar y priorizar nuestro trabajo futuro. Estoy cerrando este boleto a favor de los nuevos. Pero siéntase libre de continuar con la discusión en este número.

¿Qué es lo siguiente?

• Versión alfa (documentos y entrada de blog)
• Recopile comentarios de la comunidad.
• Siga trabajando en los problemas restantes
• Lanza Grafana 4.0 con alertas.

¿Pruébalo?

• Tienes que habilitar las alertas en la configuración .
• Ahora puede encontrar alertas en el menú lateral.
• Puede agregar una alerta yendo a un panel de gráficos y seleccionando la pestaña de alerta.
• Utilice el botón _Test alert_ para verificar su alerta.
• Para guardar la alerta solo tiene que guardar el tablero.
• Configure la notificación de activación / alerta / notificaciones para recibir notificaciones sobre alertas de activación.
• Agregue el notificador a una alerta en la pestaña de alerta.

Limitaciones actuales

• Hasta ahora solo admitimos grafito.
• Para esta versión, solo el panel gráfico tiene soporte para alertas.

Paneles de control de ejemplo

Puede encontrar cuadros de mando de ejemplo en la carpeta de ejemplos.
Los cuadros de mando de ejemplo se basan en los datos de nuestro escritor de datos de grafito falso. Puede iniciar Graphite y el escritor de datos falsos desde nuestros archivos docker-compose.

cd docker/
./create_docker_compose.sh graphite
docker-compose up

Esto solo debe considerarse una guía aproximada y agregaremos más documentación sobre alertas en las próximas semanas.

¡Feliz alerta! : cóctel:: tada:

@bergquist Felicitaciones.

¿Hay algún problema que podamos seguir sobre el futuro de esta función?

@ Workshop2 https://github.com/grafana/grafana/issues/5858

Solo hay un "Y" y no un "O" en las Condiciones de alerta para agregar "está arriba" O "está debajo" en un Panel o hay otra forma de respaldar esto?

Creo que hay una opción "está fuera del rango" / "está dentro del rango". Pero también me gustaría ver una "o".

¡Hola a todos! Muchas gracias por su contribución en esta útil funcionalidad.

Es realmente interesante para mí, pero en muchos casos necesitaría un "OR" en las Condiciones de alerta porque no hay posibilidad de crear más de una alerta en un gráfico.

Creo que sin ese "O" no podré crear alertas para este tipo de gráficos:

¿Alguna idea? ¿Está planeando agregar una opción "OR"?

BR

@jmgonzalezp sí, esperamos apoyar a OR también (no estoy seguro de mezclar AND y OR todavía)

Tenemos 2 decisiones de diseño restantes para alertar de que nos encantaría recibir comentarios sobre (categorización y gravedad / estado).

Aquí está el problema con nuestros pensamientos actuales y realmente apreciaríamos sus comentarios.
https://github.com/grafana/grafana/issues/6007

¡Hola a todos! ¡Gracias por esta gran característica de grafana!

Tengo una pregunta sobre este sistema de alerta. Actualmente, estamos usando el grupo de escalado automático en AWS para implementar grafana, ¿sería un problema si ejecuto grafana en varias máquinas? El problema al que me refiero es, ¿habría varias alertas iguales de varias máquinas grafana? ¿O grafana ya se ha encargado de eso?

@torkelo Tengo la misma pregunta que @akurniawan. Consideremos esta configuración: 1 balanceador de carga, 3 instancias de Grafana detrás del balanceador de carga, 1 base de datos Mysql que comparten las 3 instancias. ¿Cómo manejarán los servidores Grafana las alertas en este tipo de configuración? ¿Deberíamos habilitar las alertas solo en 1 instancia o Grafana realiza un seguimiento de las alertas para que varios nodos no verifiquen y envíen las mismas alertas?

@utkarshcmu @akurniawan Las alertas dentro de grafana aún no son compatibles con HA. Nuestro plan es agregar soporte a las alertas de partición entre servidores en el futuro.

@bergquist Gracias por la respuesta. :)

@bergquist ¿ Alguna ETA sobre cuándo se agregará el soporte de InfluxDB para esto?

@thisisjaid a juzgar por esto https://github.com/grafana/grafana/milestone/40 debería estar aquí el día 10.

@Dieterbe ¿ Alguna ETA para alertar al soporte para OpenTSDB?

@sofixa Gracias, debería haber mirado la hoja de ruta yo mismo, caso de no RTFMing. No obstante, apreciado.

@Dieterbe ¿ Alguna ETA para alertar al soporte para OpenTSDB?

Ya no trabajo en alertar. tal vez @torkelo o @bergquist puedan responder.

@torkelo @bergquist

Cualquier ETA para alertar al soporte para OpenTSDB

@LoaderMick @ naveen-tirupattur La alerta de OpenTSDB se agregó a Grafana, debería ser parte de la próxima versión. Además, la alerta para OpenTSDB está funcionando en las compilaciones nocturnas.

¿Alguna ETA para alertar al soporte para influxDB y prometheus también?

La alerta de

Parece que no puedo hacer que la alerta funcione con OpenTSDB con (Grafana v4.0.0-pre1 (commit: 578507a)). Probé el sistema de correo electrónico (funcionando) pero las alertas simplemente no se activan incluso cuando tengo un umbral muy bajo. ¿Hay alguna forma de ejecutar las consultas manualmente y ver los datos que está extrayendo?

Grafana v4.0.0-pre1 (confirmación: 9b28bf2)
error tsdb.HandleRequest () error Influxdb devolvió el código de estado código de estado no válido: 400 Solicitud incorrecta

@torkelo
¿Puede la 'notificación de alerta de webhook' publicar la métrica de alerta, json o tipo de formulario?

Hola chicos, ¿Grafana admitirá las alertas de consultas utilizando variables de plantilla o hay una versión de destino para esto?

Todos, intenten 4.0 beta; si falta algo, abra nuevos números.

Ricardo

Enviado por móvil; disculpe mi brevedad.

Probé 4.0 beta, pero sigo teniendo este error
error tsdb.HandleRequest () error Influxdb devolvió el código de estado código de estado no válido: 400 Solicitud incorrecta

No puedo guardar las notificaciones de alerta: enviar a, después de guardar, la fila de envío a se vuelve a dejar en blanco

@nnsaln Se supone que debe completar el destino de notificación allí, no la dirección de correo electrónico. Abra el menú lateral de grafana y coloque el cursor sobre la opción del menú de alertas, luego presione las opciones del menú de notificaciones. Allí puede configurar un destino de notificación que puede utilizar a partir de sus reglas de alerta.

¿Existe algún plan para admitir variables de plantilla junto con alertas? hago
entender que cada gráfico generado por una (o un conjunto) variable de plantilla corresponde
a un gráfico diferente y, por lo tanto, generar una alerta contra un valor estático es
incorrecto.

El lunes, 5 de diciembre de 2016 a las 2:06 a. M., Tomas Barton [email protected]
escribió:

@nnsaln https://github.com/nnsaln Se supone que debes completar la notificación
apunte allí, no dirección de correo electrónico. Abra el menú lateral de Grafana y coloque el cursor sobre
la opción del menú Alerta, luego presione las opciones del menú Notificaciones. Allí
puede configurar un objetivo de notificación que puede utilizar a partir de sus reglas de alerta.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

-
Deepak

No, actualmente no hay soporte para hacer esto. Quizás en un futuro lejano pero

El 99% de los paneles utilizan variables de plantilla. Fueron diseñados con plantilla
variables para evitar el problema de la "explosión del tablero".

El lunes 5 de diciembre de 2016 a las 8:20 p.m., Torkel Ödegaard [email protected]
escribió:

No, actualmente no hay soporte para hacer esto. Quizás en un futuro lejano pero

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

-
Deepak

Sí, pero un panel de exploración genérico no es lo mismo que un diseño de panel para reglas de alerta.

Hasta ahora no ha habido una propuesta sobre cómo admitir variables de plantilla de una manera intuitiva / comprensible. ¿Qué debe hacer la consulta de alerta con variable? Interpolar con el valor actual de la variable guardada, ¿con todos? Debería tratar cada valor como una regla separada y mantener el estado para cada etc. El soporte de variables de plantilla abre una lata de gusanos para la complejidad y el comportamiento potencialmente confuso. Podría añadirse algún día si a alguien se le ocurre una forma sencilla y comprensible.

Mientras tanto, nada le impide crear paneles de alerta separados.
La alerta es nueva y una gran adición a grafana. Evolucionará con el tiempo,
pero en el poco tiempo que se implementó, agregó un gran valor a grafana,
¡y gracias a todos los colaboradores por eso!

Soy 06.12.2016 11:14 nachm. schrieb "Torkel Ödegaard" <
[email protected]>:

Sí, pero un panel de exploración genérico no es lo mismo que un panel
diseño de reglas de alerta.

Hasta ahora no ha habido una propuesta sobre cómo admitir variables de plantilla
de una manera intuitiva / comprensible. ¿Qué debería alertar a la consulta con variable?
¿hacer? Interpolar con el valor actual de la variable guardada, ¿con todos? Deberia
tratar cada valor como una regla separada y mantener el estado para cada, etc.
la plantilla de variables abre una lata de gusanos para la complejidad y potencialmente
comportamiento confuso. podría añadirse algún día si a alguien se le ocurre una
forma sencilla y comprensible.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 Torkel.

Hace que las alertas sean bastante complicadas.

El martes 6 de diciembre de 2016 a las 2:14 p.m., Torkel Ödegaard [email protected]
escribió:

Sí, pero un panel de exploración genérico no es lo mismo que un panel
diseño de reglas de alerta.

Hasta ahora no ha habido una propuesta sobre cómo admitir variables de plantilla
de una manera intuitiva / comprensible. ¿Qué debería alertar a la consulta con variable?
¿hacer? Interpolar con el valor actual de la variable guardada, ¿con todos? Deberia
tratar cada valor como una regla separada y mantener el estado para cada, etc.
la plantilla de variables abre una lata de gusanos para la complejidad y potencialmente
comportamiento confuso. podría añadirse algún día si a alguien se le ocurre una
forma sencilla y comprensible.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

-
Deepak

@bergquist con respecto a este comentario

las alertas dentro de grafana aún no son compatibles con HA. Nuestro plan es agregar soporte a las alertas de partición entre servidores en el futuro

¿Existe un ticket para realizar un seguimiento del progreso? ¿Alguna rama para contribuir?

¡Y muchas gracias por el buen trabajo!

Kern,

<3 grafana.

Solo estaba tratando de compartir pensamientos sobre alertas con plantilla
cuadros de mando.

El viernes 9 de diciembre de 2016 a las 2:53 a.m., Dmitry Zhukov [email protected]
escribió:

@bergquist https://github.com/bergquist con respecto a este comentario

las alertas dentro de grafana aún no son compatibles con HA. Nuestro plan es agregar
soporte para particionar alertas entre servidores en el futuro

¿Existe un ticket para realizar un seguimiento del progreso? ¿Alguna rama para contribuir?

¡Y muchas gracias por el buen trabajo!

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

-
Deepak

@torkelo @Dieterbe ¡ Es increíble tener finalmente las alertas integradas en Grafana! ¿Cuál es la forma recomendada (si corresponde) de crear alertas mediante programación?

@jaimegago para crear alertas de forma programática usa la API del tablero, las alertas se guardan junto con un panel y un tablero.

@torkelo ¿Qué hay de los objetivos de las notificaciones (por ejemplo, crear un nuevo correo electrónico de notificación a través de API)?

editar: Respondiéndome a mí mismo aquí, encontré el punto final api / alert-Notifications. Creo que solo necesita ser documentado

Por supuesto, hay una API http para eso, solo vaya a la página de notificaciones de alerta, agregue una notificación y verifique la llamada http api que hace grafana.

@torkelo , ¿hay alguna API que se pueda usar para crear alertas (no crear notificaciones de alertas) mediante programación?

@CCWeiZ Alerts es parte del panel json. Por lo tanto, solo puede crear un panel que contenga alertas, no solo alertas.

Puede leer más sobre la API del tablero en http://docs.grafana.org/http_api/dashboard/

¿Está disponible? Quiero configurar una alerta si un valor se compara con hace 3 días, el valor no aumenta. (dice las solicitudes, si ahora valor - solicitudes de hace 3 días <100, entonces decimos que no hay muchas solicitudes). ¿Como hacer esto?