Grafana: [Demande de fonctionnalité] Plusieurs alertes par graphique

Cas d'utilisation concret : j'ai instrumenté mon application pour enregistrer un histogramme dans Prometheus pour chaque fonction principale (par exemple, lorsqu'un appel HTTP externe ou une E/S de disque a lieu) et je souhaite alerter lorsque l'une d'entre elles devient lente.

Actuellement, je dois définir des graphiques factices pour cela en raison de la relation 1: 1 entre le graphique et l'alerte. Il serait beaucoup plus logique de conserver les alertes définies au même endroit que le graphique lui-même.

Et vous ne pouvez pas définir cela dans une requête ?

Non; une chaîne de conditions OR est grossière, et le nom unique de l'alerte ne permet pas d'identifier clairement la raison exacte de l'alerte. Je ne veux certainement pas envoyer d'alertes du type Some part of service X is failing - les ingénieurs de garde ne seraient pas mes amis...

alors il est plus logique d'avoir des panneaux séparés pour les alertes, si vous voulez un nom et un message de règle d'alerte distincts, etc.

Oui c'est exactement ce que je fais en ce moment. Existe-t-il une probabilité d'implémenter plusieurs alertes par graphique dans un avenir proche afin que je puisse m'éloigner de cette solution de contournement ?

c'est très peu probable

peut-être s'il y a une énorme demande pour cela :)

haha OK - Je vais voir si je peux mettre en place une foule en colère ;) Sérieusement, merci pour l'honnêteté.

Ok, nous avons une foule de deux :-) Je trace les niveaux de carburant dans plusieurs réservoirs et je voulais configurer une alerte de carburant bas pour chaque réservoir.

et chaque réservoir a des seuils ou des notifications différents ?

Exactement. L'un est un réservoir d'huile de chauffage de 285 gallons. Je voulais mettre en place une alerte "faible niveau d'huile de chauffage" lorsque ce réservoir descend en dessous de 70 gals. L'autre est un réservoir de propane de 500 gal, pour cela je voulais une alerte "propane bas" lorsqu'il passe en dessous de 100 gal. J'ai mis en place des singlestats pour chacun mais les alertes ne sont pas disponibles dans un singlestat.

J'ai un graphique avec une médiane et une métrique du 90e centile. J'aimerais recevoir une alerte sur chacun. Pour ce faire, je dois créer un graphique pour chacun. Ensuite, si je veux des avertissements et des alertes critiques pour chacun, je dois créer un deuxième graphique pour chacun.

J'ai 30 ou 40 services à surveiller, chacun avec 2 à 5 métriques clés. J'ai des graphiques dans lesquels je représente graphiquement la même métrique pour plusieurs clients, et même si je n'ai pas (encore) à faire d'alertes par client, cela ajoute au nombre de métriques sur lesquelles j'aimerais avoir des alertes. La quantité de travail pour créer des dizaines de graphiques augmente très rapidement. Il serait très utile dans mon environnement de production actuel (et dans mes environnements de production précédents) d'avoir des avertissements et des alertes critiques, et d'afficher plusieurs métriques dans un seul graphique et d'alerter dessus.

J'aimerais aussi voir cette fonctionnalité. Un bon exemple est une alerte si une métrique dépasse un seuil et une autre alerte si les données ne se mettent pas à jour. C'est-à-dire si une valeur devient trop élevée ou si les valeurs ne sont pas signalées. Cela pourrait être utilisé pour montrer que tout ce qui rapporte les données a rencontré un problème qui empêche la communication avec grafana (ou n'importe quel backend).

Salut Torkelo !

J'ai eu plusieurs "j'aime" pour la fonctionnalité ! Allons-nous entrer dans la prochaine version =) ?

@rmsys peut-être qu'à un moment donné, le résoudre du point de vue UX et de la complexité du code (et de la complexité UX) prendra du temps, ce n'est pas encore sur une feuille de route, mais peut-être l'année prochaine, alors que le moteur d'alerte mûrit davantage et qu'une conception UX pour cela est travaillé en dehors

Un autre bon cas d'utilisation pour plusieurs alertes consiste à avoir différents seuils de gravité avec différentes actions. Si un serveur commence à présenter des ralentissements, un e-mail peut suffire, mais si les ralentissements deviennent extrêmes, il peut être utile de contacter l'administrateur.

J'ai un graphique qui renvoie une métrique avec la valeur de valid et invalid . Cela me serait utile car je pourrais utiliser un seul graphique contenant deux requêtes pour créer des alertes qui se déclenchent lorsque les valid sont trop bas et les invalid sont trop élevés.

De plus, le suivi des états séparés d'une alerte n'est pas toujours préféré (car l'utilisateur final aurait besoin de connaître les détails derrière les états individuels) plutôt que de simplement savoir si l'alerte est déclenchée.

Pas sûr de comprendre ce que tu veux dire par là. Peux-tu élaborer?

Pouvez-vous décrire le fonctionnement et l'aspect de plusieurs alertes par graphique ? Que diraient les annotations et le cœur vert/rouge à côté du titre du panneau (si disons 2/5 règles d'alerte où le déclenchement) ?

Voudriez-vous partager quelque chose entre les règles d'alerte ou seraient-elles complètement isolées (en plus de vivre dans le même panneau graphique et de se référer éventuellement aux mêmes requêtes).

Comment visualiseriez-vous les seuils lorsque vous avez plusieurs règles d'alerte ? Apparaîtraient-elles en tant que règles distinctes dans la page des règles d'alerte et le panneau de la liste des alertes ? Ensuite, vous avez besoin d'un moyen d'accéder à une instance spécifique d'une règle et pas seulement à l'onglet d'alerte.

Grafana est un outil visuel et nous avons choisi de lier une règle d'alerte à un graphique afin que l'état de la règle d'alerte puisse être visualisé facilement (via les métriques, les seuils et l'historique de l'état d'alerte). Je crains que le fait que chaque graphique puisse représenter plusieurs règles d'alerte compliquera cela dans une très large mesure et je ne suis pas sûr de la nécessité de cela.

@rssalerno ayant la prise en charge des règles d'alerte dans le panneau singlestat ne semble pas lié à ce problème.

@alex-phillips, votre scénario semble pouvoir être résolu en assouplissant les règles d'alerte individuelles.

Est-ce que quelqu'un a des exemples concrets où ce serait bien? Ne pas voir un scénario où il se retrouverait dans un graphique déroutant avec 2 à 5 seuils que vous ne savez pas concerne les annotations de métrique et d'historique d'alerte dont vous ne savez pas non plus de quelle règle d'alerte elles proviennent (sans survol).

Pouvez-vous décrire le fonctionnement et l'aspect de plusieurs alertes par graphique ? Que diraient les annotations et le cœur vert/rouge à côté du titre du panneau (si disons 2/5 règles d'alerte où le déclenchement) ?

Je pense que plusieurs règles d'alerte seraient annotées individuellement. Les cœurs peuvent être codés par couleur. Les règles devraient être nommées pour différencier les alertes/panneaux.

Voudriez-vous partager quelque chose entre les règles d'alerte ou seraient-elles complètement isolées (en plus de vivre dans le même panneau graphique et de se référer éventuellement aux mêmes requêtes).

En général, je pense que non, même si je soupçonne que les groupes devraient avoir un seuil partagé et un nom s'ils étaient mis en œuvre (par https://github.com/grafana/grafana/issues/6557#issuecomment-324363795).

Comment visualiseriez-vous les seuils lorsque vous avez plusieurs règles d'alerte ? Apparaîtraient-elles en tant que règles distinctes dans la page des règles d'alerte et le panneau de la liste des alertes ? Ensuite, vous avez besoin d'un moyen d'accéder à une instance spécifique d'une règle et pas seulement à l'onglet d'alerte.

