用 Amazon Q + New Relic MCP 搭建值班事故分拣 Agent

2026-06-10 31 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

凌晨两点，PagerDuty 响了。你爬起来打开 New Relic 看仪表盘、翻日志、查部署记录、在 Slack 里同步进展、最后还要在 Asana 里建任务留档——整套流程走完，半小时过去了，其中大部分时间花在"找信息"而不是"做判断"上。

Amazon Q 的 Agent 能力加上 New Relic 的 MCP Server，可以把这套"人肉串联"压缩成一条 prompt：Agent 自动查指标、拉日志、拼出根因分析摘要，再直接在 Asana 里建好交接任务。这篇文章拆解怎么把这套流程搭起来。

事故分拣为什么适合 Agent 化

事故分拣的核心动作有三步：

  1. 信息收集——错误率飙升了吗？哪个服务？最近有没有部署变更？关联的依赖有没有异常？
  2. 根因初判——把散落的证据串成一条可读的 RCA 概要，附带证据链接。
  3. 任务交接——把分析结果落到项目管理工具里，附带优先级和负责人。

这三步的特点是：每一步都要跨系统操作（观测平台、日志系统、项目管理），但决策逻辑相对固定。Agent 最擅长的就是"按固定策略跨系统编排"，人则负责最后的拍板。

整体架构：一条 prompt 串起三个系统

架构并不复杂：

用户 prompt
    │
    ▼
Amazon Q Agent（编排层）
    │
    ├──► New Relic MCP Server（观测数据）
    │       查 NRQL、拉 dashboard、读 incident 详情
    │
    └──► Asana Integration（任务管理）
            创建 task、填描述、设优先级

Amazon Q 是编排者，它收到用户的自然语言指令后，决定调用哪个工具、按什么顺序。New Relic MCP Server 把 New Relic 的查询能力暴露成 MCP 工具——Agent 不需要学 NRQL 语法，直接用自然语言描述意图，MCP Server 翻译成具体查询。Asana 部分通过 Amazon Q 的原生集成对接，创建任务时直接写入 RCA 概要和证据链接。

关键点：MCP（Model Context Protocol）是整个流程的粘合层。New Relic 已经发布了官方 MCP Server，它把 NRQL 查询、entity 搜索、dashboard 读取等能力标准化成一组 tool definition，任何兼容 MCP 的 Agent 都能直接调用。

实战搭建：从零配置到一条 prompt 出结果

下面给出一个最小可运行的配置示例，展示如何让 Amazon Q Agent 连上 New Relic MCP Server 并完成一次事故分拣。

第一步：部署 New Relic MCP Server

New Relic 的 MCP Server 是一个 Node.js 服务，需要你的 New Relic API Key。最简单的跑法是本地启动：

# 克隆官方 MCP Server
git clone https://github.com/newrelic/newrelic-mcp-server.git
cd newrelic-mcp-server

# 安装依赖
npm install

# 设置环境变量——换成你自己的 API Key
export NEW_RELIC_API_KEY="NRAK-XXXXXXXXXXXX"
export NEW_RELIC_ACCOUNT_ID="1234567"

# 启动 MCP Server（stdio 模式，供 Agent 调用）
node dist/index.js --transport stdio

如果你在远程服务器上跑，可以换成 SSE 模式并加认证：

node dist/index.js --transport sse --port 8080 --apiKey mcp-secret-token

第二步：在 Amazon Q 中注册 MCP 工具和 Asana 集成

Amazon Q 的 Agent 配置通过 YAML 定义。以下是一个精简的配置文件，把 New Relic MCP 和 Asana 都接上：

# amazon-q-agent-config.yaml
agent:
  name: incident-triage-assistant
  description: "事故分拣助手：查 New Relic 指标，拼 RCA 概要，建 Asana 任务"

  tools:
    # --- New Relic MCP Server ---
    - name: newrelic-mcp
      type: mcp
      connection:
        transport: stdio
        command: node
        args: ["dist/index.js", "--transport", "stdio"]
      env:
        NEW_RELIC_API_KEY: "${NEW_RELIC_API_KEY}"
        NEW_RELIC_ACCOUNT_ID: "${NEW_RELIC_ACCOUNT_ID}"
      # MCP Server 自动暴露的工具，无需逐个声明
      # 包括：nrql_query, entity_search, dashboard_read, incident_lookup 等

    # --- Asana 原生集成 ---
    - name: asana-create-task
      type: native-integration
      integration: asana
      action: createTask
      parameters:
        workspace: "${ASANA_WORKSPACE_GID}"
        project: "${ASANA_PROJECT_GID}"

  prompts:
    system: |
      你是事故分拣助手。收到事故描述后，按以下步骤行动：
      1. 用 newrelic-mcp 的 entity_search 找到相关服务实体
      2. 用 nrql_query 查该服务的错误率、响应时间、吞吐量（最近 30 分钟）
      3. 用 incident_lookup 查 New Relic 中是否已有对应 incident，获取详情
      4. 综合以上信息，写一段 RCA 概要（含证据链接）
      5. 用 asana-create-task 创建交接任务，描述中粘贴 RCA 概要
      如果某一步查不到数据，明确说明而不是跳过。

