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

# Workflows do AppSignal MCP

Estes exemplos mostram como as ferramentas do AppSignal MCP se combinam para tarefas comuns. Para os parâmetros de cada ferramenta, veja a [Referência de ferramentas do MCP](/pt-BR/mcp/reference).

<h3 id="investigating-a-production-error">
  Investigando um erro de produção
</h3>

1. Liste as exceções abertas recentes: *"Show me all open incidents in production from the last 24 hours"*
2. Obtenha detalhes completos sobre um incidente específico: *"Get the details for incident #847 including the stack trace"*
3. Puxe traces para ver o que aconteceu no nível do código: *"Get the error traces for incident #847"*
4. Documente seus achados: *"Add a note to incident #847: investigated the database timeout — connection pool was exhausted during peak traffic"*
5. Resolva-o: *"Close incident #847"*

<h3 id="checking-what-a-deploy-broke">
  Verificando o que um deploy quebrou
</h3>

1. Liste os erros introduzidos pelo último deploy: *"Which new errors did the last deploy to MyStore production introduce?"*
2. Verifique um deploy específico: *"Show only the new errors from deploy a1b2c3d"*
3. Investigue um deles: *"Get the details and error traces for incident #912"*
4. Verifique novamente mais tarde: *"Have any new errors appeared since 09:00 UTC today?"*

<h3 id="profiling-a-slow-action">
  Analisando uma action lenta
</h3>

1. Obtenha uma visão geral de performance: *"Which actions are slowest in the web namespace right now?"*
2. Puxe traces para o pior caso: *"Get traces for BlogPostsController#index from the last hour"*
3. Inspecione a árvore de spans para encontrar o gargalo: *"Show me the full span tree for trace abc123"*
4. Investigue um span específico: *"Get the details for span def456 in trace abc123"*

<h3 id="triaging-a-batch-of-incidents">
  Fazendo triagem de um lote de incidentes
</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">
  Pesquisando logs durante um incidente
</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">
  Reconstruindo a jornada de um cliente
</h3>

Quando um usuário reporta que algo deu errado, a resposta geralmente está espalhada por logs de várias fontes, além de erros e traces. Um agente pode costurar essa linha do tempo para você.

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

Isso usa `get_log_lines`, `get_exception_incidents` e `get_traces` em uma única conversa. A etapa final de resumo é onde o MCP entrega valor — o agente compõe a narrativa, e não você.

<h3 id="setting-up-log-processing">
  Configurando processamento de logs
</h3>

O AppSignal executa ações em linhas de log durante a ingestão, na ordem que você definir. Um padrão comum é emitir uma métrica, criar um gatilho e depois filtrar — isso garante que o AppSignal capture o sinal antes de descartar a linha de log.

1. Verifique as ações de log line existentes e sua ordem: use `get_app_resources` com `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">
  Detectando um job agendado que parou de rodar
</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">
  Descobrindo onde uma verificação de uptime gasta seu tempo
</h3>

1. Encontre o monitor e seu `id`: *"List the uptime monitors for this app"*
2. Divida uma verificação por fase: *"Get the uptime\_monitor\_timing timeseries for monitor abc123 in Europe, for every phase, over the last hour"*
3. Compare as regiões: *"Do the same for all regions and tell me which phase differs most between them"*

Veja [temporização da requisição](/uptime-monitoring/setup#request-timing) para as fases. Use `get_metrics_timeseries`, que aceita `*` como valor de `phase`. Uma consulta de lista precisa de uma fase por requisição.

<h3 id="creating-an-anomaly-detection-trigger">
  Criando um gatilho de Anomaly detection
</h3>

1. Descubra as métricas disponíveis: *"What metrics are available for my production app?"*
2. Verifique as tags disponíveis: *"What tags are available for response\_time?"*
3. Crie o gatilho: *"Create a trigger that fires when mean response time exceeds 500ms for more than 5 minutes, and notify the Slack #alerts channel"*
4. Arquive um gatilho antigo depois de substituído: use `get_triggers` para encontrar o ID primeiro, depois *"Archive the old response\_time trigger"*

<h3 id="building-a-monitoring-dashboard">
  Construindo um dashboard de monitoramento
</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.