Si les règles prennent un paramètre de couleur supplémentaire, les seuils peuvent être rendus à l'aide de cela, et différenciés en tant que tels, voudront probablement également une info-bulle. Pouvoir basculer entre les règles serait utile, et un paramètre pour rendre une règle spécifique prend en charge cette dernière, je pense?

@rssalerno ayant la prise en charge des règles d'alerte dans le panneau singlestat ne semble pas lié à ce problème.

Je crois que vous constaterez qu'il faisait référence au graphique ci-dessous, bien qu'étant donné qu'il a des panneaux séparés pour chaque réservoir, l'alerte singlestat peut résoudre son problème pour ce tableau de bord spécifique.

Est-ce que quelqu'un a des exemples concrets où ce serait bien? Ne pas voir un scénario où il se retrouverait dans un graphique déroutant avec 2 à 5 seuils que vous ne savez pas concerne les annotations de métrique et d'historique d'alerte dont vous ne savez pas non plus de quelle règle d'alerte elles proviennent (sans survol).

Principalement, j'aimerais que cela prenne en charge # 6557 et # 6553, et pour plusieurs seuils, similaires à @alex-phillips. Par exemple, un cas d'utilisation que nous avons pour #6557 est d'alerter différemment pour différents environnements ( production , beta , dev , etc.), combiné avec plusieurs seuils qui résoudre la plupart de nos problèmes. S'il y a une meilleure façon de faire cela sans plusieurs règles, ce n'est pas évident pour moi.

@torkelo

Pouvez-vous décrire le fonctionnement et l'aspect de plusieurs alertes par graphique ? Que diraient les annotations et le cœur vert/rouge à côté du titre du panneau (si disons 2/5 règles d'alerte où le déclenchement) ?

J'aime l'approche suggérée par @pdf

