企业官网建设流程全解析

5步给 Hermes Agent 接上 Prometheus + Grafana + Alertmanager 监控告警：完整配置指南

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent

本文带你用 5 个步骤为 Hermes Agent 搭建一套可落地的监控告警链路：开启 vLLM 指标端口、让 Prometheus 抓取目标、在 Grafana 里盯住核心指标，并写出两条真正会触发通知的 Alertmanager 告警规则，适合刚接触可观测性的新手照着做。

先搞懂这套监控链路：3 个角色各自负责什么

在动手前，先用一句话理解每个组件的定位（都是开源软件，社区有大量成熟实践）：

这三者分工明确：Prometheus 管"采"，Grafana 管"看"，Alertmanager 管"喊"。另外说明一点：Hermes Agent 项目本身带有服务健康监控模块（源码位于agent/monitoring/目录），负责网关健康事件与 OTLP 导出，和本文的 vLLM 指标路线是互补关系，可以并行使用。

第 1 步｜启动 vLLM 并开启指标端口

Hermes Agent 的 MLOps 模块已内置 Prometheus 支持。以 vLLM 为例，启动服务时带上--enable-metrics参数并指定指标端口，这是后面一切抓取的基础：

vllm serve meta-llama/Llama-3-8B-Instruct \ --enable-metrics \ --metrics-port 9090

⚠️ 注意：漏掉--enable-metrics是最常见的翻车点——不带上它，/metrics端点根本不存在，Prometheus 抓到的永远是空数据。

第 2 步｜让 Prometheus 抓取 Hermes Agent 目标

Prometheus 不推送、只拉取，因此需要在它的配置文件prometheus.yml中登记抓取目标。配置要点只有三处：job_name用于区分来源，targets填 vLLM 指标地址，scrape_interval控制抓取频率。

scrape_configs: - job_name: 'hermes-agent' static_configs: - targets: ['localhost:9090'] metrics_path: '/metrics' scrape_interval: 15s

保存后重启 Prometheus 容器（或kill -HUP其进程）即可生效。验证方法很简单：打开 Prometheus 的 Targets 页面，确认hermes-agent这一行状态为 UP；或者用curl localhost:9090/metrics直接看原始指标输出。

📊 第 3 步｜Grafana 里优先盯这 5 个核心指标

数据入库后，在 Grafana 新建数据源指向 Prometheus，然后建一个"AI 性能概览"面板。下面 5 个指标是排查问题性价比最高的起点，建议全部建图：

搭面板时建议按这个顺序组织：顶部放吞吐量与成功率，中间放响应时间分布，底部放 GPU 资源与错误率。这样从上往下扫一眼，就能回答"现在忙不忙、快不快、稳不稳"三个问题。

🔔 第 4 步｜两条能落地的 Alertmanager 告警规则

告警宁缺毋滥。结合上文指标，以下两条规则覆盖了"出错"和"变慢"两类最常见故障，for字段用于过滤瞬时抖动，避免半夜被单次毛刺吵醒：

groups: - name: hermes_agent_alerts rules: - alert: HighErrorRate expr: rate(vllm_request_failure_total[5m]) > 0.05 for: 2m labels: severity: critical annotations: summary: "High error rate detected" description: "Error rate is {{ $value | humanizePercentage }} for the last 5 minutes" - alert: SlowResponseTime expr: histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket) > 2 for: 5m labels: severity: warning annotations: summary: "Slow response time detected" description: "P99 response time is {{ $value }} seconds"

通知渠道在alertmanager.yml中按需配置，邮件、Slack、PagerDuty、企业微信/钉钉都有现成集成，按团队值班习惯二选一即可，不必全开。

🐳 第 5 步｜用 Docker Compose 一键拉起整套组件

手动逐个启动容易漏端口，推荐用 Docker Compose 统一部署。四个服务的要点如下：

注意 Prometheus 的 9090 是它自己的 Web UI 端口，与 vLLM 的指标 9090 并不冲突（一个在容器内，一个走业务网络），但建议按上表把宿主机侧错开到 9091，方便区分记忆。生产环境若跑在 Kubernetes 上，思路一致：把同样的 scrape 配置交给 PromStack（如 Prometheus Operator），通过 Service 暴露/metrics，Pod 扩缩容时监控会自动覆盖新实例。

⚠️ 常见坑：配置对了一直不出数怎么办

1. 指标端口没开：确认 vLLM 启动参数里确实有--enable-metrics，老进程要重启才生效。
2. 端口写串了：targets里应填 vLLM 的指标地址（9090），不是 Prometheus 自己的 UI 地址。
3. 指标名拼错：Grafana 查询为空时，先去 Prometheus 的 Metrics Explorer 里搜vllm_前缀，按实际名字抄录，别凭记忆打字。
4. 时区与时间范围：Grafana 时间选择器默认"过去 1 小时"，刚部署完记得点刷新或拉长时间窗口。
5. 队列打满的取舍：抓取间隔越小数据越密，但存储与查询压力同步上升，15 秒对多数场景已经够用。

进阶：让监控更省资源、更安静

• 对高优先级服务可把scrape_interval缩短到 5 秒，换取更快的故障发现，但要评估存储成本。
• 复杂表达式（如 p99 延迟）建议写成 Prometheus recording rules 预计算，Grafana 面板加载会明显变快。
• 给关键指标设多级阈值（warning → critical），并配合 Alertmanager 的分组与抑制，从根上避免告警风暴。
• 每季度回顾一次指标清单：删掉没人看的，补上业务新增的，保持面板"一眼能用"。

小结与下一步

到这里，Hermes Agent 的"采—看—喊"闭环就完整了：vLLM 开指标端口 → Prometheus 15 秒一抓 → Grafana 五图速览 → Alertmanager 双规则兜底。建议接下来做两件事：一是用hermes doctor之类的项目自检命令与监控数据交叉验证一次真实故障（如拔网线模拟超时）；二是把 Alertmanager 的通知接到值班群，观察一周再微调阈值。监控的价值不在于面板多漂亮，而在于告警响起时，你能在 1 分钟内定位到是哪一环出了问题。

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent