日志平台设计：从采集到查询的可靠数据流

日志平台的价值，是在需要时回答问题：某个请求为什么失败，故障影响了谁，异常从哪一层开始。能把文本写进搜索引擎，只完成了其中一小部分。

本文将旧版“通天塔日志分析平台”系列及 ELK、Kafka、Rsyslog 配套笔记合并为架构专题。保留数据流与排障思路，不再提供 ElasticStack 5.0、旧插件和旧集群配置的安装步骤。

先定义事件，再挑采集器

一条日志最好能独立解释自己。常见字段包括事件时间、采集时间、服务名、环境、严重程度、请求或追踪标识，以及具体事件内容。

事件时间说明事情何时发生，采集时间有助于判断传输延迟。时区和时间格式必须统一。异常堆栈跨多行时，也需要明确它们属于一个事件，而不是在下游才猜测怎样拼接。

日志应为排障保留上下文，同时避免写入密码、访问令牌和不必要的个人信息。哪些人能够查询哪些数据、保留多久，应当在接入时确定。

一个常见的数据路径是：应用输出，采集器读取，缓冲或队列接收，处理器解析，索引存储，最后查询与告警。不是每个系统都需要全部组件，但存在的每一段都应有明确责任。

采集器需要知道读取位置怎样保存、文件轮转怎样识别、网络中断时缓冲在哪里。处理器需要决定解析失败的事件去哪里，是直接丢弃，还是隔离后修复和重放。

将坏事件送到隔离队列时，必须同时记录原因、原始内容和处理状态。否则隔离队列只会成为另一个没人查看的日志堆。

假设事件到达速率是每秒 10,000 条，消费者只能处理 8,000 条，每秒就会多积压 2,000 条。若每条按 1 KB 粗估，半小时新增约 3.6 GB 原始数据；副本、索引与存储格式还会增加实际占用。

队列容量因此需要和允许积压时间一起规划。除了消息数量，还要看最旧未处理事件的年龄。消费者恢复后，处理速度必须高于新流量，才有机会清空积压。

缓冲耗尽时，应事先决定阻塞、降采样、丢弃低价值日志或其他处理方式。不同选择的业务后果不同，不能等磁盘满了才临时决定。

处理完成后再提交消费位置，失败恢复时可能重放；先提交再处理，则可能在中途失败时丢失尚未完成的工作。消息系统的保证也不能自动延伸到任意外部数据库。

Kafka 对交付语义、事务与外部系统协调有明确边界，使用时应结合实际配置与处理方式理解。Kafka 设计文档

对日志统计而言，重复事件可能抬高计数。因此可以为事件设计稳定标识，并让写入操作具备幂等性。需要精确计费或审计的数据，还应单独设计端到端保证，而不是默认普通日志链路已经满足要求。

经常按服务、时间和请求标识查询，就应让这些字段有稳定类型和命名。把同一个字段有时写成数字、有时写成文本，会把问题留给下游。

不是所有字段都值得索引，也不是所有日志都需要保留相同时间。高基数标识、巨大正文和无限增长的字段名会影响存储与查询成本。保留策略、分区粒度、分片与副本应结合数据量和故障目标测试，不能直接沿用旧教程中的常量。

副本提供的是某种冗余，备份与恢复则解决不同问题。配置了副本之后，仍应验证误删、错误更新和跨故障域恢复。

业务没有新日志，可能是业务平静，也可能是采集器已经停止。需要分别观察事件输入量、解析失败率、队列积压、写入拒绝、索引延迟和查询延迟。

可以发送少量已知测试事件，验证它们是否按预期进入查询结果。故障演练则覆盖网络中断、消费者重启、坏事件和存储不可用。恢复后不仅看服务是否启动，还要核对缺失、重复和积压是否符合预期。

设计明确之后，再依据所选版本的官方文档落实组件配置；配置是否正确，需要通过这些失败与恢复场景检验。