Grafana: système d'alerte de bâtiment pour grafana

J'aimerais aider avec ça! Ma suggestion serait de s'en tenir aux directives de style nagios. De cette façon, les outils pourraient facilement être utilisés avec d'autres outils de surveillance. par exemple Nagios, Zenoss, Icinga, etc.

La chose la plus importante à propos de cette fonctionnalité est d'avoir une architecture de base correcte.

Quelques questions que j'aimerais explorer
1) Quels composants sont nécessaires comment sont-ils exécutés (en proc dans grafana, hors proc),
2) Comment les choses devraient-elles être coordonnées.
3) Devrions-nous ignorer les alertes « in stream » (se concentrer uniquement sur l'extraction)

Aller plus en profondeur dans 1)
Je m'inquiète de faire de grafana-server un monolithe. J'aimerais trouver un moyen de séparer grafana-server en services plus isolés les uns des autres (et pouvant être exécutés soit inproc, soit en tant que processus séparés). C'était un peu le plan avec l'abstraction du bus. Une autre option serait de faire en sorte que le composant d'alerte ne parle qu'à grafana via l'API HTTP, ce qui pourrait limiter l'intégration, pas sûr.

Je suis d'accord avec Torkelo. D'après mon expérience avec d'autres projets avec tout "intégré", cela peut devenir assez lourd à dépanner. J'aime l'idée que le service s'exécute en externe, mais une belle page de configuration dans grafana qui communique avec le service via l'API HTTP pour gérer la gestion de toutes les alertes. De plus, pour les déploiements à grande échelle, cela finirait probablement par être une exigence car les performances finiraient par se dégrader (j'aurais au moins cela comme option de configuration).

intégrons-nous avec les paramètres actuels de seuil de grafana graph (qui sont actuellement pour la visualisation uniquement, pas pour le traitement) ? si l'expression est une vérification de seuil, nous pourrions afficher automatiquement une ligne de seuil

Je pense que cela pourrait être un bon point de départ. Alertez si c'est réglé, ne le faites pas si ce n'est pas le cas.

Retour au numéro 1. Je pense que si le service bosun pouvait fonctionner séparément mais avait toujours la possibilité de tout configurer complètement via grafana, ce serait, à mon avis, idéal.

Continuez votre travail formidable.

Le seul inconvénient que j'ai vu avec bosun est les sources de données qu'il peut utiliser. Si vous pouviez tirer parti du langage pour exprimer les alertes de bosun, mais également l'intégrer aux sources de données existantes configurées via l'interface utilisateur grafana standard, ce serait certainement l'idéal.

Être capable de représenter des seuils d'alerte, lorsque vous êtes proche d'eux, ainsi que d'envoyer automatiquement des annotations lorsqu'ils se sont déclenchés dans mon esprit, en fait une interface utilisateur à volet unique idéale.

J'attends avec impatience le travail qui sera fait ici!

1. Il doit utiliser les seuils définis dans le tableau de bord pour alerter sur
   Restons simples ; si le tableau de bord affiche la couleur d'avertissement, cela devrait être une alerte.
2. Il s'agit probablement de quelque chose en dehors du processus grafana-server lui-même.
   ... Quelque chose qui utiliserait le reste de l'API pour gratter les tableaux de bord et ses paramètres et les rendre et alerter à l'aide d'une commande externe.
3. Niveau d'alerte ; juste une case à déposer dans l'éditeur que ce tableau de bord doit être surveillé ; et il doit être vérifié toutes les minutes. S'il n'y a pas de données, il devrait toujours être alerté pendant un certain temps ? (case à cocher)

Dernièrement; comme nous dépendons davantage de Grafana, j'admets que je suis prêt à dire 2. cela pourrait être quelque chose pour lequel je serais prêt à payer.

Je suis curieux de savoir pourquoi les gens pensent que cela devrait être inclus dans Grafana ?
Grafana ne reçoit ni ne stocke ces données réelles mais "seulement" les visualise. Tout système d'alerte doit plutôt être basé sur les données du magasin de métriques.
Si cela est vraiment intégré à Grafana, j'espère que cela pourra être désactivé car ici, nous utilisons déjà Icinga pour les alertes, donc tout type d'alerte dans Grafana ne ferait qu'encombrer davantage l'interface graphique, même si elle ne serait pas utilisée du tout.

Absolument correct @dennisjac; Grafana ne fait que rendre les choses.

Mais comme nous avons déplacé les choses côté serveur, ce n'est plus seulement le rendu client ; les possibilités d'un processus de travail qui pourrait vérifier vos métriques et alerter ; est moins difficile.

Les données sont dans une base de données ; à condition qu'il soit saupoudré des données qui lui disent de vérifier la métrique ...

Certaines personnes peuvent être d'accord ou pas d'accord pour dire que nous ne devrions pas traverser les ruisseaux et obliger Grafana à faire plus que le visualiser (en gros), mais je ne suis pas eux.

Je ne suis pas vraiment opposé à la fonctionnalité pour les personnes qui souhaitent qu'elle soit intégrée mais j'espère qu'elle sera rendue optionnelle pour les personnes qui disposent déjà de systèmes de surveillance/d'alerte.

Le nouveau projet Telegraf (collecteur de métriques des gars d'influxdb) examine également les fonctionnalités de surveillance/d'alerte qui ne sont pas appréciées pour la même raison. J'ai développé cela ici :
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

Je pense que Torkelo a fait un très bon travail en nous donnant des fonctionnalités dans Grafana2 que nous n'avons pas à activer.

En ce qui concerne influxdb, ils vont devoir gagner de l'argent d'une manière ou d'une autre; soit hors du support d'influxdb et des services ou produits professionnels pour celui-ci.

Ce dernier semble beaucoup plus viable

Un autre angle à ce sujet. Il semble y avoir un support à venir pour elasticsearch en tant que stockage métrique pour grafana. Bosun peut maintenant interroger Elasticsearch pour les données de journal.

Serait-il judicieux lors de la conception du système d'alerte d'autoriser également les alertes à partir des données de journal ? Peut-être pas une fonctionnalité pour la première version, mais quelque chose qui peut être implémenté plus tard.

Je suis également d'accord avec l'idée de diviser les processus. Avoir Grafana l'interface pour afficher et créer des alertes, avoir quelque chose d'autre pour gérer les alertes. Le fait d'avoir la partie d'alerte basée sur l'API permettrait également à d'autres outils de s'interfacer avec elle.

+1 à l'alerte. En dehors de l'utilisation de DevOps, les applications conçues pour les utilisateurs finaux doivent fournir des alertes définies par l'utilisateur. C'est bien de l'avoir dans l'outil de visualisation...

+1 cela fermera la boucle - la proposition d'obtenir des métriques.

+1 Alertes de Grafana + un backend à mise à l'échelle horizontale d'InfluxDB en feront la norme à battre pour les configurations d'alertes de métriques

+1 J'aimerais une mise à l'échelle horizontale de l'alerte sur plusieurs nœuds grafana.

Ce serait formidable si l'on pouvait associer un comportement de type "anti-rebond" à une alerte. Par exemple, je souhaite déclencher une alerte uniquement si le seuil défini dépasse X pendant N minutes.

J'ai vu cela avec certains des outils d'alerte, malheureusement nous utilisons actuellement Seyren qui ne semble pas fournir une telle option. Nous utilisons Grafana pour le développement de notre tableau de bord et sommes impatients d'intégrer les alertes à Grafana également. Continuez votre bon travail.

Nous avons deux cas d'utilisation :

• l'équipe d'infrastructure crée une alerte via des outils de provisionnement comme d'habitude dans la pile de surveillance commune (vérification de cluster commune ou vérifications du système dans le système convivial de nagios)
• les développeurs de logiciels créent des métriques d'application via Grafana

Nous aimerions avoir un système d'alerte unifié qui gère les alertes, la détection des volets, l'escalade et les contacts. Cela nous aide à enregistrer et à corréler les événements/opérations dans la même source de vérité. Beaucoup de système a résolu le problème d'alerte. J'espère que Grafana pourra faire mieux à long terme, à court terme ne pas réinventer les systèmes existants serait utile en termes de livrables.

Une suggestion est que Grafana peut fournir une API pour extraire la définition de surveillance (état d'alerte), un tiers peut contribuer aux plug-ins d'exportation de configuration. Ce serait très idéal dans notre cas d'utilisation d'exportation de la configuration de nagios.

Plus important encore, j'aimerais aussi voir une solution de détection d'anomalies intégrée !

Le 15 juillet 2015, à 17h40, Pierig Le Saux [email protected] a écrit :

+1 J'aimerais une mise à l'échelle horizontale de l'alerte sur plusieurs nœuds grafana.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je suis d'accord avec @activars. Je ne vois pas vraiment pourquoi une solution de tableau de bord devrait gérer les alertes qui sont un problème plus ou moins résolu par beaucoup d'autres outils, pour la plupart assez matures. Faites une chose et faites-la bien.

À mon humble avis, il serait plus logique de se concentrer sur la partie _intégration_.

Exemple : définissez des seuils dynamiques d'avertissement/critique dans grafana (par exemple, comme dans l'exemple de @Dieterbe ci-dessus) et fournissez une API (REST ?) qui renvoie l'état (normal, avertissement, critique) de ce graphique exactement. Un nagios, un icinga, un bosun, etc. pourraient demander tous les graphiques activés pour la "surveillance" (une autre fonctionnalité de l'API), parcourir les états individuels et effectuer les alertes nécessaires.

Dans notre cas, les catalogues de services et les actions définies sont la partie la plus difficile - quel service est critique pour l'entreprise, où envoyer des e-mails, battement, etc. De plus, vous n'auriez pas à vous soucier de la gestion des utilisateurs / groupes dans grafana que la plupart des entreprises ont déjà dans un central (AD, LDAP, Crowd etc.) et intégré au système d'alerte.

Nous devons également considérer que contrairement à une solution de tableau de bord, les exigences de qualité pour un outil d'alerte peuvent être considérées comme beaucoup plus élevées en termes de fiabilité, de résilience, de stabilité, etc., ce qui crée un effort (de test) qui ne doit pas être sous-estimé.

Qu'en est-il également des vérifications non liées aux séries temporelles, telles que l'appel d'un service Web, le ping d'une machine, l'exécution de scripts personnalisés ... voudriez-vous également cela dans grafana ? Je suppose que l'adoption du patron fournirait tout cela, mais je ne suis pas vraiment familier avec cela.

D'un autre côté, je peux imaginer comment un système d'alerte simple rendrait heureux de nombreux utilisateurs qui n'ont pas une bonne alternative en place, mais cela pourrait peut-être être résolu avec quelques exemples de modèles d'intégration pour d'autres outils d'alerte.

Autant je veux que Grafana résolve tous mes problèmes, je pense que falkenbt a mis le doigt sur la tête avec celui-ci.

Une API pour exposer les données mentionnées, un peu de plomberie dans le bosun et certains modèles d'intégration avec des plates-formes d'alerte communes ont beaucoup de sens.

Félicitations pour votre nouveau travail chez raintank @Dieterbe ! Je lis votre blog depuis un moment et vous avez de très bonnes idées sur le monitoring, notamment concernant les métriques et sa place dans l'alerte. Je suis convaincu que vous trouverez un bon moyen de mettre en œuvre les alertes dans grafana.

Comme vous en conviendrez probablement, les personnes derrière Bosun alertent à peu près de la bonne manière. Ce qui manque avec Bosun, ce sont vraiment les visualisations. J'aimerais voir Bosun derrière l'interface utilisateur de Grafana. La combinaison du tableau de bord Grafanas et des alertes de bosuns derrière la même interface constituerait une solution de surveillance impressionnante et complète.

De plus, je pense qu'il serait dommage de fragmenter davantage la communauté de surveillance open source, vos idées sur la surveillance semblent vraiment compatibles avec les idées des personnes derrière Bosun. Si vous vouliez vous unir, je suis sûr que le résultat serait génial.

Là où je travaille, nous utilisons Elastic pour les journaux/événements et nous venons de commencer à utiliser InfluxDB pour les métriques. Nous avons exploré différentes solutions de surveillance et penchons actuellement vers Bosun. Nous utilisons déjà Grafana pour les tableaux de bord, mais aimerions accéder à toutes nos informations de surveillance via la même interface, ce serait formidable si Grafana pouvait devenir cette interface.

Continuez votre excellent travail et bonne chance!

Sur une tangente connexe, nous avons fait fonctionner la partie alerting alerting working en intégrant grafana avec riemann. C'était un bon exercice pour apprendre à connaître les internes de grafana :).

C'était plus facile avec riemann car la configuration n'est qu'un code clojure. J'imagine que cette intégration va être plus difficile dans Bosun.

Voici quelques captures d'écran de celui-ci en action

Les modifications apportées à la partie grafana comprenaient l'ajout d'un point de terminaison "/alerts" et "/subscriptions" et de le faire parler à une autre petite API qui se trouve au-dessus pour que riemann fasse le travail.

La bonne chose est le fait que les changements dans les définitions d'alertes sont reflétés immédiatement sans avoir à envoyer un SIGHUP à riemann. Ainsi, activer/désactiver les ajustements de période pour les changements d'état consiste simplement à le changer dans l'interface utilisateur et à faire en sorte que ce changement se propage à riemann.

Je n'ai toujours pas comparé cette intégration, mais je ne pense pas que ce sera si mauvais. Je bloguerai à ce sujet après avoir nettoyé le code et une fois qu'il sera mis en ligne.

La raison pour laquelle nous avons fait cela était que les gens peuvent simplement définir ces alertes et notifications à partir d'une interface utilisateur très familière et ne pas nous déranger pour écrire des configurations riemann :).

@sudharsh votre implémentation semble vraiment intéressante. Envisagez-vous de le relâcher dans la nature ?

plein de bonnes idées, merci à tous.
Inspirés par certains des commentaires et le projet https://github.com/pabloa/grafana-alerts de @pabloa , nous avons décidé de nous concentrer avant tout sur l'interface utilisateur et l'expérience utilisateur pour configurer et gérer les règles d'alerte dans le cadre du même workflow de éditer des tableaux de bord et des panneaux. Grafana enregistrerait ces règles quelque part et y accéderait facilement afin que d'autres scripts ou outils puissent récupérer les règles d'alerte.
Peut-être via un fichier, un appel API, une section dans la configuration du tableau de bord ou une entrée dans la base de données.
(J'aime l'idée de l'avoir dans le cadre de la définition du tableau de bord lui-même, afin que les projets open source puissent être livrés avec des fichiers json de tableau de bord grafana pour eux qui auraient des règles d'alerte incluses mais pas nécessairement actives par défaut. d'autre part les avoir dans une base de données semble plus robuste)
Dans tous les cas, nous souhaitons fournir un accès facile afin que vous puissiez générer une configuration pour tout autre système que vous souhaitez utiliser et qui exécute réellement les règles d'alerte et traite les événements. (à partir de là, j'appellerai cela un "gestionnaire").
Un tel gestionnaire pourrait être nagios, ou sensu, ou bosun, un outil que vous écrivez ou le programmeur-exécuteur d'alertes décisives qui est un gestionnaire que vous pouvez compiler dans grafana qui fournit une intégration simple et agréable soutenue par bosun mais nous voulons vraiment assurez-vous que vous pouvez utiliser le système que vous voulez.

Tant que votre gestionnaire prend en charge l'interrogation du magasin de données que vous utilisez. nous commencerions par un simple seuil statique, mais nous souhaitons également faciliter le choix des fonctions de réduction, des expressions booléennes entre plusieurs conditions, etc.

@sudharsh c'est une très belle approche. J'aime la façon dont votre solution peut parler directement à une API distante, en contournant l'étape intermédiaire décrite ci-dessus (bien sûr, cela implique qu'elle ne fonctionne que pour 1 backend donné que nous essayons d'éviter), et qu'elle peut recharger automatiquement la configuration. (vous avez raison, bosun ne le prend pas en charge actuellement, cela pourrait le faire à l'avenir. FWIW, le gestionnaire de tournesol gère cela correctement et il utilise le mécanisme d'évaluation d'expression de bosun). Je ne me suis jamais vraiment intéressé à riemann. La plupart du temps, j'ai été préoccupé par l'ajout d'un langage si différent à la pile que peu de gens comprennent ou peuvent déboguer lorsque les choses tournent mal. Mais je suis très curieux d'en savoir plus sur votre système et sur le code CLJ de Riemann. (J'adorerais si mes soupçons sont incorrects)

