日志系统这件事看起来简单做起来坑不少。我刚接手的几个业务线每天都在产生海量访问日志和业务日志之前分散在各个服务器上排查问题全靠一台台登录去看十几台机器翻下来一个上午就没了。后来下决心搞一套集中式日志平台把 ELK Stack、EFK、Graylog 这三条主流技术路线都从部署到实战走了一遍这里把完整的选型思路、部署细节、调优参数和踩坑记录整理出来给正在做同样事情的朋友一个参考。这套方案最核心的价值就是两件事第一所有日志集中存到一个地方按时间、按关键词秒级检索再也不用登录服务器翻文件第二通过 Kibana 或者 Graylog 的图表能力把日志数据变成可视化的趋势图、错误分布图故障响应速度能快一个量级。适合谁用如果你是运维工程师、后端开发、或者小团队里什么都管的同学这篇文章里的内容可以直接抄作业。1. 选型先想清楚三个问题再谈技术栈很多人在日志平台选型上第一反应就是“我要上 ELK”但实际落地之前必须先回答三个问题日志量到底多大、查询的实时性要求多高、团队手里有多少维护精力。这三个问题的答案直接决定了你该选 ELK、EFK 还是 Graylog。1.1 三种架构的本质区别ELK 是经典三件套Elasticsearch 负责存储和检索Logstash 负责采集和加工Kibana 负责可视化。它的特点是组件独立、可替换性强但 Logstash 作为一个重量级的 Java 进程吃掉的内存相当可观而且 pipeline 处理链路的调优参数多新手容易在配置上栽跟头。EFK 是把 Logstash 换成了 Filebeat。Filebeat 是一个用 Go 写的轻量级采集器二进制文件只有几十兆部署方式就是拷贝过去起个进程资源占用和 Logstash 完全不是一个量级。在“只是收集日志不做什么复杂处理”的场景下EFK 比 ELK 香得多。Graylog 是另一条路线。它把 Elasticsearch 当纯存储引擎来用自己在前面套了一层消息队列和 Processing Pipeline元数据放在 MongoDB 里。它内置了告警、权限、LDAP 集成、数据流控这些 ELK 需要组合插件才能实现的功能开箱即用程度最高。1.2 用一张表看懂适用场景对比维度ELKEFKGraylog采集端资源占用高JVM极低Go 单二进制中自带采集端或对接 Filebeat数据处理能力强支持丰富 filter弱仅轻量处理中支持 Pipeline 脚本告警与权限靠 X-Pack 或免费插件同 ELK内置完善部署复杂度高中中典型场景复杂清洗、多数据源处理海量日志轻量收集中小团队、需要快速见效我实际测试过一组数据同样接入 5 台业务服务器的 Nginx 日志Logstash 默认配置下常驻内存约 800MB 到 1.2GB而 Filebeat 只需要 60MB 左右。如果你的服务器本来就紧张这一项就能让你做出选择。1.3 我的选择结论我最后的落地方案是双轨制主力采集用 Filebeat服务端统一收进 Elasticsearch但对于个别需要做复杂字段解析的数据源比如后端服务打出的多行异常堆栈、混合格式的业务日志单独保留一条 Logstash 处理链路。搜索和可视化统一走 Kibana。这个组合兼顾了资源和灵活性也是目前社区里比较成熟的做法。2. Elasticsearch 集群部署与调优日志平台的地基不管选哪条路线Elasticsearch 都是绕不开的底座。这个环节做不好后面所有查询都会变慢甚至集群直接崩溃。日志场景下 ES 的部署和常规业务搜索场景有非常大的区别很多参数必须按日志场景重新调整。2.1 节点角色拆分别一锅烩ES 老版本是可以一个节点什么都干的但日志场景千万别这么搞。日志场景的显著特点是写入压力大、查询相对简单而且数据量随时间线性增长。你必须把节点拆成三类角色Master 节点负责集群元数据管理配置node.master: true、node.data: false、node.ingest: false。至少 3 个节点做高可用。Data 节点负责数据的存储和查询是集群的绝大多数机器。Kibana 和协调节点可以复用 Master 节点也可以单独拆。我一开始图省事把 3 台机器都设置成了 master 和 data 双角色结果集群跑了两周一次索引重建的时候 master 进程因为 IO 阻塞发生选举超时整个集群写了半个多小时不可用。拆开之后这种问题再没出现。2.2 内存和磁盘的硬指标堆内存设置是最容易出错的地方。ES 官方推荐 Xms 和 Xmx 保持一致设为系统内存的一半且最高不要超过 30GB。为什么是 30GB因为 JVM 的压缩指针技术在 30GB 以内有效超过这个值对象指针占用会翻倍GC 性能会明显下降。比如服务器是 64GB 内存给 ES 分配 31GB文件系统缓存还有 33GB这个配置是健康的。千万别给到 40GB、50GB不仅浪费内存GC 停顿还会让你怀疑人生。磁盘方面日志平台优先用 SSD不仅是查询快更关键的是写入合并时的随机 IO 性能。如果预算有限至少把热数据放在 SSD 上冷数据可以通过后面讲到的 ILM 生命周期策略滚动到机械盘。2.3 索引生命周期管理日志场景必配日志数据有一个天然特性时效性越久访问频率越低。如果不用 ILMIndex Lifecycle Management你会在几个月后面对几百个索引挤爆磁盘的窘境。我的实践方案是三个生命周期Hot 阶段当前写入的索引保留最近 3 天。Warm 阶段3 到 30 天的数据可以做只读并合并分片降低存储开销。Cold/Delete 阶段30 天以上的数据迁移到冷节点90 天以上的删除。配合 ILM 策略的滚动索引机制每天自动生成一个形如app-log-2024.06.30的索引。这样做还有个额外好处删除过期数据只需要删索引文件不需要走复杂的 delete-by-query对集群负载的影响极小。2.4 分片数和副本数的黄金法则这是日志场景最容易踩的坑。很多人建索引时喜欢按照默认配置建多个分片觉得分片越多并发性能越好。但分片数太多会导致主分片和副本分片的碎片化反而拖垮查询速度。对于日志数据我建议每天一个索引每个索引 3 到 5 个主分片副本 1 份。公式可以这样估算单分片容量控制在 30GB 以内 分片数 预计每天日志量 / 30GB向上取整例如一天产生 100GB 日志除以 30GB 约等于 3.3那就建 4 个分片。如果拿不准宁少勿多分片可以在后期通过 Split API 扩展但 shrink 却很麻烦。2.5 写入性能的关键配置日志场景写入压力大如果发现高峰期写入性能不足按顺序检查这几个配置# 副本数可以在高峰期临时设置为 0写入完成后改回 1 index.number_of_replicas: 0 # 刷新间隔默认 1s可调大到 30s减少段合并的频率 index.refresh_interval: 30s # 合并策略调整减少同时合并的段数 index.merge.scheduler.max_thread_count: 2这些配置在写入高峰期临时调整是常用做法等到搜索行为多的时候再调回来。我从 1 秒刷新改成 30 秒刷新后集群写入吞吐提升了约 20%查询延迟几乎没有感知因为日志场景里对秒级可见的需求本来就不强烈。3. 数据采集链路Logstash 和 Filebeat 的角色分工采集端是整个链路里最容易被人忽略、却最影响稳定性的环节。日志采集进程挂掉往往不是因为它自己出问题而是被拿着各种错误配置去连接不存在的服务或者被无休止的管道阻塞拖垮。想清楚它们的分工整个链路的稳定性立刻上一个台阶。3.1 Logstash 适合做什么、不适合做什么Logstash 的本质是一个数据处理管道核心价值在 Filter 阶段。它能做正则解析、Grok 格式化、GeoIP 地址解析、日期格式化、字段裁剪、甚至是调用外部 API 做富化。举个例子一条原始 Nginx 日志如果直接存进 ES你只能全文搜索。但经过 Logstash 的 Grok 解析后可以变成结构化 JSON 字段后续按状态码、响应时间、客户端 IP 做聚合查询效率天差地别。但 Logstash 不适合做大规模轻量采集。它的 JVM 常驻内存开销、启动速度和配置复杂度决定了它应该集中在服务端使用。看到有人拿二三十台 Logstash 去采集日志我的第一反应是这是给自己没事找事。3.2 Filebeat 的部署和配置细节Filebeat 的优势是便宜、干净、稳定。部署相当简单# 下载解压后编辑 filebeat.yml filebeat.inputs: - type: log enabled: true paths: - /var/log/nginx/*.log fields: log_type: nginx service: web-01 filebeat.modules: - module: nginx access: enabled: true output.elasticsearch: hosts: [es-node-01:9200, es-node-02:9200] index: nginx-log-%{yyyy.MM.dd}注意几个细节都是实测经验。第一fields下自定义的字段建议嵌套在fields_under_root: false下避免覆盖 ES 默认字段第二如果后面要接 Logstash输出模块改成output.logstash但不要同时配置output.elasticsearchFilebeat 只能配置一个输出第三它的harvester是按文件大小偏移量收集的如果日志文件被 logrotate 切走需要保证不重复读取配置clean_removed: true和合理的close_inactive可以减少这类问题。3.3 一条 Logstash 多路复用管道我最终还是留了一条 Logstash 管道专做高复杂度数据的清洗。管道配置的核心思路是把input里的多个数据源和filter里的多套解析规则隔离用if条件分流而不要为了不同格式的数据建多套管道。input { beats { port 5044 } tcp { port 5010 } } filter { if [service] nginx { grok { match { message %{COMBINEDAPACHELOG} } } } else if [service] java-app { multiline { pattern ^\\s negate false what previous } } } output { elasticsearch { hosts [es-node-01:9200] index %{[service]}-log-%{yyyy.MM.dd} } }多路复用的好处是集中管理、减少进程数量坏处是管道里某个环节出问题会影响所有数据流。所以我会在 Logstash 的pipeline.workers上按 CPU 核数调整高峰期把pipeline.batch.size从 125 调大到 300让一条管道吃下更多数据。3.4 消息队列要不要引入很多人纠结是否在采集端和服务端之间插入 Kafka。我的观点是日志量每日小于 100GB 的团队完全不需要。直接 Filebeat 到 ES 的链路已经足够稳。引入 Kafka 意味着中间多了一个需要维护的分布式系统而且日志消费落后会导致查询不到新数据排查起来比查询变慢更头疼。只有当数据量达到日均几百 G 以上或有多套下游消费系统时Kafka 的缓冲和解耦价值才真正体现出来。到那个时候我建议架构升级为 Filebeat采集 - Kafka缓冲 - Logstash消费 - ES存储这也是大型生产环境最成熟的标准链路。4. Graylog 的架构思路比 ELK 更轻量的另一条路在搭建好 ELK 基础设施后我依然花了一周时间把 Graylog 完整部署了一轮。原因很简单有些团队对告警、权限、数据接入有强烈诉求但又不想在 ELK 生态里拼接组合插件Graylog 可能是更合适的选择。4.1 Graylog 的组件拆解Graylog 的架构由三个部分组成Graylog Server处理输入数据、执行 Pipeline、提供 WEB 接口和 API。MongoDB存储配置、用户、告警规则等元数据不存日志原文。Elasticsearch还是充当检索和存储引擎的底座。这套设计聪明的地方在于它把“实时处理”和“配置检索”分开MongoDB 跑挂了只是 Web 界面和配置不可用日志写入检索不受影响。对比 ELK 需要装的告警插件、index 管理插件等Graylog 把这些能力内置了。4.2 Graylog 的生产配置要点安装部分直接照官方文档配就行踩坑点集中在配置文件的几个参数上。/etc/graylog/server/server.conf里最重要的一个是password_secret必须是一个至少 64 字符的随机字符串否则服务起不来。另一个是root_password_sha2这是 Web 端管理员密码的 SHA256 哈希千万不要记成明文填进去。数据接入上Graylog 对 Filebeat 天然友好配置 Filebeat 输出为output.logstash形式只是让数据从 Graylog 的 Beats Input 进来。如果是纯 syslog 环境它内置的 Syslog UDP/TCP input 也可以直接收。4.3 Graylog 的 Pipeline 处理日志Graylog 的处理逻辑比 Logstash 的 filter 更接近“编程模型”数据进 Input 后先进入一个处理链由 Pipeline 规则决定做什么。规则语法长得像 Java 和 Groovy 的混合体。一个很典型的场景把 Nginx 日志里的响应时间字段转成数字类型方便后续做聚合统计。rule convert request_time to number when has_field(request_time) then let rt to_double(to_string($message.request_time)); set_field(request_time_number, rt); endGraylog Pipeline 的when条件判断、阶段性的rule、以及函数库里的to_double、to_string等转换函数组成了一个对普通运维也能上手的逻辑体系。对比 Logstash 的 Grok 语法Graylog 对非专业开发者的学习曲线明显平滑一些。4.4 什么时候选 Graylog用了几天后我的判断是如果团队只有两三个人日志量不大不小没有专门的前端开发资源去定制 Kibana 展现又需要告警和用户权限Graylog 就是性价比之选。但在深度搜索定制、可视化图表复杂度和大型集群优化上ELK 生态的技术积累更深厚。本质上Graylog 做的是“够用的开箱即用”ELK 是“广袤的 DIY 空间”。5. 实际部署与使用中最常见的问题排查清单这部分是重点中的重点按我经历的频率排序都是真金白银踩出来的坑。5.1 时间字段和日志时间不一致这是日志系统里出现频率最高、影响也最隐蔽的问题。默认情况下Elasticsearch 写入文档时会把timestamp设置为 ingest 时间。一旦存在数据积压或网络延迟文档实际落库时间会晚于日志产生时间按时间筛选查询时会发现数据“迟到”了。处理方法是在 Logstash 或 Filebeat 中用日志自带时间覆盖timestamp字段。# Logstash filter 中的处理 date { match [log_time, yyyy-MM-dd HH:mm:ss,SSS] target timestamp }对于 Filebeat配置json.keys_under_root: true后在字段映射时把时间对应关系配好。改完后必须验证查一条刚写入的日志timestamp是否等于日志自身时间且带对时区这个坑最坑的是它平时不出问题一到跨时区大促活动就全乱了。5.2 索引丢失或者字段类型冲突日志平台的字段类型一旦写入几乎不能更改。这是 index mapping 的硬约束。举个例子某个字段之前被自动映射为long后来另一条日志往同一字段写入了一个字符串bulk 请求就会直接报错要么丢弃这批次数据要么整条索引写入状态变为 yellow。解决办法分两层事前定义好索引模板。对日志场景尽量在索引模板里把动态映射关掉或者对高确定性字段显式声明类型。{ template: *-log-*, settings: { number_of_shards: 3 }, mappings: { properties: { status_code: {type: integer}, request_time: {type: float} } } }但这类问题真正完美的解决方案是“事前规范”每个接入的日志源先定义语义规范和字段命名规范避免临时加字段导致的整体重构。我在实际项目中就遇到过一次开发临时在日志里加了一个名为id的字段结果把现有索引的全字段映射打乱了花了半天时间重建索引。5.3 堆内存使用过高和 Full GCES 堆内存飙升常见于两类场景一类是查询语句里用了过大的聚合桶terms聚合size设了极大值另一类是大量分片在同一个节点上导致内存占用堆积。遇到堆内存快速上涨时先看热点线程# 查询热点线程和堆使用情况 curl -s http://localhost:9200/_nodes/hot_threads curl -s http://localhost:9200/_cluster/health如果发现某个节点堆占用 85% 以上立即排查两点该节点分配的分片数是否过多最近是否有大聚合查询散落在该节点上。解决方案可以是对该节点设置分片分配过滤也可以限制聚合精度。但不要第一时间就想加内存堆内存超出 31GB 上限后加内存几乎没有正收益。5.4 字段类型和磁盘 IO 的取舍日志场景里常见的_source字段是罪魁祸首。默认 ES 会把完整的原始日志存在_source里好处是查询后能看到完整原始信息坏处是它会造成大量的磁盘占用。一个实际的分配方案如果只是需要结构化字段做聚合检索可以把_source关闭或做裁剪。但没有_source就无法从查询结果里看到原始日志全文所以我的经验是存储成本可接受就保留。如果磁盘紧张优先对_source做includes过滤排除超大字段而非整体关闭。{ mappings: { _source: { includes: [message, service, timestamp, status_code] } } }这样既控制了体积又保留了排错需要的关键字段。5.5 高峰期日志写入出现背压的排查路径集群出现写入日志告警后不要第一时间怀疑采集端。按这个路径排查效率最高先看 ES 集群健康状态确认有没有 red 索引或未分配分片。再查 CPU 和线程池队列thread_pool.write队列爆掉时说明写入能力已到瓶颈。排查是不是大量长时间运行的聚合查询抢占资源。最后看磁盘水位超过 85% 就会触发自动分配保护。背压出现往往不是单独某个环节的问题。我之前遇到过一次极端情况业务高峰流量比平时高了 3 倍ES 的写入吞吐没变但查询延迟暴增导致应用超时重试重试又带来更多查询形成恶性循环。这时正确的动作是减少查询并发、临时降低副本数、调大写入队列缓冲然后让链路稳定下来再去根治根因。5.6 日志平台的容量规划经验容量规划的核心指标是存储压缩比。日志可压缩性极强Nginx 访问日志在 ES 的_source下一般能压缩到原始文本大小的 30% 到 40%。我做过一次测算每天产生 100GB 原始日志经过解析和压缩后落盘存储大约占 30GB 到 45GB再加上副本和分片余量每天实际占用 60GB 到 90GB。所以规划一个月的数据量时不要用原始文本量去算而是用落盘量加至少 30% 的余量。磁盘使用率超过 70% 就该考虑扩容或清理旧索引不然高峰期的段合并和新索引写入会把你逼到死角。6. 部署方案落实到生产环境这篇内容拉得比较长但日志平台本身就是一个环环相扣的系统工程。最终我自己的线上环境采用了混合方案Filebeat 作为默认采集器覆盖绝大多数服务器Logstash 仅保留在少数数据源需要复杂结构化解析的链路上Elasticsearch 作为统一存储和检索底座Kibana 负责查询可视化再写了一套脚本定期做索引清理和健康巡检。Graylog 作为备选方案的技术储备后续如果个别项目有独立的告警和权限需求可以直接快速启用。再提醒一句日志平台的价值体现在“用”上而不是“建”上。建好之后一定要和团队约定日志规范什么字段打什么类型、哪些字段要脱敏、哪些日志要保留多久。没有规范再强的平台也会在混乱的数据面前失去意义。这套规范定清楚后期百分之八十的问题都会绕着你走。