Lier les erreurs aux traces et journaux

Utilisez un ID partagé pour connecter les enregistrements. Un service et une heure correspondants ne prouvent pas qu'un journal ou une span appartient à une erreur.

Trouver l'exception

Pour un ID de problème ou une URL, appelez posthog:query-error-tracking-issue-events avec include: ["exception", "correlation"], filterTestAccounts: false et une petite limit. Choisissez une occurrence sauf si l'utilisateur en demande plusieurs. Indiquez quand le résultat est un échantillon.

Pour un ID d'occurrence ou un ID de session, consultez finding-exceptions.md pour la recherche exacte. Utilisez la plage horaire de l'utilisateur si elle est fournie. Si aucun événement n'apparaît, indiquez la fenêtre que vous avez vérifiée. Ne prétendez pas qu'un événement n'a jamais existé basé sur une recherche limitée.

Suivre les IDs

1. Replay: Si l'événement contient $session_id, appelez posthog:session-recording-get avec cet ID. found: false signifie qu'aucun enregistrement n'a été trouvé ; l'erreur ou la session peut néanmoins exister. Utilisez posthog:generate-app-url avec /replay/{id} quand un enregistrement existe.
2. Trace exacte: Pour chaque $trace_id hex unique et non nul de 32 caractères, appelez posthog:apm-trace-get avec cet ID et excludeAttributes: true. Utilisez son _posthogUrl pour le lien de trace. Si l'événement contient $span_id, comparez-le avec les ID de span retournés en hex, en ignorant la casse. Un résultat vide signifie qu'aucune span retenue n'a été trouvée pour cet ID de trace. Des journaux peuvent néanmoins exister.
3. Candidats de trace de session: Si un événement n'a pas $trace_id et l'utilisateur a posé des questions sur les traces de session, utilisez posthog:apm-attributes-list pour trouver un attribut de span qui stocke l'ID de session. S'il existe une clé claire, appelez posthog:query-apm-spans avec un filtre span_attribute exact, une courte fenêtre autour de l'erreur, flatSpans: true et une petite limit. Cela trouve les spans enfants correspondantes ainsi que les spans racine. Appelez posthog:apm-trace-get pour un candidat qui a besoin d'un lien. Étiquetez-les comme correspondances de session. Le temps seul ne prouve pas quelle requête a levé l'erreur.
4. Journaux de même trace: Quand un événement a un ID de trace, consultez finding-trace-logs.md pour la recherche de service limitée et le filtre de journal exact. Incluez chaque sévérité, y compris info. Une trace peut avoir des journaux même quand aucune span n'a été retenue.

Utilisez posthog:generate-app-url avec /error_tracking/{id} quand l'ID de problème est connu. Ne construisez pas les liens PostHog à la main.

Rapporter le résultat

Pour chaque occurrence vérifiée, affichez l'heure d'erreur, les IDs utilisés pour la jointure et les liens vers le problème, le replay et la trace retenue quand disponibles. Résumez les journaux correspondants avec leur heure et sévérité. Excluez les secrets et les données personnelles inutiles des extraits de journal.

Nommez chaque lacune séparément : pas d'ID de trace sur l'événement, ID de trace mais aucune span retenue, aucun attribut de session sur les spans, aucun enregistrement ou aucun journal avec cet ID de trace dans la fenêtre vérifiée. Une span mise en correspondance par session est un candidat jusqu'à ce qu'une trace ou un ID de span exact la connecte à l'erreur. Mentionnez toute limite de ligne ou plage horaire qui a empêché la recherche d'être complète. Si une recherche échoue, dites que son résultat est inconnu au lieu de signaler qu'aucune donnée correspondante n'existe.