@dennisjac oui ce serait facultatif.
@elvarb il existe un ticket pour ES en tant que source de données . en fait, l'objectif est que si grafana prend en charge le rendu des données à partir d'une source de données donnée, il devrait également prendre en charge la composition de règles d'alerte pour celle-ci. En ce qui concerne l'exécution/l'interrogation des requêtes, cela dépend bien sûr du gestionnaire que vous décidez d'utiliser. (pour le gestionnaire de tournesol, nous commencerons par les plus populaires comme graphite et influxdb)
@rsetzer : d'accord, c'est une bonne chose de pouvoir spécifier combien de temps un seuil doit être dépassé avant de déclencher
@falkenbt : Je crois que beaucoup de choses peuvent être exprimées comme un problème de requête de séries temporelles (par exemple l'exemple pings). Mais vous avez raison, certaines choses ne sont pas vraiment liées aux séries temporelles et elles sont hors de portée de ce que nous essayons de construire ici. Et je pense que c'est OK : nous voulons fournir le meilleur moyen de configurer et de gérer les alertes sur les séries temporelles et viser l'intégration avec d'autres systèmes qui sont peut-être plus optimisés pour le cas des "scripts divers" (tels que nagios, icinga, sensu, .. .). En ce qui concerne les problèmes tels que la fiabilité de la livraison, les escalades, etc., vous pouvez vous connecter à un service tel que pagerduty.
@activars & @falkenbt cela semble-t-il correspondre à vos attentes ou que pensez-vous qui pourrait être amélioré spécifiquement ?
@jemilsson merci ! et c'est exactement comme ça que je le vois : le bosun est excellent pour alerter mais pas bon pour la visualisation. Grafana est excellent en visualisation et UX mais n'a pas d'alerte. J'essaye de conduire une collaboration qui va grandir avec le temps je pense

Quelqu'un a-t-il une idée du type de contexte à envoyer dans les notifications comme les e-mails ?
À tout le moins, la notification doit contenir une visualisation des données sur lesquelles vous alertez, mais il devrait à mon humble avis être possible d'inclure d'autres graphiques associés. Ici, nous pourrions utiliser le backend de rendu png de grafana lors de la génération du contenu de la notification. Je pense également à tirer parti de la fonction d'instantané de grafana. comme lorsqu'une alerte se déclenche, prenez un instantané d'un certain tableau de bord pour le contexte.
et peut-être que cet instantané (page html) pourrait être inclus dans l'e-mail, ou cela pourrait être un peu trop de données/complexité. De plus, les fonctionnalités javascript ne seraient de toute façon pas disponibles dans les clients de messagerie (vous ne pourriez donc pas zoomer sur les graphiques dans un e-mail). Peut-être pourrions-nous établir un lien entre l'e-mail et un instantané de tableau de bord hébergé.

J'aime l'approche générale de docker - piles incluses, mais amovibles. Donc, une implémentation d'alerte de base qui peut être échangée serait une bonne approche à mon humble avis.

influxdb sera pris en charge pour les alertes ? ou seulement du graphite ?

Une chose que j'aimerais voir, c'est l'idée d'arbres d'alerte hiérarchiques. Il y a tout simplement trop de facettes surveillées et les états d'alerte autonomes ont une cardinalité ingérable. Avec un arbre hiérarchique, je peux définir toutes ces alertes de bas niveau qui se cumulent à des alertes de niveau moyen qui se cumulent à un niveau élevé ......

En tant que telle, chaque alerte cumulée assume automatiquement la gravité élevée de tous les enfants en dessous. De cette façon, je peux avoir une impression de [et gérer] la santé du système avec précision avec une surface d'analyse beaucoup plus faible.

C'est un exemple que j'ai emprunté à un vieux document que j'ai écrit il y a quelque temps. Oui, s'il vous plaît rire à l'utilisation du mot "Struts". C'est VIEUX d'accord ? Cela présente une hiérarchie très simple pour un serveur.

À un moment donné, le serveur connaît une utilisation soutenue de 75 % du processeur, ce qui déclenche ces alertes dans un état d'avertissement : CPU-# --> CPU --> Host/OS --> System

Si l'on s'appliquait vraiment, on pourrait garder un œil sur un centre de données entier avec un seul indicateur. (oui, pas vraiment, mais ça sert d'exercice de réflexion)

Pourquoi ne pas utiliser graphite-beacon ? Je pense que vous pouvez fusionner graphite-beacon qui est très léger avec grafana.

@felixbarny J'aime cette terminologie. nous adopterons probablement cette formulation.
@JulienChampseix oui, le gestionnaire standard prendrait en charge influxdb
@nickman c'est intéressant. cela correspond en fait à l'objectif final que nous avons en tête, de pouvoir créer des alertes de très haut niveau qui peuvent inclure / dépendre de règles et d'informations d'alerte plus fines. bosun le fait déjà, et à long terme, nous voulons rendre cette fonctionnalité disponible via une interface plus conviviale, mais nous devons commencer plus simplement que cela.
@amirhosseinrajabi ressemble à un projet sympa et je pense que faire de graphite-beacon un gestionnaire pour les alertes configurées via l'interface utilisateur grafana aurait beaucoup de sens.

@Dieterbe est-il possible d'avoir une mise à jour de l'état actuel ? pour système d'alerte
afin de savoir quel système est compatible (graphite/influxdb) ?
quel abonnement disponible ? quel type d'alerte disponible ?
Merci pour votre mise à jour.

nous sommes actuellement en train de prototyper l'UX/UI. nous sommes donc loin d'être utilisables.

Salut @Dieterbe

y a-t-il des mises à jour sur la progression du système d'alerte ??

Ce serait génial d'avoir des alertes à Grafana ! Dans l'attente de cette fonctionnalité. Des mises à jour maintenant ?

@mattttt pouvez-vous fournir une mise à jour

Oui absolument. Je téléchargerai des écrans/flux d'utilisateurs demain.

Nous avons besoin d'alertes : UI pour la définition des règles, API pour la définition des règles et API pour les notifications d'alerte. Je vais regarder ce fil avec intérêt. Nous avons un système multi-locataire et aimons l'interface utilisateur et le back-end Grafana.

Oui, je suis aussi très intéressé et impatient de voir cette nouvelle fonctionnalité !
Merci beaucoup Matt ! ;)

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

Nous avons besoin d'alertes : UI pour la définition des règles, API pour la définition des règles et API
pour les notifications d'alerte. Je vais regarder ce fil avec intérêt.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-135290295 .

Il y a beaucoup d'éléments qui se mettent en place en interne, mais je ne voulais pas laisser ce fil négligé.

Voici l'une des maquettes d'un panneau sur lequel j'ai travaillé. Cela illustre la santé historique au fil du temps, en incorporant l'état dans l'info-bulle et en utilisant les seuils existants définis dans la configuration du panneau pour configurer les alertes.

Dans cet exemple, il s'agit d'une alerte sur une seule requête avec plusieurs séries. Les infobulles sont étendues pour afficher l'état au moment du survol.

_Quelques petites questions en suspens _ : Quelle quantité d'informations sur la notification d'alerte doit-elle figurer dans l'info-bulle, le cas échéant - ou ces informations doivent-elles être accessibles ailleurs dans une vue plus détaillée ? Je crois ce dernier pour le moment, mais cela vaut la peine de le demander à voix haute.

Configuration, écrans d'alerte, les flux d'utilisateurs se font lentement. Beaucoup à venir.

@mattttt sympa !

J'adore la ligne verte et rouge sous le graphique !

Cela est lié aux calculs de disponibilité, j'adorerais pouvoir voir cela comme un nombre quelque part. Totaux pour toutes les requêtes et pour chaque métrique.

À propos de l'info-bulle, parlez-vous des statistiques qui apparaissent lorsque vous survolez les lignes ?

Putain @mattttt ça a l'air génial. Je ne m'inquiéterais même pas de mettre quoi que ce soit dans l'info-bulle. La ligne de seuil et la barre d'état d'état d'alerte en bas sont plus que suffisantes.

J'ai hâte de voir ça quand ce sera fini !

J'ai hâte de voir que ça avance bien !

Nous utilisons actuellement Grafana+Bosun+OpenTSDB comme pile de surveillance et d'alerte. Je suis tout à fait d'accord que ce serait génial d'avoir le pouvoir de Bosun avec le grand UX de Grafana.

Voici un exemple où la configuration UX de Grafana est meilleure que celle de Bosun :

Le contexte

Notre pile de surveillance est partagée entre plusieurs équipes et leurs services. Un ensemble différent de services est déployé sur différents clusters/sites en fonction des spécifications du projet. Chaque équipe/service doit assumer la responsabilité de ses propres tableaux de bord/alertes.

Comparaison

Avec l'API HTTP de Grafana, les équipes peuvent METTRE leurs propres tableaux de bord lors du déploiement de leur service. Bosun n'a actuellement qu'un seul fichier pour stocker la configuration ; cela rend difficile le partage entre différentes équipes et entre différents projets.

@mattttt @torkelo @Dieterbe une idée de sortie de la pièce d'alerte (ou version bêta) ?

écho ^. Est-ce qu'il s'agit d'une version bêta ou alpha pour cela ? Je recherche des solutions d'alerte, mais j'aimerais avoir quelque chose de intégré à grafana. Je pourrais fournir beaucoup de commentaires sur les tests.

La fonction d'alerte est encore dans quelques mois, nous sommes toujours en train de prototyper l'interface utilisateur et de réfléchir à différentes manières de la mettre en œuvre, mais les progrès devraient progresser plus rapidement au cours des 2 prochains mois, nous en saurons donc plus

@mattttt avez-vous l'intention de rendre paramétrables les couleurs de la barre de santé historique ? Le vert et le rouge ne vont pas vraiment bien avec les daltoniens ;)

Concernant l'alerte : je suis assez intéressé par la façon dont cela se déroule. Nous collectons et visualisons des données depuis un certain temps maintenant, et les alertes sont quelque chose que nous essayons actuellement de comprendre. Grafana pourrait y avoir une belle place, d'autant plus que les visualisations sont déjà en place. Ce que je me demande cependant : dans quelle mesure Grafana devrait-il être plus conscient des « entités » plutôt que des séries métriques pour les alertes ? Je peux m'imaginer vouloir basculer automatiquement un changement d'état visuel (échec de la vérification ping ou http) ou manuellement (maintenance) pour ce qui dans mon cas serait un serveur, en plus des alertes basées sur des métriques.

Je suis intéressant de voir où vont les alertes dans Grafana, mais pour ceux d'entre vous qui ont besoin de quelque chose maintenant, il existe des plugins nagios comme https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details qui peuvent déclencher des alertes lorsque des seuils sont franchis.

@baaym

Ce que je me demande cependant : dans quelle mesure Grafana devrait-il être plus conscient des « entités » plutôt que des séries métriques pour les alertes ? Je peux m'imaginer vouloir basculer automatiquement un changement d'état visuel (échec de la vérification ping ou http) ou manuellement (maintenance) pour ce qui dans mon cas serait un serveur, en plus des alertes basées sur des métriques.

c'est une bonne question et aussi quelque chose dont nous avons parlé un peu.
la solution que nous voulons utiliser à court terme (et peut-être aussi à long terme) est de faire en sorte que grafana ne soit pas au courant de ces concepts de niveau supérieur. c'est-à-dire qu'en tant qu'utilisateur, vous avez le pouvoir de définir des alertes sur des séries de mesures, et à partir de ces règles d'alerte, des résultats d'alerte seront générés (incluant probablement des attributs ou des balises des noms de séries) à partir desquels vous pouvez ensuite construire les entités de votre choix. c'est une chose à laquelle nous devons réfléchir un peu plus, mais par exemple

disons que vous définissez une alerte du type movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn . cela vérifierait le seuil sur tous vos serveurs Web dans le cluster donné et générerait des alertes pour toute violation telle que movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! .
nous pourrions peut-être vous permettre de dire "le premier champ est le nom du cluster, le deuxième est le nom d'hôte", etc., afin que les alertes puissent contenir des informations plus intéressantes.
mais le fait est que le _résultat_ d'alerte contient les informations dont vous avez besoin pour identifier quelle entité rencontre des problèmes, mais il sort du cadre de grafana. Grafana serait plus la source de la configuration des règles d'alerte, et les tableaux de bord grafana pourraient être configurés pour charger des annotations et ce que vous avez pour visualiser l'état des alertes, mais il n'aurait pas une notion de concepts de haut niveau tels que les hôtes ou groupes. Je pense que c'est quelque chose qui pourrait être géré dans les gestionnaires d'alerte

@Dieterbe

Il existe deux types de problèmes d'utilisateur/d'organisation lors de la création d'une fonction d'alerte :

• Comme les startups, où ils n'ont généralement pas le temps de construire leur propre solution d'alerte. Tout se reposerait sur Grafana pour alerter sur les métriques
• Organisation d'ingénierie établie, ils ont des outils d'alerte existants construits en interne, les alertes pour les règles métier sont construites sur la base d'autres signaux d'alerte granulaires (Grafana en ferait partie).

Grafana doit fonctionner avec des pratiques d'exploitation existantes et bien établies, le faire en dehors du cycle ignore l'objectif d'alerte - avoir une vision claire de la santé des entités critiques de l'entreprise. L'alerte est préférable d'être centralisée pour permettre de construire un état clair de l'environnement. Il serait essentiel de permettre aux utilisateurs expérimentés utilisant l'API grafana (ou toute autre solution) d'exporter des règles d'alerte vers d'autres systèmes.

Lorsqu'elle est déclarée opérationnelle, chaque alerte doit éventuellement contenir un champ de documentation/lien pour expliquer le but des alertes et le comportement historique.

@activars je pense que je suis d'accord avec tout cela. à mon avis, nous adoptons une approche qui favorise le branchement de grafana dans le reste de l'environnement (principalement grâce à la séparation des préoccupations, avec des gestionnaires enfichables). pensez-vous que la conception proposée peut être améliorée de quelque manière que ce soit ?

Je pense que @ deebs031 fait une bonne remarque qui n'a pas été abordée beaucoup "les applications
À mon humble avis, le graal est une surveillance basée sur des métriques en libre-service , dans mon cas, Grafana étant le principal frontal pour les personnes qui souhaitent examiner les métriques, il serait logique de leur permettre de créer des alertes pour eux-mêmes dans la même - avouons-le IMPRESSIONNANT - UI.
J'ai personnellement fait des alertes Sensu basées sur des métriques, mais les fournir en libre-service n'est vraiment pas un jeu d'enfant par rapport à la facilité avec laquelle elles seraient intégrées à Grafana. J'ai également examiné Cabot car il avait des capacités de visualisation, mais il n'a pas été conçu pour le libre-service, donc je ne pouvais pas l'utiliser tel quel.
Je suis du côté « bien faire une chose », mais je pense que dans le cas particulier des alertes en libre-service basées sur des métriques, l'association de cette capacité avec la couche de visualisation des métriques a beaucoup de sens :

• L'utilisateur est déjà familiarisé avec l'interface utilisateur
• L'utilisateur est authentifié afin qu'elle puisse créer des alertes pour elle-même ou tout autre schéma d'autorisations activé par l'authentification
• L'utilisateur peut voir les graphiques qui sont généralement très utiles lors de la création de ces alertes basées sur des métriques

diapositives de ma présentation grafanacon sur les alertes :
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
ils sont un peu difficiles à comprendre sans contexte, la vidéo devrait être en ligne dans environ une semaine, je la publierai quand elle sera prête.

nous avons maintenant commencé à prototyper des moyens d'implémenter les modèles d'alerte/UI/définitions/etc. nous avons une assez bonne idée du flux de travail principal, bien qu'un point important que nous essayons toujours de comprendre est à quoi devrait ressembler l'intégration avec des gestionnaires d'alertes tiers.
notre réflexion actuelle est que vous pourrez utiliser grafana pour définir des seuils/règles d'alerte/définir des notifications et pour visualiser l'état historique et actuel des règles d'alerte.

l'hypothèse est que vous souhaitez utiliser le logiciel d'alerte de votre choix (bosun/cabot/sensu/nagios/...)
il y aurait donc un outil séparé qui interroge grafana sur son API http pour récupérer toutes les règles d'alerte. cet outil pourrait alors mettre à jour votre configuration bosun/cabot/sensu/nagios/..., afin que vous puissiez utiliser le logiciel d'alerte de votre choix pour exécuter et exécuter les alertes et envoyer les notifications.
mais nous voulons pouvoir visualiser correctement l'état actuel et historique, donc soit votre programme d'alerte devra être capable d'appeler un script ou un webhook ou quelque chose pour informer grafana du nouvel état, ou grafana devra l'interroger. (ce qui semble dégoûtant, étant donné que la plupart des outils ne semblent pas avoir de bonnes API)
tout cela est un peu compliqué mais il faudrait que ce soit ainsi pour accompagner les personnes pour qui il est important qu'elles restent capables d'utiliser le logiciel d'alerte de leur choix, tout en utilisant grafana pour définir les règles d'alerte et visualiser l'état.

Est-il important pour vous de pouvoir utiliser l'outil d'alerte actuel de votre choix ?

l'autre chose que nous aimerions faire est également d'écrire nous-mêmes un simple exécuteur d'alertes, qui interroge l'API grafana pour les alertes, les programme et les exécute, fait les notifications (il prendrait en charge les e-mails, slack, pagerduty, un script personnalisé et probablement quelques autres) et met à jour à nouveau l'état dans grafana.
ce serait assez facile à écrire pour nous, facile à utiliser pour vous et nous pourrions avoir une grande interopérabilité.

L'exécuteur d'alerte intégré (voir ci-dessus) est-il suffisant pour gérer toutes les règles d'alerte que vous avez configurées dans grafana ?

Voulez-vous également pouvoir utiliser plusieurs gestionnaires d'alertes ? lequel ?

@jaimegago amen ;)

Pour moi, le numéro 2 semble meilleur dans la mesure où vous pouvez vraiment minimiser le nombre de choses que vous devez configurer pour que tout fonctionne sans problème. Dans notre configuration actuelle, nous irions avec cela.

Juste comme ça a été dit si tout le monde n'est pas d'accord ;)

Modification rapide : diapositives impressionnantes. Si le produit final est à moitié aussi bon que cela, alors c'est incroyable.

+1
Je suis d'accord que le gestionnaire de notification interne avec ces intégrations est parfait ! pour les cas d'utilisation les plus courants.

Je serai heureux d'être en test bêta :) et les diapositives seront incroyables !

Je pense que le dernier message de

