2
votes

Définir des alertes de stackdriver pour des messages d'erreur spécifiques

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é:

  1. Exceptions techniques susceptibles de provoquer une panne de la fonction
  2. Erreurs personnalisées que nous enregistrons à partir de la fonction cloud

J'ai fait ce qui suit,

  • Création d'une métrique de journal à la recherche d'erreurs spécifiques (bien que cela ne fonctionnera pas en cas de "plantage" car le message d'erreur peut être différent à chaque fois)
  • Création d'une alerte pour cette métrique dans Stackdriver Monitoring avec des paramètres comme dans la section de code ci-dessous

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,

  1. Est-ce la bonne façon de procéder pour répondre à mon exigence de création d'alertes?

  2. Comment puis-je toujours recevoir des notifications d'alerte pour les erreurs suivantes?

  3. Comment définir l'incident sur "résolu" automatiquement / manuellement?


0 commentaires

3 Réponses :


3
votes

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


2 commentaires

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?!



3
votes

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.

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.

 entrez la description de l'image ici


2 commentaires

Merci! Cela m'a aidé. J'ai dû mettre Aggregator à sum , mais aussi sous Advanced Aggregation mettre Aligner à sum 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/...



0
votes

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. entrez la description de l'image ici

Dans la politique d'alerte, cette étiquette a aidé à deux choses:

  1. Nous avons regroupé par lui (nommé 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. entrez la description de l'image ici
  2. Nous l'avons utilisé dans la documentation de la notification pour inclure un lien direct vers le problème (enregistrement du journal) lui-même, ce qui était une fonctionnalité intéressante et essentielle à avoir. 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.


0 commentaires