Il rejoint votre stack ; il ne demande pas à la remplacer
L’ingestion est un standard, pas un plugin. Le reste tient en un petit nombre de connexions faites correctement, plutôt qu’en un catalogue de cent logos qui, pour la plupart, relaient un webhook. Les voici toutes, et ce que chacune fait vraiment.
- OTLP
- à l’entrée, depuis tout SDK OpenTelemetry
- MCP
- votre télémétrie, lisible par un agent de code
- OIDC + SAML
- authentification unique, les deux en production
Faire entrer les données
N’importe quel SDK OpenTelemetry
Go, Java, Python, Node, .NET, Ruby, Rust — s’il exporte de l’OTLP sur HTTP, cela fonctionne. L’endpoint et la clé sont des variables d’environnement : votre code ne change pas.
Le SDK navigateur
Capture d’erreurs, session replay masqué avant enregistrement, et un widget de retour utilisateur. Le point d’entrée « erreurs » est un module à part : la capture ne vous coûte rien du poids de l’enregistreur.
La ligne de commande
Un seul paquet npm. Il envoie les source maps qui rendent une stack trace lisible, et soumet un changement à relecture depuis une étape de build.
Collecteurs et sidecars
Un OpenTelemetry Collector exporte vers SnagSpy comme vers n’importe quel autre backend OTLP, ce qui est la bonne forme si vous diffusez déjà votre télémétrie vers plusieurs destinations.
Votre agent de code peut lire vos erreurs de production
La même ligne de commande fait tourner un serveur MCP. Pointez Claude Code, ou tout autre client MCP, vers lui : l’agent qui édite votre code peut lire les problèmes, les événements et les traces du projet qu’il est en train d’éditer.
C’est une petite fonctionnalité à l’effet disproportionné : l’agent cesse de raisonner dans l’abstrait sur votre code et commence à raisonner sur l’exception que vos utilisateurs rencontrent réellement. Ce qu’il voit est borné par les permissions de la clé que vous lui donnez — un accès en lecture seule aux événements donne un jeu d’outils strictement plus petit qu’une clé pouvant aussi écrire sur les problèmes, et une clé ne portant ni l’une ni l’autre est refusée au démarrage plutôt que silencieusement dégradée.
npx snagspy mcp
# il lit la clé dans l’environnement
SNAGSPY_API_KEY=<une clé avec events:read>Être prévenu
| Destination | Ce que c’est |
|---|---|
| Alertes et résumés, dans la langue du destinataire. L’envoi passe par un domaine d’expédition vérifié plutôt que par un SMTP direct depuis la machine applicative. | |
| Webhook | Un POST signé vers une URL qui vous appartient. L’adresse est vérifiée avant enregistrement : une destination ne peut pas être pointée vers une adresse de réseau privé pour faire récupérer quelque chose à la plateforme au nom de quelqu’un. |
Il n’y a pas d’application Slack ni d’application PagerDuty. Les deux sont joignables aujourd’hui par un webhook entrant, et appeler cela « une intégration Slack » sur cette page reviendrait à déguiser un champ URL en produit.
Créer le ticket
Un problème peut devenir un ticket dans Jira Cloud ou dans Linear, créé avec le contexte qui le rend exploitable plutôt qu’avec un lien et un titre. La création est idempotente : appuyer deux fois n’ouvre pas deux tickets, et une nouvelle tentative après un délai dépassé qui avait en réalité réussi non plus.
Savoir ce qui a changé
Les webhooks de déploiement GitHub et GitLab alimentent la chronologie que lit l’analyse de cause racine. Ce sont deux fournisseurs distincts plutôt qu’un seul avec un drapeau, parce qu’ils s’authentifient différemment : l’un signe le corps, l’autre envoie un secret partagé dans un en-tête, et le second prouve strictement moins que le premier. Les traiter comme identiques reviendrait à traiter la preuve la plus faible comme la plus forte.
Se connecter
OpenID Connect et SAML 2.0, sur une même connexion, pour qu’une organisation n’ait pas à deviner lequel des deux le produit préfère. La découverte est utilisée là où le fournisseur la propose ; les assertions sont vérifiées contre un certificat épinglé, audience, conditions et liaison à la requête comprises.
La connexion Google et GitHub passe par OpenID Connect plutôt que par des boutons dédiés. Le provisionnement SCIM n’est pas construit.
Construire la vôtre
Derrière tout ce qui précède, il y a une API REST à clés permissionnées, et les permissions sont de vraies frontières plutôt que des étiquettes : elles décident quelles routes répondent à une clé et lesquelles la refusent, et un refus nomme la permission manquante au lieu de renvoyer un rejet générique à deviner.
Commencez par celle que vous avez déjà
Si vos services émettent de l’OpenTelemetry, deux variables d’environnement vous séparent d’un tableau de bord qui fonctionne. Tout le reste de cette page peut attendre.