L'alerte dans Grafana est vraiment deux choses, la configuration d'alerte en libre-service (merci @jaimegago ,

Nous expédierons un gestionnaire d'alertes Grafana, mais fournirons également le cadre à intégrer à votre logiciel d'alerte de choix :

+1 pour construire une sorte de pont vers d'autres systèmes d'alerte (peut-être pourrions-nous penser à implémenter un système de plugin d'alerte générique :-) )

Vous pouvez également ajouter Prometheus dans la partie "External Alert Handlers". La première version de Prometheus alertmanager est en production dans plusieurs sociétés et une réécriture complète est actuellement en cours. SoundCloud peut utiliser Grafana pour configurer des alertes, mais très certainement seulement si le gestionnaire d'alertes Prometheus est utilisé comme gestionnaire d'alertes.

@grobie , bonne prise, corrigé dans le commentaire original.

@mattttt @Dieterbe c'est super ! On dirait que vous êtes sur la voie des "batteries incluses mais amovibles", ce qui est à mon humble avis le meilleur des deux mondes. Avez-vous déjà réfléchi à la manière dont vous allez transmettre les données d'autorisation au gestionnaire d'alertes ? Je pense à une histoire comme celle-ci :
En tant qu'utilisateur de Grafana, j'aimerais être alerté via _email_ et/ou _pagerduty_ et/ou _foo_ quand (une condition créée via l'interface utilisateur d'alerte Grafana) se produit.
Cet utilisateur ne devrait pouvoir envoyer des alertes qu'au système de notifications pour lequel il est autorisé, c'est une exigence pour le libre-service et devra être résolu d'une manière ou d'une autre. Depuis Grafana 2, nous avons un backend SQL + authentification/autorisation des utilisateurs avec intégration LDAP, il ne semble donc pas exagéré d'avoir cette capacité dès le premier jour d'alerte ?
Avec Sensu (qui est l'outil que je brancherais), le passage de la cible d'alerte (par exemple, l'adresse e-mail) via le gestionnaire devrait être assez simple, je ne peux pas dire pour les autres.

Salut tout le monde,
Je suis heureux de voir que cette offre est en train de progresser, car j'adore l'approche de configuration des alertes en libre-service.

Personnellement, je n'ai pas besoin d'un gestionnaire d'alertes spécifique. J'aimerais voir un gestionnaire HTTP POST générique, qui est simplement déclenché dès qu'une alerte est lancée. Je pense que la plupart des administrateurs peuvent rapidement créer quelque chose qui est capable d'accepter HTTP, puis de faire tout ce qu'ils doivent faire avec (l'envoyer à nagios, riemann, younameit). Je serais donc satisfait d'un gestionnaire HTTP qui envoie toutes les informations sur une alerte sous forme de données JSON.

En parlant d'alerte via grafana, prévoyez-vous d'ajouter quelque chose comme la détection de battement ? Ou est-ce quelque chose dont le système de contrôle externe devrait s'occuper ?

Continuez votre bon travail les gars!

À votre santé

J'aimerais voir un gestionnaire HTTP POST générique, qui est simplement déclenché dès qu'une alerte est lancée. Je pense que la plupart des administrateurs peuvent rapidement créer quelque chose qui est capable d'accepter HTTP, puis de faire tout ce qu'ils doivent faire avec (l'envoyer à nagios, riemann, younameit)

donc si une alerte se déclenche (disons "web123 a un processeur inactif critique !, valeur 1 inférieure au seuil 15") et que nous effectuons une publication http de ces données, comment géreriez-vous cela dans nagios ? vous voulez dire que nagios le prendrait en compte comme un contrôle de service passif, puis nagios enverrait les notifications?

En parlant d'alerte via grafana, prévoyez-vous d'ajouter quelque chose comme la détection de battement ? Ou est-ce quelque chose dont le système de contrôle externe devrait s'occuper ?

c'est aussi quelque chose auquel nous devons réfléchir davantage. Cela peut devenir compliqué et si les gens utilisent quelque chose comme pagerduty ou flapjack, ils peuvent l'utiliser pour agréger des événements / supprimer les doublons. Notez également que parce que vous pourrez définir des alertes sur des expressions de requête de métriques arbitraires, vous aurez beaucoup de pouvoir pour prendre en compte les données passées dans l'expression réelle, et ainsi vous pouvez créer un signal plus robuste dans l'expression qui ne change pas d'état aussi souvent.

donc si une alerte se déclenche (disons « web123 a un processeur inactif critique !, valeur 1 inférieure au seuil 15 ») et que nous effectuons une publication >http de ces données, comment géreriez-vous cela dans nagios ? vous voulez dire que nagios le prendrait en compte comme un contrôle de service passif, puis nagios enverrait les notifications ?

Type de. En fait, j'attends avec impatience l'alerte de grafana pour me débarrasser des nagios. En utilisant le gestionnaire HTTP, vous devez configurer des contrôles passifs pour que nagios puisse y soumettre les résultats. Mais j'aimerais avoir grafana comme seule source où vous pouvez configurer les alertes. Dans notre cas, les personnes autorisées à ajouter des alertes sont le véritable administrateur système qui configurerait également les vérifications dans nagios.

Avec le gestionnaire http, grafana aurait tout ce dont nous avons besoin pour cela : un tableau de bord pour une surveillance en temps réel, une API, une configuration facile des alertes et un gestionnaire http où nous pouvons transmettre les alertes à notre système de notification interne.

À votre santé

Bien que je puisse voir la logique de cette stratégie d'intégration, je ne peux m'empêcher de penser que c'est un peu exagéré. D'après ce que je comprends (et ce que j'ai pu lire dans le fil), la seule raison pour laquelle la plupart des utilisateurs de Grafana continuent d'utiliser une technologie d'alerte autonome est que Grafana n'en propose pas. Donc, il ne serait pas plus « maigre » de se concentrer d'abord sur la partie Alerte Grafana, et de la développer en tant que composant qui communique avec le reste de la pile via l'API, afin que d'autres contributeurs puissent imiter le comportement et créer adaptateurs spécifiques plus tard?

tl;dr : en se concentrant d'abord sur la construction de ses propres « batteries », Grafana disposerait d'un système d'alerte complet, qui peut ensuite évoluer vers un service d'intégration avec des outils d'alerte tiers.

Petite préoccupation, si cela n'a pas été réglé. Le système d'alerte traditionnel ne s'adapte pas bien à l'infrastructure cloud, car les ressources sont très dynamiques (provisionnées et détruites). Les alertes sur les métriques doivent prendre en charge la fonctionnalité de tentation ou de regroupement (avec le remplacement des exceptions, les charges de travail sont parfois différentes). Une alerte modélisée ou groupée doit pouvoir découvrir un nouvel ensemble de groupes.

Merci pour la mise à jour! Dans mon cas d'utilisation, les alertes intégrées dans Grafana sont tout ce dont j'aurais besoin pour le moment. J'ai attendu patiemment avec impatience l'alerte de Grafana.

Comme promis dans IRC, voici notre cas d'utilisation :

Nous avons une ancienne application Rails qui searches our logs pour patterns et a un
API HTTP pour répondre si un certain pattern a croisé c'est thresholds et
a donc le statut {OK,WARNING,CRITICAL} .

Threshold peut être soit :

• un status de CRITICAL si pattern existe.
• que status est WARNING si pattern est trouvé plus de X fois
  et status est CRITICAL s'il est trouvé plus de Y fois.
• si pattern moins d'une heure alors le status est OK ,
  moins de 3 heures status est WARNING et sinon status est
  CRITICAL .

Si je comprends bien cette fonctionnalité, Grafana prendra en charge cette utilisation
pattern (via Logstash et Elasticsearch bien sûr) lorsque cette fonctionnalité et
la source de données Elasticsearch est-elle entièrement implémentée ?

@Dieterbe @mattttt tes diapositives et maquettes sont absolument incroyables ! C'est vraiment un changeur de jeu.
Pour moi, le gestionnaire d'alertes interne Grafana conviendrait le mieux à nos besoins.
Les raisons:

• Libre-service - Très important . Nos utilisateurs ont dit haut et fort qu'ils souhaitaient créer eux-mêmes des alertes de bout en bout dans Grafana.
• Flux de travail unifié - Je veux minimiser les pièces mobiles et non les augmenter. Comme @Dieterbe l'a souligné, un gestionnaire d'alertes tiers nécessiterait au moins 4 étapes alors qu'un gestionnaire d'alertes interne n'en nécessiterait que 1 (peut-être 2 si vous devez définir une méthode de notification pour chaque seuil ? - incertain de la présentation).
• Intégration étroite et aucune dépendance vis-à-vis d'une infrastructure d'alerte tierce.

Quelques soucis :

• Quels sont les seuils de contrôle de fréquence ?
• Comment gère-t-il une fréquence d'interrogation trop rapide pour récupérer les données ? Journal, alerté et mis en file d'attente ou abandonné ?
• Pour la mise à l'échelle, nous craignons que Grafana ne soit pas en mesure de suivre le nombre de vérifications, la fréquence rapide et surtout la latence entre les sources de données que nous devrons probablement ajouter / mettre à l'échelle des serveurs Grafana pour prendre en charge les alertes internes. Je le sais car nous avons besoin de plusieurs instances de gestionnaire d'alertes tierces maintenant. Dans ce cas, comment pourrions-nous affecter ou mettre en file d'attente des vérifications de seuil de manière transparente parmi un cluster de serveurs Grafana, en particulier si les vérifications proviennent de la même source de données ? À partir d'une expérience utilisateur, j'aimerais que les utilisateurs créent de manière transparente des seuils via un cluster de serveurs Grafana à charge équilibrée sans que les utilisateurs ne se rendent à une instance "attribuée" particulière de Grafana pour un contrôle particulier.
• Pour les notifications, cela prendrait-il en charge une sorte d'architecture de plug-in afin que les notifications puissent être facilement développées et intégrées ? En général, nous avons besoin de quelque chose qui puisse effectuer des HTTP POST. C'est le plus courant avec PagerDuty, xMatters, VictorOps, Opsgenie, etc. Chacun nécessite un format, une authentification, etc. légèrement différent. Comme mentionné précédemment dans ce fil, peut-être qu'un gestionnaire HTTP POST générique fonctionnerait qui enverrait à un service HTTP personnalisé capable de faire ce que vous voulez avec. Alternativement, une capacité de script personnalisé devrait également fonctionner.
• Je suppose que des seuils pourraient être définis, récupérés et obtenir des violations via une API ? je pense que ce serait utile

Je pense qu'il est idéal de pouvoir intégrer l'alerte dans les systèmes d'alerte existants. Il y a des problèmes difficiles et laids comme la détection des volets comme mentionné qui ont été traités et il semble inutile de tout réinventer depuis le début. Je détesterais voir cela enterré sous le poids du fluage des fonctionnalités.

Mais je ne pense pas que cela doive vraiment être une intégration étroite dans tous ces gestionnaires d'alertes. Une bonne API bien documentée devrait permettre aux personnes familiarisées avec ces systèmes de s'intégrer avec peu d'effort. Donc, la diapositive avec 'grafana api -> handler' est ce qui me semble attrayant.

Scott

Salut à tous -- J'arrive tard dans cette discussion, mais j'ai une certaine expertise sur ce sujet, et je suis le développeur principal de l'un des outils qui a tenté de résoudre le problème d'alerte. Notre outil, StatsAgg est comparable à des programmes comme bosun. StatsAgg vise à couvrir les alertes flexibles, les suspensions d'alertes et les notifications et est assez mature/stable à ce stade (bien que l'API ne soit pas prête).

Quoi qu'il en soit, quelques réflexions au sujet de l'alerte :

• Alerter par des métriques individuelles est nul. Je travaille dans une entreprise qui gère des milliers de serveurs, et devoir créer/configurer/gérer des alertes séparées pour chaque série métrique de « % d'espace disque libre » est logistiquement irréalisable. Les outils de surveillance d'entreprise lient souvent plusieurs séries de mesures avec des expressions régulières (ou simplement des expressions génériques). StatsAgg a été construit sur le même principe ; plusieurs séries de métriques sont liées ensemble, puis le groupe de métriques voit les vérifications de seuil d'alerte exécutées par une seule « alerte ». À grande échelle, ce type de capacité est une nécessité.
• Si l'on accepte mon affirmation précédente selon laquelle un outil d'alerte ne doit pas alerter sur des métriques individuelles, il s'ensuit que l'outil doit disposer d'un mécanisme pour obtenir rapidement une liste de métriques éligibles et des valeurs de métriques. De nombreux outils s'appuient sur les magasins de données d'interrogation pour obtenir la liste des métriques et des valeurs métriques, et cette solution ne fonctionne franchement pas très bien à grande échelle. La logique d'alerte, de par sa nature, doit s'exécuter souvent (toutes les X secondes, ou au fur et à mesure que chaque nouveau point de données qualifié arrive). Les magasins de données (graphite, opentsdb, influxdb, etc.) n'ont tout simplement pas été conçus pour gérer les requêtes constantes de « donnez-moi la liste actuelle des métriques conformes à ce modèle » et « montrez-moi les dernières valeurs X pour ces métriques Y ». Soit ils n'ont pas le langage d'API/de requête approprié, soit ils ne peuvent tout simplement pas gérer la charge. Pour être clair, je parle d'échelles d'exécution de logique d'alerte par rapport à 10 000 séries de métriques lorsqu'il y a 10 000 000 de séries de métriques disponibles dans le magasin de données. Ce n'est pas le cas d'utilisation de tout le monde, mais c'est celui de mon entreprise.
• J'ai découvert que résoudre le problème via le traitement de flux est le seul moyen viable de résoudre les problèmes soulevés par mon dernier point. C'est pourquoi StatsAgg a été conçu pour s'asseoir devant le magasin de données. La logique d'alerte peut s'exécuter sur les métriques sans toucher à la banque de données, et les métriques passent simplement par la banque de données. Les principaux concepts de cette approche sont que 1) les alertes nouvellement créées ne peuvent pas/n'utiliseront pas les valeurs de métriques anciennes/archivées pour l'évaluation des alertes 2) si le programme de traitement de flux (ex-StatsAgg) plante, alors les points de données ne le font pas dans la banque de données 3) les valeurs métriques nécessaires à l'évaluation des alertes sont stockées en mémoire, ce qui peut constituer un problème de stabilité du serveur. 4) le programme de traitement de flux doit être capable de déconstruire et reconstruire les métriques entrantes (ce qu'InfluxDB n'a pas rendu facile au cours de la dernière année...). Même avec ces vanités, cette solution a très bien fonctionné pour mon entreprise, et à très grande échelle. Parfois, nous avons eu plus de 200 000 séries de métriques en direct, des moyennes de plus de 30 000 métriques entrantes/s, des centaines d'alertes qui évaluent des milliers de séries de métriques et un serveur exécutant StatsAgg qui transpire à peine. Pendant tout ce temps, la banque de données n'est pas interrogée du tout.

Ce sont les principales choses que je voulais mentionner. L'alerte comporte également de nombreux autres aspects importants (notifications, suspensions, etc.), mais ces solutions sont faciles à intégrer une fois que l'architecture du problème central est résolue. Je me rends compte que l'échelle de nos besoins n'est pas la même que celle de l'utilisateur moyen, mais j'espère que vous pourrez tous apprécier cette perspective.

Je voudrais suggérer de lancer avec un gestionnaire de notifications qui peut envoyer des données à Alerta : https://github.com/guardian/alerta

Alerta a une API REST très saine pour recevoir des notifications.

Je préfère une mise en œuvre lean grafana uniquement !
Je pense qu'il vaut la peine de réévaluer après que tout le monde a eu l'expérience de cette fonctionnalité dans le fantastique Grafana UX typique.

Il y aura de nombreux cas complexes et/ou systèmes backend personnalisés avec lesquels les gens voudront s'intégrer. Vous pouvez en voir beaucoup sur ce fil, principalement open source, mais il y a aussi tellement de produits commerciaux ! Ne vous embêtez pas avec les gestionnaires individuels - ce sera un rat entier et vous serez toujours en mode capture

Je conseillerais fortement de n'implémenter que deux types de gestionnaires. L'un est certainement HTTP POST, ce sera l'outil le plus polyvalent et le plus flexible. L'autre est un script personnalisé, afin que les utilisateurs puissent mettre en œuvre l'intégration avec l'outil spécifique de leur choix. Le modèle de plugin n'est pas mauvais, mais il oblige à utiliser un langage de plugin spécifique qui est limitatif. Les scripts externes sont meilleurs - tant que vous transmettez à un script tous les détails, le script peut être écrit dans n'importe quel langage - script shell, Python, etc.

Je suis avec @007reader

Je suis d'accord. Tant que les méthodes d'intégration communes sont fournies, l'implémentation personnalisée peut être un projet ou un déploiement distinct.

Par exemple, la récente version de CloudWatch est décente, mais j'aimerais en faire un projet distinct en utilisant uniquement des métriques sélectionnées synchrones vers un stockage alternatif. Cela nous donnera une rétention complète au lieu de seulement 2 semaines de données.

Salut tout le monde,
ma vidéo de présentation grafanacon est en ligne !
c'est sur https://www.youtube.com/watch?v=C_H2ew8e5OM
Je pense que ça va s'éclaircir beaucoup, mais comme vous pouvez le voir. les spécificités des intégrations doivent encore être déterminées et c'était également un sujet dont beaucoup de gens voulaient discuter. (même si le temps était limité et j'ai demandé aux gens de continuer la conversation ici pour que tout le monde puisse participer)

@simmel oui exactement. vous utiliseriez une requête ES et définiriez une règle à ce sujet.
@activars concernant le regroupement et la découverte, je pense que cela dépendra en grande partie de votre source de données, mais les exigences les plus courantes doivent être satisfaites si vous utilisez quelque chose comme le graphite ou l'ES qui, je le sais, sont très bons pour la "découverte automatique" de métriques/séries inédites /documents qui correspondent à l'expression donnée (avec caractères génériques) pour graphite ou requête (pour ES). pas sûr des autres sources. votre commentaire sur la nécessité d'appliquer des exceptions aux règles est plus délicat, nous devrons probablement y remédier à un moment donné, mais je pense que cela peut attendre que les choses soient plus claires et plus réglées. peut-être que nous pouvons éviter d'avoir besoin de cela d'une manière ou d'une autre.
La fréquence
@sknolin si je comprends bien, à votre avis, grafana ferait la planification des alertes, l'exécution, les crochets de notification de déclenchement, etc., même en utilisant un autre système comme nagios/bosun. alors quel serait exactement le rôle du système externe (nagios/bosun/...) . cela semble également similaire à ce dont parlait
@ jds86930 StatsAgg semble assez intéressant. Je pense qu'ici aussi une intégration avec grafana aurait du sens. Je pense que le traitement de flux est une approche valide qui a sa place comme alternative aux requêtes répétées. mais ce dernier est juste plus simple pour commencer et juste plus simple en général je pense. Mais les deux devraient être pris en charge. Alors oui, dans grafana, vous pourrez configurer des modèles/requêtes qui correspondent à un spectre de données, et potentiellement couvrir de nouvelles séries/données au fur et à mesure qu'elles deviennent actives. à notre avis, cependant, vous tireriez simplement parti de toutes les fonctionnalités de votre source de données (par exemple, le graphite est assez bon pour cela avec ses caractères génériques, ses expressions globales, etc. utilisez simplement StatsAgg pour résoudre ce problème. Êtes-vous en train de dire que grafana elle-même devrait faire quelque chose de spécifique ici ? Je pense que si votre source de données n'est pas assez rapide, résolvez le problème de la source de données. obtenez quelque chose de plus rapide, qui a une mise en cache pour les métadonnées métriques, peut-être un serveur de mémoire en amont ou un traitement de flux. mais de toute façon en ce qui concerne Grafana, cela ne changerait pas grand-chose à quoi je puisse penser?
@blysik oui a l'air intéressant. tant d'outils d'alerte que nous devrions intégrer :) pour être clair, aimez-vous l'idée de gérer les règles d'alerte et de les visualiser dans grafana comme elles ont été présentées jusqu'à présent, mais vous souhaitez utiliser alerta pour vous occuper des notifications ? alerta serait le principal endroit où vous allez examiner l'état de vos alertes (cela semble être une chose raisonnable à faire), mais je veux m'assurer que je comprends parfaitement comment vous voyez l'intégration.

@007reader , @shanielh , @activars juste pour être clair, cette intégration via un post ou un script HTTP générique, quel serait le but. pour dire au système externe "il y a une nouvelle règle, voici la requête, les seuils, la fréquence, etc. maintenant allez s'il vous plaît l'exécuter" ? ou grafana serait-il la chose qui exécuterait les règles et mettrait ensuite à jour les systèmes externes avec un nouvel état ?

@blysik oui a l'air intéressant. tant d'outils d'alerte que nous devrions intégrer :) pour être clair, aimez-vous l'idée de gérer les règles d'alerte et de les visualiser dans grafana comme elles ont été présentées jusqu'à présent, mais vous souhaitez utiliser alerta pour vous occuper des notifications ? alerta serait le principal endroit où vous allez examiner l'état de vos alertes (cela semble être une chose raisonnable à faire), mais je veux m'assurer que je comprends parfaitement comment vous voyez l'intégration.

Correct. Alerta s'annonce comme notre hub de notifications. Toutes sortes de choses y envoient des alertes. Par exemple : des scripts personnalisés, Cabot, Zenoss, vCenter et peut-être Grafana. Cela donne aux ops un seul endroit pour voir toutes les alertes. Et puis c'est le seul endroit qui envoie les notifications à l'ingénieur de garde.

@sknolin https://github.com/sknolin si je comprends bien, dans votre
vue, grafana ferait la planification des alertes, l'exécution, le déclenchement
crochets de notification, etc., même lorsque vous utilisez un autre système comme
nagios/bossun. alors quel serait exactement le rôle du système externe
(nagios/bosun/...) . cela semble également similaire à ce que @Crapworks
https://github.com/Crapworks parlait.

Je suppose que je n'ai pas bien expliqué. Ce n'est pas ce que je voudrais, grafana non
faire tout ça. @Crapworks (c'est amusant à taper) parle passif
contrôles de service, j'utiliserais simplement l'interrogation active.

Donc, tout ce que je voudrais, c'est une API où je peux lire l'état des alertes grafana.
Les systèmes externes font tout le reste.

Cela ne veut pas dire que s'il ne s'est pas développé d'une manière ou d'une autre en un grand général
outil d'alerte, je ne l'utiliserais pas. Juste ce que je ferais maintenant.

Scott

@sknolin

Donc, tout ce que je voudrais, c'est une API où je peux lire l'état des alertes grafana.

comment ce statut serait-il mis à jour dans grafana ? quel processus exécuterait les alertes et mettrait à jour le statut dans grafana ?

Chaque fois qu'il est interrogé, grafana met à jour le statut d'alerte, avec une sorte d'intervalle de mise en cache pour gérer plusieurs systèmes qui l'interrogent.

Je vois le point que cela nécessite toujours que grafana fasse la logique pour les alertes et la présente. Alors en y réfléchissant, non, je n'ai besoin d'aucune alerte.

Je pense que je pourrais faire toutes les alertes nécessaires si je pouvais récupérer la valeur actuelle d'une métrique sur un panneau graphique. Par exemple, lorsque nous dérivons un taux de la somme de plusieurs métriques de compteur et que nous le représentons graphiquement, il serait bien d'interroger la valeur actuelle avec le système de surveillance. C'est peut-être tout à fait faisable maintenant et je suis juste obtus.

Scott

@Dieterbe Ce dernier :

grafana soit la chose qui exécute les règles, puis met à jour les systèmes externes avec un nouvel état

@Dieterbe Je suis d'accord pour dire que l'interrogation de la source de données (Graphite, OpenTSDB, etc.) à l'aide de la syntaxe de requête native de la source de données est la plus simple/la plus facile et est probablement le moyen le plus rapide d'obtenir une forme d'alerte native dans Grafana. Pour beaucoup de gens, ce genre de solution répondra à leurs besoins, et je pense que c'est la meilleure solution pour l'implémentation initiale de Grafana (à mon avis). Mon point principal était qu'il existe un plafond sur la configurabilité et les performances des alertes qu'il sera difficile de dépasser avec le modèle « interrogation de la source de données ».

En termes d'orientations que Grafana pourrait suivre pour des solutions d'alerte à long terme, je pouvais voir quelques options :

• Travaillez avec les responsables de la banque de données pour créer des API plus rapides/meilleures spécialement conçues pour le cas d'utilisation des alertes. Je n'aime pas cette option car bon nombre de ces projets évoluent à un rythme plus lent (de quelques mois à plusieurs années) et ils peuvent ne pas accepter certaines/toutes les demandes d'amélioration. Ils voudront probablement aussi coder dans la langue native de leurs magasins de données, qui ne sont pas toujours des langages rapides (ex-Graphite en python).
• Créez des couches de traitement de flux/mise en cache pour chaque banque de données en tant que projets de réservoir de pluie distincts. Je pense que cela aurait finalement un meilleur résultat que d'essayer d'amadouer les différents responsables de la banque de données pour qu'ils créent des solutions pour leurs projets. Cela vous permettrait également de continuer à développer le travail que vous faites déjà (en utilisant les mécanismes de requête de banque de données existants). Vous pouvez même créer vos propres API personnalisées dans les couches de traitement de flux/mise en cache qui pourraient simplifier la syntaxe de requête de Grafana pour le magasin de données.
• Restez fidèle à la solution native sur laquelle vous travaillez et faites-la bien fonctionner. Des outils tiers tels que StatsAgg, bosun, etc. seront disponibles pour les cas d'utilisation plus exigeants/spécialisés/complexes. L'intégration de Grafana à ces outils serait certainement un avantage supplémentaire pour l'utilisateur, mais cela ajouterait une complexité non négligeable à Grafana. Cela dit, il semble que vous puissiez finir par le faire de toute façon (je regarde actuellement « Alerting Backends » sur la diapositive 35 de votre présentation). Je suis personnellement ouvert à la mise en œuvre d'un ensemble d'API compatibles avec Grafana dans StatsAgg ; nous aurions juste à comprendre ce que sont les API et à rédiger une documentation sur le protocole API. N'hésitez pas à m'envoyer un message/un e-mail si vous souhaitez en discuter.

Salut tout le monde,

@Dieterbe Je viens de regarder votre présentation et le truc a l'air génial. J'apprécie vraiment que vous essayiez de créer un système d'alerte de la "bonne" manière, en utilisant beaucoup de contributions de la communauté ! Merci!

Je veux aussi être un peu plus clair, car je ne pense pas que ce que j'essayais de dire était évident. Je _NE PAS_ demander à grafana d'être au courant de tout autre système de surveillance comme Nagios, Icinga, Bosun, etc. En fait, je n'ai besoin que de ceci :

• L'interface utilisateur géniale que vous avez montrée dans votre présentation ou à quoi cela ressemble quand elle est complètement terminée
• Un gestionnaire HTTP POST générique (comme d'autres personnes ici également suggéré) qui est complètement configurable (je vous donnerai un exemple plus tard)

Le flux d'événements auquel je pense :

• Vous visualisez vos données dans grafana
• Vous ajoutez des seuils d'alerte dans grafana
• Dès qu'un seuil est dépassé, le gestionnaire HTTP POST est déclenché
• A partir de là, le travail de grafanas est fait

Comme @mgravlin et @007reader mentionnés, la plupart des services de notification et d'alerte utilisent HTTP POST, nécessitant différents types de données. Donc, la chose la plus générique à laquelle je puisse penser est de laisser l'utilisateur définir ses données et en-têtes POST, afin que vous puissiez alimenter plusieurs systèmes avec un seul gestionnaire, en utilisant différents modèles. Exemple de pseudo-code :

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

Donner à l'utilisateur suffisamment de variables à utiliser ici sera suffisamment puissant pour alimenter une tonne de backends.

Et encore une fois, avec ce type de gestionnaire, tout administrateur système ayant des connaissances en codage peut créer son propre récepteur de publication http et transformer la façon dont il aime, par exemple, alimenter des backends qui ne comprennent pas la publication http.

Comme il s'agit d'un apatride, il évolue également. Placez simplement un équilibreur de charge devant le backend/api/whatever et vous êtes prêt à partir.

Au moins, cela résoudrait la plupart/presque tous mes problèmes ;)

À votre santé

Merci d'avoir créé cette fonctionnalité. Existe-t-il une date de sortie approximative ?

Torkelo a dit ENVIRON 3 mois sur IRC.
Si je l'ai bien compris, c'est une estimation vraiment approximative et doit être traitée comme telle.

Je suis ravi de pouvoir faire des alertes avec grafana. Je pense que c'est la seule caractéristique qui empêche grafana d'être l'outil de surveillance ultime.

Si vous avez une version alpha/bêta précoce, j'aimerais tester et donner des commentaires précoces avec les données de production.

++

moi 2 lol

+1

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

Si vous avez une version alpha/bêta précoce, j'aimerais tester et donner tôt
rétroaction avec les données de production.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
Si vous avez une version alpha/bêta précoce, j'aimerais tester et donner des commentaires précoces avec les données de production.

+1 moi 2

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

+1
Si vous avez une version alpha/bêta précoce, j'aimerais tester et donner tôt
rétroaction avec les données de production.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-158661279 .

+1

super de voir tous les +1 mais FWIW ils ne sont pas vraiment nécessaires. nous savons déjà que c'est la nouvelle fonctionnalité la plus attendue, et une fois que nous aurons des progrès tangibles, le code apparaîtra dans une branche séparée avec laquelle tout le monde peut jouer. D'ailleurs, nous amenons également plus de personnes à travailler à temps plein sur grafana, alors restez à l'écoute tout le monde :)

Oui s'il vous plaît, il y a 484 personnes qui "regardent" ce numéro. Chaque fois que vous le "+1", 484 personnes reçoivent une notification par e-mail. Abonnez-vous simplement à la notification et cela indiquera votre intérêt pour le problème.

+1 > ; P

Le lundi 30/11/2015 à 10:33:52-0800, Vadim Chekan a écrit :

Oui s'il vous plaît, il y a 484 personnes qui "regardent" ce numéro. Chaque fois que vous le "+1", 484 personnes reçoivent une notification par e-mail.

Désolé, je sais que vous travaillez très dur là-dessus. Y a-t-il un délai pour la première version ?

Je serais plus qu'heureux de pouvoir configurer des métriques et des seuils d'alerte (via l'interface Web ou l'API) et un cronjob/démon Grafana qui vérifie ces métriques et effectue un HTTP POST avec JSON ou invoque un script avec JSON dans stdout. Il serait _extrêmement_ simple pour les individus d'écrire un simple script python qui transmette ces informations à Pagerduty, Slack, IRC, SMS, e-mail ou autre.

Bien que j'apprécie grandement la commodité, je ne pense pas que ce soit le travail de Grafana de s'intégrer étroitement avec des outils tiers, et je préférerais voir une implémentation minimaliste plus tôt qu'une implémentation bien étoffée plus tard.

Je suis tout à fait d'accord avec @anlutro . Veuillez fournir quelque chose de simple pour commencer. Le plus intéressant pour moi est de permettre aux gens de paramétrer eux-mêmes des alertes simples (self-service). Grafana ne devrait pas essayer de remplacer les solutions d'alerte/d'escalade existantes.

Je suis également d'accord avec @anlutro . Mais au lieu de simplement fournir une API simple, ayez plutôt la partie alerte capable de gérer les plugins personnalisés qui interagissent avec l'API. De cette façon, le package de base pourrait inclure l'e-mail, le pagerduty et quelques autres, puis la communauté pourrait y ajouter si nécessaire. Semblable à la façon dont les plugins Logstash sont gérés maintenant.

+1

Des nouvelles du système d'alerte ? Des estimations ?

+1

+1
Il convient de mentionner le fonctionnement du mécanisme de hits et d'hystérésis sur les alertes collectd en tant que concept à considérer.

Avez-vous pensé à des fonctionnalités d'alerte avancées telles que la détection d'anomalies, la détection de corrélation, la détection de cause première, etc. ?

+1. Alerte en tant que sous-système de plugin - ce serait la solution la plus flexible. Pas besoin d'ajouter autant de fonctionnalités dans grafana s'il existe de nombreux projets qui peuvent mieux le faire en backend.

@Dieterbe @torkelo Ce serait formidable d'avoir même une "estimation" très approximative à ce sujet. Personnellement, j'ai tenu bon car les alertes en libre-service basées sur des métriques sont une fonctionnalité indispensable dans mon cas et je suis convaincu que Grafana est la bonne interface utilisateur pour cela. Le problème, c'est que cela fait maintenant 6 mois et qu'il n'y a eu aucune mise à jour de l'ETA ou même un commentaire de l'un d'entre vous depuis un bon moment, donc je commence à avoir des pensées contre-productives "Je vais devoir pirater quelque chose". ..Si je pouvais juste savoir si cela va prendre encore 6 mois au lieu de quelques semaines de plus, je pourrais prendre une décision beaucoup plus éclairée.

Merci!

+1
Le 18 janvier 2016 à 21h54, "Jaime Gago" [email protected] a écrit :

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo Ce serait formidable d'avoir même un très rude
« estimation » à ce sujet. Personnellement, je m'accroche depuis les métriques
l'alerte en libre-service est une fonctionnalité indispensable dans mon cas et je suis
convaincu que Grafana est la bonne interface utilisateur pour cela. Le problème c'est que c'est maintenant
6 mois et il n'y a eu aucune mise à jour de l'ETA ni même un commentaire de l'un des
vous pendant un bon moment donc je commence à avoir "Je vais juste devoir
pirater quelque chose" pensées contre-productives... Si je pouvais juste savoir si c'est
va être encore 6 mois contre quelques semaines de plus je pourrais faire beaucoup
décision mieux informée.

Merci!

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-172722684 .

+1

+1

@jaimegago vraiment désolé de ne pas avoir mis à jour ici nos progrès ou notre manque de progrès sur ce problème. Nous pensions que nous aurions du temps à consacrer à cela, mais cela finissait toujours par être poussé parce que quelque chose de plus haute priorité se présentait.

En septembre, j'ai commencé à travailler sur le support des sources de données Elasticsearch qui est devenu la base d'une version 2.5 axée sur les sources de données, après cela le problème le plus noté dans Grafana depuis la v1 était un panneau de table, et surtout après le support Elasticsearch, j'ai ressenti une petite version avec une table panneau était plus important que l'alerte, ce qui est devenu le fondement de 2.6.

Dernièrement, de nombreux utilisateurs et entreprises souhaitent s'intégrer davantage à Grafana, ce qui nous a incités à travailler sur l'amélioration de l'API et des capacités du plugin, ce qui a entraîné un autre report pour ce problème. Je suis vraiment désolé que nous ayons si mal communiqué cela. Nous avons toujours eu l'ambition de démarrer SOON, mais SOON a été poussé encore et encore :(

Mais il y a de l'espoir ! Nous avons élargi l'équipe à plein temps dédiée à Grafana, en décembre @bergquist nous a rejoint et en février, nous aurons à nouveau du renfort. Je ne peux pas offrir d'ETA mais c'est toujours un problème hautement prioritaire et nous voulons commencer dès que possible. Nous voulons que cette fonctionnalité soit la principale fonctionnalité de Grafana 3.0.

@torkelo Merci pour la mise à jour ; Je ne peux pas dire que je suis heureux, mais au moins nouveau, nous savons où nous en sommes.

Une question restante est de savoir si 2.x recevra plus de versions intermédiaires ou si 3.x sera la prochaine version. ;)

@RichiH concernant une autre version intermédiaire avant 3.0 sera publiée en février.

@torkelo Merci beaucoup d'avoir pris le temps de fournir une mise à jour détaillée.

peut-être que cela est déjà sur la feuille de route, sinon, veuillez envisager d'ajouter le "POST" dès la notification.
Nous pouvons donc envoyer l'alerte à différents systèmes pour les traiter, comme kafak

+1 pour les notifications SNMP !

+1 Je pense que c'est la plus grande fonctionnalité manquante de Grafana pour en faire un outil de surveillance viable (et le meilleur de sa catégorie) pour la production.

+1

Un administrateur (@Dieterbe ?) disponible pour verrouiller les commentaires sur ce problème de la part d'un non-collaborateur ? Nous n'obtiendrons donc que du contenu intéressant sur l'avancée des fonctionnalités, et pas ces +1 inutiles...

Si vous ne connaissez pas cette fonctionnalité, voici le lien vers la doc ad hoc GitHub .

Merci :coeur:

@Mayeu euh, en tant que l'un des "non-collaborateurs" qui a contribué avec plus d'un +1 à ce problème et dans d'autres endroits, je ne pense pas que verrouiller ce problème aux collaborateurs soit la voie à suivre. Créez simplement un filtre intelligent sur votre e-mail ;-).

Je pense aussi que les +1 remplissent un but, montrant le montant et la répartition des intérêts pour cela (et ailleurs).
Ce qui manque, peut-être, c'est un bouton +1 dans l'interface utilisateur qui remplirait le même rôle, mais sans toutes les notifications à tous les abonnés.. donc une demande de fonctionnalité pour @github.

Nous nous éloignons du sujet et c'est la première et la dernière fois que j'écris à ce sujet.

Toute personne intéressée par ce numéro doit s'inscrire en haut à droite ; il vous tiendra informé et vous n'enverrez pas d'e-mail à tout le monde.

En ce qui concerne un système de vote pour empêcher l'accumulation de +1, voir https://github.com/dear-github/dear-github - 27 jours périmés et aucune réaction de GitHub.

+1

Des nouvelles à ce propos ?

Je ne pense pas qu'il y ait encore de nouvelles à ce sujet. Mais une bonne chose à propos de la prochaine version de Grafana est :

Grafana sera capable de gérer des applications/plugins personnalisés. Ensuite, nous pouvons écrire nos propres plugins/applications d'alerte personnalisés et les importer dans Grafana. L'écriture de ces petites applications/plugins sera une victoire rapide en attendant une grande fonctionnalité d'alerte.

J'aime l'idée de configurer les alertes au même endroit que la visualisation. Des moqueries incroyables sur https://www.youtube.com/watch?v=C_H2ew8e5OM mais y a-t-il des dates de sortie ?

belle vidéo, merci !

quelques retours.

je suis satisfait de l'idée de seuils linéaires simples et de requêtes personnalisées avancées

notificateurs les plus utiles :

• exec - pourrait utiliser quelque chose comme ssh ou sendmail
• webhooks - l'utilisateur peut lever un webcgi pour ramasser des web-hooks pour faire des choses...
• email - lance un simple e-mail avec un dump json des données de notification.
• plugins... pas vraiment nécessaires

api pour extraire l'état des alertes... semble être une mauvaise idée,
Cependant, l'API pour extraire la configuration d'alerte dans un format json de base pourrait être agréable.
ce dump json pourrait être transformé en quelque chose que d'autres systèmes pourraient trouver utile de transformer.

Je ne sais pas si cela est mal vu ou non. Impossible de trouver un lien de don nulle part, mais quel type de contribution serait nécessaire pour l'intégrer à la v3 d'ici la fin du mois.. Nous pourrions vraiment utiliser cette fonctionnalité, mais nos ressources sont attachés au guichet automatique

+1

+1

C'est une fonctionnalité indispensable pour nous ici à Work Market.

Les alertes présentées sont-elles lancées ?

Non
Le jeu. 25 février 2016 à 23h13, kskaran94 [email protected] a écrit :

Les alertes présentées sont-elles lancées ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-189143056 .

Serait-il prudent de supposer que la fonctionnalité d'alertes sera publiée cet été ?

_le suspense s'intensifie_
Le 26 février 2016 à 10h23, "Ian Ha" [email protected] a écrit :

Serait-il prudent de supposer que la fonction d'alertes sera publiée dans le
l'été?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-189320869 .

Des nouvelles à ce propos?

+1

+1 serait bien de l'avoir déjà, les gens attendent déjà toute l'année ou même plus.

:+1: J'aime ça. Merci pour la vidéo et la présentation, @Dieterbe. Est-il disponible pour les tests/les premiers utilisateurs ?

@torkelo Vous avez annoncé

Nous voulons que cette fonctionnalité soit la fonctionnalité principale de Grafana 3.0

Mais en regardant le journal des modifications de la branche 3.0 non publié (1), aucune mention n'est faite d'alerte, dois-je commencer à pleurer ou est-ce que le plan est toujours d'avoir Alerte la fonctionnalité de titre 3.0 ?

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

Nous avons pris la décision de développer le système de plugins pour grafana 3 afin de pouvoir publier grafana 3, puis de commencer à travailler sur les alertes, au lieu de reporter inutilement grafana 3.

@Dieterbe Je ne peux pas dire que je suis heureux, mais cela a du sens. Le suivi évident est de savoir s'il y a quelque chose d'ETA pour alerter ; et s'il s'agit d'une fonctionnalité confirmée et engagée pour 3.1.

De plus, comme solution de contournement, http://alerta.io/ fait une partie de ce que je veux que Grafana fasse ; les personnes qui attendent cette fonctionnalité voudront peut-être l'essayer.

Y a-t-il une spécification pour le plugin? Il serait peut-être bon de construire quelque chose dans le
communauté pour gérer les alertes pour coïncider avec la sortie de la version 3 ?

Beth
Le 16 mars 2016 08:44, "Richard Hartmann" [email protected]
a écrit:

@Dieterbe https://github.com/Dieterbe Je ne peux pas dire que je suis heureux, mais ça
a du sens. Le suivi évident est s'il y a quelque chose d'ETA pour
alerte ; et s'il s'agit d'une fonctionnalité confirmée et engagée pour 3.1.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe Je pense qu'il serait également bien d'avoir la possibilité de créer une notification côté client. Par exemple, des messages vocaux sur un moniteur public avec un tableau de bord, vous n'avez donc pas besoin de regarder le tableau de bord pour savoir qu'il y a un problème. Comme les alertes sonores Zabbix. À cette fin, j'ai écrit un code JavaScript simple qui scanne un tableau de bord particulier et s'il y a des problèmes, il m'en informe à l'aide de l' API Web Speech . Pour l'instant ça marche très bien pour moi.

Qu'en est-il de l'utilisation de Kapacitor comme backend pour les alertes, leur langage de script est simple et vraiment puissant ? Ou qu'en est-il de la prise en charge de plusieurs backends d'alerte et de l'abstraction à ce sujet.

Maintenant que 3.0 est sorti, je suis vraiment ravi d'avoir des alertes dans grafana. L'alerte fera de grafana l'outil ultime.

Salut @Dieterbe ,

Comme je peux le voir sur cette version https://github.com/raintank/grafana (dont vous avez dit qu'elle contient le package d'alerte), le référentiel est maintenant obsolète et il est indiqué que tous les nouveaux développements se déroulent dans https://github. com/raintank/worldping-api. Cela me fait me demander si cette fonctionnalité d'alerte est toujours en cours de développement ou a été planifiée et modifiée pour autre chose (comme worldPing qui ne ressemble pas à ce dont nous avons discuté ici).

Salut @minhdanh , l'objectif a toujours été d'ajouter des alertes "correctement" dans grafana, pas seulement comme un hack dans un fork spécifique à un réservoir de pluie, qui est le référentiel auquel vous faites référence (et qui ne couvrait de toute façon qu'un domaine très étroit, bien qu'il puisse être judicieux de réutiliser une partie de ce code une fois que nous commençons à travailler sur un planificateur/exécuteur, que ce référentiel avait). C'est pourquoi nous avons travaillé dur pour rendre grafana si connectable pour la prochaine version de grafana 3. (et en conséquence, cela nous a permis de déplacer nos propres besoins dans une application autonome, qui est l'API worldping dont vous parlez).
Il est devenu très clair que dans un premier temps, nous devrions simplement créer l'interface utilisateur pour gérer les règles depuis l'intérieur de vos tableaux de bord et panneaux grafana et les exposer via une sorte d'API, afin que les plugins puissent les utiliser pour les exécuter. Ce sera le moyen le plus rapide de déclencher une alerte. le "planificateur/exécuteur à piles incluses" viendrait alors plus tard et pourrait réutiliser une partie du code auquel vous avez fait référence.

Quoi qu'il en soit, nous allons d'abord créer l'interface utilisateur de gestion dans grafana et exposer les règles via l'API, et nous continuerons à partir de là.

Merci @dieterbe.

Comme toujours, se pose la question d'un échéancier approximatif, même s'il ne s'agit que «
avant X".

Je comprends à quel point cette question peut être agaçante ainsi la formulation dans le
deuxième partie. J'espère que tu comprends combien c'est frustrant d'attendre l'autre
côté de la clôture peut être.

Richard

Envoyé par mobile; excusez ma brièveté.

Salut tout le monde,

J'espère que c'est ok pour Raintank de le dire ici, mais nous avons très récemment commandé près d'un mois d'heures de codage dédiées par Raintank pour travailler sur les alertes. Alors pourquoi cela ne se traduira pas encore par une fonction d'alerte finale, nous devrions voir quelque chose arriver bientôt pour jeter les bases de l'alerte dans grafana. Si d'autres entreprises suivaient notre approche ou aussi des individus investissant de l'argent dans cette affaire, cela devrait accélérer encore plus les réflexions et les priorités.

@flyersa , merci beaucoup pour la contribution ! Comment pouvons-nous également mettre de l'argent de côté ?

Jon

Bonjour à tous,

Je sais que beaucoup sont impatients pour cette fonctionnalité, et je suis heureux d'annoncer que l'équipe a commencé à travailler dessus. Nous avons expliqué nos raisons du retard dans le blog d'annonce de la bêta de Grafana 3.0

Nous publierons les alertes en deux phases. La première phase permettra aux utilisateurs de définir leurs alertes et seuils dans l'interface utilisateur de Grafana. Grafana exposera également ces définitions d'alertes via une API HTTP aux planificateurs tiers et aux backends d'alerte. Dans la deuxième phase, nous fournirons le service backend pour consommer et agir sur ces définitions, pour une solution complètement intégrée.

Nous espérons que la première phase sera publiée dans quelques semaines.

Nous essayons d'équilibrer rentabilité et rapidité, et nous apprécions GRANDEMENT le soutien commercial de nos clients tels que @flyersa. Si d'autres personnes souhaitent soutenir le développement de cette fonctionnalité et de Grafana en général, veuillez envisager d'acheter un plan d'assistance . Cela nous aidera à développer un excellent logiciel 100% open source.

Nous travaillerons en étroite collaboration avec tous les clients pris en charge lors du déploiement de la fonctionnalité et nous veillerons à ce qu'elle réponde bien à leurs besoins.

-raj dutt | PDG/cofondateur | réservoir de pluie

Salut @nopzor1200 ,

Merci pour votre mise à jour. Avez-vous une estimation du moment où les alertes seront disponibles ?

Evidemment, il est impossible de s'engager à une date précise, mais un délai sera très apprécié (semaines, mois etc.).

10x !

Salut les gars, vraiment excité pour cela. Voici comment j'envisage d'utiliser cela, si quelqu'un peut vérifier qu'il s'agit d'un modèle standard/supporté, je l'apprécierais.

• Chaque hôte que je veux surveiller émet des "Checks". Un "Chèque" consiste en :
  
  
  
  • le nom d'hôte
  
  
  • l'horodatage
  
  
  • l'état, qui est soit 0=OK, 1=WARN ou 2=CRITICAL
  
  
• Ces vérifications peuvent provenir de diverses sources arbitraires (scripts shell + cron, statsd/collectd, vérifications Nagios, etc.) et seront accumulées dans Elasticsearch. Le même contrôle peut avoir différentes configurations sur différents hôtes, mais cela sera opaque pour Grafana.
• Je vais configurer Grafana pour se connecter à Elasticsearch et alerter lorsqu'une vérification provenant de n'importe quel hôte a une valeur d'état >= 1.
• Si de nouveaux hôtes rejoignent le cluster, aucune configuration n'est requise dans Grafana ; Grafana verra simplement n'importe quel point de données dans l'état 1 ou 2, quelle que soit sa provenance.
• Si un hôte meurt subitement et arrête de transmettre des chèques, nous devons le détecter. Pour gérer cela, lorsqu'un hôte démarre, il enregistre un contrôle principal comme état "ON", et la valeur ne passe à "OFF" que lorsqu'il est arrêté normalement. De cette façon, je peux rechercher tous les hôtes "ON" qui n'ont pas émis de chèques au cours des X dernières secondes.
• En général, je n'utiliserai pas d'alertes basées sur des seuils sur des données de séries chronologiques dans Graphana. En d'autres termes, je ne ferai pas "vérifier si l'utilisation du processeur > 80%" dans Grafana lui-même, mais plutôt, Grafana recevra un contrôle "État d'utilisation du processeur" (0 / 1 / 2) et une alerte dans l'état 1 ou 2.

Salut @johnnyshields ,

Cela a l'air plutôt bien, mais au lieu de "0=OK, 1=WARN ou 2=CRITICAL", pourquoi ne pas utiliser une définition de niveau standard ? Celui utilisé par syslog est à peu près un standard de facto pour ces choses :

• Valeur -> Gravité
• 0 -> Urgence
• 1 -> Alerte
• 2 -> Critique
• 3 -> Erreur
• 4 -> Avertissement
• 5 -> Avis
• 6 -> Informationnel
• 7 -> Déboguer

Et avoir une configuration (globale ?) pour dire à grafana quel niveau considérer comme seuil d'alerte.

Compte tenu de cela, j'ajouterais les modifications suivantes à votre message :

• alerte lorsqu'une vérification provenant de n'importe quel hôte a une valeur d'état >= CONFIGURABLE_ALERT_LEVEL.
• Grafana verra simplement n'importe quel point de données dans l'état >= CONFIGURABLE_ALERT_LEVEL quelle que soit sa provenance
• Grafana recevra un niveau de vérification "CPU Usage State" et une alerte s'il est configuré en conséquence.

@brunorey merci, c'est logique !

Les niveaux et les états de journalisation sont deux choses différentes. Vous pourriez avoir un message de journal 6-Informational, mais comment quelque chose peut-il être dans un état 6-Informational ?

Les états OK, AVERTIR et CRITIQUE sont corrects, et peuvent être trop bien pour ceux qui ne se soucient que de OK et CRITIQUE. L'ajout de plus d'états ajoute de la confusion à moins que leur signification ne soit universellement comprise, et je suggère de limiter à 3.

En ce qui concerne uniquement les alertes sur "CPU state >= WARN" vs. "CPU > 80%", je soumets que certaines personnes voudront conserver leurs états à 3 niveaux dans une base de données chronologique afin qu'elles puissent voir comment l'état a changé au fil du temps. Ces personnes seront alertées en fonction des données de leur série chronologique d'état. D'autres voudront alerter sur la valeur brute du processeur supérieure à 80%. Le fait est que l'alerte des données de séries chronologiques est la seule chose nécessaire.

La raison pour laquelle je choisis un ratio d'états de journal entier plutôt que d'utiliser directement les données de la série temporelle est que je veux pouvoir contrôler ce qui est considéré comme une alerte sur chaque nœud.

Par exemple, les serveurs de travail ont régulièrement un processeur proche de 100%, et ce n'est pas un problème - je veux qu'ils tirent à plein régime sur tous les cœurs. Mais les serveurs Web ne devraient pas avoir un processeur supérieur à 20%. Donc, si je devais faire un CPU générique > 80%, ce serait trop élevé pour les sites Web et trop bas pour les travailleurs. (Ceci n'est qu'un cas).

@johnnyshields Je ne comprends pas pourquoi vous n'utiliseriez pas d'alertes basées sur des seuils sur des données de séries chronologiques, IMO, c'est là que se trouve la valeur vraiment forte (seulement?) D'ajouter des alertes à grafana/graphite. Vos trucs de style "checks" semblent mieux adaptés à quelque chose de simple comme monit - ai-je raté quelque chose ici ?

Comme expliqué ci-dessus, j'ai beaucoup de serveurs avec des rôles différents et les seuils sont différents par serveur. En fin de compte il s'agit de savoir si les seuils sont définis au sein de Grafana ou sur le serveur lui-même, je pense que le serveur est plus simple dans mon cas.

De plus, certaines vérifications sont "oui ou non", par exemple, le processus X est-il en cours d'exécution, un ping vers le port Y répond-il, etc.

Entendu. Parfois, la détermination de ces états est simple (> 80%), et parfois c'est complexe. Lorsqu'ils sont complexes, du code déterminera les niveaux et enverra le niveau dans une base de données TS. C'est une pratique courante, où les données sont transformées en informations. Ce que je veux dire, c'est qu'il n'y a aucune différence avec un sens d'alerte.

Si vous avez besoin de règles complexes pour vos alertes, ne créez pas les règles dans le moteur d'alertes, intégrez les règles dans le pipeline TS pour créer de nouvelles données TS et alertez-les.

Simplifiez le système d'alerte. Masquez la complexité dans le pipeline TS.

L'avantage de créer de nouvelles données TS dans un pipeline par rapport à un système d'alerte basé sur des règles est qu'il garde les alertes visuelles et simples pour les personnes qui définissent et reçoivent les alertes. Il y a une visualisation qui peut être envoyée par e-mail ou sms montrant juste la chose qui est alertée - même s'il s'agit d'un simple graphique d'état où ils voient que l'état est passé de WARN à CRITICAL il y a 20 minutes.

Je pense que si vous voulez contrôler ce qui est considéré comme digne d'alerte sur une base par hôte/rôle, vous avez tout aussi bien d'ajouter de la logique à ce qui est considéré comme WARN et à ce qui est considéré comme CRIT que vous ajoutez 8 couches de granularité à la gravité du alerte.

Presque tous les autres systèmes d'alerte modernes semblent avoir convergé sur OK/WARN/CRIT, et bien que ce soit probablement en partie pour vouloir la compatibilité avec les contrôles Nagios, je pense que l'idée de vouloir simplement rester simple est plus importante. Si Grafana fait de même, l'intégration avec d'autres services d'alerte/surveillance sera plus facile. Par exemple, dans mon cas, je finirais probablement par envoyer des alertes Grafana à Sensu, qui enverrait ensuite un e-mail, un message slack ou autre. Sensu n'a que OK/WARN/CRIT, donc toute granularité supplémentaire serait gaspillée.

Le niveau d'alerte de journal d'accord semble excessif. OK, Warn, Crit fera probablement le travail dans la plupart des cas.

Sur les seuils d'alertes, j'aimerais pouvoir faire des alertes basées sur l'écart type. Ils sont les plus utiles dans la pratique imo.

Le 12 mai 2016, à 8h49, RWhar [email protected] a écrit :

@johnnyshields Je ne comprends pas pourquoi vous n'utiliseriez pas d'alertes basées sur des seuils sur des données de séries chronologiques, IMO, c'est là que se trouve la valeur vraiment forte (seulement?) D'ajouter des alertes à grafana/graphite. Vos trucs de style "checks" semblent mieux adaptés à quelque chose de simple comme monit - ai-je raté quelque chose ici ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub

Personnellement, j'attendais avec impatience d'alerter en utilisant les données TS existantes introduites dans le graphite en tant qu'entrée, en particulier en agrégeant les statistiques des métriques d'application de (via StatsD) dans des plages de temps spécifiées.

En outre, il serait bien d'avoir une option où les alertes pourraient être déclenchées au seuil et des intervalles spécifiés au-delà du seuil - par exemple, définir le seuil d'alerte "rpl_delay" 200 int 50 - provoquerait des alertes à 200, 250, 300, etc. sans le besoin de spécifier manuellement des niveaux de seuil supplémentaires.

@johnnyshields Je ne comprends pas la différence entre 1=WARN ou 2=CRITICAL. L'alerte est déclenchée ou non déclenchée. Vous êtes soit au-dessus de 80% ou pas au-dessus de 80%. Je ne vois donc que deux états 0 et 1.
Ce serait également bien d'avoir des alertes plus intelligentes où vous pouvez détecter que vous avez été au-dessus de 80% pendant 5 minutes d'affilée afin que vous ne soyez pas alerté des pics temporaires. Des choses encore plus avancées sont des choses comme les seuils mobiles, où, par exemple, vous surveillez le trafic de votre site Web, et vous obtenez un trafic X et il augmente lentement, disons 1% par mois, mais tout d'un coup, vous obtenez un pic de trafic de 10% dans un heure. Vous voudriez également pouvoir surveiller le contraire, d'une baisse soudaine du trafic. Quelque chose de similaire à https://github.com/etsy/skyline puisque Skyline a disparu.

Les gars, mon message ici ne concernait pas le nombre précis d'états d'alerte à utiliser - je demandais plus généralement "Grafana prendra-t-il en charge les états énumérés en tant que cas d'utilisation d'alerte ?"

Puisqu'il existe un désaccord sur le nombre optimal (Nagios utilise 3, syslog utilise 7, certaines personnes comme 2, etc.) Grafana devrait prendre en charge un nombre arbitraire d'états.

Pour répéter ce que j'ai dit auparavant, je pense qu'il ne devrait y avoir que deux états pour chaque alerte déclenchée 1 ou non déclenchée 0. Si vous voulez savoir si vous vous approchez d'un seuil, créez un seuil supplémentaire pour la valeur inférieure.

La raison de WARN vs. CRITICAL est que les actions que vous entreprenez sont différentes. Un groupe de personnes et d'actions est généralement notifié sur WARN, et un autre groupe/différentes actions sur CRITICAL.

C'est une différenciation assez précieuse, que je ne voudrais pas partir avec un système 0-1.

@lorenwest si vous souhaitez une vérification différente pour un seuil différent, créez un seuil supplémentaire pour ce groupe distinct.
donc chaque seuil est soit 0, soit 1.
Par exemple, une autre raison pour laquelle vous voudriez que les alertes soient configurées de cette manière est lorsque vous voulez un e-mail lorsque le seuil est supérieur à 70% mais une page lorsque vous êtes supérieur à 80%. Tout comme vous voulez des groupes séparés. WARN vs. CRITICAL a trop d'ambiguïté.

@doanerock qui a du sens. Autoriser un nombre arbitraire d'alertes sur n'importe quelle métrique ou événement TS permet la plus grande flexibilité. Cela simplifie la définition d'alerte en n'ayant pas plusieurs actions pour plusieurs niveaux.

donc:

• les métriques peuvent avoir un nombre arbitraire d'états (y compris les valeurs décimales / temporelles)
• les métriques peuvent avoir plusieurs actions d'alerte attachées à la même métrique
• chaque alerte est un booléen vrai ou faux -- il est déclenché ou non déclenché.

pour donner un exemple :

• J'ai une certaine métrique avec des valeurs 0 = OK, 1 = WARN, 2 = CRITICAL
• Je configure 3 alertes :
  
  
  
  • si valeur = 1, afficher un drapeau jaune dans mon tableau de bord
  
  
  • si valeur = 2, afficher un drapeau rouge dans mon tableau de bord
  
  
  • si valeur >= 1, envoyez-moi un email
  
  

Bonjour à tous,

Je ne sais pas si c'est le bon endroit pour poser des questions sur ce sujet, mais je vais essayer de toute façon concernant le prochain module d'alerte Grafana.
Dans notre organisation, nous avons tous nos capteurs d'alertes de sécurité qui alimentent Logstash/Elasticsearch pour les événements et nous utilisons Yelp/elastalert pour exécuter des alertes avec certains modèles avec les critères suivants :

"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)

De plus, lorsque des critères d'alerte sont détectés, nous exécutons un script python externe avec des arguments qui transmettent des arguments d'Elastalert au script avec des informations telles que le champ IP source/destination, le champ d'événement et d'horodatage, et notre système NAC s'en charge à partir de là.

En regardant maintenant le module d'alerte à venir Grafana et avec Elasticsearch comme source de données, je me demande si le module d'alerte Grafan sera possible de coopérer de la même manière qu'Elastalert et éventuellement de le remplacer par les informations ci-dessus ?
s'il vous plaît donnez votre avis

Merci

Je sais que l'équipe grafana travaille dur là-dessus, et ce fil est long, mais je tiens à souligner que Kapacitor vient de fusionner une fonctionnalité qui facilitera grandement le développement d'applications de configuration d'alertes frontales : influxdata/kapacitor#577

Pour autant que je sache, l'objectif du côté de Grafana est de rendre le backend d'alerte enfichable (de la même manière que Grafana prend en charge plusieurs magasins TSDB), mais je voulais mentionner dans l'espoir que Kapacitor obtienne un support de première classe lorsque la fonctionnalité d'alerte de Grafana sera publiée. Cela semble parfaitement adapté, tout comme InfluxDB + Grafana.

@thom-nic merci pour l'astuce Kapacitor est exactement ce que je recherche...

Riemann est aussi génial et très puissant. telegraf -> riemann (alerte) -> influxdb <- grafana

Nous progressons dans la branche alerting_definitions.

Nous avons maintenant un modèle de règle d'alerte simple que vous pouvez définir dans l'interface utilisateur et via l'API HTTP. Vous pouvez récupérer des règles, des modifications de règles, des états de règles via l'API HTTP. La planification simple des règles d'alerte et l'exécution des requêtes et l'exécution des règles commencent également à se rejoindre.

Une chose qui est un gros point d'interrogation pour moi maintenant est de savoir si le modèle d'alerte actuel est trop simple et une impasse. J'entends par là que l'extension du modèle de règle d'alerte à l'avenir nécessitera des changements importants.

Modèle de règle actuel :

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

Ce modèle de stockage est à la fois représenté dans l'interface utilisateur et dans la table de base de données réelle. Ma crainte est que ce modèle de règle simple ne tire pas suffisamment parti des données de séries chronologiques. Vous ne pouvez pas spécifier de seuils dynamiques (où les seuils eux-mêmes sont les résultats d'une requête). Bien sûr ce
pourrait être ajouté plus tard, mais nécessiterait un modèle de règles et un moteur d'exécution très différents.

Mon idée est donc de supprimer ce modèle simple et de proposer un nouveau modèle plus complexe et dynamique qui pourra ultérieurement prendre en charge plusieurs requêtes pour différentes plages de temps.

Requête simple :

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

// maintenant à une alerte qui utilise un seuil dynamique basé sur ses valeurs passées

"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,
  },

Maintenant, vous pouvez remettre cela en question en déclarant que nous réinventons le graphite ici, et une expression comme celle-ci devrait être gérée par le TSDB. Mais aucun TSDB ne prend en charge les calculs avec des requêtes pour différentes plages de temps (timeShift ne décale que la même période). Certains problèmes avec les seuils dynamiques sont de savoir comment le visualiser. Cela peut également rendre la règle d'alerte plus dissociée de ce qui est réellement visualisé dans le panneau.

Je ne sais pas trop à quoi devrait ressembler le GAL (Grafana Alerting Language). S'il ne s'agit que de chaînes d'expression où chaque partie peut être soit une requête qui renvoie une ou plusieurs séries (chaque série agrégée jusqu'à un point), puis une fonction de soustraction ou de pourcentage facultative qui peut être comparée à une autre requête. L'expression entière aboutit à une valeur qui peut ensuite être utilisée avec les niveaux d'opérateur et de critique/avertissement pour obtenir l'état d'alerte.

Ou l'expression doit-elle contenir l'opérateur et les niveaux ?

D'autres options iraient en langage de programmation complet et feraient :

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

return percentDiff(last5minAvg, last24Avg)
"

@torkelo :

1. est-ce que vous l'architecte comme un composant autonome ? En fin de compte, vous construisez un processeur de signal similaire à Kapacitor pour Influxdb ** qui lui-même émet un signal (0 = "ok", 1 = "warn", 2 = "crit"). sera-t-il possible d'envoyer ce signal ailleurs que Grafana, par exemple A) à Nagios, ou B) le rediriger vers la DB ?
2. de même, grafana aura-t-il la possibilité de ne pas utiliser votre moteur de signal ci-dessus, mais plutôt de recevoir un signal 0/1/2 d'une source tierce telle qu'un plugin Nagios, dont beaucoup existent déjà dans la nature ?

