Chaque signal. Une histoire claire.
LogBrew relie logs, traces, problèmes et versions pour que chaque panne ait du sens.
Logs
Recherchez le message, puis ouvrez la trace quand un log explique une panne.
POST /webhooks/payments
{ "title": "POST /webhooks/payments", "project": "Checkout API", "duration": "12 ms", "spans": 3, "trace_id": "webhook-8e91", "issue_id": "PAY-1043", "request_id": "req-webhook-8e91", "release": "checkout-api@1.24.0", "environment": "production", "http": { "method": "POST", "route": "/webhooks/payments", "status_code": 400 }, "operations": [ { "span_id": "webhook", "parent_span_id": null, "name": "POST /webhooks/payments", "start_offset_ms": 0, "duration_ms": 12, "status": "error" }, { "span_id": "secret", "parent_span_id": "webhook", "name": "signing_key.load", "start_offset_ms": 0, "duration_ms": 3, "status": "ok" }, { "span_id": "verify", "parent_span_id": "webhook", "name": "signature.verify", "start_offset_ms": 3, "duration_ms": 9, "status": "error", "attributes": { "key_version": "v7", "signature_match": false, "payload_logged": false } } ], "logs": [ { "offset_ms": 0, "severity": "info", "message": "Payment webhook received; provider event evt-9032" }, { "offset_ms": 3, "severity": "info", "message": "Loaded signing key version v7 from runtime configuration" }, { "offset_ms": 12, "severity": "error", "message": "Signature verification failed; returned 400 without updating order state" } ] }
Mettez les preuves au travail.
Repérer les problèmes récurrents
Passez en revue les problèmes regroupés et leur dernière occurrence avant de choisir quoi investiguer.
Lire le guide des problèmesProblèmes
Recherchez les pannes et ouvrez le contexte de trace.
| Erreur | Checkout API | 3 | ||
| Critique | Checkout API | 18 | ||
| Avertissement | Checkout API | 6 | ||
| Info | Checkout API | 12 |
Voir ce qui s’est passé avant
Suivez les logs et les breadcrumbs capturés autour d’une panne. Gardez le contexte de la requête sous les yeux.
Lire le guide d’investigationTraces
Ouvrez une requête pour voir son chemin et les signaux associés.
| Checkout API | Erreur | 12 ms | 3 | |
| Checkout API | Sain | 46 ms | 3 | |
| Checkout API | Sain | 8 ms | 2 | |
| Checkout API | Erreur | 2,548 ms | 4 |
Investiguer avec votre agent
Apportez le contexte capturé dans votre flux de développement. Examinez les preuves avant de décider quoi modifier.
Lire le guide des agentsPOST /webhooks/payments
{ "title": "POST /webhooks/payments", "project": "Checkout API", "duration": "12 ms", "spans": 3, "trace_id": "webhook-8e91", "issue_id": "PAY-1043", "request_id": "req-webhook-8e91", "release": "checkout-api@1.24.0", "environment": "production", "http": { "method": "POST", "route": "/webhooks/payments", "status_code": 400 }, "operations": [ { "span_id": "webhook", "parent_span_id": null, "name": "POST /webhooks/payments", "start_offset_ms": 0, "duration_ms": 12, "status": "error" }, { "span_id": "secret", "parent_span_id": "webhook", "name": "signing_key.load", "start_offset_ms": 0, "duration_ms": 3, "status": "ok" }, { "span_id": "verify", "parent_span_id": "webhook", "name": "signature.verify", "start_offset_ms": 3, "duration_ms": 9, "status": "error", "attributes": { "key_version": "v7", "signature_match": false, "payload_logged": false } } ], "logs": [ { "offset_ms": 0, "severity": "info", "message": "Payment webhook received; provider event evt-9032" }, { "offset_ms": 3, "severity": "info", "message": "Loaded signing key version v7 from runtime configuration" }, { "offset_ms": 12, "severity": "error", "message": "Signature verification failed; returned 400 without updating order state" } ] }
Connecter votre application
Choisissez l’intégration adaptée à votre application et suivez son guide de configuration pour envoyer votre premier signal.
Lire le guide de configuration
Donnez à chaque signal un chemin vers une réponse.
Ouvrez LogBrew et transformez la prochaine question de production en investigation ciblée.
Questions fréquentes sur LogBrew
Découvrez comment connecter votre application, investiguer les erreurs et travailler avec votre agent de code.
LogBrew vous aide à investiguer les pannes de vos applications grâce aux problèmes regroupés, aux logs et aux traces. Ouvrez un problème pour inspecter le contexte capturé, ou recherchez un événement précis dans les logs. Les détails disponibles dépendent de votre intégration et de ce que votre application envoie.
Les logs enregistrent des événements individuels, y compris l’activité normale. Le suivi des erreurs regroupe les pannes liées en problèmes : vous voyez les occurrences répétées et leur date la plus récente. Utilisez le problème pour choisir quoi traiter, puis consultez les logs associés pour le contexte.
Partez d’une occurrence capturée et vérifiez son environnement, sa version, son message et sa trace de pile. Consultez les logs associés et les preuves de trace quand elles existent. Ces éléments peuvent cibler l’investigation même si vous ne reproduisez pas l’erreur en local, mais ils ne garantissent pas d’en trouver la cause racine.
Quand votre intégration capture des breadcrumbs ou des logs associés, les détails du problème peuvent montrer les événements autour de la panne. Une trace liée peut ajouter la durée des opérations. LogBrew ne peut pas reconstituer une activité que votre application n’a pas capturée.
Un log (ou journal) enregistre un événement. Une trace de pile montre les appels de fonctions associés à une erreur. Une trace distribuée suit les opérations liées d’une requête ou d’une tâche, parfois à travers plusieurs services. Chacun répond à une question différente pendant le débogage.
Utilisez Problèmes pour voir les pannes regroupées, leur nombre d’occurrences et leur dernière occurrence. Affinez les résultats par projet et par période, puis inspectez une occurrence précise. La répétition aide à repérer une tendance ; elle ne mesure pas à elle seule l’impact sur les utilisateurs.
Les événements liés peuvent être reliés quand vos intégrations capturent et propagent le même contexte de trace. Un horodatage commun ou un message similaire ne suffit pas à prouver que deux événements appartiennent à la même requête. Suivez les instructions de tracing de chaque intégration.
Une erreur peut être capturée sans contexte de trace actif. Une trace peut aussi être indisponible au moment où vous l’inspectez. Vérifiez l’état des preuves dans les détails du problème, ainsi que la configuration du tracing de votre intégration. Un SDK plus récent n’ajoute pas de contexte de trace aux anciennes occurrences.
Oui. Utilisez le contexte d’investigation disponible, la CLI ou les outils MCP pour donner à votre agent des preuves ciblées. Le guide des agents explique la démarche. Vérifiez les données que vous partagez, gardez les identifiants hors des prompts et relisez les modifications proposées avant de les appliquer.
Vous pouvez investiguer directement dans le tableau de bord. Les outils pour agents sont facultatifs. Dans les deux cas, vous vous appuyez sur les preuves capturées et le contexte manquant ou limité reste visible. LogBrew ne garantit pas de correctif automatique.
Créez un projet, choisissez l’intégration de votre langage ou de votre framework et suivez son guide de configuration. Envoyez un événement de test sans risque et vérifiez qu’il apparaît dans le bon projet. Les signaux pris en charge et la configuration varient selon les intégrations.
Vérifiez d’abord le projet sélectionné, la période et les autres filtres. Vérifiez ensuite la configuration du projet et le signal envoyé par votre intégration. Logs, problèmes et traces sont des flux distincts : une page Logs vide ne signifie pas qu’aucun problème n’a été reçu.
Vous pouvez répartir la télémétrie en projets et utiliser les vues prévues pour sélectionner un, plusieurs ou tous les projets auxquels vous avez accès. Un service identifie le composant qui envoie les données au sein d’un projet. Gardez ces périmètres clairs quand vous comparez l’activité du frontend, du backend et des workers.
La collecte et l’envoi de télémétrie consomment des ressources. L’effet dépend de votre SDK, de votre configuration et du volume d’événements. Testez votre intégration avec une charge représentative et utilisez les réglages documentés pour ce SDK. Ne partez pas du principe que le surcoût est nul.
N’incluez ni secrets ni données personnelles inutiles dans les messages, les attributs ou le contexte d’erreur. Vérifiez les options de capture et de masquage de votre SDK, puis inspectez un événement de test sans risque avant d’activer l’intégration en production. Ne partez pas du principe que chaque champ est supprimé automatiquement.
Consultez la page Tarifs pour les forfaits actuels et les quotas inclus. Une fois connecté, consultez les pages Compte et Utilisation pour les informations propres à votre compte. Fiez-vous aux détails du forfait en vigueur plutôt que de supposer une collecte illimitée.