> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Audit, analyses et erreurs Comprenez l'activité avec le contexte d'espace et des données d'événement assainies. ## Trouver des informations utiles lorsqu'une action échoue L'observabilité signifie voir ce que votre application a fait. Commencez par le terminal exécutant votre serveur Web : répétez une action qui a échoué et lisez la première erreur et tout ID de corrélation, une étiquette reliant les messages de la même requête. Partagez la commande, l'heure et l'erreur nettoyée lorsque vous demandez de l'aide ; ne partagez pas de fichiers ou de jetons .env. Pour les rapports d'erreurs hébergés, suivez Santé et opérations pour configurer les paramètres de surveillance pris en charge dans apps/web/.env.local ou dans le tableau de bord de l'environnement de l'hôte. Enregistrez et redémarrez le serveur. Déclenchez un échec de test contrôlé dans un environnement de test et confirmez qu'il apparaît avec le contexte d'espace de travail correct. La surveillance en cours de configuration ne prouve pas qu'elle a reçu un événement. ALERT_WEBHOOK_URL est une destination HTTPS facultative pour les alertes d’échec de livraison de webhooks de tâches et de terminaux. Si vous en avez besoin, créez un point de terminaison entrant compatible et enregistrez son côté serveur URL ; sinon laissez-le vide. Demandez à un agent de simuler une panne et de confirmer exactement une alerte, sans aucun secret dans son texte. Ne déclenchez pas de travail rémunéré ou d'échecs dans les comptes clients pour ce test. [Vérifier l'état de l'application et les paramètres opérationnels](https://supastack.dev/fr/docs/web/security.md) [Diagnostiquer une erreur dans le terminal local](https://supastack.dev/fr/docs/web/troubleshooting.md) ## Conserver une piste d’audit de l’espace de travail Les enregistrements d’audit capturent des changements tels que les mises à jour de configuration d’un fournisseur dans un espace de travail. Résolvez l’espace authentifié avant de lire ou d’écrire ces enregistrements et conservez cette portée dans les événements propres au produit. Enregistrez l’action et les identifiants nécessaires pour la comprendre. Les identifiants fournisseurs et autres valeurs sensibles doivent rester hors des charges utiles d’audit et des journaux. ## Enregistrer les événements produit Le package d’observabilité expose un adaptateur AnalyticsClient et des valeurs AnalyticsEvent limitées à l’espace de travail. Chaque événement contient un nom, une identité distincte, workspaceId et des propriétés facultatives. Utilisez createObservability pour router les événements vers le client d’analyse configuré. Les propriétés structurées sont expurgées avant envoi ; évitez aussi les textes libres sensibles dans les noms et valeurs de propriétés. ## Signaler les erreurs avec un contexte sûr ErrorClient capture les exceptions avec des balises workspaceId et un contexte structuré supplémentaire. La couche d’observabilité partagée nettoie les exceptions et expurge le contexte sensible avant de le transmettre au client configuré. Utilisez les adaptateurs locaux pour vérifier les événements et exceptions capturés sans contacter un fournisseur de surveillance. Avant d’activer une destination externe, vérifiez que les balises d’espace de travail sont présentes et que les identifiants sont supprimés. ## Suivre une requête dans les tâches, jobs et webhooks Les frontières d’entrée génèrent un identifiant de corrélation `corr_` qui relie la requête initiale au travail déclenché. La soumission d’une tâche d’IA ajoute cet identifiant au payload de la tâche et à l’événement `ai_task_submitted`, chaque récepteur de webhook de facturation en génère un par requête et le planificateur en génère un par job distribué. Le même identifiant accompagne les propriétés des événements `job.completed` et `ai_task_completed`, les données supplémentaires de captureException, la charge utile du registre `webhook_event` et les métadonnées payload de chaque `webhook_delivery` ; il figure ainsi dans le corps signé reçu par un abonné. Les identifiants absents ou mal formés sont tolérés : le consommateur en génère un nouveau au lieu de rejeter les anciennes lignes. ## Déclencher des alertes pour les vrais échecs Définissez `ALERT_WEBHOOK_URL` sur un endpoint HTTPS acceptant un POST JSON de forme {text, name, severity, context} ; un webhook entrant de style Slack fonctionne tel quel. Les alertes partent sans bloquer, avec un délai de cinq secondes ; un échec de livraison ajoute un avertissement console, et l’alerteur ne fait rien si la variable est absente. Les alertes fournies sont `job.failed` (avertissement : un gestionnaire de job a levé une erreur ou le type est inconnu) et `webhook.delivery_failed` (critique : uniquement après l’échec terminal d’une livraison sortante à sa dernière tentative ; les nouvelles tentatives ordinaires restent silencieuses et chaque ligne de livraison déclenche au plus une alerte). ## Mesurer les durées et diffuser des journaux structurés `serverObservability.measure` chronomètre une opération asynchrone et émet un événement d’analyse `.duration` avec `durationMs`, en cas de succès comme d’échec, sans masquer l’erreur originale. L’exécution du job `ai.task.execute` est déjà instrumentée ; sa durée arrive donc dans le client d’analyse configuré. `serverObservability.logger` écrit une ligne JSON par entrée sur stdout avec les champs de base environment et service ; la couche d’expurgation partagée retire les secrets avant toute émission. ## Suivant [Liste de contrôle de déploiement](https://supastack.dev/fr/docs/web/deployment.md)