** = accordé Kapicator utilise un traitement de flux de séries temporelles alors que votre est un moteur basé sur l'interrogation, mais émet toujours un signal.

Merci d'avoir sollicité votre contribution.

Mon opinion est de garder les alertes grafana simples, et le meilleur indicateur de simplicité est la visualisation. Si vous ne pouvez pas visualiser l'alerte sous forme de ligne sur un graphique TS existant, c'est trop complexe.

Laissez la complexité au graphique TS. Si l'alerte a des besoins plus importants, créez un autre ensemble de données TS en fonction de ces besoins et placez l'alerte sur un graphique de ces données.

Si vous n'avez qu'un seul principe directeur c'est d'exiger une simple visualisation de l'alerte.

L'autre problème est « combien d'alertes dois-je configurer » ? Ce sujet a été discuté sur ce fil, et je suis d'avis que dès que vous commencez à mettre plusieurs alertes dans une alerte (avertissement, erreur, avertissement élevé, erreur faible, etc.), vous commencez à perdre en flexibilité. Les avertissements et les erreurs sont des choses différentes - ils ont différents niveaux, différentes personnes s'en soucient et ils ont différentes méthodes de notification.

Gardez les alertes simples et laissez les gens placer plusieurs alertes sur un graphique.

Je pense que #3677 (Generic Transforms on Time Series Query Results) serait vraiment utile ici. Avec ces fonctions indépendantes de TSDB, vous pouvez créer un "graphique d'alerte" complexe où vous pouvez utiliser des seuils de valeurs fixes simples pour avertir, crit, etc.