De plus, l'approche pour afficher les annotations serait la même que dans le cas actuel, où vous avez une règle d'alerte avec > 1 conditions (chacune ayant un seuil différent). Et le cœur vert/rouge à côté du titre du panneau serait affiché en rouge (s'il y a au moins une alerte qui se déclenche), similaire au scénario actuel où au moins une condition d'une règle d'alerte est évaluée comme vraie). Et probablement aussi afficher le nombre (2/5) avec le cœur rouge dans le titre.

Voudriez-vous partager quelque chose entre les règles d'alerte ou seraient-elles complètement isolées (en plus de vivre dans le même panneau graphique et de se référer éventuellement aux mêmes requêtes).

Dans la plupart de nos cas d'utilisation, ces règles ne partageraient rien entre elles et les requêtes sont également différentes

Comment visualiseriez-vous les seuils lorsque vous avez plusieurs règles d'alerte ? Apparaîtraient-elles en tant que règles distinctes dans la page des règles d'alerte et le panneau de la liste des alertes ? Ensuite, vous avez besoin d'un moyen d'accéder à une instance spécifique d'une règle et pas seulement à l'onglet d'alerte.

Ils apparaîtraient comme des règles distinctes dans la page des alertes. L'onglet Alerte aurait probablement une liste d'alertes définies. À droite, nous aurions besoin de mettre en surbrillance/développer la règle d'alerte spécifique sur cet onglet, lorsque l'URL de la règle alret (devrait capturer l'identifiant ou l'index de l'alerte) est accessible à partir de la notification. Semble être facilement résoluble.

Dans le panneau de la liste des alertes, il n'y aurait aucun changement. Il les montre tous séparément. Sémantiquement, chaque alerte est distincte. Juste qu'il a été placé dans le même panneau.

Est-ce que quelqu'un a des exemples concrets où ce serait bien? Ne pas voir un scénario où il se retrouverait dans un graphique déroutant avec 2 à 5 seuils que vous ne savez pas concerne les annotations de métrique et d'historique d'alerte dont vous ne savez pas non plus de quelle règle d'alerte elles proviennent (sans survol).

Considérant que beaucoup de gens ont voté pour cette fonctionnalité, ce serait certainement une fonctionnalité utile. Si nous prenons en charge plusieurs alertes, je pense que ce serait à la perception de chaque utilisateur de savoir si c'est déroutant ou non. À mon humble avis, ceux qui pensent que cela prête à confusion opteraient pour l'approche actuelle de panneaux séparés pour chaque graphique et pour ceux qui pensent que l'utilité / la commodité d'avoir le même panneau utilisé pour la visualisation et l'alerte l'emporte sur la confusion perçue, opteront pour les alertes multiples . Bien sûr, cela changerait quelque peu l'UX

Dans splunk, nous avons des alertes haut/bas. Si plusieurs alertes dans grafana sont disponibles, nous utiliserons simplement la même recherche, ce ne sont que des seuils différents par rapport à la même recherche.

+1 pour cette fonctionnalité.

+1 pour ça. Notre cas d'utilisation est le suivant : nous voulons définir un graphique avec, par exemple, l'utilisation du processeur pour tous nos serveurs. Ensuite, sur ce même graphique, nous créerons deux métriques cachées, une pour l'utilisation du processeur sur les serveurs de production et une pour l'utilisation du processeur sur les serveurs hors production. Chacune de ces mesures aurait sa propre alerte, avec différents canaux de notification. Nous ne voulons pas avoir à créer plusieurs graphiques, panneaux ou tableaux de bord pour y parvenir.

+1 pour cette fonctionnalité.

Je suis venu ici en lisant certains des autres problèmes concernant les catégories et les gravités. Je suis d'accord que toutes les alertes doivent être actionnables. Mais il y a une différence entre une alerte "réparer cette première chose le matin" et une alerte "appeler le consultant à 400 $/heure dès que possible".

Comme beaucoup l'ont mentionné, cela est le plus souvent résolu par les seuils d'avertissement et critique.

Techniquement, cela pourrait être mis en œuvre de différentes manières, étiquettes, plusieurs alertes par panneau, plusieurs seuils par alerte, etc.

En ce qui concerne la confusion si la catégorisation est trop complexe, une configuration Avertissement/Critique peut simplement utiliser Rouge/Jaune. Le rouge remplace le jaune.

Pour des configurations plus complexes, une autre option en plus du survol pour localiser la série chronologique incriminée pourrait être une ligne/zone/peu importe ? Cela pourrait facilement attirer l'attention sur la bonne série chronologique.

Je pense que la plupart des utilisateurs seraient satisfaits par une séparation Warn/Crit assez simple.

C'est un must absolu pour un logiciel d'alerte, en particulier pour la surveillance des serveurs. Espace disque, mémoire, utilisation du processeur, température, charge moyenne .... tous les meilleurs exemples où l'on voudrait plusieurs alertes configurées avec différents messages avec différents seuils. Prenez l'espace disque par exemple. Besoin d'une alerte pour une utilisation du disque supérieure à 70 %, une autre pour une utilisation du disque supérieure à 90 %.

C'est un peu un cas marginal, mais nous utilisons les alertes pour nous avertir si un produit ne s'est pas vendu en quelques jours. Nous avons chaque produit comme métrique, ce qui signifie que nous ne recevons qu'une seule alerte lorsque l'une des métriques atteint le seuil d'alerte. Idéalement, nous aimerions recevoir une alerte si l'alerte indique qu'une mesure supplémentaire a également atteint le seuil d'alerte.

Nous utilisons également des vars de modèles pour répéter un graphique pour chaque produit sélectionné avec deux mesures superposées (volume et marge brute) sur les axes y gauche et droit. Cela tue toute chance d'utiliser l'alerte car la requête d'alerte ne récupère pas la variable de liste $sku pour notre IN ($sku) .

Pour contourner ce problème, j'ai essayé d'avoir une autre requête B qui exécute simplement la requête de modèle pour rechercher tous les skus qui nous intéressent et les met directement dans la requête d'alerte IN (SELECT skus from interested_product_table) . Cependant, cela commence à nous envoyer des alertes pour chaque graphique pour toutes les mesures de chaque graphique, ce qui signifie que nous obtenons :

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

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

Par exemple, ce qui est assez spam.

Entièrement d'accord que la fonctionnalité est indispensable et totalement en désaccord sur le fait que TOUTES les notifications devraient être exploitables.

L'exemple le plus simple est que vous pourriez recevoir des alertes et que vous devez agir dès que possible, comme le lendemain matin, alors qu'il existe d'autres types d'alertes qui devraient vous réveiller même au milieu de la nuit pour réparer les serveurs de production.

Jeter dans mes deux cents - j'aimerais avoir cette fonctionnalité.

Je n'ai même pas besoin de cœurs différents ou de cœurs de couleurs différentes (rouge pour toute alerte sur le graphique, c'est bien), ce sont les notifications par e-mail pour lesquelles je veux des noms différents.

Veuillez ajouter cette fonctionnalité. pour un cas d'utilisation comme celui-ci,
à partir d'un seul graphique
si valeur > X --> mou
si Valeur > X+Y --> PD

Nous avons ici une politique d'alertes actionnables, où l'alerte doit spécifier l'action à entreprendre si possible. Nous avons différentes actions à prendre en fonction des métriques trop faibles ou trop élevées.

Par exemple : CPU RDS trop bas ? vérifiez l'autre pile ici pour le comportement. Trop haut? Faites évoluer l'instance.

Comme pour les autres, nous aimons également avoir différents types d'alertes à différents seuils.

Semblable à @jdblack, je veux avoir un niveau d'avertissement de niveau d'eau élevé et un niveau d'urgence d'eau élevée. Je sais que je peux le faire avec deux requêtes, mais ce n'est pas aussi intuitif ou astucieux.

Je pensais utiliser Grafana comme moyen de signaler un système de mise à l'échelle automatique. Si la métrique est trop faible, envoyez un webhook avec un message à réduire, si elle est trop élevée, envoyez un webhook avec un message à réduire. Sans plusieurs alertes, je ne crois pas que ce ne soit pas possible. Je suis également d'accord avec d'autres dans le fil que le cas d'utilisation d'un "avertissement" puis d'un seuil "critique" est courant.

Peut-être faudrait-il revoir l'idée de coupler les alertes à un graphique ? Peut-être que les alertes devraient être créées séparément, avec un joli graphique de prévisualisation lors de la création de l'alerte. Ce découplage pourrait rendre plus de travail lors de la modification d'une métrique de graphique, mais au moins, il aurait plus de flexibilité pour créer plusieurs alertes.

J'ai essayé d'utiliser Grafana + Influx pour les réseaux de capteurs. Les tableaux de bord fonctionnent plutôt bien, sauf pour les alertes. J'ai besoin d'être alerté lorsque Sensor123 dépasse un certain seuil. Je n'ai pas besoin d'un graphique pour cela, juste une alerte. De plus, j'ai besoin d'avoir potentiellement des milliers de capteurs. Je peux configurer une alerte si "n'importe quel" capteur dépasse le seuil, mais j'ai besoin de savoir lequel(s) est/sont en alerte. J'ai configuré des tableaux de bord avec des variables de modèle pour afficher un capteur spécifique, mais je ne peux pas ajouter d'alerte pour une variable de modèle. Pour les tests, je viens de configurer une poignée d'alertes pour une poignée de capteurs dans un tableau de bord supplémentaire que personne ne regarde, mais pour aller de l'avant, j'ai besoin d'une solution différente pour les alertes.

@torkelo , Approche d'un an depuis tout commentaire officiel à ce sujet - je me demande simplement s'il y a des mises à jour qui peuvent être partagées maintenant que le système d'alerte est dans la nature depuis un certain temps ?

@MakoSDV , vous devriez envisager d'utiliser kapacitor pour ce cas d'utilisation.

+1 pour cette fonctionnalité ; ce serait également très utile pour les alertes à deux niveaux (par exemple : quelque chose > X = alerte jaune, quelque chose > Y = alerte rouge)

+1 pour rendre l'alerte plus flexible

Je surveille les graphiques de température dans une chaudière de chauffage, le seuil de basse température est trivial et doit passer par un canal de notification non critique, mais la haute température est urgente et doit bourdonner via le canal urgent. Plusieurs règles d'alerte auraient beaucoup de sens ici.

C'est dommage que ce problème semble abandonné. Est-ce que quelqu'un sait comment attirer l'attention des développeurs ?

Il semble que du point de vue de l'interface utilisateur, il serait relativement facile d'implémenter des alertes de la manière dont les remplacements sont implémentés, pour autoriser une ou plusieurs alertes sans trop de modifications de l'interface utilisateur.

@Gaibhne a écrit :

Est-ce que quelqu'un sait comment attirer l'attention des développeurs ?

Payer pour l'assistance peut-être ? Il semble qu'il n'y ait pas eu de ressources disponibles pour l'une des graves lacunes liées aux alertes, bien qu'elles soient restées les problèmes les plus notés par les utilisateurs de Github pendant des années.

+1 pour cette demande.

Nous avons un compteur configuré dans notre application pour le moment où une demande à un service externe que nous intégrons avec des délais d'expiration pour lesquels nous avons créé un graphique dans Grafana.

S'il y a quelques temps morts que nous aimerions savoir afin que nous puissions en parler au service externe plus tard, s'il y a beaucoup de temps morts, cela signifie que notre application est susceptible d'avoir été affectée pour la plupart des clients, nous devons donc répondre et traitez-le immédiatement.

+1 pour ça aussi.

Tentative de configuration de deux alertes distinctes pour un graphique :

1. Message de marge pour les données atteignant un niveau _warning_
2. Alerte Pager Duty pour les données atteignant un niveau _critique_

Actuellement, à ma connaissance, je devrais créer deux graphiques distincts des mêmes données afin d'accomplir cela. Il serait plus logique pour moi d'avoir plusieurs alertes différentes agissant sur le même graphique.

@torkelo y a-t-il une mise à jour sur les plans pour cela en 2019 ?

+1

Nous avons des tableaux de bord qui surveillent les mêmes microservices pour plusieurs clients/environnements en utilisant une variable pour basculer entre les environnements affichés.

Notre douleur actuelle pourrait être réduite si nous pouvions utiliser des variables dans le titre/le texte de l'alerte afin que nous puissions identifier le client/l'environnement, mais à plus long terme, nous aimerions vraiment pouvoir créer des alertes séparées avec des seuils différents en utilisant le même graphique.

Ce serait formidable même si cela nécessitait d'utiliser une requête différente pour chaque alerte et de simplement définir la requête sur non visible sur le graphique.

Ce que vous décrivez @itonlytakeswon semble également se rapporter à https://github.com/grafana/grafana/issues/6557 , vous voudrez peut-être également suivre celui-ci :)

Comment n'est-ce pas déjà une fonctionnalité ?

@ jsterling7 décrit parfaitement notre cas d'utilisation souhaité.

@torkelo Toute version de fonctionnalité

Soit plusieurs alertes, soit l'autorisation de valeurs de balise dans le titre/corps de l'alerte quelque part résoudrait ce problème pour notre utilisation. Nous avons un seul graphique montrant une métrique taguée avec plusieurs sources indépendantes et nous voulons savoir laquelle tombe en dessous du seuil. Je suis en train de créer les 10 graphiques distincts dont j'aurai besoin pour accomplir cela, mais cela ressemble à une fonctionnalité manquante et médiocre pour la maintenance à long terme de mon côté.

Il semble que ce soit une forte demande, je suis l'un d'entre eux qui a besoin de ce type de fonctionnalité. J'aime presque la grafana puis soudain cette limitation me rebute.

Mon cas d'utilisation est similaire à d'autres référencés ici et au problème #6557. Nous avons plusieurs clusters elasticsearch surveillés dans un seul modèle de tableau de bord. Je voudrais déclencher des alertes pour eux individuellement et comme c'est le cas maintenant, je ne peux pas simplement créer un graphique avec les requêtes codées en dur, mais je dois créer un graphique pour chaque cluster, afin que ces alertes fonctionnent ...

+1, cela aiderait grandement notre environnement ! Même juste une configuration de deux alertes jaune / rouge «cœur» par graphique, où si le rouge est déclenché, il remplace le jaune.

+1 ce serait génial, se demandant à quel point il serait trivial de simplement autoriser chaque condition à avoir une notification d'alerte configurable facultative et si ce n'est pas pour une condition spécifique, il peut se rabattre sur un message de notification par défaut ... le moyen le plus rapide d'y arriver je pense ?

+1 cela nous serait également très utile. Nous avons beaucoup de tableaux de bord avec des modèles sur plusieurs variables, ce serait formidable d'avoir une substitution de modèle effectuée à la fois sur le nom de l'alerte et sur la notification d'alerte.

+1, IMO cela devrait être présent dans chaque système de surveillance... il existe de nombreuses situations où vous devez identifier la gravité de l'alerte et réagir en conséquence, ce qui signifie plusieurs alertes avec différents seuils dans le même tableau de bord.

+1 de moi aussi - surpris que cela n'existe pas déjà !

+1

Je pense que cette fonctionnalité va de pair avec la limitation de la prise en charge des requêtes de modèle.

J'ai mis en place quelques graphiques alimentés par prometheus avec des requêtes qui ont des modèles sur l'instance et des étiquettes de type. Je contourne le problème du modèle en créant des requêtes invisibles pour les valeurs du modèle.

Je souhaite des alertes distinctes pour chaque valeur de modèle, mais je suis limité à une seule alerte avec une action + un message générique à taille unique. Je peux utiliser une longue liste OU pour alerter sur toutes mes requêtes, mais cela semble grossier.

Une alternative consiste à créer un tableau de bord séparé avec des tonnes de panneaux que personne ne regarde, juste pour servir de source d'alerte.

L'ajout de la prise en charge de plusieurs alertes semble être la première étape de la prise en charge des alertes de requête de modèle.

+1. C'est quelque chose qu'on se doit d'avoir!

+1 C'est extrêmement utile

@torkelo "alors il est plus logique d'avoir des panneaux séparés pour les alertes, si vous voulez un nom et un message de règle d'alerte distincts, etc."

Cela n'a aucun sens. Exiger que les utilisateurs visualisent le même panneau plusieurs fois juste pour pouvoir envoyer des messages d'alerte non génériques utiles n'est pas une solution. C'est un hack pour quelque chose qui devrait être une fonctionnalité, et cela ajoute du bruit qui dégrade l'utilité du produit.

@torkelo "alors il est plus logique d'avoir des panneaux séparés pour les alertes, si vous voulez un nom et un message de règle d'alerte distincts, etc."

Cela n'a aucun sens. Exiger que les utilisateurs visualisent le même panneau plusieurs fois juste pour pouvoir envoyer des messages d'alerte non génériques utiles n'est pas une solution. C'est un hack pour quelque chose qui devrait être une fonctionnalité, et cela ajoute du bruit qui dégrade l'utilité du produit.

Exactement. +1 pour plusieurs alertes par panneau

Dans notre situation, nous mesurons les tensions des cellules dans les batteries (16 cellules par batterie). Nous représentons graphiquement les 16 séries sur un seul panneau à des fins de comparaison et avons un panneau différent pour chaque batterie.

Une seule alerte pour le panneau (graphique) n'est pas trop utile. Nous avons vraiment besoin de pouvoir configurer au moins une alerte par cellule afin que l'e-mail d'alerte indique quelle(s) cellule(s) est/sont hors de portée en termes de tension.

Étant donné que, dans notre cas, la plage de tension acceptable est la même pour chaque cellule, il serait formidable de pouvoir définir une limite supérieure et inférieure et de relier les plages de cellules individuelles à ces limites définies.

Pour le moment, nous devons programmer 16 instructions x OR pour la série de cellules, et (re)-définir les limites de chaque cellule dans le processus - pénible à mettre en place et un cauchemar de maintenance à modifier.

Idéalement, nous devrions également programmer des événements d'avertissement et critiques pour chacune des cellules du panneau graphique.

Je pense qu'il est grand temps que la structure d'alerte soit modifiée pour englober les exigences que les utilisateurs ont identifiées. Ces exigences sont couramment mises en œuvre dans les systèmes SCADA qui génèrent également des alertes. C'est vraiment juste un moteur logique, sûrement ?

Une mise à jour pour ceci? J'ai l'impression que cette fonctionnalité est indispensable pour les déploiements plus importants. D'autant plus que nous aimerions avoir un seul graphique montrant par exemple l'utilisation du stockage, nous voulons une alerte pour 70%, 80% etc etc etc qui ne devrait pas contenir d'énormes quantités de graphiques.

Je viens juste de tomber dessus et je suis très surpris qu'il n'y ait pas encore de moyen de le faire D:

Je vois ici https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 que cela ne sera pas implémenté à l'avenir et que les alertes seront entièrement retirées des tableaux de bord.

Comment cela affectera-t-il le modèle json du tableau de bord ? Quelqu'un peut-il dire quand il y aura plus de nouvelles à ce sujet?

C'était une fonctionnalité indispensable. Une mise à jour sur la situation à venir?

+1 pour plusieurs alertes par panneau

+1 pour cette fonctionnalité.

C'était une fonctionnalité indispensable. Une mise à jour sur la situation à venir?

Besoin de cette fonctionnalité.

3 ans après.. Quelqu'un peut nous dire pourquoi cela n'est pas mis en place (malgré le nombre de demandes) ?
C'est dû à une contrainte technique pour le mettre en place ? C'est rejeté ? C'est à faire ?
Comme dit précédemment, semble une «fonctionnalité de base».
Exemple : J'ai un tableau de bord et une série avec 200 serveurs, si j'ajoute une alerte :
Un des 200 serveurs est mort : cool je reçois l'alerte avec le nom
Oups, un nouveau serveur est mort : pas d'alerte (ou besoin de rafraîchir le tableau de bord ou d'attendre le rappel 24h après..)
Ce n'est pas possible d'ajouter comme une case à cocher pour être alerté par ligne dans la série (au lieu de la série 'complète') ?
Si quelqu'un du dev, l'équipe de grafana peut répondre pour un feedback...

