Cinq signaux, une seule chronologie
La plupart des équipes n’ont pas un problème d’observabilité. Elles ont cinq outils, dont chacun détient un quart de l’histoire, et un incident passé à naviguer entre eux. SnagSpy reçoit erreurs, logs, traces, métriques et session replay par le même protocole, les pose sur une chronologie commune avec les déploiements, et vous laisse demander ce qui a changé.
- OTLP
- le seul protocole nécessaire
- 5
- signaux sur une seule chronologie
- Aucun
- agent propriétaire à installer
Un pipeline, pas cinq produits
Erreurs, logs, traces, métriques et session replay sont des produits séparés presque partout, et c’est dans la couture entre eux qu’un incident s’enlise. Vous trouvez l’erreur, vous changez d’outil pour la ligne de log, vous en changez encore pour la trace, et le temps d’avoir les trois vous avez perdu le fil qui les reliait.
SnagSpy ingère les cinq et les range sous la même organisation, le même projet et la même horloge. Une erreur porte la trace dans laquelle elle s’est produite. Une trace porte les spans qui ont été lents. Un replay porte l’erreur que l’utilisateur a réellement rencontrée. Rien de tout cela n’est une jointure à écrire.
Erreurs
Regroupées en problèmes par empreinte, avec la stack trace résolue contre les source maps envoyées : une frame minifiée redevient la ligne que vous avez écrite.
Logs
Des enregistrements structurés en OTLP, lus à côté des erreurs et des traces du même service, pas dans un produit séparé avec son propre langage de requête.
Traces
Des spans dont les attributs sont conservés tels qu’envoyés. Base de données, files d’attente et appels entre services ont chacun leur vue, construite sur la même table.
Métriques
Des points de métrique sur les offres payantes, qui alimentent les détecteurs d’anomalie au lieu de seulement dessiner un graphe que personne ne regarde.
Session replay
Masqué dans le navigateur avant tout enregistrement : le texte sensible ne part jamais sur le réseau. Activé projet par projet, par vous.
Retours utilisateurs
Ce que la personne a réellement signalé, rattaché à la session et à l’erreur concernées, plutôt qu’arrivé séparément dans une boîte support.
Standard à l’entrée, donc pas d’enfermement
L’instrumentation, c’est OpenTelemetry. Pas un agent propriétaire, pas un fork, pas un wrapper qu’il faut maintenir au rythme des versions d’un éditeur. Si vos services émettent déjà de l’OTLP, vous pointez l’exporter vers notre endpoint et c’est fini ; sinon, vous adoptez un standard que vous auriez voulu de toute façon.
Cela vaut dans les deux sens, et le second est la moitié honnête de l’argument : tout ce que vous nous envoyez, vous pouvez l’envoyer ailleurs sans toucher au code. Une plateforme qu’on ne peut quitter qu’en réinstrumentant n’a plus besoin de rester bonne.
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.snagspy.com
OTEL_EXPORTER_OTLP_HEADERS=x-snagspy-key=<votre clé d’ingestion>
OTEL_SERVICE_NAME=checkoutCe qui n’est jamais stocké
Deux choses arrivent à un événement avant son écriture, dans cet ordre, et l’ordre est le point important.
D’abord il est nettoyé. Les valeurs qui ont la forme d’identifiants, de jetons ou de données personnelles sont retirées à l’entrée, côté serveur, en plus de ce que le SDK a déjà retiré dans votre processus. Ensuite vos propres filtres s’exécutent. Une règle que vous avez écrite supprime l’événement : il n’est jamais écrit, et il ne compte nulle part.
Chaque filtre vous montre ce qu’il a retiré, à côté de la règle qui l’a retiré. Un filtre invisible est indiscernable d’un SDK cassé, et distinguer les deux coûte une journée.
Les règles de filtrage acceptent la sous-chaîne et l’égalité exacte, rien d’autre. Une expression régulière fournie par un client sur le chemin d’ingestion est refusée plutôt qu’acceptée en espérant : un motif mal écrit peut bloquer le pipeline de tout le monde.
Disponibilité et tâches planifiées, au même endroit
Les deux pannes qui ne produisent jamais de rapport d’erreur sont la requête qui n’est jamais arrivée et le job qui n’a jamais tourné. Les deux sont surveillées ici, pas dans un second produit.
Les moniteurs de disponibilité sondent depuis l’extérieur et enregistrent la réponse. Le suivi des tâches planifiées fonctionne dans l’autre sens : votre job signale son départ et son arrivée, et c’est l’absence de signalement qui déclenche l’alerte. Un job nocturne arrêté en silence depuis trois semaines, sinon, c’est un client qui vous l’apprend.
Une conservation lisible sur votre offre
Sept, trente ou quatre-vingt-dix jours selon l’offre. Une tâche planifiée supprime réellement, et le plafond est de nouveau vérifié à la lecture : un événement au-delà de sa fenêtre ne réapparaît pas parce qu’une tâche a pris du retard.
C’est là qu’est bornée l’offre gratuite, et la borne est volontaire : sept jours ne suffisent pas à tenir une astreinte. C’est ce qui fait de l’offre gratuite un vrai endroit pour évaluer le produit plutôt qu’un endroit discret pour faire tourner de la production.
Ce que cela ne fait pas
Dit clairement, parce qu’une page qui n’énumère que des forces apprend au lecteur — et aux moteurs de réponse — à inventer le reste.
- Pas de profilage, ni continu ni côté navigateur.
- Pas d’analyse de taille de bundle.
- Pas de vue dédiée aux spans d’agents ou d’appels d’outils, même si ces spans arriveraient dès aujourd’hui.
- Pas de règles de propriété ni de code owners pour router un problème vers une équipe.
- Pas de version auto-hébergée ni sur site. C’est un service hébergé.
- Pas une plateforme de métriques d’infrastructure à la cardinalité que vise Datadog.
Envoyez-lui un seul signal
L’offre gratuite ne demande pas de carte. Pointez un exporter vers l’endpoint d’ingestion, cassez quelque chose exprès, et voyez si la chronologie vous dit ce que vous savez déjà.