endueendue
← Cas d’usage
Monitoring dev

Réunir vos outils de monitoring derrière un seul agent d’astreinte

Connectez Datadog, OpenSearch, Sentry et PagerDuty en collant une clé API, puis créez un agent d’astreinte qui les consulte un par un, dans l’ordre, dès qu’une alerte se déclenche.

Quand une alerte 5xx se déclenche, l’ingénieur d’astreinte commence par ouvrir des onglets. Datadog pour le monitor, Sentry pour la stack trace, OpenSearch pour retrouver les logs de la même plage horaire. Puis GitHub, pour voir si quelque chose vient d’être déployé.

Si ces outils sont connectés à un seul agent, vous pouvez lui confier toute cette tournée de vérifications en une phrase. Demandez « que s’est-il passé au cours de la dernière heure ? » : l’agent interroge chaque outil tour à tour et revient avec une synthèse, preuves à l’appui. Les connecter ne demande aucun code. Vous collez dans un formulaire la clé API que chaque service vous fournit.

Idéal pour les équipes qui

  • jonglent entre quatre ou cinq tableaux de bord à chaque alerte
  • commencent chaque passation d’astreinte en redemandant « qu’est-ce qui sonne en ce moment ? »
  • utilisent des outils de monitoring différents selon les services, sans endroit unique où tout voir ensemble

Ce qu’il vous faut

  • Un compte endue et un agent
  • Une clé API pour chaque outil de monitoring à connecter. Si l’agent ne fait que consulter, commencez par une clé en lecture seule

1. Connecter vos outils de monitoring

  1. Dans la barre de gauche, allez dans Resources → Connectors et ouvrez l’onglet Discover. Les outils de monitoring sont regroupés sous Observability & Incidents.
  2. Choisissez un outil : endue vous montre d’abord ce que l’agent pourra en faire. Quand cela vous convient, appuyez sur Connect.
  3. Saisissez un nom de connexion et la clé, puis appuyez sur Connect. C’est tout. Choisissez un nom que vous reconnaîtrez plus tard, comme Datadog · prod.

Le groupe Observability & Incidents dans l’onglet Discover. Datadog, Elasticsearch, Grafana, New Relic, PagerDuty et Sentry, chacun avec son nombre d’outils et le nombre d’outils soumis à approbation.

Le formulaire de connexion Datadog. Quatre champs : nom de la connexion, site, clé API et clé d’application.

