1. 分布式日志系统概述日志系统是现代IT架构中不可或缺的基础组件。随着业务规模扩大传统的单机日志收集方案逐渐暴露出性能瓶颈和可靠性问题。我们团队最近完成了一个日均处理百亿级日志条目的分布式系统今天就来分享这套架构的设计思路和实现细节。这个系统最核心的挑战在于如何在保证数据可靠性的前提下实现海量日志的实时收集、高效存储和快速检索。我们最终采用的方案结合了Kafka的消息队列、Elasticsearch的索引能力和自研的流处理组件整套系统在压测中实现了每秒百万级日志写入和亚秒级检索响应。2. 架构设计解析2.1 核心组件选型日志采集层选用Filebeat作为agent相比Logstash它的资源占用更低实测单实例内存消耗50MB特别适合大规模部署。传输层采用Kafka集群分区策略根据日志来源的IP哈希分配确保相同主机的日志始终写入同一分区。存储层采用Elasticsearch的冷热数据分离架构热节点集群3个data节点32核/128GB内存/NVMe SSD温节点集群5个data节点16核/64GB内存/SAS HDD索引策略按天分片设置15天自动滚动ILM策略2.2 关键设计决策写入优化通过批量提交和压缩传输降低网络开销。实测显示当batch.size设置为1MB时Kafka生产者吞吐量可达8MB/s千兆网络环境下。存储优化采用自定义mapping关闭不必要的字段分析仅对关键字段如error_code、trace_id建立倒排索引。这使得单个日志文档的存储体积减少了40%。3. 核心实现细节3.1 日志收集管道Filebeat配置示例部分filebeat.inputs: - type: log paths: [/var/log/app/*.log] fields: env: production processors: - decode_json_fields: fields: [message] target: json output.kafka: hosts: [kafka1:9092, kafka2:9092] topic: applogs-%{[fields.env]} partition.round_robin: reachable_only: true compression: snappy关键提示必须设置fields.env区分环境避免测试日志污染生产数据。我们曾因配置错误导致测试日志混入生产集群引发严重事故。3.2 流处理拓扑使用Flink实现的日志清洗作业包含以下算子格式校验过滤非法JSON约占总量的0.3%字段提取解析嵌套结构如将$.user.id展开为顶层字段敏感信息脱敏使用正则表达式匹配并替换信用卡号等PII数据路由分发根据日志级别将ERROR以上日志单独写入告警队列DataStreamLogEntry stream env .addSource(new KafkaSource()) .map(new LogParser()) .filter(new LogValidator()) .keyBy(entry - entry.getHostIp());4. 性能优化实战4.1 写入吞吐提升通过以下参数组合我们将ES写入性能从2w docs/s提升到15w docs/s刷新间隔refresh_interval30s副本数number_of_replicas1写入期间线程池thread_pool.write.size8批量大小bulk.actions50004.2 查询加速方案针对高频查询场景如status:500 AND api:/v1/order我们建立status_api复合字段使用doc_values预排序配置fielddata缓存仅限低频字段查询响应时间从1200ms降至80ms。5. 运维监控体系5.1 健康检查指标Kafka滞后监控消费组延迟5分钟触发告警ES健康度_cluster/health?timeout30s返回yellow状态持续10分钟需介入节点负载JVM内存使用75%时自动扩容5.2 灾备方案采用跨机房双活架构日志同时写入两个Kafka集群同步复制使用MirrorMaker实现集群间数据同步ES配置snapshot到对象存储每日全量每小时增量6. 典型问题排查案例1日志丢失现象Filebeat显示已发送但Kafka无数据根因生产者acks1且min.insync.replicas2修复改为acksall并验证ISR列表案例2查询超时现象复杂聚合查询频繁timeout分析发现存在cardinality爆炸的user_id字段方案改用hyperloglog算法估算去重数这套系统上线后稳定运行了18个月日均处理日志量从3TB增长到15TB。最大的收获是分布式系统必须为每个组件设计降级方案我们通过动态调整Kafka保留策略和ES刷新间隔成功应对了多次流量高峰冲击。