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指标采集器按固定间隔去拉取数据定时抓取 vLLM 暴露的/metrics指标并存入自己的时序数据库Grafana可视化面板用 PromQL 查询并画图把成功率、首 token 延迟等指标变成直观图表Alertmanager告警调度器接收规则评估结果并推送通知判定错误率、延迟超阈值后通过邮件、IM 等渠道通知到人这三者分工明确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 个指标是排查问题性价比最高的起点建议全部建图指标含义PromQL 查询用途请求成功率rate(vllm_request_success_total[5m])反映服务整体健康度首 token 延迟 p50histogram_quantile(0.5, vllm_time_to_first_token_seconds_bucket)典型用户的等待体验首 token 延迟 p99histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket)长尾慢请求压测与扩容的关键依据GPU 缓存使用率vllm_gpu_cache_usage_perc预判显存压力提前扩缩容活跃请求数vllm_num_requests_running结合吞吐量判断负载拐点搭面板时建议按这个顺序组织顶部放吞吐量与成功率中间放响应时间分布底部放 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 统一部署。四个服务的要点如下服务镜像关键配置宿主机端口hermes-agenthermes-agent:latest启动命令加--enable-metrics --metrics-port 90908000、9090prometheusprom/prometheus挂载./prometheus.yml:/etc/prometheus/prometheus.yml9091容器内 9090grafanagrafana/grafana挂载grafana-data数据卷持久化仪表盘3000alertmanagerprom/alertmanager挂载./alertmanager.yml9093注意 Prometheus 的 9090 是它自己的 Web UI 端口与 vLLM 的指标 9090 并不冲突一个在容器内一个走业务网络但建议按上表把宿主机侧错开到 9091方便区分记忆。生产环境若跑在 Kubernetes 上思路一致把同样的 scrape 配置交给 PromStack如 Prometheus Operator通过 Service 暴露/metricsPod 扩缩容时监控会自动覆盖新实例。⚠️ 常见坑配置对了一直不出数怎么办指标端口没开确认 vLLM 启动参数里确实有--enable-metrics老进程要重启才生效。端口写串了targets里应填 vLLM 的指标地址9090不是 Prometheus 自己的 UI 地址。指标名拼错Grafana 查询为空时先去 Prometheus 的 Metrics Explorer 里搜vllm_前缀按实际名字抄录别凭记忆打字。时区与时间范围Grafana 时间选择器默认过去 1 小时刚部署完记得点刷新或拉长时间窗口。队列打满的取舍抓取间隔越小数据越密但存储与查询压力同步上升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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 5步给 Hermes Agent 接上 Prometheus + Grafana + Alertmanager 监控告警：完整配置指南
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指标采集器按固定间隔去拉取数据定时抓取 vLLM 暴露的/metrics指标并存入自己的时序数据库Grafana可视化面板用 PromQL 查询并画图把成功率、首 token 延迟等指标变成直观图表Alertmanager告警调度器接收规则评估结果并推送通知判定错误率、延迟超阈值后通过邮件、IM 等渠道通知到人这三者分工明确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 个指标是排查问题性价比最高的起点建议全部建图指标含义PromQL 查询用途请求成功率rate(vllm_request_success_total[5m])反映服务整体健康度首 token 延迟 p50histogram_quantile(0.5, vllm_time_to_first_token_seconds_bucket)典型用户的等待体验首 token 延迟 p99histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket)长尾慢请求压测与扩容的关键依据GPU 缓存使用率vllm_gpu_cache_usage_perc预判显存压力提前扩缩容活跃请求数vllm_num_requests_running结合吞吐量判断负载拐点搭面板时建议按这个顺序组织顶部放吞吐量与成功率中间放响应时间分布底部放 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 统一部署。四个服务的要点如下服务镜像关键配置宿主机端口hermes-agenthermes-agent:latest启动命令加--enable-metrics --metrics-port 90908000、9090prometheusprom/prometheus挂载./prometheus.yml:/etc/prometheus/prometheus.yml9091容器内 9090grafanagrafana/grafana挂载grafana-data数据卷持久化仪表盘3000alertmanagerprom/alertmanager挂载./alertmanager.yml9093注意 Prometheus 的 9090 是它自己的 Web UI 端口与 vLLM 的指标 9090 并不冲突一个在容器内一个走业务网络但建议按上表把宿主机侧错开到 9091方便区分记忆。生产环境若跑在 Kubernetes 上思路一致把同样的 scrape 配置交给 PromStack如 Prometheus Operator通过 Service 暴露/metricsPod 扩缩容时监控会自动覆盖新实例。⚠️ 常见坑配置对了一直不出数怎么办指标端口没开确认 vLLM 启动参数里确实有--enable-metrics老进程要重启才生效。端口写串了targets里应填 vLLM 的指标地址9090不是 Prometheus 自己的 UI 地址。指标名拼错Grafana 查询为空时先去 Prometheus 的 Metrics Explorer 里搜vllm_前缀按实际名字抄录别凭记忆打字。时区与时间范围Grafana 时间选择器默认过去 1 小时刚部署完记得点刷新或拉长时间窗口。队列打满的取舍抓取间隔越小数据越密但存储与查询压力同步上升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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考