Grafana: Alerte : restrictions d'heure de la journée

Créé le 16 nov. 2016  ·  83Commentaires  ·  Source: grafana/grafana

Restrictions d'heure de la journée.

Voyez deux façons dont cela pourrait être mis en œuvre.

1) En tant que condition d'alerte
2) En tant que filtre sur les notifications

arealerting typfeature-request

Commentaire le plus utile

Pour contourner ce problème, utilisez prometheus comme backend :

  • Ajoutez la requête suivante à votre métrique : hour() , qui renvoie l'heure du jour (0-23). Vous pouvez le masquer dans le graphique.
  • Ajoutez une condition AND supplémentaire à votre alerte, afin qu'elle ne déclenche une alerte que si la requête hour() se situe dans la plage souhaitée (par exemple : heures de bureau).

La même chose peut être faite avec day_of_week() .

Tous les 83 commentaires

Quelqu'un a-t-il trouvé une solution de contournement pour ce scénario ? Je suis choqué que seulement 4 personnes aient voté pour ce ticket car toute la fonction d'alerte est essentiellement rendue inutile pour moi à moins que mes systèmes ne soient opérationnels 24h/24 et 7j/7. J'ai l'impression qu'il me manque une autre fonctionnalité ou technique que tout le monde utilise pour contourner ce problème...

Dans l'état actuel des choses, je dois soit désactiver toutes les notifications d'alerte, soit simplement accepter le fait que je recevrai un tas de fausses notifications lorsque mes processus arrêteront EOD.

Ne pas essayer de paraître vraiment critique, juste confus comment tout le monde gère ces alertes. J'aime Grafana depuis des années maintenant et je surveille la fonction d'alerte depuis son introduction dans la v4. Mais c'est un peu un casse-tête à chaque fois qu'il y a une mise à jour d'alerte et cette limitation n'est pas corrigée.

@bblazei tu as raison ! c'est une fonctionnalité incroyable qui doit être priorisée et qui sera certainement utile pour ppl!
@torkelo savez-vous quand cette fonctionnalité sera prévue ?

Non pas Eta pour le moment car ce n'est pas sur notre feuille de route pour les deux prochaines versions (4.3 et 4.4)

Hum c'est dommage. Comment recommanderiez-vous d'utiliser le cadre d'alerte sur des systèmes qui ne fonctionnent pas 24h/24 et 7j/7 ?

C'est quelque chose que nous aimerions beaucoup car nous devons avoir différents niveaux d'alerte selon l'heure de la journée

Nous attendons (pas si) patiemment cela aussi. Nous utilisons actuellement des graphiques curl à Slack périodiquement.

@torkelo torkelo. ça fait un moment que je ne vois pas de mise à jour à ce sujet. nous cherchons également quelque chose comme si nous pouvons désactiver les alertes grafana pour une heure précise. est-ce possible?

Quelqu'un a-t-il une mise à jour pour cette fonctionnalité?

Je suis en mesure de suspendre manuellement les alertes sur la page Liste d'alertes, mais (par exemple) lors de notre sauvegarde quotidienne du serveur de base de données à 2h30a, nous recevons une alerte sur "Network I/O Waits In Progress". Ce serait certainement bien de créer des alertes qu'il ne notifie pas pendant certaines périodes de temps.

Est-ce que grafana prend en charge une opération modulo ? Ensuite, vous devriez pouvoir utiliser la fonction d'identité pour obtenir l'heure unix en tant que métrique supplémentaire dans votre panneau. Avec la fonction modulo, vous pouvez obtenir le reste de la division du temps Unix par 86400 (le nombre de secondes dans une journée). Ensuite, vous pouvez ajouter une condition de plage sur la métrique de temps dans votre alerte. À droite?

Serait-il difficile d'ajouter l'opération modulo à cet effet ?

Vraiment besoin de cette fonctionnalité!

Des mises à jour à ce sujet ? S'agit-il d'un WIP ou de quelque chose qui est simplement « considéré » en ce moment ?

Nous aimerions vraiment utiliser des délais différents pour certaines alertes comme l'utilisation, dont nous prévoyons qu'elle dépassera un certain seuil pendant la journée mais pas la nuit.