Cela vous dérangerait-il d'essayer prometheus pour alerter et de laisser grafana faire des tableaux de bord ?

@beastea Si vous devez configurer un autre outil juste pour que Grafana fonctionne, cela ne sert à rien d'utiliser Grafana. Nous passons à Datadog car cette fonctionnalité existe là-bas et ce n'est qu'un seul outil.

@anne-nelson, vous devez configurer le collecteur de métriques, le stockage des métriques et, pour une configuration appropriée, jouer avec HA autour de lui pour faire fonctionner Grafana, n'est-ce pas?
Datadog n'est pas seulement le seul outil, il vous le cache et fait du bon travail, vous pouvez également utiliser grafana avec datadog : https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea Je ne sais pas quels sont ces outils, donc je ne pense pas que nous les utilisons. Nos métriques sont envoyées à Influx, nous allons juste les envoyer à Datadog au lieu de Grafana. Pourquoi est-ce que j'enverrais des choses à Datadog via Grafana alors que je peux simplement les envoyer directement ? Je veux utiliser le moins d'outils possible.

@anne-nelson, vous pouvez implémenter des métriques poussées dans votre application, mais il est parfois très utile d'avoir certaines des métriques système poussées également afin que vous puissiez savoir ce qui se passe avec vos disques et autres éléments. C'est ce que je veux dire par rassembleur de métriques, un démon local qui fait de telles choses, comme telegraf, collectd ou fluentd.
Influx dans votre configuration - est une chose qui stocke les métriques et donne une riche capacité à effectuer des recherches via grafana en tant qu'interface utilisateur Web vers les données brutes qui vous donne une chance en utilisant un langage de requête d'influx interne pour manipuler vos données.
En cas d'avoir Datadog au lieu d'Influx, cela fonctionne exactement de la même manière. Grafana ici -est une interface utilisateur pour l'accès aux données. Dans une configuration générale. Donc, il ne fait rien avec vos données, il les présente simplement sous forme de graphiques. Donc, vous les envoyez de toute façon directement.
Dans le cas où, comme vous l'avez décrit, vous travaillez avec inlux, pourquoi vous n'envisagez pas d'utiliser kapacitor ou flux pour résoudre le problème que vous avez décrit, car ils fournissaient de nombreuses capacités de portée, alors grafana peut vous offrir et ils sont toujours du même fournisseur et comme le même environnement. Flux fait même partie du colis d'expédition d'afflux.

