Skip to main content
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.

​
Enquête sur une erreur en production

  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 »

​
Vérification de ce qu’un deploy a cassé

  1. Lister les erreurs introduites par le dernier deploy : « Which new errors did the last deploy to MyStore production introduce? »
  2. Vérifier un deploy spécifique : « Show only the new errors from deploy a1b2c3d »
  3. Enquêter sur l’un d’eux : « Get the details and error traces for incident #912 »
  4. Vérifier à nouveau plus tard : « Have any new errors appeared since 09:00 UTC today? »

​
Profilage d’une action lente

  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 »

​
Triage d’un lot d’incidents

  1. « Find all open incidents in the background namespace from the last week »
  2. « Narrow that to incidents whose exception or action name matches ‘Timeout*’ »
  3. « Mark incidents #120, #121, and #122 as work in progress and assign them to Jana »
  4. « Close all incidents related to ActionMailer — they were fixed in the last deploy »

​
Recherche de journaux pendant un incident

  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 »

​
Reconstruction du parcours d’un client

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.

​
Configuration du traitement des journaux

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 »

​
Détection d’une tâche planifiée qui s’est arrêtée

  1. « List the cron check-ins on MyStore production »
  2. « Show the recent runs for the nightly-export check-in, and which of them were missed or late »
  3. « Create a cron check-in for daily-invoices that runs at 02:00 UTC with a 15-minute grace period, and notify the payments-oncall notifier »

​
Repérage du temps passé par une vérification de disponibilité

  1. Trouver le moniteur et son id : « List the uptime monitors for this app »
  2. Décomposer une vérification par phase : « Get the uptime_monitor_timing timeseries for monitor abc123 in Europe, for every phase, over the last hour »
  3. Comparer les régions : « Do the same for all regions and tell me which phase differs most between them »
Consultez chronométrage de la requête pour connaître les phases. Utilisez get_metrics_timeseries, qui accepte * comme valeur de phase. Une requête de liste nécessite une phase par requête.

​
Création d’un déclencheur de Anomaly detection

  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 »

​
Construction d’un tableau de bord de surveillance

  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 »