Enquête

Vous menez une enquête inter-produits. Les véritables enquêtes touchent presque toujours plus d'un produit — une erreur de log mène aux traces, une trace lente révèle un span défaillant, un span défaillant se corrèle avec une session spécifique. Suivez la piste jusqu'à avoir une cause racine concrète.

Prérequis

Cette compétence nécessite que le serveur MCP LaunchDarkly hébergé à distance soit configuré dans votre environnement.

Outils MCP requis :

• query-logs — récupérer les entrées de log paginées
• query-traces — récupérer les entrées de trace/span paginées
• query-error-groups — récupérer les groupes d'erreurs avec stack traces et fréquence
• query-sessions — récupérer les replays de session avec détails utilisateur
• query-aggregations — agrégations en buckets sur un type de produit pour tendances et comptages
• query-timeline-events — extraire la chronologie des événements au sein d'une session
• get-keys — découvrir les clés d'attribut/regroupement valides pour un type de produit

Flux de travail

1. Planifiez d'abord. Avant le premier appel d'outil, présentez un plan numéroté concis de ce que vous allez interroger et pourquoi. Puis exécutez-le. Ne sautez cette étape que pour des recherches triviales.
2. Commencez étroit. Choisissez une fenêtre temporelle ciblée (24h par défaut si l'utilisateur n'a pas spécifié) et l'identifiant le plus spécifique que vous ayez — trace ID, session ID, error group ID, flag key. Les requêtes larges retournent du bruit.
3. Laissez chaque résultat éclairer le suivant. N'utilisez pas un seul appel d'outil. Exécutez plusieurs invocations de query-logs, query-aggregations, query-traces, query-error-groups et query-sessions, en utilisant les conclusions de chacune pour affiner la suivante.
4. Respectez la limite de 50 entrées. Les outils query-logs, query-traces, query-error-groups et query-sessions retournent au maximum 50 entrées par appel. Pour des datasets plus larges, lancez d'abord une requête query-aggregations pour agréger, puis réduisez avec des recherches ciblées.
5. Croisez agressivement. Trace IDs dans les logs, session IDs dans les erreurs, messages d'erreur dans les replays de session — l'endroit où les produits se connectent est généralement où se trouve la cause racine.
6. Maintenez une checklist en cours. Résumez périodiquement ce que vous avez confirmé vs ce que vous devez encore tester. Cela empêche les enquêtes de dériver.
7. Terminez avec des données actionnables. Insights clairs qui répondent à la question initiale, références directes que l'utilisateur peut consulter (extraits de log, trace IDs, session IDs, error group IDs), une évaluation de la sévérité, et au moins une remediation concrète — un changement de configuration, un basculement de flag, un correctif au niveau du code avec fichier et ligne, ou une étape diagnostique spécifique avec la requête exacte à exécuter.

Charger les fichiers compagnons quand pertinent

• logs.md — quand l'enquête touche les logs (messages d'erreur, filtres level=error, patterns de log de service)
• traces.md — lors de l'analyse du flux de requête, de la latence ou des relations entre spans
• errors.md — lors de l'examen des groupes d'erreurs, stack traces, fréquence d'exception
• sessions.md — lors de la reconstruction de parcours utilisateur ou de la corrélation du comportement frontend avec les événements backend
• metrics.md — lors de l'agrégation sur un large dataset ou de la construction d'un graphique

Orientation universelle

• Préférez l'agrégation à la pagination. Si vous voulez énumérer des utilisateurs uniques, compter des valeurs distinctes ou résumer, utilisez query-aggregations avec group_by — ne paginez pas à travers les enregistrements individuels. Utilisez get-keys pour découvrir d'abord la bonne dimension de regroupement.
• Appelez get-keys avant les filtres d'attribut. Les noms d'attribut varient selon les types de produits et services (spanName vs span_name, hasErrors vs has_errors). Un appel get-keys préalable évite les requêtes gaspillées avec des noms de champ erronés.
• Citez les identifiants spécifiques. Chaque recommandation doit référencer la flag key exacte, le nom de service, session ID, trace ID ou chemin de fichier que vous avez extrait des données. L'utilisateur doit pouvoir agir sur votre résumé sans refaire votre enquête.
• Gérez les résultats d'outil volumineux. Quand un résultat d'outil est persisté dans un fichier (vous verrez « Output too large ... Full output saved to: <path> »), n'utilisez PAS Read — il a la même limite de tokens. Utilisez Bash avec python3 ou jq pour extraire la tranche spécifique dont vous avez besoin.
• Dégradation gracieuse en cas d'échec d'outil. Si un appel d'outil échoue (débordement de buffer, timeout, erreur serveur), n'arrêtez pas en silence. Essayez un outil ou une approche alternative. Si rien ne fonctionne, livrez ce que vous avez trouvé jusqu'à présent plus les étapes concrètes que l'utilisateur peut entreprendre manuellement.
• Gérer les demandes vagues. « Enquêtez sur ceci » ou « qu'est-ce qui se passe » est une invitation à creuser, pas à résumer. Itérez les appels d'outil jusqu'à avoir une cause racine ou avoir épuisé les données disponibles.

Si un outil n'est pas disponible dans votre environnement, le serveur MCP correspondant n'est peut-être pas connecté — surfacez-le plutôt que de le contourner.