Ce sera vraiment utile.

@beastea donc probablement préférable de supprimer la fonction "alertes" dans grafana et de migrer les gens vers un autre outil (pour éviter une usine à gaz de plusieurs outils) ?
Je veux dire, OK, nous pouvons utiliser kapacitor, prometheus, etc. Mais la fonction d'alerte existe déjà dans Grafana, donc c'est un non-sens dans mon cas.

Au fait, qu'est-ce qui empêche d'ajouter cette case à cocher pour avoir une alerte par ligne ? Une explication peut probablement aider à comprendre.

@beastea Il semble vraiment étrange que vous essayiez de convaincre quelqu'un de ne pas utiliser Grafana.

Comme l'a souligné Anthosz, tant que l'alerte est une fonctionnalité de Grafana, il est raisonnable de s'attendre à pouvoir ajouter plusieurs alertes à un graphique. Si vous pensez que nous ne devrions pas utiliser Grafana pour l'alerte, alors Grafana ne devrait pas avoir d'alerte en tant que fonctionnalité. Il est clair que beaucoup de gens veulent cette fonctionnalité, et que beaucoup de produits concurrents l'offrent déjà. Honnêtement, je ne comprends pas pourquoi il y a autant de recul à ce sujet.

@anne-nelson Je n'essaie pas de convaincre qui que ce soit de ne pas faire ce qu'il aimerait faire. J'essaie de donner un conseil pour jeter un coup d'œil dans la direction différente qui pourrait déjà vous offrir une solution aujourd'hui.
Je ne dicte pas ce que vous devez utiliser pour quoi, je propose une alternative qui pourrait vous donner une solution juste aujourd'hui. Je ne repousse pas, je vous donne un conseil. Si vous pensez que mon conseil n'est pas utile, alors c'est dommage mais c'est tout. Je suis désolé que vous ayez l'impression que je vous agace et que je sois trop insistant avec mes conseils.
Amusez-vous bien.

@beastea , j'avais supposé en raison de votre attitude défensive que vous travailliez pour Grafana. Cette fonctionnalité est pertinente pour beaucoup de gens, et suggérer des produits alternatifs sur une demande de fonctionnalité est inutile et fait dérailler cette discussion. Ce n'est pas un stackoverflow.

Est-ce que tout le monde peut simplement le faire tomber? Vous spammez potentiellement des centaines de personnes, ce n'est pas productif.

Désolé pour le bruit supplémentaire tous.

@torkelo cela vous dérangerait terriblement de nous donner une mise à jour sur cette demande de fonctionnalité ? Ce sujet est ouvert depuis un certain nombre d'années et, comme vous pouvez le constater, suscite toujours de l'intérêt. À tout le moins, cela peut aider à réduire les querelles et les bavardages inutiles sur ce sujet pour obtenir une sorte de réponse "officielle" indiquant si cela est inclus ou non dans la feuille de route actuelle. Acclamations.

Celui-ci et #6041 qui est similaire sont complètement ignorés. Je me demande pourquoi.

Pour nous, cela a du sens, car notre équipe d'exploitation enregistre de nouvelles intégrations dans notre plateforme. Nous commençons automatiquement à envoyer des métriques à graphite. Et un seul panneau en grafana surveille tout cela.

Lorsque plusieurs systèmes tombent en panne, nous ne recevons l'alerte que pour le premier. Et pas très explicatif non plus.

Lorsque l'un est en panne et qu'un second s'éteint également, l'alerte ne se déclenche plus.

Le cas d'utilisation que j'ai pour cela est de définir des alertes de taux de gravure multi-fenêtres via prometheus et grafana. C'est une pratique courante d'avoir des alertes de ce type pour la surveillance des SLO comme défini dans le manuel Google SRE à https://landing.google.com/sre/workbook/chapters/alerting-on-slos/

Un must absolu, veuillez suivre ce sujet..

Je suis également passé de l'alerte Prometheus à l'alerte Grafana et j'attends cela avec impatience !

Quelqu'un qui a déjà travaillé sur Grafana peut-il énumérer les défis connus pour résoudre ce problème ?

Hey @torkelo , peut-être pouvez-vous nous éclairer à ce sujet !

Décevant de voir que 7.x n'a apporté aucune amélioration à l'alerte - la suggestion précédente selon laquelle l'alerte devait être entièrement supprimée ne me remplit pas d'espoir, mais si tel était le cas, la supprimer sûrement dans 7.x aurait été logique compte tenu de l'ampleur de la refonte?

Ce serait formidable d'avoir une sorte de mise à jour sur les raisons pour lesquelles cela est si difficile à mettre en œuvre, juste pour que nous puissions comprendre _ pourquoi _ ce problème est ouvert depuis si longtemps.