+1

+1

+1

Pourquoi les gens ( @bascarsija & @maizy) rejettent-ils les demandes des gens à ce sujet ?

les gens "votent contre" ces messages "+1" qui provoquent l'envoi de notifications par e-mail à tous ceux qui sont abonnés à ce fil. l'effet cumulatif de nombreuses personnes ajoutant ces messages « +1 » aux fils de discussion réduit considérablement la valeur de la fonction d'abonnement aux fils de discussion en réduisant considérablement le rapport signal/bruit.

vous pouvez indiquer votre intérêt ou votre accord avec des propositions spécifiques ou des commentaires faits par d'autres sans déclencher de telles notifications par e-mail en simplement « votant pour » ou « contre-vote » via les réactions. la manifestation la plus évidente de solidarité/d'intérêt global pour un problème est généralement la réaction qui compte sur la description initiale/principale du problème -- veuillez envisager d'y ajouter vos réactions.

franchement, il s'agit d'un problème systémique avec Github - il s'applique également à tous les threads de problèmes dans tous les projets. vous trouverez de nombreux appels à travers les différents fils de discussion demandant une telle utilisation car l'interface utilisateur Github n'informe pas les utilisateurs de cette conséquence ou ne la décourage pas de manière évidente, et les utilisateurs qui sont conscients du problème (et/ou en sont affectés négativement) sont probablement hésitant à fournir une telle rétroaction en ajoutant encore un autre message au fil (diminuant ainsi davantage le rapport signal/bruit).

Merci pour l'explication. Je suppose que les personnes qui publient ces +1 ne l'auraient pas fait s'ils savaient que c'était juste un ennui. Publier une courte explication à ce sujet aurait pu en arrêter quelques-uns... ainsi que ma question. Pouce vers le bas pourrait signifier un certain nombre de choses.

Une mise à jour sur les alertes de calendrier à une certaine heure de la journée, de la semaine, du mois et de l'année ?

Pour contourner ce problème, utilisez prometheus comme backend :

  • Ajoutez la requête suivante à votre métrique : hour() , qui renvoie l'heure du jour (0-23). Vous pouvez le masquer dans le graphique.
  • Ajoutez une condition AND supplémentaire à votre alerte, afin qu'elle ne déclenche une alerte que si la requête hour() se situe dans la plage souhaitée (par exemple : heures de bureau).

La même chose peut être faite avec day_of_week() .

Nous avons également besoin de cette fonctionnalité si nous voulons pouvoir offrir un service 24H basé sur différentes équipes dans le monde... est-ce que cela est prévu ?

En attendant, cette fonctionnalité se prépare, j'essaie d'utiliser une solution de contournement.

Exemple:

```
métrique A : production.application_a.actual_metric = 123 (C'est ma métrique actuelle)
métrique B : helper.time_helper.hour = 1 à 24 ( Fausse métrique de temps qui est envoyée heure du jour chaque minute au graphite)

   alert requirement :

(la métrique A est inférieure à 100 ET l'heure est comprise entre 10 et 20)
OU
(la métrique A est inférieure à 50 ET l'heure est en dehors des plages 10 et 20)
```

en d'autres termes:

metric A threshold is 100 between 10AM to 8PM and it is 50 for rest of the time

Ma question :

Pour le scénario ci-dessus, puis-je obtenir un seul panneau graphique ou dois-je vraiment deux panneaux graphiques différents, un pour la plage intérieure et la plage extérieure ? Ou y a-t-il un autre moyen dans grafana d'y parvenir ? (Remarque : j'utilise du graphite 0.9.)

image

En attendant également cette fonctionnalité, approche intéressante pour envoyer de fausses métriques à grafana... vous vous demandez simplement quelle serait une option simple et agréable pour générer les métriques ?

+1 pouvons-nous simplement avoir une requête arbitraire que nous pouvons utiliser des expressions pour limiter la condition d'alerte ?

heure entre 1 et 2 ET

+1 serait tellement apprécié !

