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

​
Investigando um erro de produção

  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”

​
Verificando o que um deploy quebrou

  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?”

​
Analisando uma action lenta

  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”

​
Fazendo triagem de um lote de incidentes

  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”

​
Pesquisando logs durante um incidente

  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”

​
Reconstruindo a jornada de um cliente

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

​
Configurando processamento de logs

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”

​
Detectando um job agendado que parou de rodar

  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”

​
Descobrindo onde uma verificação de uptime gasta seu tempo

  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 para as fases. Use get_metrics_timeseries, que aceita * como valor de phase. Uma consulta de lista precisa de uma fase por requisição.

​
Criando um gatilho de Anomaly detection

  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”

​
Construindo um dashboard de monitoramento

  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”