Voici ce que demande chaque formulaire.

  • Datadog : site, clé API, clé d’application. Pour le site, vous pouvez coller app.datadoghq.com tel quel depuis la barre d’adresse de votre navigateur
  • Elasticsearch · OpenSearch : l’URL https du cluster et une clé API
  • Grafana : l’URL de votre Grafana et un jeton de compte de service (commence par glsa_)
  • Sentry : URL du serveur (https://sentry.io en SaaS), slug de l’organisation, jeton d’authentification
  • New Relic : région (us ou eu) et une clé API de type USER (commence par NRAK-)
  • PagerDuty : clé API et adresse e-mail du compte sous lequel les actions sur les incidents sont enregistrées

OpenSearch se connecte via le connecteur Elasticsearch. Les API de recherche et d’agrégation sont les mêmes, les requêtes fonctionnent donc telles quelles. En revanche, l’authentification se fait uniquement par clé API (Authorization: ApiKey) : un cluster qui n’accepte qu’un nom d’utilisateur et un mot de passe ne peut pas encore être connecté.

GitHub et Slack se connectent en vous identifiant auprès du service, sans clé. Vous créez une connexion une seule fois sur votre compte, et n’importe lequel de vos agents peut l’utiliser.

2. Les rattacher à l’agent

Créer une connexion ne la donne pas à tous les agents. Vous décidez, agent par agent, des outils dont il dispose.

  1. Ouvrez l’agent et passez sur Studio en haut de l’écran. Le canevas présente l’agent tout entier sur un seul écran.
  2. Appuyez sur + Add Connector en haut à droite et choisissez, dans l’onglet My connectors, les connexions que vous venez de créer. Si un outil n’est pas encore connecté, vous pouvez le connecter sur place depuis l’onglet Catalog.
  3. Les outils rattachés s’alignent dans la colonne de droite du canevas.

Le canevas de Studio. L’agent Oncall est relié aux connexions Datadog, OpenSearch, Sentry, PagerDuty, Grafana et GitHub.

Cliquez sur la colonne des connecteurs pour ouvrir la liste des connexions de cet agent. Chacune affiche son état actuel. Basculez l’interrupteur pour en mettre une en pause, ou appuyez sur Remove pour la retirer. Dans les deux cas, seul cet agent est concerné. La connexion elle-même reste sur votre compte.

La liste des connecteurs. Les sept connexions affichent OK, chacune avec un interrupteur marche/arrêt et un bouton Remove.

3. Écrire l’ordre de vérification dans le prompt

Une fois les outils rattachés, l’agent choisit déjà celui qui convient à la question. Mais écrire l’ordre que votre équipe suit réellement rend les réponses plus régulières. Nous avons ouvert Prompt sur le canevas et écrit ceci.

Quand une alerte ou une question arrive, vérifie dans cet ordre.

  1. Datadog : état du monitor du service, logs d’erreur de la dernière heure
  2. Sentry : nouvelles issues, dernière stack trace et release à partir de laquelle elles sont apparues
  3. OpenSearch : logs de requêtes dans app-logs-* sur la même plage horaire
  4. GitHub : PR fusionnées autour de ce moment-là
  5. PagerDuty : incidents ouverts et personne d’astreinte en ce moment

Réponds brièvement. Joins à chaque cause présumée la ligne de log ou l’issue qui l’étaye. Demande avant de mettre un monitor en sourdine, d’acquitter ou de résoudre un incident, ou de publier sur Slack.

L’éditeur de prompt. Chaque enregistrement est conservé sous forme de révision.

Noms de services, motifs d’index, noms de dépôts : tout ce que seule votre équipe peut savoir mérite d’être écrit. L’agent cessera de poser la question.

À l’usage

Dans le chat, collez l’alerte telle qu’elle est arrivée ou posez simplement la question.

Alerte 5xx reçue sur checkout-api. Que s’est-il passé au cours de la dernière heure ?

L’agent balaie d’abord Datadog, Sentry et PagerDuty, tous en même temps. Quand quelque chose ressort, il resserre la recherche avec la stack trace Sentry, les logs OpenSearch et les PR GitHub. Chaque appel d’outil et ses arguments restent affichés au-dessus de la réponse : vous pouvez remonter de n’importe quelle conclusion jusqu’à sa source.

La vue du chat. Sous deux séries d’appels d’outils, une synthèse indique que les 5xx ont augmenté juste après le déploiement de 14:07, avec les preuves fournies par chaque outil.

Tout ce qui est difficile à annuler, il le demande d’abord

Les consultations s’exécutent sans rien demander. Les actions qui font taire des alertes ou qui laissent une trace visible par l’équipe font d’abord apparaître une carte d’approbation. La carte est positionnée par défaut sur Cancel : une touche Entrée malencontreuse ne lancera rien.

Une carte d’approbation pour la mise en sourdine d’un monitor Datadog. Elle indique la durée de 30m et le monitor visé, avec Cancel sélectionné par défaut.

Parmi les outils de monitoring, voici les actions qui passent par une approbation.

  • Mettre un monitor Datadog en sourdine, passer une alerte Grafana sous silence
  • Acquitter ou résoudre un incident PagerDuty, ou y ajouter une note
  • Résoudre ou ignorer une issue Sentry, acquitter ou clore une issue New Relic

L’envoi d’un message Slack et la création d’une issue GitHub passent par la même carte.

Au quotidien

  • Une vérification matinale : dites à l’agent dans le chat « lance cette vérification chaque jour ouvré à 9 h » et vous pouvez en faire une routine. Personne ne surveille l’exécution d’une routine : tout ce qui demande une approbation, comme une mise en sourdine, est donc ignoré, et le résultat signale que l’étape a été ignorée.
  • Regardez d’abord l’état : quand une clé expire ou que ses autorisations changent, l’état affiché dans la liste des connecteurs change aussi. Si l’agent semble buter sur un outil en particulier, commencez par là.