这是 Beta 探索课程,内容结构、实验步骤和示例可能会继续调整。
为什么需要 Agent
日志采集是可观测系统的入口
日志采集是可观测系统的入口。入口不稳定,后面的查询、指标和告警都会失真。
最初我们可能让应用直接把日志写进数据库或远程服务,但这样会把业务请求和日志系统强耦合:日志服务慢,业务也会慢;日志服务挂了,业务甚至可能被拖垮。
更合理的方式是让应用先写本地日志,由采集 Agent 负责读取、缓冲和发送。
日志采集完整链路
应用进程只写本地日志文件业务与日志平台解耦
本地日志按路径滚动写入可批量、可持久化
采集 Agent读文件 / 缓冲 / 批量维护 offset,失败重试
消息队列 / 网关削峰填谷下游不可用时缓冲
解析与清洗脱敏 / 统一字段 / 索引日志变结构化事件
存储与计算检索 / 指标 / trace支撑查询与告警
关键认知:
Agent 的价值在于 隔离业务与日志平台——应用只写本地文件,
下游不可用时 Agent 本地缓冲并重试,日志服务慢不会拖垮业务。采集是入口,入口不稳定,后面的查询、指标和告警都会失真。
Agent 的价值
Agent 部署在每台机器或每个容器节点上,它的价值在于隔离业务和日志平台:
- 应用只负责写本地文件,性能可控。
- Agent 可以批量发送,减少网络开销。
- 下游不可用时,Agent 可以本地缓冲并重试。
- 采集策略可以统一管理,不需要频繁改业务代码。
offset 与断点续读
Agent 读取指定路径的日志文件,维护 offset(读取位置),保证进程重启后能从上次位置继续读取:
- 不重复发送已经读过的内容。
- 不跳过未发送的内容。
- 重启后从持久化的 offset 恢复。
一句话
Agent 的核心价值是隔离:应用只写本地文件,Agent 负责搬运。日志服务慢不会拖垮业务,采集策略还能统一管理。
发现内容有问题?
告诉我们哪里需要改进。
