Solution de ticketing automatique pour les petits incidents de prod

Bonjour à la communauté DevOps,

Je me pose la question de la création de ticket automatiquement à la suite de petit incident de prod (ie. ce qu’on met actuellement en niveau error dans les logs).

Actuellement, on a une alerte sur loki et on se retrouve plusieurs dans l’équipe à examiner le log tous les matins.

Un système de gestion de ticket relié aux logs permettrait de mieux classifier les soucis et d’être exhaustif sur le traitement de ces petits incidents, sous réserve que cet outil soit capable de bien regrouper les incidents similaires.

Sur mes expériences d’outil de ticketing (Gitlab, kanboard, bugzilla, mantis) je n’ai pas trop vu ce genre de fonction, il me semble que la création de ticket est plutôt humaine.

Est-ce que vous avez déjà utilisé un tel outil ? Est-ce que ça existe ? Si oui, je serais intéressé par un petit retour.

Salut,

Personnellement je te conseillerai une intégration avec un outil d’alerting comme Opsgenie ou PagerDuty . Au besoin, si vous avez un outil de ticketing comme ServiceNow ou Jira, vous pouvez l’interfacer sans souci avec ces outils là.

je te conseillerai une intégration avec un outil d’alerting comme Opsgenie ou PagerDuty

J’ai l’impression qu’il s’agit d’outil très ops (ie orienté astreinte), je cherche plutôt un outil pour les alertes plus mineures (et très verbeuses), en plus je ne suis vraiment pas fan de leur tarification par user.

Après un peu d’investigation, j’ai l’impression que ce que je recherche se rapproche plus de Sentry, je suis (très) preneur de retour s’il y a des utilisateurs de cet outil sur le forum.

Il y a même une intégration dans giltab Error Tracking | GitLab

Hello!

Ce ne serait pas le job de Prometheus alertmanager ?

Comme tu as déjà Loki, tu peux y mettre des alerting rules qui va envoyer des alertes à alertmanager.

Et au niveau de l’alertmanager, peut être qu’un receiver de type webhook te permettrait d’envoyer une requête HTTP POST vers ton outil de ticket pour créer un ticket.

Et au niveau de l’alertmanager, peut être qu’un receiver de type webhook te permettrait d’envoyer une requête HTTP POST vers ton outil de ticket pour créer un ticket.

Les alertes qu’on fait sont assez basiques du type {job="myJob"} != "INFO"

Il faudrait un truc un peu intelligent qui arrive à incrémenter un compteur pour les lignes avec pattern similaire, et aussi la possibilité d’attribuer quelqu’un sur une alerte.

Une métrique générée par Loki via un “recording rule” ?

On utilise Sentry (surtout pour les erreurs des applications mobiles), ça marche plutôt bien.
Sinon on a une problématique similaire à la tienne et depuis plusieurs années on fait ça :

  • chaque log d’erreur est envoyé dans un canal slack/discord
  • ca peut être un canal par team en fonction de l’appli ou un canal par défaut
  • pour éviter qu’on soit plusieurs à regarder inutilement, on met un bête emoticone “yeux” sur le message pour indiquer qu’on regarde

finalement c’est tout bête mais ça fonctionne plutôt bien.

1 « J'aime »

Merci pour le partage de la technique, en plus, on a déjà un webhook sur Slack, ce n’est pas aussi parfait que ce que j’avais en tête, mais c’est très facile à mettre en place.

Par contre, pourquoi n’utilisez-vous pas Sentry, il me semblait que ça créait des tickets ?

oui sentry créé des issues dans sa propre interface, mais on ne passe pas notre journée dessus, contrairement à discord/slack.
après on peut aussi l’intégrer avec notre outil de ticketing (type jira) mais c’était pas forcément notre besoin, nous voulions quelque chose de très simple et ne pas avoir la gestion de tickets en plus (un peu plus lourd en terme de process)

L’intérêt du ticket est à mon avis surtout s’il y a des besoins d’historisation des incidents/erreurs, ce qui n’est pas trop cas.

1 « J'aime »