企业官网建设流程全解析

3个组件搭一条AI代理日志监控管道：Hermes Agent 日志从采集到告警

凌晨两点，值班群弹出消息：线上 Hermes Agent 卡了半小时，工具调用一次都没成功。你打开服务器，会话日志散在~/.hermes/sessions/目录里，几百个 JSON 文件按并发会话各自生长，翻哪个、怎么拼时间线，全靠手。更麻烦的是，想确认有没有把 API key 明文写进日志，得逐文件肉眼看。这类排障耗时的根源不在日志本身，而在于它们从来没被当成一个可分析的数据流。

这套做法的思路很朴素：把日志监控拆成三个组件——采集端、管道端、告警端，中间用 ELK Stack 落地。下面按数据流动的路径讲一遍。

日志从哪来：把会话文件变成标准数据源

Hermes Agent 的会话记录默认落在~/.hermes/sessions/，JSON 格式，内容是一次完整交互的全过程。并发一多，文件增长很快，直接堆在文件系统里做管理是低效的——这是集中化要解决的第一件事。

日志侧的入口是hermes_logging.py，它处理轮转和脱敏，但只算"守门"，不算分析。想让它吐标准数据，在采集端做两件事：

from hermes_logging import setup_logging, set_session_context # 初始化日志系统 setup_logging(verbose=True, mode="agent") # 设置会话上下文 set_session_context("session_12345")

再配合环境变量让输出结构化：

export HERMES_VERBOSE_LOGGING=1 export HERMES_LOG_FORMAT=json

这里有个坑必须提前处理：脱敏要在日志落盘之前完成，而不是等它进了 Elasticsearch 再补救。agent/redact.py里的RedactingFormatter是现成的，按规则把密钥、令牌替换掉再写出去：

from agent.redact import RedactingFormatter formatter = RedactingFormatter( patterns=[ r'(api_key|secret|password)=["\']?([^"\'\s]+)["\']?', r'(token|auth)=["\']?([^"\'\s]+)["\']?' ] )

这样下游管道里看到的每一行都是安全的，日志监控链路的安全性在源头就锁死了。

Logstash 管道怎么配：从文件到索引

拿到标准 JSON 之后，管道端的工作是持续采集、解析、转发。一份可用的logstash-hermes.conf大致长这样：

input { file { path => "/HOME/.hermes/sessions/*.json" start_position => "beginning" codec => "json" sincedb_path => "/dev/null" } } filter { # 会话ID提取 mutate { add_field => { "[@metadata][session_id]" => "%{[session_id]}" } } # 时间戳格式化 date { match => [ "timestamp", "ISO8601" ] } } output { elasticsearch { hosts => ["http://localhost:9200"] index => "hermes-logs-%{+YYYY.MM.dd}" document_id => "%{[@metadata][session_id]}-%{+HHmmss}" } }

三个点值得展开。一是按天滚动索引hermes-logs-%{+YYYY.MM.dd}，让 Elasticsearch 索引优化有了天然的时间边界，查询和生命周期管理都按天切。二是document_id用会话 ID 加秒级时间戳拼出来的确定性 ID，同一份日志重放不会重复入库。三是sincedb_path => "/dev/null"是演示用的：它会让 Logstash 每次重启都从文件头重读全部历史，生产环境务必改成真实的 sincedb 文件路径，否则重启一次就全量回放一遍。

部署用 Docker Compose 最快，先别急着上生产——单机模式适合验证链路：

version: '3.8' services: elasticsearch: image: elasticsearch:8.11.3 environment: - discovery.type=single-node - ES_JAVA_OPTS=-Xms512m -Xmx512m ports: - "9200:9200" volumes: - es_data:/usr/share/elasticsearch/data logstash: image: logstash:8.11.3 volumes: - ./logstash-hermes.conf:/usr/share/logstash/pipeline/logstash.conf depends_on: - elasticsearch kibana: image: kibana:8.11.3 ports: - "5601:5601" depends_on: - elasticsearch volumes: es_data:

ES 堆给到 512m 只是起步值，日志量上来之后要按实际调整；集群健康、映射和查询该看的都看，查询侧再配一下索引别名、合理的分片数和查询缓存就够了，不展开。

存多少删多久：Elasticsearch 的 ILM 策略

日志数据是只增不减的，光靠按天建索引还不够，得给hermes-logs-*配索引生命周期管理（ILM），让存储成本可控：

• 热阶段 7 天：高性能存储，实时查询走这里
• 温阶段 30 天：标准存储
• 冷阶段 90 天：归档
• 删除阶段：365 天后自动清掉

历史日志的空间大头还能再压：用agent/trajectory.py里的轨迹压缩能力对过期日志做智能压缩，压缩比目标定在 70% 以上。配合 Kibana 的角色权限（RBAC）和审计记录，访问面也一起管住；传输层 TLS 和静态数据加密按你们的密钥轮换策略走，这部分是安全基线，不赘述。

Kibana 监控仪表板搭哪些指标

数据进库之后，可视化端别贪多，先上四类核心指标：

• 会话活跃度：活跃会话数量，实时刷新
• 资源消耗：CPU、内存、磁盘使用率
• 错误率统计：按错误类型分类
• 响应时间分布：API 调用延迟分析

这四块能覆盖 80% 的日常排查场景。上仪表板的同时把运维基线也定下来：日志收集成功率大于 99.9%、端到端延迟小于 1 秒、平台可用性大于 99.95%、压缩比大于 70%。有了基线，后面异常检测才有参照物。

异常检测和告警怎么接：别让模型空转

监控做到这一步还是"看"，要主动发现得加一层日志异常检测。训练数据用前面入库的日志文档做特征，模型配置大致如下：

# 异常检测配置示例 from skills.mlops.axolotl import train_anomaly_model # 准备训练数据 training_data = prepare_log_features(log_documents) # 配置异常检测模型 config = { "model_type": "anomaly_detection", "training_samples": 10000, "detection_threshold": 0.95, "features": ["response_time", "error_rate", "session_duration"] } # 训练模型 model = train_anomaly_model(training_data, config)

detection_threshold定在 0.95，特征选了响应时间、错误率、会话时长三个维度。阈值和样本量都是需要回头调的：误报多了就调阈值、加训练样本，再配告警抑制规则，别一上来就期望模型零误报。

告警出口走gateway/delivery.py的投递通道，配合出站 webhook 把生命周期事件推到外部端点。投递是 fire-and-forget 设计：有界队列加单守护线程，回调永不阻塞 agent 主循环——这一点接自定义通知逻辑时要遵守，不然网络抖动会拖住会话本身。规则分三档：资源超阈值的阈值告警、机器学习识别出的异常模式、以及基于历史趋势的提前预警。

上线前最后再检查一遍

真正容易翻车的就两处。一是前面说的sincedb_path指向/dev/null，重启即全量回放，索引瞬间翻倍；二是单机 ES 的堆内存，日志量涨上来后 512m 会很吃力，按集群健康状态及时调整ES_JAVA_OPTS。链路如果断，按采集端目录权限、Logstash 配置语法、ES 服务状态这个顺序查，基本十分钟能定位。

行动建议：先在一台测试机上把上面三个组件串通，跑一周真实会话流量，拿 Kibana 的四类指标和 0.95 阈值下的误报率做调参依据，再考虑扩到多节点。日志监控这套东西，值不值一天搭，就看凌晨那次告警你是不是还得手动翻文件。