前几天同事丢给我一个线上问题用户反馈报表数据不准。我登到机器上第一反应就是翻日志结果 grep 了大半天才把一条请求链路拼出来——日志散落在好几个目录格式还不统一看一次得来回开三个终端。那一刻我意识到日志链路这件事不能再拖了所以就有了这套 Filebeat → Logstash → Elasticsearch → Kibana 的部署版本基于 Elasticsearch 5.2。这篇东西不是官方文档的搬运而是一次完整落地记录。包含为什么要这么拆组件、每个环节怎么配、数据流动起来之后踩过的坑以及最后怎么在 Kibana 里把日志变成能查的报表。如果你正准备搭一套日志平台或者已经被日志散落问题折磨过这篇应该能帮你少走不少弯路。补充一句虽然这套组合是 5.2 时代的产物但链路设计和排查思路放到现在依然适用很多线上老集群至今还是这个架构。1. 日志链路整体设计与组件选型思路1.1 这套链路到底解决什么问题先把痛点说清楚。没有集中式日志平台的时候我们排查问题基本靠 SSH 登录服务器然后 find、grep、tail 三连。单机还好一旦服务是多节点部署你根本不知道请求落到哪台机器上只能一台一台翻。更麻烦的是不同团队写的日志格式还不一样有的带时间戳有的纯文本有的跨行输出grep 出来的结果根本没法做关联分析。引 Filebeat 到 Kibana 这条链路核心解决三件事。第一是采集集中化所有机器的日志通过 Filebeat 统一收集送到一个地方存储不再需要逐台登录。第二是检索实时化日志进入 Elasticsearch 后可以按关键词、时间范围、字段值做秒级查询比 grep 全文件快太多了。第三是分析可视化Kibana 把结构化之后的日志变成柱状图、折线图、饼图配合过滤条件一眼就能看出错误趋势和接口成功率。这套链路适合谁适合那些已经有多个业务节点、日志量每天几个 GB 到几十 GB、需要快速定位线上问题或者做基础监控看板的团队。哪怕你只是想在个人电脑上搭一套环境学习 Elasticsearch这个链路也值得完整跑一遍因为理解了全链路之后你才能真正知道日志数据是怎么从一行文本变成可查询的文档的。1.2 为什么采集端选了 Filebeat 而不是 Logstash很多人第一次搭 ELK 会犯一个错误在每台机器上装一个 Logstash 来采集日志。Logstash 确实支持 file 输入也能采集但它是个 JVM 进程默认堆内存就吃掉 1GB加上各种 filter 插件单机内存占用非常夸张。你想想如果 20 台业务机器每台都跑一个 Logstash光采集端就吃掉 20GB 内存这个成本大多数团队扛不住。Filebeat 是 Go 写的轻量级采集器安装包几十 MB运行内存通常只有几十 MB对业务主机的影响可以忽略不计。它用 yaml 配置启动即采集不需要装 JVM部署成本低。最关键的它在 5.x 就已经支持了 registry 机制会把已经读取的文件偏移量记录到本地文件里采集进程重启后继续从上次的位置读不会重复发送也不会丢数据。这一点对于日志采集场景来说非常重要后面我会专门讲 registry 踩坑。所以一经验证的原则是采集端用轻量级 Filebeat处理端用重量级 Logstash各司其职。Filebeat 只负责把文件内容读出来往上游推不承担解析责任保证对业务机器零负担。如果文件在读取过程中被轮转、改名Filebeat 也能通过文件标识继续追踪这些都比你用 Logstash 硬扛要省心。1.3 为什么中间还要保留 Logstash 这一跳有人会问Filebeat 不是可以直接把数据发到 Elasticsearch 吗为什么中间非要再插一个 Logstash这里其实是两条路线的取舍。直接 Filebeat 到 ES 的优点是链路短、组件少、故障点少适合日志格式已经非常规整、而且你只是为了做全文检索的场景。但真实环境里的日志几乎都是“脏”的Nginx 日志至少有十几种字段要拆Java 异常堆栈是多行文本业务自定义日志更是什么怪格式都有。如果让原始文本直接进 ES你得到的只是一个能 grep 的大文本文件Kibana 里没法按 URL 分组、没法按响应码统计、也没法绘制接口延迟趋势图。Logstash 的存在就是为了在数据进 ES 之前完成解析、清洗、结构化。它用 grok 正则模板把一行文本拆成 method、path、status、response_time 等字段用 date 过滤器把字符串时间解析成 ES 的标准时间格式用 mutate 删掉不需要的原始字段减少存储压力。同时 Logstash 还能对接多种数据源Kafka、Redis、JDBC 都可以作为输入后面你想接入数据库变更日志或者消息队列数据扩展成本很低。另外一个很容易被忽略的好处是解耦。当 ES 集群短暂不可用时Logstash 会把数据积压在自己的内存或持久队列里等 ES 恢复后再继续写入。如果你直接 Filebeat 到 ESES 一抖动Filebeat 的回退机制会让数据堆积在采集端恢复之后的瞬间可能造成流量尖峰。加一层 Logstash 等于给链路加了一个缓冲区和安全阀。1.4 版本匹配与兼容性约束这套链路里所有组件版本必须严格对应这一点在 5.2 时代特别敏感。Elastic 全家桶的版本策略是主版本号必须一致比如你装了 Elasticsearch 5.2那么 Filebeat、Logstash、Kibana 必须选 5.2.x 系列混用不同大版本会出现协议不兼容最常见的就是 Filebeat 5.x 发数据给 Logstash 6.x 时报错或者 Kibana 连不上 ES。组件版本默认端口核心作用Filebeat5.2.x无主动连接采集日志文件推送至 LogstashLogstash5.2.x5044beats 输入解析清洗日志输出至 ESElasticsearch5.2.x9200HTTP/ 9300节点通信存储与检索日志数据Kibana5.2.x5601可视化查询与看板JDK1.8 及以上-ES 与 Logstash 运行依赖版本匹配的重要性我是在生产环境栽过跟头的。有一台测试机的 Logstash 手滑装了 6.xFilebeat 还是 5.2结果 beats 输入插件在握手阶段一直报错排查了一下午才发现是版本问题。后来我养成了习惯部署前先列一个版本清单所有组件的下载地址和校验和提前核对好再动手安装。新人如果刚开始学这套链路现在不一定要用 5.2可以直接装 7.x 或 8.x 的新版本但要注意配置格式有变化。比如 Filebeat 5.x 的配置是filebeat.prospectors6.x 以后改成了filebeat.inputsKibana 5.x 连 ES 用的是elasticsearch.url7.x 改成elasticsearch.hosts。本篇我按标题的 5.2 版本来写如果你用的是新版本对照调整即可。2. 核心组件安装与配置要点2.1 Elasticsearch 5.2安装、启动与关键配置Elasticsearch 安装本身不复杂tar 包解压就能用但关键的坑都在配置和启动参数上。解压之后先别急着启动先改config/elasticsearch.yml里的三样东西cluster.name、node.name、path.data和path.logs。cluster.name决定了集群身份多节点加入同一个集群必须同名path.data指定数据目录一定要放到有足够磁盘空间的分区不然日志一涨就把系统盘写满。默认的数据目录在安装目录下升级或误删会导致数据丢失所以生产环境一定要指定独立目录。再往下是网络配置。单机学习环境通常用network.host: 127.0.0.1只允许本机访问如果你要让 Logstash 或 Kibana 跨机器连接就得改成network.host: 0.0.0.0同时注意防火墙放行 9200 端口。5.2 版本还保留了discovery.zen.ping.unicast.hosts配置单节点就填[127.0.0.1]避免启动时走多播发现浪费时间。ES 5.x 的 JVM 堆内存默认是 2GB如果你机器只有 4GB 内存建议在config/jvm.options里把-Xms和-Xmx调成一致比如-Xms2g -Xmx2g两个值必须相等这样 JVM 不会在运行中动态扩容性能更稳定。Windows 上启动 ES 5.2 有几个特有坑。第一不要用管理员权限双击elasticsearch.bat因为 ES 检测到管理员权限会拒绝启动这是它的安全机制我用管理员身份跑过一次直接报can not run elasticsearch as root的同类错误。第二确保系统装了 JDK 1.8 并配置好JAVA_HOME环境变量ES 5.x 自带了一套检查逻辑找不到 JDK 会立刻闪退。第三如果双击 bat 窗口一闪而过多半是配置文件写错了用命令行elasticsearch.bat跑一下才能看到具体报错信息。启动完成后验证方式很简单浏览器访问http://localhost:9200返回一段包含cluster_name和version的 JSON 就说明 ES 起来了。如果你想查看当前安装过哪些分词器插件用命令elasticsearch-plugin list比如装了 IK 分词器之后这个命令会输出analysis-ik。想测试分词效果可以调用_analyze接口curl -X POST http://localhost:9200/_analyze -H Content-Type: application/json -d { analyzer: ik_max_word, text: 中华人民共和国 }2.2 Kibana 安装与连接验证Kibana 安装非常简单下载 tar 包解压改config/kibana.yml里的三个配置server.port默认 5601保持即可server.host如果想允许外部访问改成0.0.0.0关键的是elasticsearch.url5.2 版本里这个配置连接 ES 的 HTTP 地址填http://localhost:9200。注意 5.x 版本不能写成elasticsearch.hosts那个字段在 7.x 才生效如果你按新教程配老版本Kibana 会直接报配置不存在。启动 Kibana 用bin/kibana它会先检查 ES 连通性连不上会在日志里刷红色 WARN。等一两分钟让服务完全起来浏览器访问http://localhost:5601首次进入会让你创建一个索引模式Index Pattern。这一步卡住过不少人明明 ES 里已经有数据了但索引模式输入框里填logstash-*却提示 No matching indices。原因往往是索引还没创建成功或者匹配规则写错。Kibana 的索引模式需要先匹配到 ES 中至少一个实际存在的索引它内部会调_cat/indices接口去拉索引列表如果没有任何索引符合规则就什么都不显示。验证 Kibana 和 ES 连通性还有个快捷方法在浏览器里直接访问http://localhost:5601/api/status能看到 Kibana 的状态以及它连接 ES 的健康状态比看日志直观得多。这个页面在排查“Kibana 起来了但页面一直转圈”这类问题时特别有用。2.3 Filebeat 采集配置与断点续传机制Filebeat 5.2 的核心配置在filebeat.yml当时用的还是prospectors写法结构如下filebeat: prospectors: - type: log paths: - /var/log/nginx/access.log fields: log_type: nginx-access fields_under_root: true output: logstash: hosts: [192.168.1.100:5044]这里两个细节值得展开。第一fields和fields_under_root: true的含义是给每条日志打一个自定义标签log_typenginx-access并且把这个字段提升到 JSON 顶层。后续在 Logstash 里可以根据这个字段区分日志来源在 Kibana 里也可以按它筛选。如果不加fields_under_root字段会嵌套在fields.log_type里查询时要写完整路径烦得很。第二paths支持通配符比如/var/log/nginx/*.log会采集目录下所有 log 文件但要注意如果同时匹配到压缩归档文件Filebeat 也能读但会把压缩包当成二进制文件处理产生乱码数据所以归档文件最好单独放目录。启动 Filebeat 用./filebeat -e -c filebeat.yml-e让日志输出到终端方便调试。启动后它会在data/registry文件里记录每个被采集文件的唯一标识和当前读取的偏移量。这个机制保证了三点文件被轮转后能继续追踪新文件Filebeat 重启后不会重复发送旧数据如果输出端暂时不可用数据在本地积压恢复后继续推。我踩过的一个低级坑是删除了某个旧日志文件后Filebeat 一直在 registry 里保留对这个文件的记录导致每次启动都会尝试去读一个不存在的文件日志里疯狂刷Harvester could not be started。解决方法是删掉 registry 文件让 Filebeat 重新扫描目录但这样也会导致现有文件重新发送一遍所以更好的方式是尽量别把日志文件直接删掉改成归档轮转让 Filebeat 自然过渡到新文件。2.4 Logstash 管道配置与自定义插件Logstash 5.2 的核心是管道配置一个完整配置分 input、filter、output 三段。最简配置长这样input { beats { port 5044 } } filter { grok { match { message %{COMBINEDAPACHELOG} } } date { match [timestamp, dd/MMM/yyyy:HH:mm:ss Z] target timestamp } mutate { remove_field [message] } } output { elasticsearch { hosts [http://192.168.1.100:9200] index nginx-access-%{YYYY.MM.dd} } }filter 是整个配置里最需要花心思的部分。grok 用的是正则模板匹配%{COMBINEDAPACHELOG}是 Logstash 内置的一个复合模式可以拆解标准 Apache/Nginx 访问日志生成clientip、method、request、httpversion、response、bytes等字段。如果你的日志不是标准格式就得自己写正则比如%{IP:clientip} \[%{HTTPDATE:timestamp}\] %{WORD:method} %{URIPATHPARAM:request} %{INT:status}。写正则时建议先用grokdebugger调试别直接在管道里试错那个调试工具在 Kibana 的 Dev Tools 里也有实时反馈匹配结果效率高很多。date 过滤器解决的是日志时间和系统时间不对齐的问题。Nginx 日志里的时间是字符串17/May/2024:10:30:00 0800而 ES 默认要求timestamp字段是 ISO8601 格式。date 过滤器就是做这个转换的同时把时区偏差也纠正掉。我后面会专门讲 8 小时时区问题坑就出在这里。关于集成自定义插件Logstash 5.2 提供了一个完整的插件机制。如果你要写自己的 filter 插件用 Ruby gem 方式开发一个logstash-filter-xxx模块然后执行bin/logstash-plugin install /path/to/xxx.gem安装。插件逻辑一般写在filter/{插件名}.rb里核心重写filter(event)方法通过event.get(field)和event.set(field, value)操作字段。如果只是做简单字段加工不建议直接写插件用 mutate 和 ruby 过滤器组合就够了插件维护成本高升级 Logstash 还要重新适配。Logstash 启动前一定要用bin/logstash -f logstash.conf --config.test_and_exit先做语法校验配置有低级错误会在启动前暴露出来而不是等你拉起服务之后才发现管道没起来。启动以后加-r参数可以自动重载配置改完配置不用重启进程这在调试阶段特别节约时间。3. 端到端链路实战从 Nginx 日志到 Kibana 可视化3.1 一条完整链路的配置串联我拿 Nginx 访问日志当样例把四个组件串起来跑一遍按顺序操作就能复现。假设场景是有一台业务服务器/var/log/nginx/access.log在持续写入我们需要把这些访问日志采集、解析、存储并在 Kibana 里展示访问趋势和状态码分布。第一步Elasticsearch 先启动确认 9200 端口可访问。第二步Kibana 启动确认 5601 可访问。第三步Logstash 启动监听 5044 端口注意启动日志里出现Starting pipeline和Successfully started pipeline才算真的起来了如果只看到Logstash started说明管道还没加载完。第四步Filebeat 启动推送数据。四个组件的启动顺序有讲究建议按 ES → Kibana → Logstash → Filebeat 的顺序。因为 Filebeat 启动后立刻想连接 Logstash如果 Logstash 没起它会持续重试并积压少量数据而 Logstash 启动时如果 ES 不可用管道也能起来但输出到 ES 时会一直报连接错误。先启动后端组件前端的采集服务就能一次连上日志里也干净。完整 Filebeat 配置我在上一节已经给了Logstash 配置我给一个能直接跑的完整版input { beats { port 5044 } } filter { grok { match { message %{COMBINEDAPACHELOG} } remove_field [message] } date { match [timestamp, dd/MMM/yyyy:HH:mm:ss Z] target timestamp } geoip { source clientip } } output { elasticsearch { hosts [http://localhost:9200] index nginx-access-%{YYYY.MM.dd} } stdout { codec json } }output 里我同时加了 stdout这样启动 Logstash 时能在控制台直接看到解析后的 JSON 数据方便确认 grok 是否匹配成功。注意如果 grok 匹配失败Logstash 会给事件打上_grokparsefailure标签数据还是会进入 ES但 message 字段不会被移除你后来在 Kibana 里会看到很多无法解析的原始文本这时候就要去调整正则。3.2 三节点逐段验证数据流链路调通之前永远不要一次把四个组件全部启动完就以为完事了。我习惯的做法是每加一个环节就验证一次数据流这样出问题知道在哪一段。验证 Filebeat → Logstash 这一段看 Logstash 启动窗口。配置里如果加了stdout { codec json }Logstash 每收到一条数据就会在控制台打印一条 JSON能看到clientip、response、request这些字段说明 grok 解析成功。如果控制台没有任何输出首先查 Filebeat 的日志看是不是连接被拒绝再看 5044 端口有没有监听netstat -an | grep 5044最后确认 Filebeat 的 paths 路径是否正确文件有没有在写入新内容。这里踩过的一个坑是测试用的日志文件是历史文件Filebeat 默认从文件末尾开始读不会把文件里已有的老日志发出来所以测试时要么等新日志写入要么在 paths 里临时把文件的start_position改成beginning。验证 Logstash → ES 这一段用curl查看 ES 索引列表curl -s http://localhost:9200/_cat/indices?v正常情况下你应该能看到类似nginx-access-2024.05.17的索引并且docs.count在持续增长。如果索引列表里看不到任何索引说明 Logstash 写入失败去 Logstash 日志里搜Could not index event多半是 ES 地址写错、索引名里有非法字符或者 ES 磁盘空间满了导致只读。如果 Logstash 控制台已经打印了 JSON但 ES 里没有索引还有一个可能是你 ES 版本和 Logstash 大版本不一致bulk 请求的 header 格式不兼容。验证 ES → Kibana 这一段在 Kibana 的 Management → Index Patterns 里新建索引模式输入nginx-access-*点击创建。之后进入 Discover 页面左侧能看到按时间倒序排列的日志文档右侧可以搜索关键词。这一步如果发现索引模式匹配不到索引回到上一步确认 ES 里有索引如果索引模式能创建但 Discover 里没有数据多半是索引模式的时间字段没选对必须选择timestamp字段Kibana 默认按它排序选错会显示No results found。3.3 索引模板与批量写入参数调优日志场景有个特点索引数量随着天数不断增长。我们不希望 ES 用默认模板处理这些索引得提前定义好字段映射和分片副本策略否则可能出现字段类型错误或者分片数不合理的问题。自定义索引模板是应对这个问题的标准做法。创建模板的方式是用 PUT 请求curl -X PUT http://localhost:9200/_template/nginx_template -H Content-Type: application/json -d { template: nginx-access-*, settings: { number_of_shards: 3, number_of_replicas: 1 }, mappings: { doc: { properties: { timestamp: { type: date }, clientip: { type: ip }, request: { type: text, fields: { keyword: { type: keyword } } }, status: { type: integer }, response_time: { type: float } } } } }模板的作用是自动匹配未来所有以nginx-access-开头的索引索引创建时自动套用这里定义的分片数和字段映射。注意 5.x 的文档类型默认是doc到了 7.x 已经不能自定义 type只能叫_doc。如果你在 5.2 里用多重类型后续升级会非常痛苦所以现在新建索引我建议直接只用单类型。Logstash 写入 ES 的批量参数直接决定吞吐量。5.x 里有两个地方需要关注一个是pipeline.batch.size和pipeline.batch.delay控制 Logstash 从输入到过滤的批量事件数和等待时间默认分别是 125 和 50ms另一个是 elasticsearch output 插件里的flush_size默认 500即攒够 500 个事件才真正向 ES 发一次 bulk 请求还有idle_flush_time默认 1 秒即使不够 500 个事件也会定期刷一次。底层逻辑是 Logstash 最终调用 ES 的_bulk接口把多条文档打包在一次 HTTP 请求里发送。_bulk的格式是每两行一组第一行是 action 元数据如{ index: { _index: xxx, _type: doc } }第二行是文档 JSON整个请求体是一串按行拼接的文本。手动测试批量写入可以直接 curl 一个最小请求curl -X POST http://localhost:9200/_bulk -H Content-Type: application/json --data-binary bulk_data.json调优经验是不要盲目把flush_size调得很大如果单条日志体积很大一次 bulk 请求可能超过 ES 设置的http.max_content_length默认 100MB反而报错。我一般把flush_size设为 500 到 1000 之间配合pipeline.batch.size128已经能满足几 GB 日均日志的写入需求。3.4 时间字段处理与 Kibana 图表搭建日志链路里时间戳的正确性直接影响排障。Filebeat 收到日志后会给事件加上一个timestamp但这个时间是 Filebeat 采集时的系统时间不是日志本身记录的时间。如果日志写入时间和采集时间差了几分钟甚至几小时你按timestamp查询就会看到数据延迟。正确做法是始终在 Logstash 里用 date 过滤器把日志里的业务时间解析出来覆盖掉timestamp。我当时的配置是date { match [timestamp, dd/MMM/yyyy:HH:mm:ss Z] target timestamp }这个timestamp字段是 grok 从 Nginx 日志里提取出来的字符串日期格式形如17/May/2024:10:30:00 0800所以 match 模式写成dd/MMM/yyyy:HH:mm:ss Z。这里最容易踩的坑是时区偏移。ES 存储时间默认是 UTC而 Kibana 展示时会根据浏览器或配置的时区转换。如果你在 date 解析时没带时区信息Logstash 会默认按 UTC 解析存储的timestamp会比本地时间少 8 小时Kibana 里看到的曲线整体偏移排查问题的时候会怀疑人生。解决方式有两种。一种是在 match 模式里带上Z匹配时区偏移Logstash 解析时会把字符串里的0800转成 UTC 存储。另一种是给 date 过滤器加timezone Asia/Shanghai告诉 Logstash 当字符串没有带时区时按这个时区解释。我两种都试过最省心的是在 Nginx 日志格式层面就把时区打出来然后 date 解析时用Z匹配这样无论服务器在哪个时区数据始终准确。Kibana 可视化就相对简单了。进入 Visualize 页面新建一个 Vertical Bar 图表选择你创建的索引模式Metrics 选 CountBuckets 选 X-AxisAggregation 选 Date Histogram字段选timestampInterval 按数据量选 1m 或 1h。再叠加上一个 Split Series按status.keyword分组就能看到每个 HTTP 状态码随时间变化的分布。如果日志里加了response_time字段还可以建一个 Metric 选 Average 的折线图看接口平均耗时的趋势。这些图表保存后再放到 Dashboard 上就是一套最基础的日志监控看板。4. 常见问题排查与避坑实录4.1 排查清单与链路故障速查表我整理了一份 ELK 链路最常见的故障速查表基本覆盖了从零搭建到日常运行会遇到的绝大部分问题建议收藏起来对照排查。现象排查方向根因与解法ES 启动闪退查看启动日志多半是 JDK 版本不对或配置文件语法错误用命令行方式启动才能看到报错ES 启动报 max virtual memory areas 错误检查系统内核参数Linux 执行sysctl -w vm.max_map_count262144Filebeat 启动后无数据查看 Filebeat 日志和 registry先确认 output 端通不通再确认日志文件是否有新写入Filebeat 重复发送历史日志查看 registry 文件偏移量测试阶段可删除 registry生产环境不要乱删会导致重建索引Logstash 管道没起来检查配置语法用--config.test_and_exit校验配置Logstash 有日志但 ES 无索引查看 Logstash 输出日志ES 地址写错、索引名非法、版本不兼容Kibana 无法连接 ES查看 Kibana 日志确认 Kibana 配置里 url 字段是否正确ES 是否可达Kibana 看不到索引检查 Index Pattern索引还没创建或匹配规则错误用_cat/indices确认Kibana 时间偏移 8 小时查 Logstash date 过滤器时区解析问题match 模式加上 Z 或指定 timezoneLogstash 内存不足调整 jvm.options默认 1GB 不够用可调到 2GB但别超过物理内存一半ES 索引变成只读查看磁盘空间磁盘超 85% 会自动只读清理旧索引或加磁盘大量 _grokparsefailure查看 Logstash 日志grok 正则匹配不上用 Grok Debugger 调试4.2 实操中几个最让我印象深刻的坑第一个坑是 Windows 下启动 ES 5.2 一直闪退。我最初以为是 JDK 没配好反复检查了JAVA_HOME和PATH结果还是闪退。最后用命令行方式启动才发现配置文件里network.host写成0.0.0.0:92005.x 版本端口要单独用http.port配置不能写在network.host里。这个低级错误提醒我ES 的配置项分得很细每个参数都有明确的语法不要凭直觉和网上的旧资料随意组合。Windows 下还有一点如果端口被占用 ES 也会启动失败但日志窗口一闪而过看不到原因用命令行方式启动就全部暴露了。第二个坑是 Filebeat 重复采集日志。起因是测试时我用 Filebeat 读同一个日志文件改了几次配置重启结果 ES 里出现了大量重复文档。问题出在 registry 文件被手动删过一次Filebeat 重新扫描目录时从文件开头重新读。后来我意识到 registry 就像数据库里的 offset 记录删了它等于从头消费。生产环境里千万不要随便删 registry除非你明确知道这些日志可以重采。另外如果有多个 Filebeat 实例监听同一个文件目录一定要错开路径否则两个进程各自维护偏移量会产生大量重复数据。第三个坑是 Logstash 能正常接收数据但 ES 里始终没有索引。我排查了很久最后用curl调 ES 的_cat/indices发现根本没有索引创建而 Logstash 日志里也没有报错。后来发现在 pipeline 配置里 output 的 index 名称写成了nginx-access-%{YYYY.MM.DD}Logstash 解析的时候把大小写搞混了实际创建的索引名变成了nginx-access-2024.05.17之外的一个奇怪字符串。这种问题只能通过仔细检查 output 配置里的字符串拼接逻辑解决。4.3 链路监控与日常维护建议链路搭好只是开始日常维护才是长期的事。日志链路最怕的就是“静默挂掉”——Filebeat 采集到日志但 Logstash 处理出错了数据没有进 ES而你完全不知道自己正在“裸奔”。我从那次事故之后养成了几个习惯分享给你。第一每台采集机上都要看 Filebeat 的运行日志它的日志默认输出到 stderr生产环境建议用 systemd 或 supervisor 托管并配置日志轮转。一旦 Filebeat 长时间报连接错误立刻处理因为积压的数据会在网络恢复后变成尖峰写入可能把 ES 打挂。第二在 Kibana 里建一个“数据新鲜度”监控定时查看索引最新文档的timestamp和当前时间的差值超过阈值就告警。没有现成监控工具时可以用 cron 脚本调用_cat/indices定时检查索引数量增长情况。第三Logstash 的内存和持久队列监控非常重要Logstash 进程内存占满会导致 JVM GC 频繁处理能力下降数据积压越来越多形成恶性循环。另外建议把 ES 的日志索引按天创建之后配一个定时清理任务比如只保留 30 天的数据。5.2 版本还没有成熟的 ILM 索引生命周期管理我是用脚本每小时调一次 ES 的 delete 接口处理超过保留期的索引。后来新版本虽然自带 ILM 了但这个按天建索引再清理的思路到今天依然是日志场景的主流做法。4.4 关于中文分词与业务字段扩展如果你的日志里包含中文搜索关键词直接存储会按单个汉字切分检索效果很差。比如搜索“订单创建失败”默认分词器可能只会匹配到包含“订”或“单”的文档这时候就需要装 IK 分词器这类中文分词插件。5.2 版本安装插件用elasticsearch-plugin install analysis-ik装完重启 ES再在索引模板里把需要分词的字段指定为ik_max_word。我踩过的一个坑是装完 IK 分词器后没有重新索引旧数据发现之前已经到 ES 的日志依然按默认分词器存储。分词器在映射创建时就决定了后装插件不会影响已存在的索引。所以要么在接受数据前就规划好分词方案要么重建索引然后重新导入数据。如果是从旧版本升级这个点更要留意不然会出现新旧索引检索行为不一致的诡异问题。关于业务字段扩展我的建议是不要什么字段都往 ES 里塞。ES 索引字段过多会显著增加内存占用因为每个字段的倒排索引都要加载到内存。日志场景要优先保留核心字段时间、来源 IP、请求路径、状态码、响应耗时、错误堆栈。其他业务日志里出现的动态字段要么在 Logstash 里用 mutate 过滤掉要么用fielddata限制开启避免动态映射生成一大堆无意义的字段。这个经验是从一次 ES 集群频繁 Full GC 中总结出来的当时就是因为我们把整个消息体都塞进了_source还开启了全字段动态映射结果堆内存被撑爆了。最后再说两句这套 Filebeat → Logstash → Elasticsearch → Kibana 链路我前前后后搭过好几次每一次重搭都比上一次顺手。最核心的体会是不要试图一次把所有组件全配好再启动一定要从后往前先把 ES 和 Kibana 跑通再加 Logstash最后加 Filebeat每一段都用最小样例验证。这样出了问题最多只在一个环节里找原因不用大海捞针。还有一点想分享的是日志链路本身不是目的让日志能被快速检索和分析才是目的。所以花时间把 Logstash 的 grok 正则写好把索引模板规划清楚比盲目加组件和调参更有价值。每条日志从采集到展示经过了采集、解析、存储、可视化四个环节任何一个环节粗糙了最后在 Kibana 里看到的都是不可用的数据。先把基础链路的每一环都打磨干净后面再考虑加消息队列、加监控告警、加日志压缩归档这些扩展功能心里才有底。