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