Juste un commentaire sur un travail grossier autour
J'utilise collectd / Influxdb
J'ai un processus cron qui écrit la valeur de l'heure dans un fichier ext plat
Le plugin collect Table lit cela comme une Table_Value - Instance "Hour"
Dans toute alerte où je dois utiliser uniquement une plage, j'ajoute l'heure métrique (max) au tableau de bord en tant que métrique cachée, puis dans l'alerte, utilisez une valeur de plage ET - ne se déclenche que si l'heure est comprise entre X et Y
La même chose fonctionne aussi le jour de la semaine

Brut mais efficace

@torkelo avez-vous une idée du moment où cela pourrait être mis en œuvre ?

Non, désolé, ce n'est pas sur la feuille de route de l'équipe principale

toute solution de contournement pour empêcher l'envoi d'alertes lorsqu'une instance Cloud vm est planifiée pour être désactivée en raison d'être planifiée. la plupart des systèmes l'ont depuis de nombreuses années.
s'il vous plaît ajouter ceci ;) réglage de la fatigue d'alerte.

J'ai un processus cron qui écrit la valeur de l'heure dans un fichier ext plat
Dans toute alerte où je dois utiliser uniquement une plage, j'ajoute l'heure métrique (max) au tableau de bord en tant que métrique cachée, puis dans l'alerte, utilisez une valeur de plage ET - ne se déclenche que si l'heure est comprise entre X et Y

C'est une solution de contournement assez efficace avec un avantage subtil mais utile par rapport au simple fait d'ignorer les alertes entre X - Y : si la situation n'est pas rectifiée avant Y, je reçois ma première alerte à Y. Si j'ignore simplement les alertes entre X - Y, je ne serait pas alerté même après Y (bien que l'on puisse utiliser la fonction "Envoyer des rappels", je suppose).

Il s'est avéré qu'une tâche cron n'était pas nécessaire lors de l'utilisation du graphite comme source de données :

J'ai ajouté une métrique C de timeSlice(isNonNull(identity(1)), '02:30 -9h', '06:00 -9h') et ajouté la condition d'alerte AND max() OF query(C, 1m, now) HAS NO VALUE pour exclure les alertes entre 2:30 et 6:00. (Ce -9h est dû au fait que mon décalage horaire est de +9:00 et que timeSlice() semble être en UTC.)

EDIT : Après quelques jours d'essai, cette astuce timeSlice() ne semble pas fonctionner...

C'est une énorme fonctionnalité manquante. Pourquoi ce n'est pas sur la feuille de route ? Semble trivial à mettre en œuvre

Vraiment merci à @albertvaka pour sa solution de contournement en utilisant la fonction hour() de Prometheus.

Malheureusement, on voit qu'il n'y a aucun moyen de considérer automatiquement le fuseau horaire lors de l'utilisation de la fonction hour() (et c'est un problème quand il y a l'heure d'été). Nous ne pouvions calculer le fuseau horaire que manuellement en fonction du mois et du jour, mais ce n'est pas une bonne solution.

Plus d'infos sur prométhée/prometheus#4160

ce serait bien de pouvoir définir différents niveaux de seuil pour différentes périodes datetime
par exemple, c'est ok s'il n'y a presque pas d'événements d'activité utilisateur la nuit, mais pas ok pendant la journée

Y a-t-il des progrès sur cette demande?

Pas sûr, mais je n'ai rien trouvé de nouveau à ce sujet dans Grafana 6.1.3

J'adorerais voir cette fonctionnalité implémentée. Nous utilisons Grafana pour les alertes critiques pour l'entreprise, ce serait bien de ne pas informer les personnes de l'entreprise lorsque cela n'est pas nécessaire, par exemple pendant leur temps libre.

+1, j'adorerais que cela soit mis en œuvre.

+1 Dieu m'en garde, j'oublie de suspendre la surveillance avant de rentrer chez moi pour le week-end, je reviendrai lundi à des milliers d'e-mails pour le comportement attendu

+1 s'il vous plaît implémentez cela dès que possible - je vais devoir tout porter sur Thingsboard si cela ne sera pas implémenté bientôt https://thingsboard.io/

