30分钟搭好 Hermes Agent 性能监控Prometheus Grafana Alertmanager 实战【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent深夜群里有人喊模型服务 P99 时延翻倍了但日志一片祥和根本无从下手。这个场景正是 Hermes Agent 性能监控要解决的问题——用 Prometheus 持续拉取指标、用 Grafana 把它们变成一张能读的大盘、再用 Alertmanager 在恶化前把你叫醒。下面按时间线走从零到整套可用。一条命令开启指标暴露先让数据跑起来以 Hermes Agent 自带的 vLLM 部署为例启动时加两个参数即可把指标暴露在 9090 端口的/metrics上vllm serve meta-llama/Llama-3-8B-Instruct \ --enable-metrics \ --metrics-port 9090然后写一个最小可用的 Prometheus 配置prometheus.yml只保留一个抓取任务scrape_configs: - job_name: hermes-agent metrics_path: /metrics scrape_interval: 15s static_configs: - targets: [localhost:9090]启动 Prometheus 后直接访问http://localhost:9091/targets端口映射见后文状态是 UP 就说明链路通了。想验证原始数据curl localhost:9090/metrics | grep vllm能刷出一长串指标就是成功。核心指标拆解先盯住这四个信号先把这四个指标看明白大盘就成了一半。指标名含义PromQL 示例参考告警阈值vllm_request_success_total/vllm_request_failure_total成功/失败请求累计数rate()换算成每秒速率rate(vllm_request_failure_total[5m]) / rate(vllm_request_success_total[5m] vllm_request_failure_total[5m])5 分钟失败率 5%vllm_time_to_first_token_seconds_bucket首 token 耗时直方图histogram把耗时切成一堆区间桶统计落点用histogram_quantile就能算出任意分位histogram_quantile(0.99, sum(rate(vllm_time_to_first_token_seconds_bucket[5m])) by (le))P99 2s 持续 5 分钟vllm_gpu_cache_usage_percGPU 上 KV 缓存推理中间状态的存储区占用比例vllm_gpu_cache_usage_perc 0.95 持续 5 分钟vllm_num_requests_running/vllm_num_requests_waiting正在运行 / 排队等待的请求数vllm_num_requests_waiting排队数 0 持续 3 分钟把指标摆进一张 Grafana AI 服务大盘Grafana 里新建数据源指向 Prometheus然后按一眼能看出好坏的顺序加面板请求成功率用上面的失败率 PromQL加一条 5% 的红色阈值线首 token 时延 P50 / P99 双曲线用户体感变化第一时间可见GPU 缓存使用率面积图配 95% 阈值活跃 排队请求数容量是否扛得住看这里。先把这四块跑通再往里加吞吐、错误分布等细节面板别一上来就堆二十个图。三条值得抄的模型服务告警规则groups: - name: hermes-agent rules: - alert: HighErrorRate expr: rate(vllm_request_failure_total[5m]) / rate(vllm_request_success_total[5m] vllm_request_failure_total[5m]) 0.05 for: 2m labels: { severity: critical } - alert: SlowFirstToken expr: histogram_quantile(0.99, sum(rate(vllm_time_to_first_token_seconds_bucket[5m])) by (le)) 2 for: 5m labels: { severity: warning } - alert: GPUCacheNearFull expr: vllm_gpu_cache_usage_perc 0.95 for: 5m labels: { severity: warning }阈值为什么这么定HighErrorRate瞬时毛刺谁都有用for: 2m滤掉单次抖动只留真的在坏的信号5% 是多数推理服务可接受的底线。SlowFirstToken首 token 超过 2 秒用户已经开始骂人但冷启动、批处理波动会误报所以for给到 5 分钟。GPUCacheNearFullKV 缓存快满时调度器会抢占重算时延会先于错误率劣化95% 是留出的缓冲线。通知渠道选型上记住一条原则critical走能吵醒人的即时通道IM 强提醒或电话warning走异步通道邮件或工单并按服务名分组抑制——同一服务多条 warning 合并成一条推送否则你收到的会是风暴而不是信息。用 Docker Compose 一键拉起监控栈services: prometheus: image: prom/prometheus ports: [9091:9090] volumes: [./prometheus.yml:/etc/prometheus/prometheus.yml] grafana: image: grafana/grafana ports: [3000:3000] alertmanager: image: prom/alertmanager ports: [9093:9093] volumes: [./alertmanager.yml:/etc/alertmanager/alertmanager.yml]docker compose up -d之后Prometheus 在 9091、Grafana 在 3000、Alertmanager 在 9093。模型服务本体按你自己的部署方式跑只要把它的 9090 端口对 Prometheus 可达即可。生产环境如果跑在 K8s 上把指标端口写成 Service 暴露、抓取交给集群内的 Prometheus Operator 就行细节可参考项目里的 vLLM 部署文档。排查与调优四个高频问题的最短解法现象原因处理Prometheus target 一直 DOWN查无指标9090 端口没对 Prometheus 可达或metrics_path写错在 Prometheus 所在机器curl目标地址的/metrics通了再查防火墙/网络告警风暴同一问题刷屏阈值太敏感、没加for窗口给每条规则补forAlertmanager 里按标签分组 抑制大盘加载慢、查询卡复杂 PromQL 每次实时计算用 recording rules 把高频查询预计算成指标面板直接引用不知道scrape_interval设多少—15s 是大多数场景的甜点关键服务压到 5s但存储与 CPU 开销约涨 3 倍从猜到看盘定位做完这套下次 P99 飙升时你打开 Grafana 就能在十秒内指认是错误率、时延还是容量先出的问题。更多指标细节和模型服务部署参数直接翻项目里的 MLOps 模块 和 vLLM 技能文档。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考