@torkelo bonjour.
J'ai le même besoin - plusieurs alertes pour une seule métrique sur un seul graf mais avec plusieurs serveurs surveillés.
J'ai ~ 100 serveurs avec une métrique définie d'espace libre sur la partition '/' (par exemple - car j'ai des dizaines de métriques de ce type). Et je dois recevoir une notification d'alerte unique sur CHAQUE serveur si l'espace libre sur '/' devient inférieur à 20 %.
Actuellement, cela ne se produira pas, si, par exemple, le serveur2 lance une alerte, et pendant que les gars travaillent à résoudre le problème, le serveur4 lance la même alerte - nous ne serons pas avertis. Ou est-ce qu'il me manque une fonctionnalité?

La voie de la multiplication des panels par serveur par métrique n'est pas la voie.
Quelqu'un pourrait-il s'il vous plaît me conseiller, comment rendre cela possible?
Dois-je mettre à jour mon Grafana (la version actuelle est la 6.3.5) ? Ajouter des extensions ? Plugins ? Rien d'autre?

Je remercie et apprécie tous ceux qui peuvent conseiller ou aider.

@torkelo bonjour.
J'ai le même besoin - plusieurs alertes pour une seule métrique sur un seul graf mais avec plusieurs serveurs surveillés.
J'ai ~ 100 serveurs avec une métrique définie d'espace libre sur la partition '/' (par exemple - car j'ai des dizaines de métriques de ce type). Et je dois recevoir une notification d'alerte unique sur CHAQUE serveur si l'espace libre sur '/' devient inférieur à 20 %.
Actuellement, cela ne se produira pas, si, par exemple, le serveur2 lance une alerte, et pendant que les gars travaillent à résoudre le problème, le serveur4 lance la même alerte - nous ne serons pas avertis. Ou est-ce qu'il me manque une fonctionnalité?

La voie de la multiplication des panels par serveur par métrique n'est pas la voie.
Quelqu'un pourrait-il s'il vous plaît me conseiller, comment rendre cela possible?
Dois-je mettre à jour mon Grafana (la version actuelle est la 6.3.5) ? Ajouter des extensions ? Plugins ? Rien d'autre?

Je remercie et apprécie tous ceux qui peuvent conseiller ou aider.

Ce sujet est ouvert depuis 2017 (Et la réponse de @torkelo est 🤡 "c'est plus logique d'avoir des panneaux séparés pour les alertes" 🤡 (très sympa de créer un panneau par serveur/alerte quand on a 600 serveurs) 🤡).

Il semble que le seul moyen soit de migrer de Grafana vers une autre solution ou de créer une usine à gaz avec plusieurs outils à entretenir.

@anthosz - merci beaucoup. Le problème est que l'environnement n'est pas le nôtre mais celui des clients, donc ce serait une sorte de tâche très difficile pour moi d'insister là-dessus pour mon chef de file et pour qu'il surmonte les clients "ne paiera pas pour ça" .
Cependant, au moins j'ai quelques faits disant "aucune possibilité d'organiser de tels déclencheurs / alarmes - de cette façon".

Merci encore.

_rejoindre(voix, chœur)_
J'ai un capteur de courant sur un circuit surveillant une pompe à air, 1,5 A nominal et une pompe d'effluent 10 A nominal. La pompe à air fonctionne 24h/24 et 7j/7, la pompe à effluents fonctionne à la demande en fonction des niveaux du réservoir. Lorsque tout va bien, le courant (I) est soit de 1,5 A lorsque la pompe d'effluent est éteinte, soit de 11,5 A lorsque la pompe d'effluent est allumée.

La première panne courante est la panne de la pompe à air qui est alertée par (Imax < 0,5A ou Iavg entre 9A et 11A) qui détecte soit l'absence de courant, soit la pompe d'effluent en marche lorsque la pompe à air est morte. Ceci doit être résolu dans les 48h pour éviter une défaillance du système. Les données sont de 1 point par minute, alertes après 90 minutes.

La deuxième alerte souhaitée sur le même graphique est (Imax > 14A ou Iavg entre 2A et 9A) qui indique une pompe d'effluent bouchée ou de l'air en ligne alors qu'elle devrait pomper. Il s'agit d'une alerte beaucoup plus urgente qui peut devoir être traitée dans les 3 heures, donc une alerte après 5 minutes serait idéale.

Les deux alertes proviennent du même capteur de courant à distance qui envoie des données via LoRa. Plusieurs alertes me simplifieraient pour ne pas avoir à dupliquer une requête de tableau de bord pour le même capteur.

Les graphiques multiples @torkelo ne sont tout simplement pas évolutifs pour de nombreux utilisateurs. Cela semble être une chose si simple à ajouter et je suis curieux de savoir pourquoi vous ne l'envisagez pas ?

peut-être s'il y a une énorme demande pour cela :)

Hey @torkelo , qu'est-ce que vous considérez comme une énorme demande ? 96 commentaires et 250 "j'aime" dans ton commentaire c'est énorme ? Il s'agit de la 8ème demande de fonctionnalité ouverte la plus commentée et une seule demande de fonctionnalité fermée a plus de commentaires que cela. C'est aussi la 3ème demande de fonctionnalité ouverte avec plus de :+1: réactions. Que faut-il pour entrer dans la feuille de route ?

@torkelo J'ai eu un scénario de cas très simple.

J'ai besoin d'une alerte différente si la valeur passe en dessous du seuil, que l'alerte lorsque la valeur dépasse un seuil (différent).

Voici un scénario différent. Lorsque je surveille le nombre de serveurs sains, j'ai besoin d'alertes différentes lorsque je perds 1 serveur (redémarrage légitime qui n'est pas un problème à moins qu'il ne prenne plus de 10 minutes), par rapport à la perte de 5 serveurs.

Voici encore un autre scénario. Je souhaite définir une alerte différente si le taux d'augmentation d'une file d'attente dépasse un seuil, et une alerte différente si la taille de la file d'attente elle-même dépasse un seuil.

En termes de visualisation, je pense que la communauté serait satisfaite de toute solution pour commencer. par exemple, ne visualisez que la première alerte (donc aucune modification de l'interface utilisateur n'est nécessaire). Visualisez toutes les alertes avec des lignes verticales qui, lorsqu'elles sont survolées, vous indiquent quelle alerte s'est déclenchée. Afficher uniquement les seuils/alertes lorsque vous survolez une série particulière, etc.

Juste mes 2 centimes.

Salut!

Je voulais intervenir ici, nous (Spotify) en avons également besoin.

Nous gérons actuellement notre propre moteur d'alerte d'alertes d'approvisionnement de Grafana et d'alertes par série temporelle. Nous renvoyons actuellement les annotations d'alerte par série temporelle dans grafana.

Ainsi, en termes d'interface utilisateur, la première série temporelle d'alerte fait passer le panneau/l'alerte à l'état "Alerte", et chaque alerte suivante s'accumule (l'historique de l'état affichera plusieurs mises à jour "pour" alerter, et de même, plusieurs changements retour à "ok")

Nous "en avons besoin" car c'est ainsi que nous avons toujours procédé à l'alerte, donc s'éloigner de l'alerte par série temporelle serait un énorme changement social, pour environ 10 000 alertes. Nous aimerions beaucoup utiliser et adopter l'alerte native Grafana et mettre à jour notre source de données pour la prendre en charge.

Je voulais intervenir ici, nous (Spotify) en avons également besoin.

Avez-vous également utilisé l'entreprise Grafana ? Peut-être peut aider/motiver les développeurs =)

Nous aimerions également voir cette fonctionnalité, la possibilité de déclencher plusieurs alertes à partir du même graphique. Donner la possibilité de se déclencher sur un état "inférieur" ainsi que sur un état "supérieur", et avoir la possibilité d'avoir ce qui serait effectivement un avertissement orange avant une violation de seuil plus importante

Nous gérons actuellement notre propre moteur d'alerte d'alertes d'approvisionnement de Grafana et d'alertes par série temporelle. Nous renvoyons actuellement les annotations d'alerte par série temporelle dans grafana.

@sjoeboo est un peu hors sujet ici, mais est-ce que quelque chose est accessible au public ?

@vbichov pas encore , nous voulons ouvrir le moteur d'alerte, bien que le calendrier soit en constante évolution. Je suis sûr que je pourrais partager un patch que nous avons sur notre fork interne (pas idéal) pour permettre le suivi des alertes par série via des annotations.

une note, le moteur d'alerte, en ce moment, est spécifique à notre TSDB (https://github.com/spotify/heroic)

+1 pour cette fonctionnalité. c'est quelque chose comme un avertissement/critique. Nous voulons recevoir un avertissement avant que la vie ne s'aggrave. Ensuite, nous devrions recevoir des alertes critiques pour prendre des mesures immédiates.

Je suis étonné que cela n'ait pas été mis en œuvre après 3 ans de demandes par les utilisateurs.

Devoir créer plusieurs panneaux (un pour chaque alerte) finit par encombrer un tableau de bord et rend l'ajout de nouvelles alertes beaucoup plus compliqué qu'il ne devrait l'être

Je me demande toujours pourquoi il y a un 1 affiché dans l'onglet Alertes si vous ne pouvez pas définir plus d'une alerte par panneau. Dans l'onglet de requête, ce nombre indique également le nombre de requêtes définies. J'ai donc toujours pensé que cela serait possible et je suis assez surpris que ce ne soit pas encore disponible.

Intéressant que cela ne soit toujours pas mis en œuvre. Je conviens que le "compte" sur l'onglet d'alerte est trompeur car il laisse croire qu'il peut y en avoir plusieurs. De plus, avoir un panneau par règle d'alerte est un peu ridicule, car cela signifie que j'ai un tableau de bord "inutile" qui n'est rien d'autre que des panneaux d'alerte. C'est certainement un tableau de bord désordonné, mais c'est le seul moyen de l'implémenter. Principalement, c'est pour que je puisse avoir des règles différentes pour les noms et/ou la combinaison de points de terminaison de notification. C'est pour le moins compliqué.

Cela a-t-il été fait ?
Version Grafana = 4.x

Maintenant, la version Grafana passe à 7.x et je n'ai pas vu cette fonctionnalité

Cela a-t-il été fait ?
Version Grafana = 4.x

Maintenant, la version Grafana passe à 7.x et je n'ai pas vu cette fonctionnalité

Tellement naïf😁

+1 pour cette fonctionnalité.
Sur une seule métrique, je voudrais

1. Une alerte d'avertissement pour indiquer qu'un composant ne se comporte pas comme prévu et nécessite une surveillance étroite par le support de 2e ligne
2. Une alerte d'erreur pour indiquer qu'un composant est défaillant et déclencher des appels à l'ingénierie de 3e ligne.
   La duplication de la métrique est maladroite et rend nos tableaux de bord confus pour le suivi.

Tant de fonctionnalités simples sont constamment refusées par ce groupe, vérifiez les nombreuses autres demandes de fonctionnalités... cela semble être quelque chose de basique.

Je vais donner un autre exemple.

Je dirige un synology et je voudrais alerter à ce sujet. Raid Status a une valeur normale de 1. Cependant, il a également une valeur Degraded de 11 et une valeur Crashed de 12. Degraded signifie que les données sont toujours accessibles. Crashed signifie un risque élevé de perte de données.

Je souhaite envoyer un avertissement si le raid est dégradé et une alarme critique si le raid est en panne.
J'ai plusieurs volumes et pools de stockage et exiger plusieurs graphiques pour chacun n'est pas évolutif.

Cela peut également être appliqué à quelque chose d'aussi simple que l'utilisation de l'espace disque.
Je souhaite envoyer un avertissement si l'utilisation du disque atteint 80 % et une alarme critique si l'utilisation du disque atteint 90 %. Faire plusieurs graphiques pour CHACUN de mes disques n'est pas une demande raisonnable.

Et je ne comprends pas le commentaire selon lequel c'est difficile dans l'interface utilisateur. Vous avez déjà quelque chose de similaire qui est une liste de tableaux de bord. Lorsque vous cliquez sur l'onglet Alerte, il doit afficher une liste de règles d'alerte par nom avec un bouton "Créer une nouvelle alerte" en bas. Chaque règle d'alerte doit avoir une option "modifier", "désactiver" ou "supprimer" à sa droite. En cliquant sur l'alerte ou sur le bouton de modification, cela devrait vous amener à la page de modification existante qui s'affiche mais pour cette règle d'alerte spécifique.

Faire plusieurs graphiques pour CHACUN de mes disques n'est pas une demande raisonnable.

Vous pouvez utiliser l'API pour automatiser la création/mise à jour des tableaux de bord et leurs alertes. Si vous le souhaitez, vous pouvez créer un programme qui interroge prometheus (ou quelle que soit la source dont vous disposez) en exécutant périodiquement des requêtes pour obtenir une découverte de service pour les cibles et créer automatiquement des alertes pour celles-ci.

Incroyable que cette fonctionnalité n'ait pas encore été implémentée, avec les énormes retours que ce problème a.

J'utilise Grafana comme moteur de visualisation et d'alertes aux télescopes Magellan. Si j'ai plusieurs sous-systèmes qui partagent des caractéristiques qui méritent qu'ils soient tous en 1, lorsqu'un problème survient et que l'un commence à mal se comporter, mes utilisateurs doivent recevoir un avertissement cryptique et creuser ce qui échoue.

La création de tracés factices est une solution de contournement, pas une solution. Cela semble basique !

+1 fonctionnalité nécessaire

+1

Exactement la même situation que l'OP. Fonctionnalité de base qui aurait déjà dû être implémentée.

Les gens peuvent-ils arrêter de spammer ce problème de fil sans rien ajouter de valeur ?.

Utilisez les réactions en haut du problème pour signaler votre intérêt.

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc est infiniment plus utile pour un mainteneur pour affirmer quels problèmes sont "populaires" que les spams les boîtes de réception des e-mails et les notifications github de tout le monde avec des informations déjà claires en regardant simplement la description du problème.

Si c'est si basique, peut-être que parmi tous les plaignants qui s'attendent à ce que d'autres personnes fassent du travail gratuitement pour eux, quelqu'un devrait l'implémenter lui-même et faire une demande d'extraction ou maintenir son propre fork si les responsables ne le veulent pas en amont.

@thomasf "Les gens peuvent-ils arrêter de spammer ce problème de fil sans rien ajouter de valeur ?" - Comme toi ?

Si les mainteneurs sont toujours dans le fil, les nouveaux commentaires le leur rappellent au moins. À ce stade, cela semble un peu inutile, il n'y a aucun moyen que les responsables l'implémentent après si longtemps et les gens devraient vraiment passer à de meilleurs outils comme Datadog où les responsables s'en soucient réellement, mais des centaines de commentaires (en particulier lorsqu'ils ont des scénarios réels ) a bien plus d'impact qu'un simple coup de pouce.

Si les mainteneurs sont toujours dans le fil, les nouveaux commentaires le leur rappellent au moins. À ce stade, cela semble un peu inutile, il n'y a aucun moyen que les responsables l'implémentent après si longtemps et les gens devraient vraiment passer à de meilleurs outils comme Datadog où les responsables s'en soucient réellement, mais des centaines de commentaires (en particulier lorsqu'ils ont des scénarios réels ) a bien plus d'impact qu'un simple coup de pouce.