@torkelo pouvez-vous nous donner des informations sur ce problème ? Y at-il des progrès?

Salut, y a-t-il quelqu'un avec suffisamment de connaissances pour l'implémenter et faire une pull request ?

Je peux vous dire ce que j'ai fait pour "obtenir" cette fonctionnalité. Je ne peux pas partager le code car il est propriétaire, mais je peux partager une idée, qui n'est sujette à aucun taureau propriétaire * * que ce soit.

J'ai implémenté quelques fonctions Lambda [SomeCloudProviderOfYourChoice] planifiées par cron qui utilisaient l'API REST Grafana pour mettre à jour des tableaux de bord entiers à partir de charges utiles JSON exportées avec ses alertes et ses seuils en fonction des périodes actives/inactives du système en conséquence (notre système est actif 8 à 10 heures par jour hors week-end). Cela fonctionne assez bien.

Mais.

Chaque fois que vous travaillez avec des tableaux de bord dans l'interface graphique Web Grafana, vous devez garder à l'esprit que chaque fois que vous apportez des modifications à quoi que ce soit en vidant les tableaux de bord JSON et en les validant dans le référentiel "Grafana Scheduler" est OBLIGATOIRE . Si vous oubliez de vider votre charge utile (South Park S11E09), vos modifications seront perdues à chaque démarrage du planificateur (récupérable, mais douloureux). Et vous devez propager votre modification aux deux vidages JSON actifs/inactifs, ce qui signifie essentiellement doubler l'effort (et même plus si les différences ne sont pas documentées en conséquence). En fait, cette "solution" signifie que vous avez besoin d'un _processus_ bien documenté, maintenu, visible et strictement suivi, ce qui, à long terme, pourrait être encore plus nul que de ne pas avoir du tout cette fonctionnalité. Nous modifions nos seuils d'alerte si rarement qu'il ne semble pas trop compliqué pour nous de gérer la surcharge de _process_.

En tous cas...

Je travaille actuellement avec Aiven Grafana qui s'exécute sur SQLite (appliqué par le fournisseur), donc si la base de données a été modifiée en quelque chose de plus simultané et riche en fonctionnalités, on peut comprendre comment utiliser des déclencheurs de base de données + événements pour gérer ces petits mises à jour partielles effectuées via l'interface graphique Web Grafana afin de rendre l'ensemble du processus plus transparent.

Restez à l'écoute, bonne chance!

Veuillez ajouter ceci pour terminer, cela est absolument nécessaire pour les migrations à partir d'autres plates-formes.

Le moyen le plus simple avec les requêtes T-SQL est de tromper GRAFANA (solution de contournement) :

SELECT timestamp AS time,
        CASE 
            WHEN DATEPART(HOUR, SYSDATETIME()) NOT IN (0,1,2,3,4,5,6) 
            THEN COUNT(document_number)
            ELSE 0 
        END AS Receipts
FROM GRAFANA.dbo.ReceiptsErrorsHistory
WHERE timestamp >= DATEADD(DAY, -7, GETDATE())
AND document_type = 'receipt'
GROUP BY timestamp

Quel est l'état de cette mise en œuvre ? Nous utilisons actuellement seyren et cabot pour les alertes, et aimerions migrer vers les alertes Grafana. Sans la restriction de temps, nous ne pourrons pas avancer.

Dans le cas de la recherche Elastic, j'ai trouvé un moyen simple de résoudre ce problème.
Utilisez les maths de date : https://www.elastic.co/guide/en/elasticsearch/client/net-api/7.x/date-math-expressions.htm.

par exemple, si vous voulez des données avec une plage (AM 00:00 ~ PM:12:00) alors @timestamp :[now/d TO now/d+12h] peut renvoyer le résultat souhaité

@sukjoonhong, je ne peux pas le faire fonctionner. Avez-vous une capture d'écran s'il vous plaît ?

J'ai mis en place une solution de contournement qui utilise cron pour activer et désactiver les alertes. Cela ne fonctionnerait que si vous souhaitez désactiver TOUTES les alertes du jour au lendemain (ou si vous pouvez être dérangé par des scripts d'alertes individuelles).

