这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
日志采集
日志采集是可观测系统的入口。入口不稳定，后面的查询、指标和告警都会失真。最初我们可能让应用直接把日志写进数据库或远程服务，但这样会把业务请求和日志系统强耦合：日志服务慢，业务也会慢；日志服务挂了，业务甚至可能被拖垮。
更合理的方式是让应用先写本地日志，由采集 Agent 负责读取、缓冲和发送。
应用进程 -> 本地日志文件 -> 采集 Agent -> 消息队列/日志网关 -> 存储与计算为什么需要 Agent
Agent 的价值在于隔离业务和日志平台：
- 应用只负责写本地文件，性能可控。
- Agent 可以批量发送，减少网络开销。
- 下游不可用时，Agent 可以本地缓冲并重试。
- 采集策略可以统一管理，不需要频繁改业务代码。
Agent 通常部署在每台机器或每个容器节点上。它读取指定路径的日志文件，维护 offset，保证进程重启后能从上次位置继续读取。
采集可靠性
日志采集不可能追求绝对不丢，但要明确丢失边界。常见机制包括：
- 本地缓冲：下游不可用时，日志先写到本地队列。
- 批量发送：按条数或时间窗口聚合，提高吞吐。
- 失败重试：网络失败后指数退避，避免持续打爆下游。
- 背压限流：本地队列过大时，优先保留错误日志或关键业务日志。
- offset 持久化：Agent 重启后不重复大量发送，也不跳过未发送内容。
这些策略本质上是在“可靠性、延迟、资源占用”之间做取舍。
日志分级
不是所有日志都同等重要。采集系统应该支持按级别和业务标签区分策略：
ERROR和关键审计日志优先保留。INFO日志用于排查和统计，可以在高峰期采样。DEBUG日志默认关闭，只在临时诊断时打开。- 大字段、堆栈和请求体需要脱敏和大小限制。
如果没有分级，业务一旦打印大量无意义日志，采集链路就会被噪音淹没。
采集链路的风险
日志采集链路自身也需要监控：
- Agent 是否存活。
- 本地缓冲队列是否积压。
- 发送失败率是否上升。
- 每个服务的日志量是否突增或突降。
日志量突降可能不是系统变稳定了，而是采集挂了。只有采集入口可靠，后续解析和指标计算才有意义。