生产环境日志收集的常见痛点
日志数据量暴增导致存储成本飙升，每天TB级的日志让硬盘告警邮件就没停过。查询速度越来越慢，故障发生时等日志检索结果等到心焦，业务部门已经在群里@了十几次。更头疼的是分布式系统下的日志分散问题，一个请求链路的日志要跨5-8台服务器拼图，排查问题像玩侦探游戏。
日志采集层优化实战
Filebeat替代Logstash能降低40%的资源占用，配置时注意这些参数：
harvester_buffer_size 设置为16KB-32KBmax_procs 不要超过CPU核数的70%loadbalance模式避免单点故障| 采集工具 | CPU消耗 | 内存占用 | 吞吐量 |
|---|---|---|---|
| Logstash | 高 | 500MB+ | 5K EPS |
| Filebeat | 低 | 50MB | 10K EPS |
日志传输环节的可靠性设计
Kafka作为日志缓冲层时，这些配置能避免数据丢失：
acks=all 确保所有副本确认min.insync.replicas=2 最小同步副本数message.max.bytes（ 1MB-5MB）under-replicated-partitions指标遇到网络抖动时，本地磁盘缓冲机制要配合queue.max.messages=5000使用，突然断网也能保住最近5000条日志。曾经有个电商大促时因为没配这个，丢了3分钟订单日志，CTO直接拉了个事故复盘会。
存储优化与成本控制
冷热数据分离存储方案能省60%成本：
Elasticsearch的索引策略要这么玩：
number_of_shards=3（数据量小于500GB时）refresh_interval=30s 查询实时性和写入性能的平衡点force merge合并分段查询效率提升技巧
给Nginx日志加上这些字段，排查效率提升3倍：
log_format main '$remote_addr $request_id $host "$request" '
'$status $body_bytes_sent $request_time '
'"$http_referer" "$http_user_agent" '
'upstream_addr=$upstream_addr upstream_status=$upstream_status '
'upstream_response_time=$upstream_response_time';
Kibana里创建这些预置查询：
日志规范与治理
研发团队必须遵守的日志分级规范：
用log4j2的异步日志时，RingBufferSize 设为512-1024，监控AsyncLoggerConfig.RingBufferFull指标，超过5%就要扩容。某次秒杀活动就因为这个缓冲队列满了，导致日志线程阻塞影响了核心交易。
Kafka分区数的设置其实是个需要精细调校的技术活，不能简单拍脑袋决定。实际操作中我们会先评估业务峰值流量，比如双11大促期间日志量可能暴增3-5倍，这时候按照日常流量设置分区肯定会出问题。 先用压测工具模拟业务高峰，观察单个分区在5MB-10MB/s流量下的表现，重点关注消息堆积和消费延迟这两个关键指标。
分区太少会导致消费者吃不饱，太多又会把ZooKeeper拖垮。我们有个电商客户就吃过亏，32台Broker的集群设了256个分区，结果ZK集群频繁超时。后来调整到64-96个分区后，不仅稳定性上来了，消息吞吐量反而提升了20%。还有个经验是分区数最好能被Broker数量整除，比如3台Broker设6或9个分区，这样数据分布更均匀，不会出现某台机器特别忙的情况。
常见问题解答
Filebeat和Logstash应该如何选择？
Filebeat适合轻量级日志采集场景，资源占用低且部署简单，而Logstash适合需要复杂数据处理的场景。如果只是日志转发，用Filebeat能节省40%以上的资源；如果需要实时解析JSON、CSV等复杂格式，Logstash的filter插件更强大。 吞吐量在5K-10K EPS以下的场景优先考虑Filebeat。
Kafka日志缓冲应该设置多少分区？
分区数 为Kafka集群Broker数量的2-3倍，单个分区吞吐量控制在5MB-10MB/s。例如3台Broker的集群，设置6-9个分区比较合适。要避免分区数过多导致ZooKeeper压力过大，也要防止分区数不足成为性能瓶颈。
日志存储如何平衡查询速度和成本？
采用热（7天内）-温（7-30天）-冷（30天+）三级存储策略。热数据用SSD+高规格ES节点，温数据用HDD+普通节点，冷数据转存到对象存储。查询响应时间可控制在热数据200ms内，温数据1-2秒，冷数据5-10秒，存储成本能降低60%-70%。
日志采集导致主机CPU过高怎么办？
首先调整Filebeat的max_procs参数（不超过CPU核数的70%），然后降低harvester_buffer_size（16KB-32KB），最后考虑限制采集频率（如非关键日志改为5-10秒批量采集）。如果仍无法解决，需要评估是否业务日志量确实需要扩容主机。
如何快速定位分布式系统的请求链路日志？
必须确保全链路透传trace_id，在Nginx、应用代码、RPC调用等环节都要传递这个标识。 采用OpenTelemetry等标准协议，配合Kibana的trace_id预置查询，能实现跨5-8台服务器的日志一键聚合展示。