Dans crontab sur la box grafana, j'ai ajouté :

1 * * * * root /root/do-alert-thing.sh

Et dans /root/do-alert-thing.sh :

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Remplacez simplement Somewhere/Sometime par votre fuseau horaire (astuce : exécutez timedatectl list-timezones pour une liste) et ajoutez vos informations d'identification au lieu de [email protected] . Ce point de terminaison d'administration ne fonctionne qu'en mode d'authentification de base selon la documentation .

J'espère que cela aide quelqu'un là-bas.

@Atem18
2019-10-14-094215_3840x1080_scrot

Dans mon cas, cette requête a fonctionné.

@sukjoonhong Merci je vais essayer !

J'ai mis en place une solution de contournement qui utilise cron pour activer et désactiver les alertes. Cela ne fonctionnerait que si vous souhaitez désactiver TOUTES les alertes du jour au lendemain (ou si vous pouvez être dérangé par des scripts d'alertes individuelles).

Dans crontab sur la box grafana, j'ai ajouté :

1 * * * * root /root/do-alert-thing.sh

Et dans /root/do-alert-thing.sh :

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Remplacez simplement Somewhere/Sometime par votre fuseau horaire (astuce : exécutez timedatectl list-timezones pour une liste) et ajoutez vos informations d'identification au lieu de [email protected] . Ce point de terminaison d'administration ne fonctionne qu'en mode d'authentification de base selon la documentation .

J'espère que cela aide quelqu'un là-bas.

J'ai essayé cela et cela fonctionne, mais dans grafana ui, il est indiqué qu'il ne s'arrête que pendant une heure. Il faudrait donc que je fasse un crontab qui se répète toutes les heures jusqu'à ....?

J'ai abordé cela sous un angle différent où vous générez une métrique d'activation/désactivation de prometheus basée sur la sortie d'un script, par exemple une commande ps qui vérifie si le script de sauvegarde est en cours d'exécution. Ensuite, dans mon tableau de bord, j'ai une "Sauvegarde active" pour afficher l'état de la sauvegarde et dans mon panneau principal avec toutes mes requêtes et alerte, j'ajoute le contrôle de condition qui n'alertera pas si la métrique de sauvegarde est = 1. Cette approche serait vous permettent également d'ajouter une alerte distincte qui se déclenche si la sauvegarde dure plus longtemps qu'elle ne le devrait lorsque vous prenez en compte les données de métrique historiques.

J'ai mis en place une solution de contournement qui utilise cron pour activer et désactiver les alertes. Cela ne fonctionnerait que si vous souhaitez désactiver TOUTES les alertes du jour au lendemain (ou si vous pouvez être dérangé par des scripts d'alertes individuelles).
Dans crontab sur la box grafana, j'ai ajouté :
1 * * * * root /root/do-alert-thing.sh
Et dans /root/do-alert-thing.sh :

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Remplacez simplement Somewhere/Sometime par votre fuseau horaire (astuce : exécutez timedatectl list-timezones pour une liste) et ajoutez vos informations d'identification au lieu de [email protected] . Ce point de terminaison d'administration ne fonctionne qu'en mode d'authentification de base selon la documentation .
J'espère que cela aide quelqu'un là-bas.

J'ai essayé cela et cela fonctionne, mais dans grafana ui, il est indiqué qu'il ne s'arrête que pendant une heure. Il faudrait donc que je fasse un crontab qui se répète toutes les heures jusqu'à ....?

Vous ne savez pas pourquoi vous voyez ce comportement ; pour moi, il s'interrompt et reste en pause pendant 9 heures, jusqu'à ce que je le rallume en utilisant la ligne cron du matin.

