# Guide support — retrouver un problème dans SigNoz (§80/§81)

## Identifiants utiles

| Identifiant | Où le trouver | Attribut SigNoz |
|---|---|---|
| **TraceId** (`X-Omika-TraceId`) | header de réponse API, log mobile | `omika.trace_id` |
| **SessionId** | header/log | `omika.session_id` |
| **OperationId** | log de synchronisation | `omika.operation_id` |
| **EventId** | payload diagnostic | identifiant du log / attribut |

## Scénario type (§81)

1. Un utilisateur signale une erreur.
2. On dispose d'un **TraceId** (visible dans la réponse API ou le log mobile).
3. Dans SigNoz → **Logs** → filtre `omika.trace_id = <GUID>`.
4. On retrouve, corrélés par ce TraceId :
   - l'événement **mobile** (s'il a été forwardé) ;
   - la **requête API** (span HTTP dérivée) ;
   - l'**erreur serveur** (EventCode `OMK-API-...`).

Aucune donnée sensible n'est exposée : les attributs exportés sont uniquement ceux de
la [liste blanche](data-whitelist.md).

## Codes d'événements (pivot, §39)

Les `EventCode` restent le pivot de normalisation (`OMK-MOB-...`, `OMK-API-...`,
`OMK-DIAG-...`). Ne jamais remplacer ces codes par du texte libre. Rechercher par
`EventCode` pour agréger, puis affiner par `TraceId`/`SessionId`.

## Doublons (§42)

La chaîne est **at-least-once** : des doublons peuvent apparaître dans SigNoz
(réessai après panne, checkpoint perdu). Utiliser `EventId` pour les identifier.
La déduplication centrale n'est pas critique et peut être ajoutée plus tard si
nécessaire, sans rendre le pipeline critique.