Ou peut-être que les responsables se sont désabonnés de la notification sur ce problème à cause du spam, qui n'est pas le seul avec beaucoup de +1/message sans mise à jour. S'il vous plaît, ne comparez pas Grafana et DataDog (nous étions des utilisateurs des deux, pas moyen de revenir à DataDog)

La meilleure façon d'obtenir celui-ci est de contribuer (ou probablement de payer pour Grafana Entreprise)

Vous avez très très tort. Libre ou pas vous ne pouvez pas mettre un
forum/slack/github/canal de commentaires, puis ignorez-le. Si vous pensez que
mettre un logiciel sous licence open source signifie "pas de plaintes" et "les gens
développera gratuitement pour vos fonctionnalités ", vous vous trompez encore une fois. Dans
mon cas, je leur ai expliqué qu'avec ces fonctionnalités, je peux vendre du grafana à dix
mes clients. Ils m'ont ignoré, ça veut dire qu'ils sont énervés contre un client. Super
déplacer probablement ils font "assez" d'argent et ils ne veulent pas plus, je suis content
pour eux....

Le jeudi 14 octobre 2020 à 15:35 Thomas Frössman <
[email protected]> par écrit :

Les gens peuvent-ils arrêter de spammer ce problème de fil sans rien ajouter de
valeur?.