J'ai mis en place une solution de contournement qui utilise cron pour activer et désactiver les alertes. Cela ne fonctionnerait que si vous souhaitez désactiver TOUTES les alertes du jour au lendemain (ou si vous pouvez être dérangé par des scripts d'alertes individuelles).
Dans crontab sur la box grafana, j'ai ajouté :
1 * * * * root /root/do-alert-thing.sh
Et dans /root/do-alert-thing.sh :

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Remplacez simplement Somewhere/Sometime par votre fuseau horaire (astuce : exécutez timedatectl list-timezones pour une liste) et ajoutez vos informations d'identification au lieu de [email protected] . Ce point de terminaison d'administration ne fonctionne qu'en mode d'authentification de base selon la documentation .
J'espère que cela aide quelqu'un là-bas.

J'ai essayé cela et cela fonctionne, mais dans grafana ui, il est indiqué qu'il ne s'arrête que pendant une heure. Il faudrait donc que je fasse un crontab qui se répète toutes les heures jusqu'à ....?

Vous ne savez pas pourquoi vous voyez ce comportement ; pour moi, il s'interrompt et reste en pause pendant 9 heures, jusqu'à ce que je le rallume en utilisant la ligne cron du matin.

Je ne dis pas que je vois ce comportement, mais cela le dit littéralement dans l'interface utilisateur de grafana. Pause pendant 1 heure. J'ai donc supposé que l'astuce de la pause ne fonctionnait que pendant 1 heure.

Mais si c'est faux, je suis corrigé.

Je ne dis pas que je vois ce comportement, mais cela le dit littéralement dans l'interface utilisateur de grafana. Pause pendant 1 heure. J'ai donc supposé que l'astuce de la pause ne fonctionnait que pendant 1 heure.

Mais si c'est faux, je suis corrigé.

Cela pourrait simplement être l'état d'alerte ; par exemple, si l'alerte était OK, elle afficherait :

image

Je suppose que s'il a été mis en pause pendant une heure, il dirait "PAUSED for 1 hour" ?

Stupide moi, je pense que j'ai dû mal interpréter

Merci pour la clarification!

Est-il prévu d'implémenter cette fonctionnalité dans les versions 6.6.x > après quatre ans ?

Nous attendons toujours avec impatience de voir cela mis en œuvre également. Il s'agit d'un système d'alerte très inefficace si les utilisateurs libres, en vacances ou indisponibles reçoivent des alertes lorsqu'ils n'ont pas besoin de répondre.