Le modèle de règle d'alerte simple serait alors tout ce qui est nécessaire. La complexité est alors "cachée" dans la création et la combinaison des graphes.

Je suis tout à fait pour que ce soit simple. Je ne suis pas un développeur, je suis plutôt un développeur léger et j'aimerais pouvoir céder ma plate-forme Grafana/Graphite à mon équipe d'administrateurs pour qu'elle la gère. Cela étant le cas, un générateur d'alertes similaire à celui existant sera beaucoup plus facile à utiliser. Pas trop compliqué s'il introduit une charge de nouvelles instructions tant que les règles peuvent toujours être construites de la même manière que les requêtes pour les graphiques le sont actuellement, il sera facile de s'y familiariser.

tl;dr un tout nouveau langage peut être excessif et trop complexe. Règles de construction avec mouse=good.

À moins de créer un tout nouveau langage, j'ai supposé qu'il s'agirait en grande partie d'une interface pour les plates-formes d'alerte existantes telles que Kapacitor, Reimann et Bosun, de la même manière que Grafana fournit une interface pour composer des requêtes InfluxDB. Par exemple, le gros du travail est effectué par un système d'alerte tiers et Grafana fournit l'interface utilisateur. Ce n'est peut-être pas le cas ?

IIRC, Grafana veut aller dans la voie des "piles incluses, mais amovibles". C'est-à-dire qu'il doit fonctionner de manière autonome avec un moteur d'alerte inclus, mais doit également être enfichable sur les plates-formes existantes.