把配置文件放到 Amazon Q 的项目目录下，Agent 启动时会自动加载。

第三步：一条 prompt 完成分拣

配置好之后，值班人员只需要发一条自然语言指令：

订单服务的错误率在过去 15 分钟从 0.3% 飙升到 8%，请分拣这个事故。

Agent 的执行轨迹大致如下：

→ entity_search("OrderService") → 找到实体 ID: MNX-ORDER-PROD
→ nrql_query("SELECT errorRate FROM Metric WHERE entity = 'MNX-ORDER-PROD' SINCE 30 MINUTES")
  → 结果：errorRate 0.3% → 8.2%，14:22 开始飙升
→ nrql_query("SELECT count(*) FROM TransactionError WHERE entity = 'MNX-ORDER-PROD' SINCE 30 MINUTES FACET error.message")
  → 结果：Top error = "TimeoutException: payment-gateway响应超时"
→ incident_lookup(entity="MNX-ORDER-PROD") → New Relic 已有 open incident #INC-2048
→ 生成 RCA 概要：
    根因初判：订单服务依赖的 payment-gateway 超时，14:22 开始。
    证据：NRQL 查询链接 × 2，Incident #INC-2048 链接
→ asana-create-task：
    标题：[P2] OrderService 错误率飙升 — payment-gateway 超时
    描述：RCA 概要 + 证据链接
    指派：on-call 组

从 prompt 到 Asana 任务，整个链路不到一分钟。人只需要看一眼 RCA 概要，确认判断方向没问题，就可以开始修了。

边界与取舍

这套方案不是万能的，几个实际落地时要注意的点：

Agent 的判断质量取决于观测数据的覆盖度。 如果 New Relic 里没有对应服务的 APM 数据、没有自定义的 error metric，Agent 查出来的结果就是空的。落地前先确认关键服务都有完整的 instrumentation。

MCP Server 的权限要收紧。 New Relic API Key 给了 Agent 查询能力，也给了它读取所有 entity 的能力。建议用 scoped API Key，只开放读权限，且限制到特定 account。

RCA 概要是"初判"不是"定论"。 Agent 拼出来的分析是基于指标和日志的表面关联，深层根因（比如数据库死锁、第三方服务降级）仍然需要人去验证。在 Asana 任务描述里加一句"待人工确认根因"，避免团队把 Agent 输出当成最终结论。

Asana 集成的字段映射要提前约定。 优先级怎么定（P1/P2/P3 的触发条件）、指派给谁（on-call rotation 还是固定组）、标签体系——这些应该在 Agent 配置的 system prompt 里写清楚，而不是每次让 Agent 自己猜。

上手清单

如果你想在团队里试这套流程，建议按这个顺序走：

  1. 选一个高频事故场景做试点——比如某个微服务的 5xx 告警，不要一开始就覆盖所有服务。
  2. 确认 New Relic 数据覆盖——目标服务有 APM agent、有 custom metric、有 alert policy。
  3. 本地跑 MCP Server 验证连通性——用 nrql_query 手动查一条数据，确认 API Key 和 Account ID 没问题。
  4. 写最小 Agent 配置——只接 New Relic MCP，不接 Asana，先验证 Agent 能正确查数据、拼概要。
  5. 加上 Asana 集成——在配置里补上任务创建，跑一次完整链路。
  6. 在值班流程里嵌入——把 Agent 的入口放到 Slack/Teams 的值班频道，让 on-call 人员习惯先 prompt 再手动确认。

事故分拣不会因为 Agent 而消失，但"找信息拼上下文"这二十分钟可以压缩到一分钟。省下来的时间，用在真正需要人判断的地方。

# AI # AWS # LLM # 云平台 # 全栈 # 后端 # 机器学习

相关推荐