Nous aimerions beaucoup inclure une option pour définir différentes heures (pour nos heures d'ouverture de cas) pour alerter.

Idem ici, ce serait très bien d'avoir ça.

Des solutions de contournement existent pour certains backends (j'en utilise une pour MySQL qui implique de filtrer les événements en dehors de certaines plages de temps via la requête), mais l'avoir comme "fonctionnalité appropriée" serait certainement un plus.

Nous aimerions également voir cette fonctionnalité dans une future version. Il serait utile de pouvoir filtrer/supprimer les alertes pendant nos fenêtres « après les heures normales ». Par exemple, si nous pouvions filtrer les alertes si elles se produisent après 20h et avant 8h le lendemain.

Ce serait génial d'avoir cette fonctionnalité, s'il vous plaît. Dans l'état actuel des choses, c'est comme le gamin qui crie au loup la nuit. Je viens de mettre mon téléphone dans le tiroir. L'alerte est inutile. Merci.

Nous avons sérieusement besoin de la fonctionnalité de reconnaissance de Grafana. Sans la fonction d'alerte d'accusé de réception , la fonction d'alerte de Grafana ne peut pas être utilisée dans un environnement de service de production critique.

Ce serait formidable de voir cette fonctionnalité dans Grafana. Seules les alertes pendant des heures spécifiques sont pertinentes pour nous, heures de travail +-2h, pendant la nuit il y a une augmentation (prévue) des valeurs surveillées qui entraîne actuellement des alertes :-(

+1 sur demande de fonctionnalité

Ce sera une excellente fonctionnalité si nous pouvons ajouter des alarmes pour des régions horaires spécifiques. Les règles d'alarme ne devraient fonctionner que pour une région temporelle spécifique.

Cela pourrait être génial d'avoir un moyen de configurer différents canaux de notification concernant les périodes, tels que :

  • un lundi normal -> notifier via Slack
  • Lundi 1er janvier -> notifier par SMS

Les périodes de temps peuvent être définies par l'utilisateur et liées à un canal de notification.

J'ai parcouru la plupart des commentaires, donc désolé si quelqu'un a articulé le cas d'utilisation suivant, mais je ne l'ai pas remarqué.

Une raison de prendre en charge les restrictions d'heure de la journée pour les alertes est pour les séries de données éparses. Considérez une configuration lorsqu'un travail par lots s'exécute une fois par jour, entre minuit et 2 heures du matin afin de préparer les données pour un briefing quotidien à 8 heures. Le point de données unique « travail terminé » est émis à la fin.

Il n'y a pas un bon moyen d'alerter à ce sujet sans restriction de temps.

« Alerte si aucun point de données au cours des X dernières heures » ne fonctionnera pendant un nombre de X heures. Par exemple, si j'alerte sur "aucun point de données au cours des dernières 24 heures", cela fonctionne tant que toutes les tâches s'exécutent correctement chaque jour. Cependant, si j'obtiens un échec, je réexécute le travail à 11h pour rattraper mon retard. Puis mon alerte pour le lendemain est cassée (puisqu'elle ne se déclenchera qu'après 11h). C'est mon cas d'utilisation principal pour la restriction de temps. La seule alerte possible est d'avoir la logique d'évaluation d'alerte sur ON de 2h à 8h et d'alerter si « aucun point de données au cours des 8 dernières heures ».

Ce cas d'utilisation ne concerne pas la suppression des alertes pendant les heures de travail ou la réduction du bruit à une heure précise de la journée. Même avec une réponse sur appel 24h/24 et 7j/7, l'alerte ci-dessus ne peut pas être exprimée avec précision sans restrictions d'heure de la journée.

+1 à cette fonctionnalité.
Dans notre cas, il est nécessaire d'envoyer une alerte avec les informations des N derniers jours une fois par jour/heure/semaine. Tout est compliqué par le fait que la newsletter doit être faite à une heure strictement fixe (8h00, 13h00 et ainsi de suite).

Comme solution de contournement, nous prévoyons de gérer les alertes via HTTP Api, mais nous aimerions voir cette fonctionnalité dans la partie client du grafana.

Besoin de cette fonctionnalité. Exemple : Réseau PROD avec des heures de maintenance - Vous souhaitez maintenant arrêter certaines notifications pendant cette fenêtre de maintenance. par exemple, tous les dimanches soirs entre des plages horaires spécifiques. Pas possible pour le moment.

J'aimerai vraiment cette fonctionnalité lorsqu'elle sera disponible. Je voudrais arrêter d'alerter pour la période de temps spécifique dans une plage de 24 heures.

+100000

+1
Je pense que c'est une fonctionnalité essentielle d'utiliser Grafana comme un véritable moteur d'alerte.

Bien que le service réel conserve un état sain, la métrique peut changer en fonction du calendrier spécifié.
Nous avons besoin d'un moyen général de contrôler nos alertes pendant ce calendrier.

+1

Ce serait une fonctionnalité intéressante à avoir du côté client. À l'heure actuelle, nous devons dériver des champs tels que hourOfDay, dayOfWeek, dans Logstash afin de les avoir présents dans ES pour ajouter une métrique supplémentaire à l'ensemble de métriques, et l'ajouter dans les règles d'alerte.

M'avertir si la métrique moyenne A qui correspond à l'utilisation du processeur est supérieure à 90 % pendant 1 m
ET
si la métrique B qui est max hourOfDay des mêmes documents est comprise entre RANGE.

Cela fonctionne, mais cela semble gênant de travailler comme ça, comme solution de contournement.
D'autant plus que Grafana a énormément évolué depuis 2016 sur d'autres domaines, mais c'est un peu oublié depuis 2016.

J'ai mis en place une solution de contournement qui utilise cron pour activer et désactiver les alertes. Cela ne fonctionnerait que si vous souhaitez désactiver TOUTES les alertes du jour au lendemain (ou si vous pouvez être dérangé par des scripts d'alertes individuelles).

Dans crontab sur la box grafana, j'ai ajouté :

1 * * * * root /root/do-alert-thing.sh

Et dans /root/do-alert-thing.sh :

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Remplacez simplement Somewhere/Sometime par votre fuseau horaire (astuce : exécutez timedatectl list-timezones pour une liste) et ajoutez vos informations d'identification au lieu de [email protected] . Ce point de terminaison d'administration ne fonctionne qu'en mode d'authentification de base selon la documentation .

J'espère que cela aide quelqu'un là-bas.

salut
Pouvez-vous me dire comment obtenir l'url des alertes individuelles ?

salut
Pouvez-vous me dire comment obtenir l'url des alertes individuelles ?

C'est dommage qu'après 4 ans, cette fonctionnalité manifestement demandée n'ait pas été implémentée. Mon cas d'utilisation est une simple domotique où le routeur doit être redémarré de temps en temps (c'est celui du FAI et ne peut pas survivre plus d'une semaine de disponibilité). J'ai un adaptateur de prise simple avec un cadran qui réinitialise le routeur tous les soirs. Donc, chaque nuit, je reçois de nombreuses alertes concernant la panne de mes capteurs dans Telegram. Une simple fonction de désactivation des alertes pendant un certain intervalle de temps serait utile.

Il n'est pas nécessaire que ce soit une planification super sophistiquée tout de suite. Dans la première version de cette fonctionnalité, il pouvait s'agir uniquement de l'heure de la journée. Avec des horaires plus complexes ajoutés à des étapes ultérieures

Avons-nous un moyen de programmer des alertes à un moment particulier.

+1 pour cette fonctionnalité.

Est-ce que grafana prend en charge une opération modulo ? Ensuite, vous devriez pouvoir utiliser la fonction d'identité pour obtenir l'heure unix en tant que métrique supplémentaire dans votre panneau. Avec la fonction modulo, vous pouvez obtenir le reste de la division du temps Unix par 86400 (le nombre de secondes dans une journée). Ensuite, vous pouvez ajouter une condition de plage sur la métrique de temps dans votre alerte. À droite?

Serait-il difficile d'ajouter l'opération modulo à cet effet ?

Cela semble fou mais cela fonctionne et pour mon cas d'utilisation, c'était suffisant. ??

time() % 86400

Pourtant, c'est pénible qu'il n'y ait pas de solution plus pratique qui ne soit pas un hack évident. ??

Cela semble fou mais cela fonctionne et pour mon cas d'utilisation, c'était suffisant. ??

time() % 86400

Pourtant, c'est pénible qu'il n'y ait pas de solution plus pratique qui ne soit pas un hack évident. ??

@ochrstn quelle version de grafana avez-vous car j'ai essayé cela sur v6.6.1 et l'opération modulo a été essentiellement ignorée dans la requête?

Cela semble fou mais cela fonctionne et pour mon cas d'utilisation, c'était suffisant. ??

time() % 86400

Pourtant, c'est pénible qu'il n'y ait pas de solution plus pratique qui ne soit pas un hack évident. ??

@ochrstn quelle version de grafana avez-vous car j'ai essayé cela sur v6.6.1 et l'opération modulo a été essentiellement ignorée dans la requête?

v6.6.2

Est-ce que grafana prend en charge une opération modulo ? Ensuite, vous devriez pouvoir utiliser la fonction d'identité pour obtenir l'heure unix en tant que métrique supplémentaire dans votre panneau. Avec la fonction modulo, vous pouvez obtenir le reste de la division du temps Unix par 86400 (le nombre de secondes dans une journée). Ensuite, vous pouvez ajouter une condition de plage sur la métrique de temps dans votre alerte. À droite?
Serait-il difficile d'ajouter l'opération modulo à cet effet ?

Cela semble fou mais cela fonctionne et pour mon cas d'utilisation, c'était suffisant.

time() % 86400

Pourtant, c'est pénible qu'il n'y ait pas de solution plus pratique qui ne soit pas un hack évident.

Hey @ochrstn :) Pourriez-vous fournir des détails sur la façon dont vous avez procédé ?

Cette page vous a été utile?
0 / 5 - 0 notes