Je dirais qu'il doit venir avec quelques méthodes intégrées - e-mail (hôte SMTP d'approvisionnement) et WebAPI/Webhook. Ensuite, le reste peut venir avec des plugins, tels que l'intégration dans PagerDuty.

@felixbarny pouvez-vous décrire ce que vous entendez par pluggable sur les plates-formes existantes ? Bien entendu, les notifications d'alerte s'intégreront à de nombreux outils d'alerte existants. Mais pour que d'autres systèmes gèrent la planification et l'exécution des règles d'alerte, cela pourrait être délicat, ce serait possible, il suffit de lire les règles de l'API HTTP Grafana. Mais cela nécessiterait beaucoup de code pour gérer la planification et l'exécution des règles. Mais nous fournirons bien sûr une option pour définir uniquement les règles dans Grafana, et pour qu'un autre système lise en permanence les règles et les exécute.

@GriffReborn, vous pensez à un niveau différent. Les backends d'alerte existants que j'ai mentionnés prennent en charge _déjà_ les sorties telles que SMTP, PagerDuty, etc. :
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

Ces produits font _déjà_ bien les alertes complexes et dynamiques. Ce qu'ils n'ont pas, c'est une interface visuelle agréable pour configurer et gérer les alertes, identifier visuellement les alertes actives, etc. Ce que j'aurais aimé avoir, c'est une interface utilisateur frontale qui pousse essentiellement les configurations vers, par exemple, votre alerte (prise en charge par Grafana) système de choix qui fait alors tout le travail.

@thom-nic je suis d'accord. L'objectif principal devrait être de créer un tableau de bord d'alerte qui peut utiliser les flux d'informations d'alerte existants ("feed agnostic"). Faire un moteur de traitement du signal léger sponsorisé par Grafana (idéalement en tant que autonome) devrait être une préoccupation secondaire.

@johnnyshields créer de nouveaux panneaux qui affichent les informations des backends d'alerte existants est facile pour tous ceux qui le souhaitent. Ce que nous essayons de faire, c'est de permettre aux utilisateurs de Grafana de définir facilement des règles d'alerte sur leurs requêtes métriques qu'ils définissent dans les panneaux graph / singlestat. Ensuite, ayez un moteur d'alerte dans le backend grafana qui planifie, exécute et évalue ces règles, met à jour l'état d'alerte, déclenche des notifications, etc.

Je pense également que le modèle simple devrait être suffisant et permettra également d'avoir la fonctionnalité tant attendue dans les plus brefs délais. À tous les grafana est pour les métriques, les alertes de base devraient être suffisantes.

@torkelo pour être honnête, je ne connais pas très bien les plates-formes d'alerte comme bosun et je ne sais pas à quoi pourrait ressembler une intégration appropriée. Je faisais référence à des propos de @Dieterbe , par exemple dans sa présentation Grafanacon : http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny eh bien, c'est ce que nous prévoyons de faire également. Avoir des API pour d'autres backends d'alerte à utiliser afin de lire les règles définies dans Grafana. Mais nous ne fournirons pas le pont qui lit les règles d'alerte de Grafana et les traduit vers un autre moteur d'exécution de règles.

Donc, une idée que nous avons maintenant est de définir des règles simples comme celle-ci

Mais aussi pouvoir avoir des seuils dynamiques et comparer avec une autre requête ou la même requête mais avec une plage de temps et une agrégation différentes.

Une autre requête "prévision" complexe. Lorsqu'une requête est utilisée pour obtenir une ligne de tendance, puis prévoir cela dans le temps et alerter à ce sujet.

Cela semble être le meilleur des deux mondes. J'adore cette idée ! Les fonctions « Évaluer par rapport » font-elles partie de Grafana ou sont-elles spécifiques à la TSDB ?

@felixbarny, ils font partie du modèle de règle d'alerte Grafana et seront traités par le moteur d'évaluation des règles d'alerte Grafana.

Serez-vous capable d'attacher plusieurs règles à un seul graphique ? J'aime la simplicité des niveaux d'avertissement/critique dans une règle, et certains graphiques ont des seuils haut et bas qui nécessiteraient soit plusieurs niveaux dans une alerte, soit plusieurs alertes sur un graphique.

Et bien que j'aime la fonctionnalité de règle complexe, tout cela peut être réalisé en créant un graphique différent et en alertant sur ce graphique avec une règle simple. L'avantage de garder la complexité hors du système d'alerte est que l'historique des circonstances provoquant le déclenchement de la règle est conservé dans la TSDB.

Cela vous permet de visualiser une alerte sous la forme d'une simple ligne horizontale sur un graphique et de voir comment cette règle se serait (ou s'est) déclenchée au fil du temps.

Il continue d'alerter simple pour la personne moyenne, assez complexe pour tout le monde et accessible pour ceux qui comprennent les choses visuellement.

@lorenwest oui, nous garderons les choses simples et n'autoriserons qu'une seule règle d'alerte par panneau. Mais une règle peut utiliser une requête qui renvoie plusieurs séries, ce qui divisera essentiellement la règle en plusieurs (vous pouvez donc avoir une seule règle qui vérifiera chaque serveur, si la requête renvoie une série par serveur).

Et bien que j'aime la fonctionnalité de règle complexe, tout cela peut être réalisé en créant un graphique différent et en alertant sur ce graphique avec une règle simple.

Je ne suis pas sûr de te comprendre. Un autre graphique ne résout pas du tout le scénario dans lequel vous souhaitez alerter sur une requête par rapport à elle-même sur une plage de temps différente, par rapport à une autre requête entièrement (peut-être que l'autre requête est une autre source de données récupérant des seuils dynamiques à partir d'une base de données). Ce scénario ne peut pas être résolu dans la TSDB ou en divisant simplement la règle en deux règles dans deux panneaux distincts.

Mais notre objectif principal est de résoudre le cas simple et de le rendre facile et intuitif, mais nous voulons également, au moins plus tard, prendre en charge des règles d'alerte plus complexes qui tirent vraiment parti du fait que vous traitez avec des données TSDB et aussi du fait que différentes requêtes peuvent cibler différentes sources de données

Je pense que le point soulevé par @lorenwest est que les règles d'alerte étant de simples seuils, les règles sont appliquées aux données visualisées dans le graphique. Donc, si vous superposez les seuils, vous pouvez clairement voir où dans le passé l'alerte se serait déclenchée en fonction des seuils actuels

Avec un modèle d'alerte plus complexe, il n'y a plus d'indicateur visible indiquant où les seuils entraîneraient une alerte.

En restant fidèle au modèle simple, vous pourriez répondre à de nombreuses exigences de surveillance complexes à condition que la source de données en fournisse la capacité. Pour le "pourcentage de changement par rapport à", vous pouvez créer une requête graphite (graphique différent) qui compare le jour actuel avec le précédent, puis définir des seuils simples à ce sujet. C'est certainement un processus beaucoup plus compliqué pour créer des alertes, mais cela fonctionne.

Heureux que nous soyons sur la même longueur d'onde @torkelo. Cela correspond à la description du message d'origine.

Je n'ai pas envie de créer une toute nouvelle plate-forme d'alerte à relier à Grafana. Ce que j'espère des alertes Grafana, c'est quelque chose pour remplacer NewRelic, mais avec la puissance impressionnante que Grafana apporte. Pouvoir déclencher une alerte (que ce soit par e-mail, API ou autre) lorsqu'un de mes graphiques atteint un seuil... c'est GOLD. Des trucs qui changent la vie.

Même de simples alertes de seuil seraient une bonne solution simple.

Si vous suivez cette règle, vous serez en or :

Ne jamais autoriser une alerte qui ne peut pas être visualisée par superposition sur un panneau.

Si vous ne pouvez pas le visualiser, c'est trop complexe. Construisez un graphique qui incarne cette complexité et alertez sur ce graphique. Cela nous oblige à créer des visualisations qui incarnent cette complexité (une bonne chose) tout en permettant au créateur d'alertes (et au consommateur) de voir facilement dans quoi ils s'embarquent.

@woodsaj Je suis d'accord pour dire que nous voulons encourager le lien entre ce sur quoi vous alertez et ce que vous voyez, ce n'est pas quelque chose dont nous avons jamais discuté de l'abandon. Ce que nous essayons de réfléchir, c'est jusqu'où vont les seuils statiques de requête unique, sont-ils assez bons pour la v2 de Grafana Alerting ou la v3 ? Et pour susciter une discussion sur les limitations du type de règles d'alerte possibles avec une requête unique et des seuils statiques.

Actuellement, les TSDB sont très rigides quant au type de requêtes imbriquées que vous pouvez effectuer (comparer une série à elle-même par exemple). Graphite est le seul à prendre en charge les requêtes imbriquées. Mais même Graphite ne peut pas comparer deux requêtes qui ciblent des fenêtres temporelles différentes (le décalage temporel déplace simplement la même fenêtre, mais pas une fenêtre temporelle de taille différente). Mais plus j'y pense, plus je suis d'accord pour dire que la plupart de ces problèmes peuvent être résolus dans la requête TSDB étant donné qu'elle est suffisamment puissante.

La principale raison de soulever cette discussion est de réfléchir à la façon de modéliser la règle, quels sont les composants qui composent une règle, quelles abstractions contient-elle (requête, fenêtre temporelle, agrégation, niveaux, etc.). Comment pouvons-nous éventuellement prendre en charge des seuils dynamiques dans la v2 ou des requêtes d'alerte plus riches en fonctionnalités qui prévoient des tendances dans le futur. Comment le moteur d'évaluation des modèles et des règles devrait-il changer ?

En ce qui concerne "Les alertes devraient-elles être mappées sur les panneaux" - je pense que cela peut être une option utile mais serait une mauvaise contrainte de conception, même pour la v1.

Je pense que l'un des aspects les plus délicats de l'alerte est la portée, et une fois que vous commencez à parler de visualisation, le problème devient apparent.

Je pense à la portée comme à la surface / profondeur d'un système qu'une alerte couvre en tant que portée. Ainsi, par exemple, vos alertes peuvent être étendues :

• Services (métriques d'application)
• Des clusters entiers qui composent un service
• Nœuds individuels dans un cluster
• Hôtes / processus dans un cluster
• Sous-système de processus / applications (métriques middleware)
• Sous-systèmes d'hôtes (c'est-à-dire disque, processeur) (métriques système)

Je ne crois pas qu'il existe une réponse unique "correcte" sur la couche sur laquelle il faut alerter. Parfois, cela dépend des équipes, de l'importance du service, de l'infrastructure générale (c'est-à-dire cloud vs hardware, cluster vs monolith), etc... Donc, étant donné les étendues en couches, une hiérarchie d'alerte semble être une bonne chose. Mais je ne pense pas que la définition de ces hiérarchies soit généralement maintenable. C'est beaucoup de travail, de changements, et il y a souvent des relations qui ne font pas de jolis arbres dans les systèmes du monde réel. Agressivité du livre SRE de Google :

"""
Google SRE n'a connu qu'un succès limité avec des hiérarchies de dépendances complexes. Nous utilisons rarement des règles telles que « Si je sais que la base de données est lente, alerte pour une base de données lente ; sinon, alerte pour que le site Web soit généralement lent. » Les règles dépendantes des dépendances concernent généralement des parties très stables de notre système, telles que notre système de drainage du trafic utilisateur hors d'un centre de données. Par exemple, « Si un centre de données est vidé, ne m'alertez pas sur sa latence » est une règle d'alerte de centre de données courante. Peu d'équipes chez Google maintiennent des hiérarchies de dépendances complexes, car notre infrastructure a un taux constant de refactorisation continue.
"""

Le type d'alerte est également lié à la portée (c'est-à-dire envoyer un e-mail au lieu de le consigner / de l'afficher sur le tableau de bord pour que quelqu'un s'occupe de lui lorsqu'il fait sa ronde matinale)

Donc, pour Grafana, mes alertes peuvent correspondre à :

