> ## 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.

# AppSignal MCP-Workflows

Diese Beispiele zeigen, wie AppSignal MCP-Tools für gängige Aufgaben zusammengesetzt werden. Die Parameter der einzelnen Tools finden Sie in der [MCP-Tool-Referenz](/de/mcp/reference).

<h3 id="investigating-a-production-error">
  Untersuchen eines Produktionsfehlers
</h3>

1. Aktuelle offene Ausnahmen auflisten: *„Show me all open incidents in production from the last 24 hours"*
2. Vollständige Details zu einem bestimmten Vorfall abrufen: *„Get the details for incident #847 including the stack trace"*
3. Traces abrufen, um zu sehen, was auf Codeebene passiert ist: *„Get the error traces for incident #847"*
4. Ihre Erkenntnisse dokumentieren: *„Add a note to incident #847: investigated the database timeout — connection pool was exhausted during peak traffic"*
5. Lösen Sie ihn: *„Close incident #847"*

<h3 id="checking-what-a-deploy-broke">
  Prüfen, was ein Deploy kaputtgemacht hat
</h3>

1. Die vom letzten Deploy verursachten Fehler auflisten: *„Which new errors did the last deploy to MyStore production introduce?"*
2. Einen bestimmten Deploy prüfen: *„Show only the new errors from deploy a1b2c3d"*
3. Einen davon untersuchen: *„Get the details and error traces for incident #912"*
4. Später erneut prüfen: *„Have any new errors appeared since 09:00 UTC today?"*

<h3 id="profiling-a-slow-action">
  Profilieren einer langsamen Aktion
</h3>

1. Performance-Überblick abrufen: *„Which actions are slowest in the web namespace right now?"*
2. Traces für den schlimmsten Übeltäter abrufen: *„Get traces for BlogPostsController#index from the last hour"*
3. Span-Baum untersuchen, um den Engpass zu finden: *„Show me the full span tree for trace abc123"*
4. In einen bestimmten Span eintauchen: *„Get the details for span def456 in trace abc123"*

<h3 id="triaging-a-batch-of-incidents">
  Triage eines Batches von Vorfällen
</h3>

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"*

<h3 id="searching-logs-during-an-incident">
  Durchsuchen von Protokollen während eines Vorfalls
</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">
  Rekonstruieren einer Kunden-Journey
</h3>

Wenn ein Benutzer meldet, dass etwas schief gelaufen ist, ist die Antwort normalerweise über Protokolle aus mehreren Quellen sowie Fehler und Traces verstreut. Ein Agent kann diese Zeitleiste für Sie zusammenfügen.

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?"*

Dies greift in einer einzigen Konversation auf `get_log_lines`, `get_exception_incidents` und `get_traces` zu. Der abschließende Zusammenfassungs-Schritt ist, wo MCP seinen Wert beweist — der Agent verfasst die Erzählung, nicht Sie.

<h3 id="setting-up-log-processing">
  Einrichten der Protokollverarbeitung
</h3>

AppSignal führt Protokollzeilen-Aktionen während der Erfassung in der von Ihnen definierten Reihenfolge aus. Ein gängiges Muster besteht darin, eine Metrik auszugeben, einen Trigger zu erstellen und dann zu filtern — dies stellt sicher, dass AppSignal das Signal erfasst, bevor die Protokollzeile verworfen wird.

1. Die vorhandenen Protokollzeilen-Aktionen und ihre Reihenfolge überprüfen: Verwenden Sie `get_app_resources` mit `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="catching-a-scheduled-job-that-stopped-running">
  Erkennen eines geplanten Jobs, der nicht mehr läuft
</h3>

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"*

<h3 id="finding-where-an-uptime-check-spends-its-time">
  Herausfinden, wo eine Uptime-Prüfung ihre Zeit verbringt
</h3>

1. Den Monitor und seine `id` finden: *„List the uptime monitors for this app"*
2. Eine Prüfung nach Phase aufschlüsseln: *„Get the uptime\_monitor\_timing timeseries for monitor abc123 in Europe, for every phase, over the last hour"*
3. Regionen vergleichen: *„Do the same for all regions and tell me which phase differs most between them"*

Die Phasen finden Sie unter [Anfrage-Timing](/uptime-monitoring/setup#request-timing). Verwenden Sie `get_metrics_timeseries`, das `*` als `phase`-Wert akzeptiert. Eine Listenabfrage benötigt eine Phase pro Anfrage.

<h3 id="creating-an-anomaly-detection-trigger">
  Erstellen eines Anomaly detection-Triggers
</h3>

1. Verfügbare Metriken entdecken: *„What metrics are available for my production app?"*
2. Verfügbare Tags prüfen: *„What tags are available for response\_time?"*
3. Den Trigger erstellen: *„Create a trigger that fires when mean response time exceeds 500ms for more than 5 minutes, and notify the Slack #alerts channel"*
4. Einen alten Trigger archivieren, sobald er ersetzt wird: Verwenden Sie `get_triggers`, um zuerst die ID zu finden, dann *„Archive the old response\_time trigger"*

<h3 id="building-a-monitoring-dashboard">
  Erstellen eines Monitoring-Dashboards
</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"*

***


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.