> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flux de travail AppSignal MCP

Ces exemples montrent comment les outils AppSignal MCP se combinent pour des tâches courantes. Pour les paramètres de chaque outil, consultez la [Référence des outils MCP](/fr/mcp/reference).

<h3 id="investigating-a-production-error">
  Enquête sur une erreur en production
</h3>

1. Lister les exceptions ouvertes récentes : *« Show me all open incidents in production from the last 24 hours »*
2. Obtenir les détails complets sur un incident spécifique : *« Get the details for incident #847 including the stack trace »*
3. Récupérer les traces pour voir ce qui s'est passé au niveau du code : *« Get the error traces for incident #847 »*
4. Documenter vos conclusions : *« Add a note to incident #847: investigated the database timeout — connection pool was exhausted during peak traffic »*
5. La résoudre : *« Close incident #847 »*

<h3 id="profiling-a-slow-action">
  Profilage d'une action lente
</h3>

1. Obtenir un aperçu des performances : *« Which actions are slowest in the web namespace right now? »*
2. Récupérer les traces pour le pire contrevenant : *« Get traces for BlogPostsController#index from the last hour »*
3. Inspecter l'arbre des spans pour trouver le goulot d'étranglement : *« Show me the full span tree for trace abc123 »*
4. Plonger dans un span spécifique : *« Get the details for span def456 in trace abc123 »*

<h3 id="triaging-a-batch-of-incidents">
  Triage d'un lot d'incidents
</h3>

1. *« Find all open incidents in the background namespace from the last week »*
2. *« Mark incidents #120, #121, and #122 as work in progress and assign them to Jana »*
3. *« Close all incidents related to ActionMailer — they were fixed in the last deploy »*

<h3 id="searching-logs-during-an-incident">
  Recherche de journaux pendant un incident
</h3>

1. *« Find all error logs from the last hour »*
2. *« Show me logs where message contains 'timeout' on web-1 between 14:00 and 15:00 »*
3. *« Get fatal logs from the payments source over the last 30 minutes »*

<h3 id="reconstructing-a-customer-journey">
  Reconstruction du parcours d'un client
</h3>

Lorsqu'un utilisateur signale qu'un problème est survenu, la réponse est généralement répartie sur les journaux de plusieurs sources, ainsi que sur les erreurs et les traces. Un agent peut recoller cette chronologie pour vous.

1. *« Get all logs for user.id=4321 from production over the last 24 hours, across every source »*
2. *« Narrow that to the window between 14:00 and 15:30 UTC and group the results by source »*
3. *« List any open exception incidents from production in that same window — anything tagged with user.id=4321? »*
4. *« For incident #903, pull the error traces and walk the span tree »*
5. *« Summarize what happened: which actions did this user hit, what failed, and where did the error originate? »*

Cela utilise `get_log_lines`, `get_exception_incidents` et `get_traces` dans une seule conversation. L'étape finale de résumé est là où MCP justifie son intérêt — l'agent compose le récit, pas vous.

<h3 id="setting-up-log-processing">
  Configuration du traitement des journaux
</h3>

AppSignal exécute les actions de ligne de journal lors de l'ingestion, dans l'ordre que vous définissez. Un modèle courant consiste à émettre une métrique, créer un déclencheur, puis filtrer — cela garantit qu'AppSignal capture le signal avant d'écarter la ligne de journal.

1. Vérifier les actions de ligne de journal existantes et leur ordre : utilisez `get_app_resources` avec `sections: ["log_line_actions"]`
2. *« Create a metrics action that counts log lines where severity is error as log.error\_count »*
3. *« Add a trigger action that fires an alert when severity is fatal »*
4. *« Add a filter to drop all health check log lines »*
5. *« Reorder those actions so the metrics action runs first, then the trigger, then the filter »*

<h3 id="creating-an-anomaly-detection-trigger">
  Création d'un déclencheur de Anomaly detection
</h3>

1. Découvrir les métriques disponibles : *« What metrics are available for my production app? »*
2. Vérifier les tags disponibles : *« What tags are available for response\_time? »*
3. Créer le déclencheur : *« Create a trigger that fires when mean response time exceeds 500ms for more than 5 minutes, and notify the Slack #alerts channel »*
4. Archiver un ancien déclencheur une fois remplacé : utilisez `get_triggers` pour trouver d'abord l'ID, puis *« Archive the old response\_time trigger »*

<h3 id="building-a-monitoring-dashboard">
  Construction d'un tableau de bord de surveillance
</h3>

1. *« What metrics are available for my production app? »*
2. *« Create a dashboard called 'API Health' in production »*
3. *« Add a line chart of p95 response time by action to the API Health dashboard »*
4. *« Add an area chart of error rate broken down by namespace »*
5. *« Add a Big Number tile showing the mean of response\_time, formatted as a duration »*

***