• Un panneau
• Un groupe de panneaux
• Un tableau de bord
• Un groupe de tableaux de bord (qui, j'imagine, aurait des analyses)

Parfois, je souhaiterai que ces alertes envoient une notification, d'autres fois, je souhaiterai qu'elles soient simplement un indicateur visuel quelque part dans Grafana sur l'un des champs d'application (c.-à-d. seuil franchi ou changements d'état en tant que marqueurs d'annotation). Cela va être différent pour différentes entreprises et même différents groupes/services au sein d'une entreprise.

@kylebrandt, l'idée de l'alerte dans Grafana est de la lier à des panneaux et à des visualisations. Où vous pouvez avoir des graphiques et des panneaux qui visualisent des métriques avec une portée différente (comme des services, des clusters, des hôtes individuels) et en ayant cela, vous pouvez alerter à n'importe quel niveau ou portée.

Ne pas voir comment lier une alerte à un panneau et quelque chose qui peut être visualisé arrêtera de définir des alertes à différents niveaux. Et bien sûr, vous préciserez par alerte quelles notifications doivent être utilisées.

@torkelo La décision d'alerter se

Ainsi, $metric > $threshold est l'alerte la plus basique, et elle renvoie vrai si la métrique dépasse le seuil bien sûr. Cela s'intègre bien dans un panneau (visualisez la métrique et visualisez le seuil dans un panneau). Mais, afin d'éliminer le bruit d'alerte, la portée et les conditions ont tendance à s'étendre au-delà de cela dans la majorité des cas (quand nous avons commencé à travailler sur Bosun, je pensais que ces cas seraient la minorité, pas tellement il s'avère que si vous voulez contrôler le bruit). Alors vous pourriez dire quelque chose comme :

Alerte si :

• Le processeur est au-dessus de 80% pendant X minutes
• Le travail A n'est pas en cours d'exécution (que nous savons augmenter le processeur et nous nous en moquons) et le travail A n'est pas en cours d'exécution depuis plus d'une heure
• Dieter a bu plus de 3 tasses de Starbucks au cours des dernières 24 heures (car quand il en a plus, il fait des bêtises qui augmentent le processeur et nous ne voulons pas alerter à ce sujet)

Donc, visualiser uniquement l'alerte est (Vrai / Faux) lorsqu'il y a plusieurs conditions n'est pas très utile. Nous devons visualiser chaque condition (et peut-être même plus pour les informations de support).

Faire de toutes ces conditions une nouvelle métrique n'aide pas vraiment à la visualisation sur le moment car ce serait juste Vrai/Faux et ce que vous devez vraiment voir, ce sont toutes les informations sous-jacentes. Donc, ce que nous avons au lieu de visualiser métrique + seuil, c'est de visualiser métrique(s) + seuil(s) qui pourraient être à différentes échelles.

Donc, dans ce cas, oui, l'Alerte peut être mappée sur un seul panneau, mais en fonction de la visualisation et de l'alerte, il existe de nombreux cas où ce n'est pas vraiment ce que l'on voudrait. Je voudrais un panneau pour chacun des éléments booléens qui composent l'alerte, pour voir lequel de ceux-ci a déclenché - mais afin d'éviter la fatigue des alertes, je ne veux qu'une seule notification pour la combinaison de toutes les conditions.

semble qu'une sorte de menuisier d'alerte avec une logique booléenne simple pourrait rendre cela facile.

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 J'ai alerting_definitions de Github et l'ai construite conformément aux instructions. Mais malheureusement, je ne vois aucun onglet "Alerte" (présenté ci-dessus) dans le panneau Graphique.
De plus, j'ai trouvé "alerting: enabled=false" dans le "Server setting" de "Server Administration". Cela affecte-t-il la fonction d'alerte ? Y a-t-il un indicateur de build ou d'exécution que je devrais utiliser ?
s'il vous plaît des conseils.

J'ai essayé avec le dernier code (ebada26b85d8410142c2942ef7ba78b17e88313c), activé les alertes et obtenu l'interface utilisateur.

Mais j'ai des tonnes d'erreurs

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"

J'ai essayé avec les sources de données InfluxDB, en mode proyy et direct.

Est-ce quelque chose d'attendu ?

Oui, ce n'est pas encore prêt à tester.

OK bon à savoir.

Je vais suivre les mises à jour de temps en temps.
Peut-être vaut-il mieux attendre que cette branche soit fusionnée dans le master donc tout à fait prête à l'emploi ?

oui, nous espérons le fusionner pour maitriser peut-être mi-juillet là-bas environ

Avez-vous une mise à jour de l'avancement à ce sujet?
Allez-vous encore frapper à la mi-juillet?
Avoir cette fonctionnalité en production dès que possible serait vraiment d'une grande aide !

Même une version allégée avec une alerte par e-mail uniquement serait géniale !
Une mise à jour sur vos progrès serait formidable (je dois choisir entre mettre en place un système d'alerte personnalisé ou me fier à Grafana, et je préfère définitivement la 2ème option !).
Merci les gars

L'hiver est arrivé, les alertes aussi :)

Le mar. 12 juillet 2016 à 01h41, c-val [email protected] a écrit :

Même une version allégée avec une alerte par e-mail uniquement serait géniale !
Une mise à jour sur vos progrès serait formidable (je dois choisir entre
mettre en place un système d'alerte personnalisé ou s'appuyer sur Grafana, et j'ai définitivement
préférez la 2e option !).
Merci les gars

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390,
ou couper le fil
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

Deepak

Je considérerais cela comme une « exigence commerciale » et conseillerais de l'évaluer au niveau de « l'architecture d'entreprise ». En appliquant _certaines_ des pratiques et des modèles utilisés pour l'architecture logicielle d'entreprise, vous serez en mesure de communiquer vos idées grâce à la modélisation agile qui à son tour favorise une meilleure qualité de compréhension à la fois pour les parties prenantes et l'équipe de développement.

Avant de pouvoir commencer à parler technologie et architecture sauce secrète, nous devons au moins nous mettre d'accord sur ce qui suit :

1. Nous pensons à nos fonctionnalités en termes de « Business Process Management (BPM) » ; et
2. Nous utilisons le "Business Process Modeling Language (BPML)" afin de pouvoir commencer à modéliser les exigences et les implémentations au même endroit avec UML.
3. Nous définissons notre architecture avec une discipline au niveau de l'entreprise.

Maintenant la partie amusante ! Ayant une vaste expérience de la surveillance à l'échelle mondiale, je recommande que nous prenions en considération les éléments suivants :

• Laissez grafana tranquille, c'est la couche de présentation ! Si vous souhaitez ajouter un flux de travail pour la modélisation et la définition de règles de génération d'alertes, ce n'est pas grave, mais laissez-le là. Après tout, c'est pourquoi les panneaux et les plugins ont été implémentés, n'est-ce pas ?
• Laissez les données là où elles étaient destinées. Les mesures qui sont téléphonées à la maison doivent être traitées comme des citoyens de première classe et le stockage persistant de leurs valeurs est la priorité absolue. Que ce soit dans un cache, documentdb, tsdb ou un serveur SQL, cela n'a pas d'importance. La tolérance aux pannes est implicite .. avec les bonnes "sélections technologiques" pour l'architecture bien sûr).
• Pour nous permettre de configurer la disponibilité et l'évolutivité, nous devons utiliser les bons frameworks spécialement conçus pour cela : rencontrez l'architecture orientée services ("SOA"). À un niveau très élevé, nous pouvons utiliser le protocole de file d'attente de messages pour transmettre et recevoir des événements et des messages via le protocole "AMQP". Oubliez REST & HTTP... pour l'instant. En utilisant un serveur de file d'attente de messages comme RabbitMQ ou ZeroMQ, nous avons un pipeline de communication distribué, tolérant aux pannes, hautement disponible, que les éditeurs/expéditeurs de données et les travailleurs/récepteurs pour le traiter peuvent tous deux utiliser. C'est le "bus de service d'entreprise". (Consultez ce diaporama expliquant ZeroMQ).
• Utilisez un langage de requête créé spécifiquement pour les modèles de données composites disparates, non liés. En utilisant une « Base de données Graph » et l'interface de requête « SparQL » :

SPARQL permet aux utilisateurs d'écrire des requêtes sur ce que l'on peut vaguement appeler des données "clé-valeur" ou, plus précisément, des données qui suivent la spécification RDF du W3C. L'ensemble de la base de données est donc un ensemble de triplets "sujet-prédicat-objet". Ceci est analogue à l'utilisation par certaines bases de données NoSQL du terme "document-key-value", comme MongoDB.
[..]
SPARQL fournit ainsi un ensemble complet d'opérations de requête analytique telles que JOIN, SORT, AGGREGATE pour les données dont le schéma fait intrinsèquement partie des données plutôt que de nécessiter une définition de schéma distincte. Les informations de schéma (l'ontologie) sont souvent fournies en externe, cependant, pour permettre à différents ensembles de données d'être joints de manière non ambiguë. De plus, SPARQL fournit une syntaxe de parcours de graphe spécifique pour les données qui peuvent être considérées comme un graphe et une fig.
..
https://en.wikipedia.org/wiki/SPARQL

Rappelez-vous, ce que Grafana nous a donné que Nagios n'a jamais fait se résume à un seul point d'échec : le manque d'évolutivité. Grafana est "rapide" comme vous le dites mais vous ne tenez pas compte du fait que vous ne faites que stocker et traiter des données de séries temporelles -- pas la ou les couches de métadonnées non plus ! Nous avons besoin de la sémantique de SparQL et de la puissance d'Elasticache + moteur(s) de base de données graphique.

Cela peut sembler complexe .. ce qui peut facilement devenir beaucoup plus complexe que ces deux pages, mais je vous ai épargné des années de force brute, d'essais et d'erreurs et j'ai éliminé le bruit (c'est-à-dire qu'il existe 30 modèles de conception pour l'architecture d'entreprise, 12 pour uml, etc., nous avons juste besoin de parler de 3 pour pouvoir éliminer cela -- pour l'instant)

Cela devrait faire tourner les engrenages. J'ai besoin de dormir (j'ai passé une nuit entière) et je vais travailler sur la partie 2. N'hésitez pas à me contacter @appsoa sur skype ou yomateo sur IRC.

Quelques gourmandises en attendant :

• Un exemple d'architecture de référence que j'ai créé à l'aide de SOA .
• Microsoft Azure Service Fabric : créez et exploitez des applications toujours actives, évolutives et distribuées.

@talbaror Idéalement, vous captureriez les messages de journal du NAC à l'aide d'un agent comme avec un pare-feu PIX et les feriez simplement expédier/rejouer via rsyslogd ou tout autre protocole utilisé par le serveur de traitement d'événements.

Si vous n'avez pas configuré de service de traitement d'événements, vous pouvez utiliser le traitement des règles de Snort - Network Intrusion Detector . Envoyez-moi un ping si vous avez besoin d'aide .. J'ai passé 4 ans dans une entreprise de sécurité en tant que service ;)

Pouvez-vous intégrer la détection d'anomalies comme banshee ?
Avec marqueurs visuels et alertes.

@torkelo, s'il vous plaît, donnez-nous un mark-to-market sur le calendrier d'expédition ?

@johnnyshields Je travaille dessus maintenant tous les jours. C'est délicat et il faut vraiment avoir les bases pour que le système d'alerte puisse évoluer et s'enrichir à l'avenir. Le modèle actuel avec lequel je travaille a l'air vraiment bien, publiera une mise à jour la semaine prochaine sur le nouveau modèle de règle d'alerte basé sur les conditions.

J'espère le fusionner avec le master et le rendre disponible (derrière le basculement des fonctionnalités) dans les 2 semaines si les choses se passent bien. Nous n'avons pas encore de date fixée pour la prochaine version de Grafana, qu'il s'agisse d'une version 3.2 en septembre ou d'une version 4.0 plus importante fin octobre.

@torkelo J'espère que nous recevrons l'alerte dès que possible. L'attendre.
Utilisation de grafana pour kubernetes.

Pour les autres personnes qui ont déjà statsd/graphite/grafana en place et qui n'attendent que le système d'alerte Grafana pour être prêt à faire les premières alertes, j'ai trouvé une excellente alternative à utiliser en attendant, Seyren : https://github.com /scobal/seyren

Il s'intègre facilement à PagerDuty et vous pouvez simplement copier les cibles graphiques que vous avez déjà dans vos tableaux de bord grafana pour les alertes en spécifiant les seuils d'avertissement et d'erreur.

On dirait que l'équipe a fait de grands progrès sur la fonction d'alerte. Je crois en la philosophie "ne faire qu'une chose mais la faire bien". Je ne sais pas si mettre toute la logique d'alerte dans Grafana est la meilleure idée. Quoi qu'il en soit, je viens d'écrire un petit démon node js "flapjack-grafana-receiver" pour publier des événements grafana sur flapjack. Je vais probablement l'ouvrir.

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

Mise à jour en cours!

Au moins une personne travaille à temps plein sur les alertes depuis avril, les progrès n'ont pas été aussi rapides que nous l'aurions souhaité en raison de nombreuses réécritures. Même si nous visons des fonctionnalités d'alerte de base pour la version initiale, nous pensons qu'il est important de bien définir le modèle de règle d'alerte fondamental afin que nous puissions étendre la définition des règles d'alerte et le moteur d'évaluation des règles d'alerte dans les prochaines versions sans une refonte majeure.

L'objectif de commencer par une alerte très simple nous a fait tomber dans des impasses qui ne semblaient pas correctes et a nécessité de grandes réécritures. Mais nous sommes maintenant de retour sur la bonne voie et faisons de bons progrès sur un modèle de règles basé sur les conditions dont nous sommes beaucoup plus satisfaits.

Définition de la règle

Le nouveau modèle de règle d'alerte est composé d'une ou plusieurs conditions. Les conditions peuvent être de différents types. Pour le moment, il n'y a qu'un type de requête. Mais nous pouvons ajouter plus tard des conditions comme Time of day , ou Day of week , ou plus intéressant encore Other alert (vous pouvez donc inclure l'état d'une autre règle d'alerte comme condition).

La condition de requête est composée d'une requête et d'une plage de temps, un réducteur qui prendra tous les points de données renvoyés pour chaque série renvoyée par la requête et la réduira à une seule valeur à utiliser dans la comparaison de seuil. Le réducteur pourrait également à l'avenir être une "prévision" qui effectue une régression linéaire sur les données et prévoit une valeur future.

La partie évaluation de la condition de requête peut être supérieure à, inférieure à, entre etc. Vous pourrez faire glisser des poignées dans le graphique pour définir des seuils.

Le modèle basé sur les conditions offre de nombreuses possibilités intéressantes pour rendre les règles d'alerte plus puissantes à l'avenir sans une refonte totale du moteur. La condition de requête comporte également ces composants enfichables qui permettront une extension (réducteur avec paramètres et évaluateur avec paramètres).

Notifications

La semaine dernière, nous avons travaillé sur les notifications et les choses commencent à se mettre en place !

Nous avons des types de notification par e-mail, webhook et slack. La notification slack a l'air plutôt bien :)

Vouloir aider?

Vous pouvez déjà tester et donner votre avis, le code réside dans la branche d'alerte et vous devez également l'activer dans le fichier de configuration avec.

[alerting]
enabled = true

Fusionner pour maîtriser

Nous sommes très près de fusionner cela pour maîtriser et continuer le travail là-bas. J'avais espéré le faire avant mes vacances d'été (je viens de passer 1 semaine) mais il y a encore quelques modifications mineures du schéma SQL que j'aimerais faire avant de fusionner avec master. La fusion vers le master se produira d'ici le 19 août, je le promets :) Après cela, les alertes seront dans la dernière version nocturne 4.0, il vous sera donc facile de tester et de signaler les bogues et les commentaires.

Ce qui reste?

Il manque un certain nombre de fonctionnalités que nous souhaitons pour une version bêta.

• Plus de réducteurs et possibilité de changer de réducteur (seulement en moyenne maintenant)
• La notification par e-mail ressemble à de la merde
• Verrouiller le schéma pour le webhook
• Conception pour la page de liste d'alertes
• Afficher l'historique des alertes
• Afficher l'historique des alertes sous forme d'annotations sur le graphique
• Planificateur d'alertes et stabilité du moteur
• Améliorations du planificateur d'alertes pour répartir la charge (afin que les alertes ne soient pas exécutées en même temps)
• Mise en cluster du planificateur d'alertes

Je suis vraiment désolé que cette fonctionnalité prenne autant de temps.

@torkelo s'il vous plaît avoir la possibilité de mettre les machines en mode maintenance pendant une période définie dans la version bêta.

@torkelo Merci pour la mise à jour. D'après ce que je peux voir, cela vise à avoir des alertes au sein de Grafana. Suivez-vous toujours le cours modulaire présenté dans https://github.com/grafana/grafana/issues/2209#issuecomment -149351263 ?

Merci également à tous les elfes cachés qui y travaillent. Je soupçonne @Dieterbe , mais je ne sais pas.

@RichiH, nous ne savons pas comment cela fonctionnera, nous avons essayé de comprendre comment

@torkelo Mes pensées allaient dans le même sens, c'est pourquoi j'ai décidé de demander.

Personnellement, je me soucie des alertes de Prometheus, mais j'apprécierais une belle intégration visuelle avec Grafana. Peu m'importe où je définis les règles tant qu'elles sont stockées et exécutées par Prometheus.

@bergquist Comme vous serez au promcon, s'asseoir et parler des approches possibles peut avoir du sens. Si vous le souhaitez, je demanderai aux développeurs de Prometheus quelle heure conviendrait le mieux. Il peut y avoir ou non un moment tranquille pour s'asseoir le soir avant et/ou après le nettoyage ; Je peux te renseigner si tu veux.

Bonjour @torkelo - ça a l'air super.

Je viens de retirer votre branche et lorsque je teste une alarme pour ElasticSearch, j'obtiens l'erreur

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

... cela signifie-t-il qu'ElasticSearch n'est pas encore pris en charge :cry:

ps dans la sortie du processus, j'obtiens ceci:

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, nous ne prenons en charge que le graphite pour les alertes jusqu'à présent, mais nous prendrons éventuellement en charge Elasticsearch :) J'ajouterai un meilleur message d'erreur pour cela.

Comment le système d'alerte se comportera-t-il si la requête ne renvoie aucune donnée ? Déclenchera-t-il une alerte par défaut ?
De plus, un simple réducteur count serait cool, qui renvoie simplement le nombre de points de données renvoyés par une requête.