Utilisez les réactions en haut du problème pour signaler votre intérêt.

Si c'est si basique, peut-être que quelqu'un parmi tous ceux qui se plaignent s'attend à
d'autres personnes pour faire du travail gratuitement pour eux devraient le mettre en œuvre eux-mêmes
et faire une pull request ou maintenir leur propre fork si le
les mainteneurs n'en veulent pas en amont.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

Le montant d'argent que je suis prêt à dépenser pour _n'importe quel_ logiciel est directement proportionnel au niveau de service client que je peux prévoir de recevoir pour mon investissement. Qu'il s'agisse d'un produit open source offrant un "support payant" ou d'un produit commercial, cela n'a pas vraiment d'importance.

Le fait que ce problème reste ouvert si longtemps sans même un coup d'œil des responsables du projet extrapole malheureusement à un sentiment raisonnable de doute quant à savoir si quelque chose serait différent en dépensant de l'argent. Si vous essayez de vendre des logiciels, il est probablement sage d'en tenir compte.

faire une pull request ou maintenir leur propre fork

S'il y avait même un indice des développeurs sur où commencer, je suis sûr que je ne suis pas le seul à dire que j'envisagerais cela, que je pense que je devrais ou non, simplement en raison de la valeur considérable que cela aurait fournir. Malheureusement, cela ne semble pas être le cas et j'ai peu d'intérêt à essayer de désosser le produit pour une fonctionnalité dont les responsables ne semblent pas vraiment se soucier.

Enfin, à moins que le fil ne soit fermé/verrouillé, je ne vois aucune raison pour qu'on ne s'exprime pas. Vous êtes autorisé à vous désinscrire si cela ne vous convient pas. En fait, j'aime lire les gens se lamenter sur l'absurdité relative de cela. 😁

L'alerte Alerting NG (NextGen) prévue pour 8 prendra en charge plusieurs instances d'alerte à partir d'une seule définition d'alerte. Ainsi, quelque chose comme host=* avec un système comme prometheus créera des alertes par hôte.

Quelques informations générales à ce sujet dans le contexte des statistiques uniques ajoutées à https://github.com/grafana/grafana/issues/6983#issuecomment -712915673

Nous sommes toujours en train de concevoir et de prototyper, mais pour répondre à quelques réflexions initiales sur les choses :

Plusieurs alertes par graphique

La définition des alertes sera leurs propres entités, elles ne seront donc pas liées à un panneau. Les définitions d'alerte peuvent devenir plusieurs instances d'alerte. Ensuite, un panneau peut s'abonner à des instances ou à des définitions. J'imagine que nous voudrons toujours un joli chemin UX à partir du panneau Dashboard pour créer une alerte, car c'est un bon flux.

De plus, le suivi des états séparés d'une alerte n'est pas toujours préféré (car l'utilisateur final aurait besoin de connaître les détails derrière les états individuels) plutôt que de simplement savoir si l'alerte est déclenchée.

Une fois que de nombreuses alertes d'une définition sont autorisées, la façon dont elles doivent être regroupées devient un problème (car on peut accéder à de nombreuses alertes). Je vois actuellement deux chemins pour savoir comment cela fonctionnerait avec Alerting NG :

1. Utilisez alerting NG avec un IRM comme pagerduty ou alertmanager qui peut gérer le regroupement d'instances d'alerte.
2. Modifiez votre requête pour regrouper par une dimension de portée plus grande. Ainsi, par exemple, si requête cluster=* au lieu de host=*,cluster=* (ou groupez par pour sql comme les sources de données). Alternativement, j'ai l'intention d'ajouter des fonctionnalités aux expressions côté serveur (fournies avec alerting ng) pour permettre les opérations group/by pivot si la source de données ne le fait pas. Ce serait le cas lorsque vous n'utilisez pas d'IRM et que vous envoyez directement à des services tels que l'e-mail/slack.

avertissement/critique

Celui-ci est plus compliqué. Pour la conception WIP, je l'ai supprimée en tant que fonctionnalité (au moins pour une définition d'alerte, j'aurai peut-être un moyen de dupliquer la définition d'alerte, de la modifier et d'une certaine façon de l'étiqueter/étiqueter avec sévérité)

C'est dur, car dans de nombreux cas, c'est très utile :

• Pour moi, avertissement/critique a des utilisations claires : approche cassée/cassé, ou dégradé/cassé.
• Sans eux, de nombreuses configurations finiront par répéter un bon nombre d'alertes pour différents niveaux de gravité.

Alors pourquoi décider de ne pas en avoir ? Cela ajoute un peu de complexité non évidente:

• En supposant que vous souhaitiez prendre en charge vos seuils provenant d'une autre métrique (ou que vos seuils soient des plages de temps de requête différentes, et non des valeurs), il y a maintenant deux conditions à exécuter.
• Pour les états des instances d'alerte, je souhaite au minimum prendre en charge :
  
  
  
  • Inconnu : une instance a disparu
  
  
  • Erreur : La requête qui aurait découvert qu'il y a un problème avec les instances est cassée
  
  
  • Alerte : la condition est vraie
  
  
  • Normal. La condition n'est pas vraie
  
  
• Nous voulons également continuer à avoir des expressions similaires à FOR. Lors de l'ajout d'états supplémentaires, la conception n'a pas de battement ni de résultat de notifications manquées ni de bruit est compliqué. En général, les machines à états au fil du temps sont très sujettes aux bogues et sont difficiles à corriger (recherchez TLA / Logique temporelle des actions pour en savoir plus si vous aimez ce genre de choses). Ainsi, l'ajout de niveaux de gravité augmente l'espace d'état plus qu'on ne le devinerait. Ce qui signifie que nous sommes plus susceptibles d'avoir des comportements involontaires, ou des comportements pour lesquels il est plus difficile d'avoir un modèle mental.
• Lorsque vous cherchez à vous intégrer à d'autres systèmes ou IRM, avoir des notions spécifiques sur la gravité pourrait compliquer l'intégration.

(au moins pour une définition d'alerte, il y aura peut-être un moyen de dupliquer la définition d'alerte, de la modifier et d'une certaine façon de l'étiqueter/étiqueter avec gravité

Il s'agit d'une solution de contournement parfaitement acceptable pour la différenciation critique/avertissement. Je suis plus qu'heureux de maintenir des seuils distincts. Avoir un seuil combiné d'avertissement/critique serait une bonne chose, mais ce n'est pas un dealbreaker.

alors la façon dont ils doivent être regroupés devient un problème (car on peut obtenir de nombreuses alertes)

Il appartient à l'utilisateur de gérer son propre volume de tickets et la génération d'alarmes. Si vous définissez des alarmes, chacune doit être un e-mail ou une notification distincte. Pensez-y de cette façon, si vous créez un système automatisé pour générer des tickets basés sur le déclenchement d'alarmes, le regroupement de plusieurs alarmes dans un seul e-mail, par exemple, rendrait cela difficile ou simplement désagréable. De plus, plusieurs alarmes apparaissant dans un seul e-mail signifient que chaque alarme ne peut pas avoir son propre fil de discussion, elle devrait être séparée manuellement par les utilisateurs et de nouveaux fils de discussion lancés. Au lieu de cela, chaque déclenchement d'alarme doit avoir sa propre notification afin que les threads puissent être contenus dans cette alarme spécifique.

Espérons que cela simplifie la conception alarmante car vous ne devriez pas vous soucier du regroupement. C'est à l'utilisateur de gérer.