一个被低估的瓶颈
日志太多挤占带宽是一件容易被忽略的事，当业务高峰期来临时，采集器疯狂发送日志，可能导致正常业务请求变慢,应对方式有三个具体动作。
压缩与批处理：给传输瘦身
在Filebeat配置里开启压缩,并设置批量发送参数。
output.elasticsearch: hosts: ["http://your-server:9200"] compression_level: 5 bulk_max_size: 2000 flush_bytes: "2MB"
把压缩级别定为5，既不会消耗太多CPU，又通常能让传输数据量减少百分之七八十，批量发送能降低网络请求次数,避免每一条日志都建立一个TCP连接。
采样策略：不是所有日志都值得全量保留
很多日志的数据结构相同，比如健康检查、用户轮询，这些日志可以按比例采样，只保留百分之十或更少，注意，采样不能用于安全审计,只适用于监控和性能分析。
四类日志必须全量保留：登录事件、权限变更、支付操作、非法请求，其余日志如访问日志、运行状态,采样足矣。
服务器日志管理的日常操作清单
汇总成一套可执行的日常步骤，照着做就行。
- 在每台服务器的采集器配置中，先做一次本地过滤,只发送Warn级别以上的日志。
- 给日志发送目标配置一个本地缓冲目录，目标挂掉时有临时落盘,避免丢数据。
- 建立索引命名规则，如
log-YYYY-MM-DD，按天滚动,方便删除旧索引。 - 每天凌晨定时执行日志轮转，按大小或时间切割文件,防止单文件无限增长。
- 每周做一次压缩测试,确认压缩后冷数据的体积和恢复时间。
- 监控收集端的CPU、内存和网络占用,确保日志采集不挤占业务资源。
关于服务器日志分析的常见问题
服务器日志分析工具哪个好用？
如果你的服务器少于十台，优先考虑Vector + Loki的组合，轻量且支持反代，如果你需要报表和告警，自建ELK或使用云日志服务更合适，关键在于你愿不愿意投入精力维护，托管服务适合“不想折腾”的团队。
日志文件多大才需要集中管理？
没有绝对标准，当你在单台服务器上执行grep发现要等十几秒，或者需要用多台服务器的日志联合排查问题时，就该集中了，单台日志超过5GB/天，或服务器超过五台,集中管理带来的效率提升就很明显。
怎么降低日志存储成本而不丢失有用信息？
通过分级存储和过滤规则，将所有日志先写到本地，只把Warn级别以上的日志实时传输到分析端，对于访问日志，可以把静态资源请求过滤掉，只保留动态接口请求，对于需要长期保存的合规日志，使用日志归档工具（如Zip）压缩后上传到对象存储，平时不占热存储空间,需要时再解压。