Impossible de trouver un moyen propre de définir des notifications d'alerte Stackdriver en cas d'erreurs dans les fonctions cloud
J'utilise une fonction cloud pour traiter les données vers le magasin de données cloud. Il existe 2 types d'erreurs sur lesquelles je souhaite être alerté:
J'ai fait ce qui suit,
Ceci est fait selon la réponse à la question, comment créer une alerte par erreur dans stackdriver
Pour le premier déclencheur de la condition, je reçois un e-mail. Cependant, sur les déclencheurs suivants, disons le lendemain, je ne le fais pas. L'incident est également à l'état «ouvert».
Resource type: cloud function Metric:from point 2 above Aggregation: Aligner: count, Reducer: None, Alignment period: 1m Configuration: Condition triggers if: Any time series violates, Condition: is above, Threshold: 0.001, For: 1 min
J'ai donc 3 questions,
Est-ce la bonne façon de procéder pour répondre à mon exigence de création d'alertes?
Comment puis-je toujours recevoir des notifications d'alerte pour les erreurs suivantes?
Comment définir l'incident sur "résolu" automatiquement / manuellement?
3 Réponses :
Normalement, les alertes se résolvent d'elles-mêmes une fois que la stratégie d'alerte cesse de se déclencher. Le problème que vous rencontrez avec vos alertes ne se résolvant pas est que votre métrique n'écrit que des points différents de zéro - s'il n'y a pas d'erreur, elle n'écrit pas zéro. Cela signifie que la politique ne reçoit jamais un signal sans ambiguïté que tout va bien, donc les alertes restent simplement là (elles se fermeront automatiquement après 7 jours, mais j'imagine que ce n'est pas si utile pour vous).
C'est un problème courant et difficile à résoudre. Une possibilité est d'écrire votre politique sous la forme d'un ratio d'erreurs par rapport à quelque chose de différent de zéro, comme le nombre de demandes. Tant que le nombre de demandes est différent de zéro, le ratio calculera zéro s'il n'y a pas d'erreurs, et donc une alerte sur le ratio sera automatiquement résolue. Cependant, vous devez être un peu prudent en ce qui concerne les erreurs d'arrondi - si le nombre de demandes est suffisamment élevé, vous risquez de manquer une seule erreur car le ratio pourrait s'arrondir à zéro.
Aaron Sher, ingénieur Stackdriver
pour l'instant, nous demanderons à l'équipe d'assistance de vérifier manuellement l'erreur dans Stackdriver.
Avec les outils disponibles, il est difficile à résoudre, mais en réalité, cela semble très facile à résoudre pour Google - il suffit de prévoir un délai d'attente variable, pour la journalisation des incidents, au-delà des 7 jours?!
J'avais un problème similaire et j'ai réussi à au moins recevoir un mail à chaque fois. Le «truc» semble être d'utiliser sum
au lieu de count
en combinaison avec pour la valeur la plus récente
- voir la capture d'écran ci-dessous. P >
Cela oblige Stackdriver à envoyer un e-mail chaque fois qu'une entrée de journal correspondante est trouvée et à clôturer le problème une minute plus tard.
Merci! Cela m'a aidé. J'ai dû mettre Aggregator
à sum
, mais aussi sous Advanced Aggregation
mettre Aligner
à sum code> et
Seconday Aggregator
à sum
. Je ne sais pas si d'autres configurations fonctionnent également pour résoudre le problème ci-dessus ou non, mais cela a fonctionné pour moi.
J'ai essayé de résumer dans ce blog comment je l'ai fait fonctionner pour mes besoins medium.com/@prasadsawant1107/...
Nous avons contourné ce problème en ayant le insertId
comme étiquette de la métrique basée sur le journal que nous avons créée pour chaque enregistrement de journal que nous obtenons des pods exécutant nos services.
Dans la politique d'alerte, cette étiquette a aidé à deux choses:
record_id
) qui a servi à rendre chaque incident unique, de sorte qu'il a été signalé sans attendre que d'autres incidents soient résolus et en même temps, il a été résolu instantanément.
https://console.cloud.google.com/logs/viewer?project=MY_PROJECT&advancedFilter=insertId%3D%22${metric.label.record_id}%22
Comme @Aaron Sher l'a mentionné dans sa réponse, c'est un problème délicat. Nous avons peut-être fait quelque chose de non recommandé ou non efficace, mais cela fonctionne bien et nous sommes bien sûr ouverts aux recommandations d'amélioration.