@bergquist Je pensais que l'alerte serait transparente par rapport à la source de données utilisée. Combien de temps avant de pouvoir commencer à prévisualiser/tester la fonctionnalité d'alerte sur une source de données autre que graphite ? (Je me rends compte des questions "combien de temps..." que personne n'aime, désolé)

@RichiH Une option consiste à créer une application grafana comme le fait bosun. https://grafana.net/plugins/bosun-app Mais cela ne permet pas la réutilisation des requêtes / tableaux de bord de manière simple. Parlons-en plus à promcon. Hâte de te rencontrer! :)

Pas de support influxdb au départ aussi ?

je ne connaissais pas sa liaison spécifique au graphite :( Nous utilisons également influx et
recherche élastique ;)

Le lundi 8 août 2016 à 14 h 18, elvarb [email protected] a écrit :

Pas de support influxdb au départ aussi ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

Enrico Kern

Ingénieur système en chef

glispa GmbH
Rue Sonnenburger 73
10437 Berlin, Allemagne

tél. : +49 30 5557130-17
télécopieur : +49 30 5557130-50
skype : flyersaenrico. [email protected]

---

Sitz Berlin, AG Charlottenburg HRB 114678B

Au début, nous ajouterons probablement Prometheus avant la sortie. Peut-être InfluxDB ou Elasticsearch également, étant donné que la planification et l'exécution des alertes se déroulent dans le backend, le code de demande et de réponse a été écrit à partir de zéro (en Go), le code du plug-in de source de données frontend (écrit en js) ne peut pas être réutilisé.

Nous utilisons influx, je pense que nous pouvons renoncer à l'intégration de grafana et utiliser Kapacitor avec une simple interface Web pour créer et gérer des alertes.

+1 Alerte + InfluxDB.

Le lundi 8 août 2016 à 6h01, Thom Nichols [email protected]
a écrit:

Nous utilisons influx, je pense que nous pouvons renoncer à l'intégration de grafana et utiliser
Kapacitor avec une interface Web simple pour créer et gérer des alertes.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

Deepak

Il est regrettable que le travail que nous avons consacré à la création de plugins de source de données ne soit utile que sur le client.

Compte tenu du travail immédiat et à long terme prenant en charge les alertes pour différentes sources de données, la construction d'une architecture de plug-in go, etc., ne serait-ce pas presque la même quantité de travail (sinon moins) pour créer le serveur d'alerte dans NodeJS, afin qu'il puisse utiliser plug-ins de source de données ?

Mis à part les opinions sur go vs nodejs, cela pourrait réduire considérablement la duplication de code pour les alertes sur différentes sources de données.

Et si vous n'aimez vraiment pas les nœuds, je parie qu'il existe un mécanisme d'appel pour le chargement et l'exécution de JS.

Alerte +1 pour ElasticSearch

Bonjour, nous attendons le système d'alerte depuis... OpenTSDB ! Peut-on
espérer l'obtenir pour OpenTSDB bientôt ? (Peut-être quand ?)

Merci beaucoup à l'équipe !

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

Alerte +1 pour ElasticSearch

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

Alerte +1 pour ElasticSearch
Aurait-il la possibilité d'exécuter un script sur alerte ?

Avez-vous déjà la branche d'alerte dans une image docker ?

1. Les requêtes d'alerte ne fonctionnent-elles que pour la requête « A » ? Est-ce codé en dur ?
2. Quand pouvons-nous nous attendre à une version d'alerte entièrement fonctionnelle ? (19e toujours la cible)
3. Quand pouvons-nous nous attendre à ce qu'Elasticsearch fonctionne avec les alertes ?

Éditer:

1. Puis-je ajouter plus d'une règle d'alarme par graphique ?
2. Puis-je ajouter des informations sur l'alarme au message HTTP ? (tableau de bord/graph/observed_query/alarm_config/alarm_query/threshold/warn_or_crit/value/observed_timeframe/time_of_occurence)

@DEvil0000

1) Vous pouvez passer à n'importe quelle requête que vous avez dans l'onglet métriques.
2) Entièrement fonctionnel, cela dépend de ce que vous voulez dire. Nous prévoyons de le fusionner pour maîtriser cette semaine. Ensuite, les gens peuvent commencer à tester la construction nocturne et donner leur avis. La version alpha dans les 2-3 semaines, la version bêta et stable dépend des commentaires et de la rapidité avec laquelle elle peut devenir stable
3) Elasticsearch est délicat, nécessite beaucoup de code pour interroger et analyser la réponse en séries temporelles, il viendra donc probablement après l'ajout de la prise en charge de Prometheus et InfluxDB

@torkelo
Je suis nouveau sur elasticsearch, grafana et go lang. Et je pense que vous avez déjà recherché des clients mais les avez-vous vus ?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
Ces bibliothèques pourraient réduire l'effort.

Merci également à tous les elfes cachés qui y travaillent. Je soupçonne @Dieterbe , mais je ne sais pas.

L'alerte est désormais principalement @torkelo et @bergquist (et @mattttt ). Je me suis concentré sur notre futur backend graphite, https://github.com/raintank/metrictank

Je suis très heureux de voir cette fonctionnalité progresser. J'adorerais avoir la prise en charge d'OpenTSDB car d'autres solutions d'alerte (Bosun) ne seraient pas assez conviviales pour une utilisation régulière ici.

J'espère voir l'alarme dans la prochaine version officielle et rendre hommage aux programmeurs qui ont travaillé dur pour coder.

J'espère voir l'alarme dans la prochaine version officielle et rendre hommage aux programmeurs qui ont travaillé dur pour coder.

@superbool désolé de ne pas pouvoir lire ceci et la traduction google n'a pas été très utile

La fusion en master se produira d'ici le 19 août, promis :)

@torkelo hehe la prochaine fois que je parie. Y a-t-il une nouvelle date ?

Pouvons-nous nous attendre à ce que l'alerte pour OpenTSDB soit programmée ?
(modeste) fondation pour encourager le dev.

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

J'espère voir l'alarme dans la prochaine version officielle et rendre hommage aux programmeurs qui ont travaillé dur pour coder.

@superbool https://github.com/superbool désolé je ne peux pas lire ceci et
la traduction google n'a pas été très utile

La fusion en master se produira d'ici le 19 août, promis :)

@torkelo https://github.com/torkelo hehe la prochaine fois que je parie.
nouveau rendez-vous ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-241340597 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@DEvil0000 J'espère que la fonction d'alerte pourra être publiée dans la prochaine version stable de Grafana, et je souhaite rendre un hommage appuyé à tous ceux qui développent l'outil.
Désolé, mon anglais n'est pas très bon, j'espère que vous pouvez comprendre mes mots

@DEvil0000 Le plan était de fusionner vendredi dernier mais en raison d'événements imprévus ( https://twitter.com/torkelo/status/766514688997732352 ) nous avons dû le reporter un peu :) Nous avons encore quelques petites choses à faire.

@torkelo Félicitations !
@bergquist @torkelo J'ai besoin d'une alerte avec élastique avant octobre (alpha me conviendrait). Puis-je vous aider les gars à le mettre en œuvre? Vous avez juste besoin de me fournir quelques informations pour avoir un point de départ ;)

La branche d'alerte a maintenant été fusionnée avec master. :mains_levées:

Nous apprécions tous les commentaires que nous avons reçus de ce problème. Merci à vous tous !
Pour de futures discussions et commentaires, veuillez publier dans le problème d'alerte correspondant ou en créer un nouveau. Cela nous aide à organiser et à prioriser nos travaux futurs. Je ferme ce ticket en faveur des nouveaux. Mais n'hésitez pas à poursuivre la discussion dans ce numéro.

Alors, quelle est la prochaine étape ?

• Version alpha (docs et article de blog)
• Recueillez les commentaires de la communauté.
• Continuez à travailler sur les problèmes restants
• Lancez Grafana 4.0 avec alerte.

Essaye le?

• Vous devez activer les alertes dans la configuration .
• Vous pouvez maintenant trouver des alertes dans le menu latéral.
• Vous pouvez ajouter une alerte en accédant à un panneau graphique et en sélectionnant l'onglet alerte.
• Utilisez le bouton _Test alert_ pour vérifier votre alerte.
• Pour enregistrer l'alerte, il vous suffit d'enregistrer le tableau de bord.
• Configurez la notification sur /alerting/notifications pour être averti des alertes de déclenchement.
• Ajoutez le notificateur à une alerte dans l'onglet Alerte.

Limites actuelles

• Jusqu'à présent, nous ne prenons en charge que le graphite.
• Pour cette version, seul le panneau graphique prend en charge les alertes.

Exemples de tableaux de bord

Vous pouvez trouver des exemples de tableaux de bord dans le dossier des exemples.
Les exemples de tableaux de bord sont basés sur les données de notre faux rédacteur de données graphite. Vous pouvez démarrer graphite et le fake-data-writer à partir de nos fichiers docker-compose.

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

Cela ne doit être considéré qu'à titre indicatif et nous ajouterons plus de documentation sur les alertes dans les semaines à venir.

Bonne alerte ! :cocktail: :tada:

@bergquist Félicitations.

Y a-t-il un problème que nous pouvons suivre concernant l'avenir de cette fonctionnalité ?

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

Il n'y a qu'un « ET » et non un « OU » dans les conditions d'alerte pour ajouter « est au-dessus » OU « est en dessous » dans un panneau ou existe-t-il un autre moyen de le soutenir ?

Je pense qu'il existe une option "est hors de portée"/"est à portée". Mais j'aimerais aussi voir un "ou".

Bonjour à tous! Merci beaucoup pour votre contribution à cette fonctionnalité utile.

C'est vraiment intéressant pour moi, mais dans de nombreux cas, j'aurais besoin d'un "OU" dans les conditions d'alerte car il n'y a aucune possibilité de créer plus d'une alerte dans un gragh.

Je pense que sans ce "OU" je ne pourrai pas créer d'alertes pour ce genre de graphes :

Une idée? Envisagez-vous d'ajouter une option « OU » ?

BR

@jmgonzalezp oui, nous espérons également prendre en charge OR (pas encore sûr de mélanger AND et OR)

Nous avons 2 décisions de conception restantes pour alerter sur lesquelles nous aimerions avoir des commentaires (catégorisation et gravité/état).

Voici le problème avec nos pensées actuelles et nous apprécierions vraiment vos commentaires.
https://github.com/grafana/grafana/issues/6007

Salut tout le monde! Merci pour cette fonctionnalité si géniale dans grafana!

J'ai une question concernant ce système d'alerte. Actuellement, nous utilisons un groupe de mise à l'échelle automatique dans AWS pour déployer grafana. Est-ce que cela poserait un problème si j'exécute grafana sur plusieurs machines ? Le problème auquel je fais référence est le suivant : y aurait-il plusieurs mêmes alertes provenant de plusieurs machines grafana ? Ou grafana a déjà géré ça ?

@torkelo J'ai la même question que @akurniawan. Considérons cette configuration : 1 équilibreur de charge, 3 instances Grafana derrière l'équilibreur de charge, 1 base de données Mysql que les 3 instances partagent. Comment les serveurs Grafana géreront-ils les alertes dans ce type de configuration ? Devrions-nous alors activer les alertes uniquement sur 1 instance ou Grafana garde une trace des alertes afin que plusieurs nœuds ne vérifient pas et n'envoient pas les mêmes alertes ?

Les alertes @akurniawan dans grafana ne prennent pas encore en charge la haute disponibilité. Notre plan est d'ajouter la prise en charge des alertes de partition entre les serveurs à l'avenir.

@bergquist Merci pour la réponse. :)

@bergquist Un ETA sur le moment où le support InfluxDB sera ajouté pour cela?

@thisisjaid à en juger par ce https://github.com/grafana/grafana/milestone/40 il devrait être ici le 10.

@Dieterbe Un ETA pour alerter le support d'OpenTSDB ?

@sofixa Merci, j'aurais dû regarder la feuille de route moi-même, cas de non RTFMing. Apprécié quand même.

@Dieterbe Un ETA pour alerter le support d'OpenTSDB ?

Je ne travaille plus sur les alertes. peut-être que @torkelo ou @bergquist peuvent répondre.

@torkelo @bergquist

Tout ETA pour la prise en charge des alertes pour OpenTSDB

@LoaderMick @naveen-tirupattur L'alerte OpenTSDB est ajoutée à Grafana, devrait faire partie de la prochaine version. De plus, l'alerte pour OpenTSDB fonctionne dans les versions nocturnes.

Un ETA pour alerter le support pour influxDB et prometheus aussi ?

L' alerte

Je n'arrive pas à faire fonctionner l'alerte avec OpenTSDB avec (Grafana v4.0.0-pre1 (commit: 578507a)). J'ai testé le système de messagerie (fonctionnant) mais les alertes ne se déclenchent tout simplement pas même lorsque j'ai un seuil très bas. Existe-t-il de toute façon pour exécuter les requêtes manuellement et voir les données qu'il extrait ?

Grafana v4.0.0-pre1 (validation : 9b28bf2)
erreur tsdb.HandleRequest() erreur Influxdb a renvoyé statuscode code d'état invalide : 400 Bad Request

@torkelo
La "notification d'alerte webhook" peut-elle publier la métrique d'alerte, le json ou le type de formulaire ?

Salut les gars, Grafana prendra-t-il en charge les alertes pour les requêtes utilisant des variables de modèle ou existe-t-il une version cible pour cela ?

Tous, veuillez essayer la version 4.0 bêta ; s'il manque quelque chose, ouvrez de nouveaux problèmes.

Richard

Envoyé par mobile; excusez ma brièveté.

J'ai essayé la version 4.0 bêta, mais j'ai toujours cette erreur
erreur tsdb.HandleRequest() erreur Influxdb a renvoyé statuscode code d'état invalide : 400 Bad Request

Je ne peux pas enregistrer les notifications d'alerte - envoyer à, après avoir enregistré, la ligne d'envoi à est redevenue vide

@nnsaln Vous êtes censé remplir la cible de notification là-bas, pas l'adresse e-mail. Ouvrez le menu latéral de grafana et survolez l'option de menu Alerte, puis appuyez sur les options de menu Notifications. Là, vous pouvez configurer une cible de notification que vous pouvez utiliser à partir de vos règles d'alerte.

Existe-t-il un plan pour prendre en charge les variables de modèle avec les alertes ? je fais
comprendre chaque graphique généré par une variable modèle (ou un ensemble) correspond
à un graphique différent et donc générer une alerte contre une valeur statique est
Pas correcte.

Le lundi 5 décembre 2016 à 02h06, Tomas Barton [email protected]
a écrit:

@nnsaln https://github.com/nnsaln Vous êtes censé remplir la notification
cibler là, pas l'adresse e-mail. Ouvrez le menu latéral de grafana et survolez
l'option de menu Alerte, puis appuyez sur les options de menu Notifications. Là
vous pouvez configurer une cible de notification que vous pouvez utiliser à partir de vos règles d'alerte.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

--
Deepak

Non, il n'y a actuellement aucun support pour le faire. Peut-être dans un avenir lointain mais

99% des tableaux de bord utilisent des variables de modèle. Ils ont été conçus avec un modèle
variables pour éviter le problème "d'explosion du tableau de bord".

Le lundi 5 décembre 2016 à 20h20, Torkel Ödegaard [email protected]
a écrit:

Non, il n'y a actuellement aucun support pour le faire. Peut-être dans un avenir lointain mais

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

--
Deepak

Oui, mais un tableau de bord d'exploration générique n'est pas la même chose qu'une conception de tableau de bord pour les règles d'alerte.

Jusqu'à présent, il n'y a pas eu de proposition sur la façon de prendre en charge les variables de modèle de manière intuitive / compréhensible. Que doit faire la requête d'alerte avec variable ? Interpoler avec la valeur de variable enregistrée actuelle, avec tout ? Devrait-il traiter chaque valeur comme une règle distincte et conserver l'état pour chaque etc. La prise en charge des variables de modèle ouvre une boîte de vers pour la complexité et un comportement potentiellement déroutant. pourrait être ajouté un jour si quelqu'un propose un moyen simple et compréhensible.

En attendant, rien ne vous empêche de créer des tableaux de bord d'alertes séparés.
L'alerte est nouvelle et un énorme ajout à grafana. Il évoluera dans le temps,
mais en peu de temps, il a été mis en œuvre, il a ajouté une valeur énorme à grafana,
et merci à tous les contributeurs pour cela !

Suis 06.12.2016 11:14 nahm. schrieb "Torkel degaard" <
[email protected]> :

Oui, mais un tableau de bord d'exploration générique n'est pas la même chose qu'un tableau de bord
conception de règles d'alerte.

Jusqu'à présent, il n'y a pas eu de proposition sur la façon de prendre en charge les variables de modèle
d'une manière intuitive/compréhensible. Que doit alerter la requête avec variable
faire? Interpoler avec la valeur de variable enregistrée actuelle, avec tout ? Devrait-il
traiter chaque valeur comme une règle distincte et conserver l'état pour chaque etc.
la modélisation des variables ouvre une boîte de vers pour la complexité et potentiellement
comportement déroutant. pourrait être ajouté un jour si quelqu'un propose un
manière simple et compréhensible.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 Torkel.

Cela rend l'alerte assez compliquée.

Le mar. 6 déc. 2016 à 14:14, Torkel Ödegaard [email protected]
a écrit:

Oui, mais un tableau de bord d'exploration générique n'est pas la même chose qu'un tableau de bord
conception de règles d'alerte.

Jusqu'à présent, il n'y a pas eu de proposition sur la façon de prendre en charge les variables de modèle
d'une manière intuitive/compréhensible. Que doit alerter la requête avec variable
faire? Interpoler avec la valeur de variable enregistrée actuelle, avec tout ? Devrait-il
traiter chaque valeur comme une règle distincte et conserver l'état pour chaque etc.
la modélisation des variables ouvre une boîte de vers pour la complexité et potentiellement
comportement déroutant. pourrait être ajouté un jour si quelqu'un propose un
manière simple et compréhensible.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

--
Deepak

@bergquist concernant ce commentaire

les alertes dans grafana ne prennent pas encore en charge la haute disponibilité. Notre plan est d'ajouter la prise en charge des alertes de partition entre les serveurs à l'avenir

Existe-t-il un ticket pour suivre la progression ? Une branche à contribuer ?

Et un grand merci pour le beau travail!

Kern,

<3 ans.

J'essayais juste de partager des réflexions sur les alertes avec un modèle
tableaux de bord.

Le vendredi 9 décembre 2016 à 02h53, Dmitry Zhukov [email protected]
a écrit:

@bergquist https://github.com/bergquist concernant ce commentaire

les alertes dans grafana ne prennent pas encore en charge la haute disponibilité. Notre plan est d'ajouter
prise en charge des alertes de partition entre les serveurs à l'avenir

Existe-t-il un ticket pour suivre la progression ? Une branche à contribuer ?

Et un grand merci pour le beau travail!

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

--
Deepak

@torkelo @Dieterbe C'est génial d'avoir enfin des alertes intégrées à Grafana ! Quelle est la méthode recommandée (le cas échéant) pour créer des alertes par programmation ?

@jaimegago pour créer des alertes par programmation, utilisez l'API du tableau de bord, les alertes sont enregistrées avec un panneau et un tableau de bord.

@torkelo Qu'en est-il des cibles de notifications (par exemple créer un nouvel e-mail de notification via l'API) ?

edit: En me répondant ici, j'ai trouvé le point de terminaison api/alert-notifications. Je pense qu'il faut juste documenter

Bien sûr, il existe une API http pour cela, il suffit d'aller sur la page des notifications d'alerte, d'ajouter une notification et de vérifier l'appel de l'API http que grafana fait

@torkelo , existe-t-il une API pouvant être utilisée pour créer une alerte (pas créer une notification d'alerte) par programmation

@CCWeiZ Alerts fait partie du json du tableau de bord. Ainsi, vous pouvez uniquement créer un tableau de bord contenant des alertes et non uniquement des alertes.

Vous pouvez en savoir plus sur l'API du tableau de bord sur http://docs.grafana.org/http_api/dashboard/

est-ce disponible : je souhaite configurer une alerte pour que si une valeur se compare à il y a 3 jours, la valeur n'augmente pas. (dit les demandes, si maintenant la valeur - il y a 3 jours demandes < 100, alors nous disons qu'il n'y a pas beaucoup de demandes.). Comment faire cela ?