Montre HN: Superlog (YC P26) – Observabilité qui s'installe elle-même et répare les bugs

Montre HN: Superlog (YC P26) – Observabilité qui s'installe elle-même et répare les bugs

Bonjour HN, nous sommes Nico et Arseniy, fondateurs de Superlog (https://superlog.sh). Nous construisons un outil d'observabilité qui s'installe elle-même et répare les bugs, sans avoir besoin d'être ouvert. Il a un wizard qui configure la registration quotidienne et un agent qui investigate les erreurs et ouvre des PR.

Démo courte: https://www.youtube.com/watch?v=xFhU9Mk247M.

Dans nos startups précédentes, nous avons essayé Sentry, Datadog, Grafana, Dash0, et rien n'était suffisant. La telemétrie et l'alertage corrects nécessitent encore une quantité énorme de configuration manuelle. Nous avons eu des difficultés à ajouter des registres de bonne qualité, donc le débogage était difficile, surtout lorsque les codebases grandissent à un rythme plus rapide. Pendant ce temps, le facteur de prix de Datadog/Dash0 continuait à monter, et nous avons encore passé des heures d'ingénierie pour apprendre, configurer et maintenir nos outils d'observabilité.

Avec Sentry, nous nous sommes retrouvés submergés par une flotte d'alertes dans notre canal Slack, la plupart étaient des duplicats ou manquaient de contexte, donc la fatigue des alertes/interruptions constantes était un problème réel. La notification #ops était toujours la sensation la plus mauvaise du samedi matin

Nous avons vu trop souvent que les serveurs se dépassaient de mémoire et de disque, et trois métriques AWS nous donnaient trois valeurs différentes. La moitié des graphiques sur les dashboards étaient normalement vides ou obsolètes, et cliquer manuellement à travers les UI, surtout lorsque l'équipe est petite, semblait un immense gaspillage de temps.

À un certain point, nous avons compris que résoudre ce problème serait plus précieux que ce que nous avions travaillé, et nous avions l'expertise pour le faire, puisque Arseniy avait passé des années à Datadog, recevant des notifications nocturnes pour déboguer des incidents de production. Alors nous avons décidé de construire une plateforme qui fonctionne : agent- premier, MCP-natif, sans configuration.

Voici comment fonctionne Superlog : nous avons un wizard qui scanne votre repository, et l'instrumente automatiquement avec des registres, des traces et des métriques via OpenTelemetry. Nous nous assurons de mettre en évidence les principaux modes de faillite, la performance des points de terminaison, l'utilisation par tenant et le coût LLM/flux (par appel, tenant et modèle).

Les erreurs sont improntées et regroupées en incidents, donc vous voyez un seul problème, pas mille duplicats. Lorsque vous recevez une notification de Superlog, vous voyez un résumé de faillite clair, sa sévérité et son impact inférés à l'avance.

Puis l'agent investigate et essaie de résoudre le problème. Si il a suffisamment de contexte, il produit un PR concis et testé. Si non, il publie ses résultats pour l'équipe d'investigation, et tire automatiquement les ingénieurs qui pourraient contribuer plus de contexte basé sur la documentation, les investigations précédentes et les threads Slack.

Dans chaque cas, le résultat est un PR propre par incident, publié dans Slack, que vous pouvez merger, ignorer ou ouvrir comme une session de Claude Code et modifier.

Trois choses que nous pensons sont différentes des autres fournisseurs d'observabilité :

(1) Nous résolvons le problème de configuration. Le wizard instrumentera tout avec des SDK OTel natifs, respectant les conventions sémantiques, avec un étiquetage de service et d'environnement correct. Nous travaillons également sur des dashboards et des alertes automatiques natifs, pour que vous puissiez voir ce qui se passe, et ne pas manquer les modes de faillite subtils.

(2) Notre telemétrie ne décroît pas. Le wizard exécute quotidiennement, et ajoute des registres, des alertes et des dashboards où ils sont nécessaires. Vous n'avez pas besoin de vous rappeler d'instrumenter de nouvelles fonctionnalités. La prochaine fois que quelque chose se casse, les données que vous avez besoin pour les déboguer sont déjà là.

(3) Notre objectif est de résoudre la fatigue des alertes. Nous utilisons des agents pour combiner des erreurs similaires et améliorer les résumés, pour vous donner des informations pertinentes à l'avance. Nous avons un setup d'évaluation personnalisé qui s'assure que les résumés sont denses et corrects, et la sévérité et l'impact sont précis. Nous donnons également des scores de confiance pour chaque métrique LLM-augmentée, pour que les hypothèses incorrectes ne soient pas renforcées.

Important : la telemétrie de Superlog est neutre pour les fournisseurs, vous conservez donc tous les registres/métriques/traces que nous installons. Le prix est sur le site. Nous sommes précoces, donc attendez-vous à des bords rugueux et s'il vous plaît dites-nous quand vous les trouvez.