Hermes Agent 的 AI 代理日志监控完整指南用 ELK Stack 从 0 到告警的 4 个阶段【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent凌晨两点告警群弹出一条响应超时值班的人打开服务器面对的是散落在几个目录里的 JSON 日志文件——翻到凌晨三点也没定位到是哪个会话出了问题。如果你正在用 Hermes Agent 跑 AI 代理这种日志都在就是没法看的困境靠堆人肉是解决不了的得上一套集中式的 AI 代理日志监控。这套完整方案不复杂用 ELK StackElasticsearch Logstash Kibana 三件套业界最常见的日志分析组合把 Hermes Agent 的会话日志收进来、查得动、报得出。先看图日志从哪来、经过谁、到哪去图里这个会话列表就是故事的起点。Hermes Agent 把每个会话的完整交互过程记成 JSON 文件放在本机~/.hermes/sessions/目录下——AI 代理日志监控要的原始数据天生就是结构化的这点比很多系统省了不少事。数据流一共三段。起点是这些 JSON 会话文件中间是 Logstash可以理解为日志的搬运工翻译官负责读取文件、补字段、统一时间戳再转发出去终点是 Elasticsearch带全文检索能力的分布式存储日志存进去就能用类 SQL 的方式查。Kibana 则负责把查询结果画成图表和仪表板。一句话会话产生日志Logstash 搬运ES 落地Kibana 呈现。 阶段一装起来先把 ELK 三件套跑通你不需要自己编译部署一条 compose 命令就能把三个容器拉起来# 用 Docker Compose 一键拉起 Elasticsearch、Logstash、Kibana 三个容器 services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.11.3 environment: - discovery.typesingle-node # 单节点模式测试环境够用 - ES_JAVA_OPTS-Xms512m -Xmx512m ports: [9200:9200] logstash: image: docker.elastic.co/logstash/logstash:8.11.3 environment: - XMS1g - XMX1g ports: [5044:5044] kibana: image: docker.elastic.co/kibana/kibana:8.11.3 ports: [5601:5601]把这份docker-compose.yml存到部署机上执行docker compose up -d即可。注意两件事ES 的 512MB 内存是给测试机留的余量生产环境按内存翻倍配置浏览器打开http://机器IP:5601能进 Kibana 登录页说明整套栈活着。Hermes Agent 本身怎么跑都行仓库里的Dockerfile提供了容器化部署的参考写法日志位置不变。 阶段二接通日志让 Logstash 盯上会话文件这一阶段的核心是一个 Logstash 管道配置文件可以理解为作业说明书从哪读、怎么处理、往哪写# logstash-hermes.conf读会话日志、提取会话 ID、按天写入 ES input { file { path /root/.hermes/sessions/*.json start_position beginning # 首次从文件头读把存量日志也收进来 } } filter { mutate { add_field { [metadata][session_id] %{[session_id]} } } date { match [ timestamp, ISO8601 ] } } output { elasticsearch { hosts [http://localhost:9200] index hermes-logs-%{YYYY.MM.dd} # 每天一个索引方便生命周期管理 } }把它挂进 logstash 容器volume 映射到/usr/share/logstash/pipeline/logstash.conf后重启容器。配置里有三个值得留意的点sincedb_path别设成/dev/null否则 Logstash 每次重启都从头重读日志会重复入库会话 ID 被搬进metadata字段后同一会话的日志在 ES 里可以串起来查索引名按天切分hermes-logs-2026.08.28这种后面做索引自动清理就方便。在 ES 里执行一条GET hermes-logs-*的查询能返回文档数说明链路通了。 阶段三看得清用 Kibana 把日志变成面板Kibana 的 Discover逐条翻查日志的界面是验证阶段的最佳位置。先建一个数据视图指向hermes-logs-*你会注意到日志里干干净净——这是 Hermes Agent 内置的 agent/redact.py 的功劳这个脱敏模块在日志落盘前就把 API 密钥、token 这类敏感串遮掉了短 token 全遮盖长 token 只留头尾几位方便排查。敏感信息不进 ES是你敢把日志集中存储的前提。仪表板建议先放四块内容活跃会话数按session_id去重计数、错误分布按错误类型聚合堆叠柱状图最直观、响应时间分位数P50/P95/P99 折线、会话 ID 过滤器顶部常驻排查时一输即定位。查询技巧先用时间范围缩小区间再用会话 ID 精确过滤这样即使数据量大也查得飞快。Kibana 告警配置建议从最简单的阈值规则开始比如最近 5 分钟 error 级别日志数超过 50 条就推送到值班群。阈值不用追求一步到位跑一周后按实际流量调比一上来就配复杂规则靠谱。️ 阶段四防异常从阈值告警走向预测性提醒纯阈值规则有个软肋慢速劣化比如延迟每天涨 3%单看每天都正常它发现不了。这里 Hermes Agent 留了一个很好的口子agent/monitoring/ 目录下的 OTLP 导出器OTLP 是 OpenTelemetry 的标准协议可以理解成观测数据的通用插头能把网关健康事件实时流式输出到你配置的任何 OpenTelemetry Collector 端点注释里明确支持对接企业现成的可观测性栈。装上这个可选依赖pip install hermes-agent[otlp]并配置导出端点后异常检测和趋势预警就能直接复用企业现有的告警体系不用重新发明轮子。如果暂时不想上 OTel也可以在 Kibana 里用统计规则兜底错误率、P95 延迟的同比突增告警加上基于 7 天窗口的容量趋势预测已经能覆盖大部分防患于未然的场景。 避坑手册四个高频问题现象→原因→处理现象Logstash 拉不到新日志。原因容器内路径写错或sincedb_path被设成/dev/null位置数据库丢失等于每次重启都失忆。处理进容器确认path指向的文件真实存在sincedb_path改成持久化路径并挂载 volume让重启后能从断点续读。现象Kibana 时间线错乱日志排序不符合直觉。原因date过滤器没生效字段格式和声明的ISO8601对不上Kibana 只能退而求其次用接收时间排序。处理在 Kibana 里抽查几条文档的原始timestamp和会话文件里的timestamp字段比对格式不一致就改match的解析格式改完重启 logstash 容器让新数据走新规则。现象Kibana 查询越来越慢。原因分片数配得不合理或查询条件没落在date字段上ES 被迫做全量扫描。处理单节点测试环境保持默认分片数即可生产环境按数据节点数配置查询习惯上先时间范围、后关键字过滤频繁用于过滤的字段如session_id、错误类型在索引映射里声明为keyword类型。现象索引越积越多磁盘告急。原因按天建索引但没有清理策略hermes-logs-*无限生长。处理给 ES 配一套 ILMIndex Lifecycle Management索引生命周期管理可理解为 ES 的自动保洁计划热阶段留 7 天保证查询速度温阶段 30 天冷阶段压缩存储 90 天超过 365 天自动删除。配完之后这块可以彻底不管。收尾这套东西真正值钱的地方是把半夜翻日志变成看一条推送。出问题时一条会话 ID 就能调出完整交互链路告警直接打到值班群不用等人发现容量规划也有真实数据支撑而不是拍脑袋。等 Hermes Agent 的会话量和插件数量继续涨扩展路径是现成的Logstash 端加更细的解析规则OTLP 那条链路挂上更丰富的指标维度异常检测从阈值规则升级到统计模型。日志监控这件事起点只是把日志收进一个地方终点是让系统开始替你看日志。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考