从零开始给 Hermes Agent 接上性能监控Prometheus Grafana Alertmanager 五步搭完【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent凌晨两点你的 Hermes Agent 推理服务悄悄变慢直到客户先打电话来你才发现。问题不在代码在于没人盯着指标。今天带你从零给 Hermes Agent 性能监控接线Prometheus 负责把 vLLM 模型服务和网关状态拉进数据库Grafana 把曲线画出来Alertmanager 在阈值越线时把人叫醒。全程五步配完一套就能用。监控蓝图三个组件各管一件事组件职责类比Prometheus定时抓取指标并存储记账员Grafana把指标画成可看的面板仪表盘Alertmanager越线时触发通知值班电话数据流向一句话服务暴露指标 → Prometheus 定期去门口取数 → Grafana 查询展示Alertmanager 对同一批数据做规则判断后推送告警。第1步 · 先让服务把指标摆出来这一步解决没数据可抓的问题。模型侧用 vLLM 时启动只加两个参数就够vllm serve meta-llama/Llama-3-8B-Instruct \ --enable-metrics \ --metrics-port 9090 # 其余参数省略--enable-metrics打开指标采集开关默认是关的--metrics-port 9090指标暴露在 9090 端口的/metrics路径下用curl localhost:9090/metrics能拉到纯文本即成功Hermes Agent 自身的网关健康指标如hermes.gateway.up、hermes.gateway.active_agents由 agent/monitoring 模块产生通过 OTLP 导出配置里把monitoring.export.otlp.enabled打开并填好 endpoint 即可。第2步 · 最小可用的 prometheus.yml这一步解决Prometheus 知道去哪取数的问题只留四个关键字段scrape_configs: - job_name: hermes-agent metrics_path: /metrics scrape_interval: 15s static_configs: - targets: [localhost:9090] # 其余字段省略job_name给这组目标起个名字后面写 PromQL 会用到scrape_interval: 15s多久去它门口取一次数据高优先级服务可缩到 5stargets谁在哪个端口挂指标端口填错是最常见的翻车点第3步 · Grafana 看盘五块面板先搭起来这一步解决数据躺在库里眼睛看不到的问题。接入 Prometheus 数据源后优先建这几块面板面板PromQL 指标含义何时该盯请求成功率rate(vllm_request_success_total[5m])5 分钟内成功请求占比低于 99% 就是事故首 token 延迟 p50histogram_quantile(0.5, vllm_time_to_first_token_seconds_bucket)一半请求的出字时间日常基线首 token 延迟 p99histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket)最慢 1% 的出字时间卡顿投诉来了先看它GPU KV cache 占用vllm_gpu_cache_usage_perc显存缓存用了多少超过 0.9 会开始排队活跃请求数vllm_num_requests_running正在推理的并发量突增突降都异常网关存活hermes.gateway.upAgent 网关是否在跑变 0 即宕机面板搭建顺序先建请求成功率状态行红绿一眼分辨好坏延迟用 p50/p99 双曲线p99 单独设阈值线资源类cache、并发放下半区按 5m 窗口看趋势面板标题带上 job 名多目标时方便区分第4步 · 告警到人两条规则守住底线这一步解决曲线变红却没人知道的问题。在 alertmanager.yml 的 rule 文件里写groups: - name: hermes-agent rules: - alert: HighErrorRate expr: rate(vllm_request_failure_total[5m]) 0.05 for: 2m labels: { severity: critical } annotations: summary: 错误率超 5%持续 {{ $value }}s - alert: SlowTTFT expr: histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket) 2 for: 5m labels: { severity: warning } # 第二条的 annotations 省略severity分级。critical 打电话warning 发群里避免什么都喊救命for: 2m持续 2 分钟才告警滤掉瞬间毛刺通知渠道按需接每接一条改一处 config邮件SMTPSlack 或 飞书 Webhook钉钉机器人 WebhookPagerDuty值班升级第5步 · 一套 Docker Compose 全拉起这一步解决组件散落各处、重启就忘的问题只留服务名、端口、卷services: hermes-agent: image: hermes-agent:latest ports: [8000:8000, 9090:9090] prometheus: image: prom/prometheus ports: [9091:9090] volumes: [./prometheus.yml:/etc/prometheus/prometheus.yml] grafana: image: grafana/grafana ports: [3000:3000] volumes: [grafana-data:/var/lib/grafana] alertmanager: image: prom/alertmanager ports: [9093:9093] volumes: grafana-data: # 镜像其余字段省略上 K8s 后把 Prometheus 的静态 targets 换成 ServiceMonitor 自动发现即可扩缩容时监控自动跟上。避坑速查 现象告警一条接一条刷屏。→原因瞬时毛刺直接触发for写得太短。→解法给规则加for: 2m同类告警用 group_wait 合并。现象Grafana 里 target 状态一直 DOWN。→原因targets的端口填成了服务业务端口 8000指标其实在 9090。→解法先curl localhost:9090/metrics验证能拉通再填配置。现象p99 面板显示 No Data成功率却正常。→原因histogram_quantile需要_bucket数据服务没暴露直方图就只剩总量。→解法确认--enable-metrics打开指标里确实有_bucket后缀项。现象PromQL 查不到 hermes 开头的指标。→原因网关健康指标走 OTLP 导出没进 Prometheus。→解法中间加 OTel Collector 的 prometheus 导出器统一转成 9090 抓取。现象compose 里互相访问超时。→原因容器网络里 localhost 指容器自己。→解法targets 填服务名如hermes-agent:9090。完成自检清单 ✅curl localhost:9090/metrics能返回指标文本Prometheus 的 Targets 页显示 UPGrafana 五块面板有数据且 p99 有独立曲线Alertmanager 手动触发一条测试告警通知渠道收到重启整套 compose五分钟内容器全恢复且指标连续清单都勾上了监控就算真正跑起来了。想继续深入可以 clone 仓库https://gitcode.com/GitHub_Trending/he/hermes-agent翻翻 agent/monitoring 里的网关健康指标定义再看看 Dockerfile 了解服务本身的启动方式。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
从零开始给 Hermes Agent 接上性能监控Prometheus Grafana Alertmanager 五步搭完【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent凌晨两点你的 Hermes Agent 推理服务悄悄变慢直到客户先打电话来你才发现。问题不在代码在于没人盯着指标。今天带你从零给 Hermes Agent 性能监控接线Prometheus 负责把 vLLM 模型服务和网关状态拉进数据库Grafana 把曲线画出来Alertmanager 在阈值越线时把人叫醒。全程五步配完一套就能用。监控蓝图三个组件各管一件事组件职责类比Prometheus定时抓取指标并存储记账员Grafana把指标画成可看的面板仪表盘Alertmanager越线时触发通知值班电话数据流向一句话服务暴露指标 → Prometheus 定期去门口取数 → Grafana 查询展示Alertmanager 对同一批数据做规则判断后推送告警。第1步 · 先让服务把指标摆出来这一步解决没数据可抓的问题。模型侧用 vLLM 时启动只加两个参数就够vllm serve meta-llama/Llama-3-8B-Instruct \ --enable-metrics \ --metrics-port 9090 # 其余参数省略--enable-metrics打开指标采集开关默认是关的--metrics-port 9090指标暴露在 9090 端口的/metrics路径下用curl localhost:9090/metrics能拉到纯文本即成功Hermes Agent 自身的网关健康指标如hermes.gateway.up、hermes.gateway.active_agents由 agent/monitoring 模块产生通过 OTLP 导出配置里把monitoring.export.otlp.enabled打开并填好 endpoint 即可。第2步 · 最小可用的 prometheus.yml这一步解决Prometheus 知道去哪取数的问题只留四个关键字段scrape_configs: - job_name: hermes-agent metrics_path: /metrics scrape_interval: 15s static_configs: - targets: [localhost:9090] # 其余字段省略job_name给这组目标起个名字后面写 PromQL 会用到scrape_interval: 15s多久去它门口取一次数据高优先级服务可缩到 5stargets谁在哪个端口挂指标端口填错是最常见的翻车点第3步 · Grafana 看盘五块面板先搭起来这一步解决数据躺在库里眼睛看不到的问题。接入 Prometheus 数据源后优先建这几块面板面板PromQL 指标含义何时该盯请求成功率rate(vllm_request_success_total[5m])5 分钟内成功请求占比低于 99% 就是事故首 token 延迟 p50histogram_quantile(0.5, vllm_time_to_first_token_seconds_bucket)一半请求的出字时间日常基线首 token 延迟 p99histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket)最慢 1% 的出字时间卡顿投诉来了先看它GPU KV cache 占用vllm_gpu_cache_usage_perc显存缓存用了多少超过 0.9 会开始排队活跃请求数vllm_num_requests_running正在推理的并发量突增突降都异常网关存活hermes.gateway.upAgent 网关是否在跑变 0 即宕机面板搭建顺序先建请求成功率状态行红绿一眼分辨好坏延迟用 p50/p99 双曲线p99 单独设阈值线资源类cache、并发放下半区按 5m 窗口看趋势面板标题带上 job 名多目标时方便区分第4步 · 告警到人两条规则守住底线这一步解决曲线变红却没人知道的问题。在 alertmanager.yml 的 rule 文件里写groups: - name: hermes-agent rules: - alert: HighErrorRate expr: rate(vllm_request_failure_total[5m]) 0.05 for: 2m labels: { severity: critical } annotations: summary: 错误率超 5%持续 {{ $value }}s - alert: SlowTTFT expr: histogram_quantile(0.99, vllm_time_to_first_token_seconds_bucket) 2 for: 5m labels: { severity: warning } # 第二条的 annotations 省略severity分级。critical 打电话warning 发群里避免什么都喊救命for: 2m持续 2 分钟才告警滤掉瞬间毛刺通知渠道按需接每接一条改一处 config邮件SMTPSlack 或 飞书 Webhook钉钉机器人 WebhookPagerDuty值班升级第5步 · 一套 Docker Compose 全拉起这一步解决组件散落各处、重启就忘的问题只留服务名、端口、卷services: hermes-agent: image: hermes-agent:latest ports: [8000:8000, 9090:9090] prometheus: image: prom/prometheus ports: [9091:9090] volumes: [./prometheus.yml:/etc/prometheus/prometheus.yml] grafana: image: grafana/grafana ports: [3000:3000] volumes: [grafana-data:/var/lib/grafana] alertmanager: image: prom/alertmanager ports: [9093:9093] volumes: grafana-data: # 镜像其余字段省略上 K8s 后把 Prometheus 的静态 targets 换成 ServiceMonitor 自动发现即可扩缩容时监控自动跟上。避坑速查 现象告警一条接一条刷屏。→原因瞬时毛刺直接触发for写得太短。→解法给规则加for: 2m同类告警用 group_wait 合并。现象Grafana 里 target 状态一直 DOWN。→原因targets的端口填成了服务业务端口 8000指标其实在 9090。→解法先curl localhost:9090/metrics验证能拉通再填配置。现象p99 面板显示 No Data成功率却正常。→原因histogram_quantile需要_bucket数据服务没暴露直方图就只剩总量。→解法确认--enable-metrics打开指标里确实有_bucket后缀项。现象PromQL 查不到 hermes 开头的指标。→原因网关健康指标走 OTLP 导出没进 Prometheus。→解法中间加 OTel Collector 的 prometheus 导出器统一转成 9090 抓取。现象compose 里互相访问超时。→原因容器网络里 localhost 指容器自己。→解法targets 填服务名如hermes-agent:9090。完成自检清单 ✅curl localhost:9090/metrics能返回指标文本Prometheus 的 Targets 页显示 UPGrafana 五块面板有数据且 p99 有独立曲线Alertmanager 手动触发一条测试告警通知渠道收到重启整套 compose五分钟内容器全恢复且指标连续清单都勾上了监控就算真正跑起来了。想继续深入可以 clone 仓库https://gitcode.com/GitHub_Trending/he/hermes-agent翻翻 agent/monitoring 里的网关健康指标定义再看看 Dockerfile 了解服务本身的启动方式。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
