日志收集从全能收集器退化为专用轻量客户端并只追求连续不追求完整

分布式系统一个请求跨越多个节点，必须有覆盖整个链路的全局日志系统，这 催生了专门的日志收集器。ELK最初让Logstash同时兼任节点侧收集客户端 （Shipper）和归集转换服务端（Master）两个角色——Logstash插件化设计 优秀，兼任本身没什么技术障碍，但它和插件基于JRuby、跑在独立JVM进程上、 默认堆就要1GB，作为归集端（只需部署少数几个节点）这点开销无所谓，但 要在成千上万个业务节点上都部署一份，就显得太重。Elastic.co后来把节点侧 该做的事整理成以Libbeat为核心的Beats框架，用Golang重写出功能更少但更 轻量高效的Filebeat——这是一次”专用轻量组件替代全能重型组件”的典型 架构演进，背后的逻辑是节点侧组件的部署密度决定了它必须为”轻”而牺牲 “全”。日志收集器面临的另一个现实约束是：像淘宝这种日均10PB量级日志、 收集器实例上百万的规模下，”归集到系统里的日志”要和”实际产生的日志” 保持绝对一致是不现实的，也不该为此付出过高代价——日志只追求”在可承受 代价范围内保证较高数据质量”，而不追求绝对完整精确。缓解这个矛盾最常见 的做法是在Logstash/Elasticsearch前架一层抗压更强的队列缓存（Kafka或 Redis），当处理能力遇到瓶颈或短暂停顿时，用队列削峰填谷，避免日志 数据整体丢失。