最近业务日志量上来了接触ELK的朋友越来越多。我见过不少人折腾这套东西最有意思的是他们往往不是被Elasticsearch的查询语法难倒的而是卡在最开始——怎么把三个组件干干净净地跑起来。本机装个单机版ES倒是简单但要把Logstash和Kibana串起来还要考虑版本兼容、内存占用、数据持久化大多数新手一上来就是一团乱麻。我自己也在这条路上踩了不少坑今天就把一套完整的、基于Docker启动ELK的流程整理出来全部是可以直接照着操作的方案。我采用的组合是经典的Docker容器化方案用容器把Elasticsearch、Logstash、Kibana三件套分别跑起来再用一个自定义网络让它们互通。这套方式最大的好处是不用在宿主机上装一堆依赖Java版本冲突、系统库缺失这类问题统统绕开缺点是三个容器各自的状态需要费点心管理。如果你只是本地测试或者小规模日志收集这个方案非常合适如果以后要上生产集群可以在本文基础上把ES换成多节点编排但原理是相通的。下面我按照实际操作顺序把整个流程拆开讲清楚。1. 为什么推荐用Docker跑ELK容器化方案的优势与代价先说结论用Docker跑ELK核心收益是“环境隔离”和“快速重建”。ELK三个组件对运行环境的要求并不完全一致尤其是Elasticsearch它对JDK版本、系统参数都有讲究。如果直接在宿主机上装你会面临几个很实际的问题可能你机器上已经装了某个版本的JDK而ES要求的版本和你现有环境对不上Logstash的Ruby/Java环境也可能和系统里其他软件互相污染更难受的是一旦你哪天想升级版本或者换配置卸载清理的过程很容易留尾巴。Docker把这些事情全部打包进了镜像里。我在这台机器上下好镜像换个机器照样跑只要端口和数据卷挂载一致几分钟就能复现一套环境。对于需要反复初始化、验证配置的工程师来说这种可重复性简直太重要了。不过容器化也不是没有代价。最大的代价就是你得把“进程管理”的思维方式切换成“容器管理”。以前ES崩了你看一眼日志、重启一下系统服务就完事现在你要关注容器的运行状态、重启策略、数据卷有没有挂对还要考虑容器内的用户权限问题。你得适应这种新常态用docker logs代替直接查看日志文件位置用docker restart代替systemctl restart。刚开始可能会不习惯但用顺了以后你会发现这套机制反而更清晰——每个组件的日志、数据、配置文件都有了明确的边界。还有一点值得说明Docker跑ELK其实是对官方发布包的一种“封装”并没有改变ELK本身的架构。Elasticsearch该开几个节点、Logstash管道怎么配、Kibana怎么连ES这些核心逻辑和裸机部署完全一致。所以你在这里学到的东西未来切换到物理机部署或者Kubernetes集群思路一样能迁移。2. 动手前的准备工作镜像版本、内存规划和目录结构2.1 版本选择千万别把大版本混着用ELK三件套的版本兼容性是个大坑。我最早踩过的坑就是图省事分别拉取了当时最新的三个镜像结果Elasticsearch是8.xLogstash是7.xKibana是8.x连起来以后Kibana直接报版本不匹配。实际上这三个组件的版本号必须保持主版本一致最好连小版本也尽量一致。比如Elasticsearch、Logstash、Kibana都选用7.17.x或者都选用8.8.x这样才能保证协议兼容。这里给一个具体建议目前主流的稳定线上版本是7.17系列和8.x系列。7.x的配置方式、API风格在许多资料里都有大量沉淀插件生态也比较成熟8.x引入了安全特性默认开启、新的API设计但配置上多了一些额外步骤。如果是自己学习或者内网使用7.17.x是低门槛的选择如果是从零开始的新项目且愿意多花点时间理解安全配置选8.x也没问题。决定好大版本后三个镜像的tag保持一致。我自己这次用的是7.17.x原因很简单我需要的几个Logstash插件在7.x下验证过不想为了升级版本额外踩坑。提示拉镜像之前先确认自己的Docker环境是能正常访问公共镜像仓库的。如果使用自定义镜像加速源提前配好避免拉取超时。2.2 内存预估ELK是个吃内存大户Elasticsearch默认的JVM堆内存设置很保守但也不算小默认是1GBLogstash的JVM堆大小默认是1GBKibana是Node.js应用内存占用相对低一些一般512MB到1GB就够了。这三个加起来最少最少需要给Docker分配3GB以上的内存空间。如果你的机器总共就2GB内存建议先加内存或者把ES和Logstash的堆内存调小到512MB但那样做性能会明显下降尤其采集日志量大的时候Logstash会频繁GC最终导致数据积压。我自己的经验是日志量在每天几十GB以内给ELK分配4GB内存就够了。Elasticsearch的堆内存设置成2GBLogstash给1GB剩下给Kibana和系统留余量。设置方法是环境变量ES_JAVA_OPTS-Xms2g -Xmx2g。注意Xms和Xmx建议设置成相同值避免运行过程中动态扩容堆内存带来的性能波动。内存规划还有一个容易被忽略的点Elasticsearch除了JVM堆外还依赖操作系统的Page Cache来加速搜索和索引所以它实际消耗的内存会比-Xmx设置的值要多不少。如果你看到容器内存占用比配置的堆内存大别慌这是正常现象。2.3 目录规划数据卷一定要提前想好容器是临时性的一旦删除容器内的所有数据都会消失。Elasticsearch里的索引数据、Logstash的管道配置、Kibana的配置都需要通过数据卷volume或者绑定挂载bind mount持久化到宿主机上。我的习惯是统一在一个目录下建好三个子目录比如mkdir -p /data/elk/es-data mkdir -p /data/elk/es-log mkdir -p /data/elk/logstash-pipeline mkdir -p /data/elk/kibana-config然后启动容器时把对应目录挂载进去。这样做的好处是备份、迁移、清理都集中在一个目录里完成不用东一个路径西一个路径找。我强烈建议你在第一次启动之前就把目录规划好而不是装完以后再回头补挂载——Docker容器创建以后挂载参数是没法改的只能重建容器。2.4 内核参数最容易忽略的一步Elasticsearch有个知名的启动错误max virtual memory areas vm.max_map_count [65530] is too low。这是Linux内核参数限制导致的问题和Docker本身无关但很多人第一次用Docker跑ES就会撞上。解决办法是在宿主机上执行sudo sysctl -w vm.max_map_count262144为了让系统重启后仍然生效还需要把它写进/etc/sysctl.conf文件。这个参数如果不调ES容器会启动失败日志里会明确告诉你问题出在哪。很多人以为是自己镜像拉错了折腾半天其实一句话就能解决。3. 核心实操从零启动Elasticsearch、Logstash、Kibana3.1 先建一个共享网络三个容器之间要互相通信最简单的办法是创建一个Docker网络让它们都在这个网络里跑。这样容器之间就可以用容器名作为主机名互相访问而不依赖IP地址。IP地址是动态分配的一旦容器重建就变了用容器名则稳定得多。docker network create elk-network这条命令创建一个名为elk-network的桥接网络。后面启动的三个容器都加上--network elk-network参数它们就能通过容器名互通了。例如Kibana要连接Elasticsearch就可以直接用http://elasticsearch:9200这样的地址而不用去查ES容器的IP。3.2 启动Elasticsearch容器Elasticsearch是整套系统里最核心、也是配置项最多的组件。我先说单节点模式这是测试环境最常用的。命令如下docker run -d \ --name elasticsearch \ --network elk-network \ -p 9200:9200 \ -p 9300:9300 \ -e discovery.typesingle-node \ -e ES_JAVA_OPTS-Xms2g -Xmx2g \ -e TZAsia/Shanghai \ -v /data/elk/es-data:/usr/share/elasticsearch/data \ -v /data/elk/es-log:/usr/share/elasticsearch/logs \ elasticsearch:7.17.10逐个解释一下关键参数-p 9200:9200是把容器的9200端口映射到宿主机9200是REST API端口我们后续用curl访问、Kibana连接都用它9300是节点间通信端口单节点模式下其实用不到但映射出来方便以后扩展集群。discovery.typesingle-node告诉ES以单节点模式运行如果不加这个参数ES会默认尝试发现集群中的其他节点找不到就会一直报错然后退出。ES_JAVA_OPTS设置堆内存前面说过了。TZAsia/Shanghai设置时区这个很重要不然日志时间戳会差8小时。启动后检查状态docker ps看到容器状态是Up就说明起来了。然后查看日志docker logs elasticsearch确认没有报错信息特别是不要出现vm.max_map_count的提示。最后验证ES是否正常响应curl http://localhost:9200返回的JSON里包含cluster_name、tagline之类的信息就说明ES完全就绪了。第一次启动会因为初始化数据而稍慢可能需要几十秒耐心等一下再curl。注意如果之前启动过程中ES因为异常退出过/data/elk/es-data目录下可能残留了损坏的节点锁文件。再次启动前把这些文件清理掉前提是确认没有有价值的数据否则ES可能拒绝启动。3.3 启动Logstash容器Logstash的角色是数据管道从各种数据源采集日志经过处理和结构化最后输出到Elasticsearch。启动它之前我们得先准备一份管道配置文件。我习惯在宿主机上建一个目录专门存放管道配置比如刚才的/data/elk/logstash-pipeline。在里面写一个最简单的管道配置文件logstash.confinput { beats { port 5044 } } output { elasticsearch { hosts [http://elasticsearch:9200] index logstash-%{YYYY.MM.dd} } }这个配置的含义是通过Beats协议在5044端口接收日志数据输出到Elasticsearch索引名按日期滚动。这里的elasticsearch是ES容器的名字因为在同一个Docker网络内Logstash可以直接用容器名解析到ES的地址。然后启动Logstash容器docker run -d \ --name logstash \ --network elk-network \ -p 5044:5044 \ -e TZAsia/Shanghai \ -v /data/elk/logstash-pipeline:/usr/share/logstash/pipeline/ \ logstash:7.17.10注意挂载路径Logstash镜像启动时默认会读取/usr/share/logstash/pipeline/目录下的配置文件。我们把宿主机上的目录整个挂载进去这样以后修改配置只需改动宿主机文件然后重启容器即可。实际使用中Logstash启动比ES要慢因为要加载JRuby环境和一系列插件有时候要等上一两分钟。启动后同样用docker logs logstash查看日志看到类似[INFO ] ... Pipelines running的提示就说明管道跑起来了。我自己的习惯是在写复杂的输出配置之前先加一个stdout { codec rubydebug }输出把Logstash接收到的数据打到容器日志里验证一下确认数据确实流转起来了再去掉这个输出。这个调试习惯帮我省了不少排查问题的时间。3.4 启动Kibana容器Kibana是可视化的那层配置相对简单。它主要是告诉它ES在哪里docker run -d \ --name kibana \ --network elk-network \ -p 5601:5601 \ -e ELASTICSEARCH_HOSTShttp://elasticsearch:9200 \ -e TZAsia/Shanghai \ -v /data/elk/kibana-config:/usr/share/kibana/config/ \ kibana:7.17.10启动后访问http://localhost:5601就能看到Kibana的页面。首次访问的时候Kibana会要求你创建索引模式Index Pattern如果你已经用Logstash往ES里写入了数据就可以直接在Kibana里创建一个匹配的索引模式比如logstash-*然后到Discover页面查看日志了。有一个细节Kibana启动时如果连不上ES页面会一直转圈报错。所以务必确认Kibana容器日志里没有Unable to connect to Elasticsearch之类的错误。如果连不上排查两步一是确认三个容器是否在同一网络里二是确认容器内部的ES地址用了容器名elasticsearch而不是localhost。提示在容器里访问localhost指向的是容器自身不是宿主机的服务。想要从容器里访问宿主机服务Docker里通常要使用特殊的网关地址启动时配置好端口映射后在容器内用宿主机IP也可以但不如直接用Docker网络互通来得干净。ELK三个组件放同一网络里互相访问是最省事的方式。4. 配置Logstash管道从采集到结构化输出的完整实践上面那个简单的管道配置只是打通了流程实际生产环境远远不够。Logstash的强大之处在于丰富的输入、过滤、输出插件。我详细讲讲几个常用的配置形态以及里面的关键细节。4.1 输入源从文件读取日志很多场景下我们需要让Logstash直接读取宿主机上某个日志文件比如应用系统写出的app.log。容器里读取宿主机文件靠的是挂载mkdir -p /data/app-logs docker run -d \ --name logstash \ --network elk-network \ -p 5044:5044 \ -e TZAsia/Shanghai \ -v /data/elk/logstash-pipeline:/usr/share/logstash/pipeline/ \ -v /data/app-logs:/var/log/app-logs:ro \ logstash:7.17.10注意我们在启动参数里多挂载了一个/data/app-logs目录到容器的/var/log/app-logs并加了ro表示只读防止Logstash意外改动原始日志文件。然后在管道配置文件里指定文件路径input { file { path /var/log/app-logs/*.log start_position beginning sincedb_path /dev/null } }这里有两个关键参数。start_position beginning表示从文件开头读取如果设置成end那Logstash启动后只读新追加的内容以前的内容不会处理。合理的选择取决于你的场景首次接入历史日志时用beginning日常增量采集时用end。sincedb_path /dev/null则告诉Logstash不要记录文件读取位置这样每次容器重启都会重新读一遍所有文件。测试时这么很方便但生产环境千万别这么配否则重复数据会刷爆ES。生产环境应该用默认的sincedb机制把读取进度持久化到数据目录。4.2 过滤器用Grok解析非结构化日志日志如果在写入时没有经过结构化通常是一长串文本比如2023-06-01T12:00:0008:00 ERROR [order-service] Failed to process order: timeoutGrok解析后可以把时间、日志级别、服务名、错误信息分别提取成字段这样就能在Kibana里按日志级别过滤、按服务名聚合了。一个简单的Grok规则filter { grok { match { message %{TIMESTAMP_ISO8601:log_time} %{LOGLEVEL:log_level} \[%{DATA:service}\] %{GREEDYDATA:message_body} } } date { match [log_time, ISO8601] target timestamp } }这种配置看起来简单但Grok正则写起来挺磨人的。我的建议是先在Kibana的开发工具页面或者Groovy在线调试器上验证正则能不能匹配你的实际日志样本再往配置里写。Grok内置了上百种正则模式常用的IP、LOGLEVEL、DATA、GREEDYDATA、NUMBER都能直接用。GREEDYDATA匹配到最后DATA匹配到下一个分隔符或者结尾。date过滤器的作用是把日志里自带的时间覆盖到timestamp字段上。这非常重要因为Elasticsearch默认的timestamp是Logstash收到日志的时间如果日志是延迟批量推送的默认时间就失真了。用日志原文里的时间去覆盖后续在Kibana里按时间排序、按时间聚合才准确。4.3 输出分索引、调分片前面输出配置里只写了ES的地址和索引模式实际使用还需要考虑索引分片和副本。内网环境单节点测试建议设置副本数为0否则分片健康状态会长期停留在YELLOW。可以用ES的索引模板来设置output { elasticsearch { hosts [http://elasticsearch:9200] index app-log-%{YYYY.MM.dd} template_name app-log-template template /usr/share/logstash/templates/app-log-template.json } }模板文件内容里可以设置分片数、副本数和字段映射。比如{ index_patterns: [app-log-*], settings: { number_of_shards: 1, number_of_replicas: 0 }, mappings: { properties: { service: { type: keyword }, log_level: { type: keyword }, message_body: { type: text } } } }实际使用中索引模板的配置可以直接放到ES侧管理通过_index_templateAPI创建Logstash只管写入就行。这样可以把模板的能力从Logstash配置里解耦出来只让Logstash负责采集和转换。这种方式更清晰我个人也更推荐。5. 常见问题与排查实录那些让人抓狂的坑5.1 Elasticsearch容器反复重启症状容器启动后几秒就退出用docker ps -a看状态是Exited或者一直Restarting。排查思路先看日志docker logs elasticsearch十有八九会告诉你原因。我遇到的概率排序是第一vm.max_map_count太低按前面的方法调高内核参数立刻解决第二data目录权限问题目录的属主不是容器里的elasticsearch用户UID 1000需要chown -R 1000:1000 /data/elk/es-data第三磁盘空间不足ES启动时会检查磁盘空间剩余空间低于阈值会拒绝启动。5.2 Kibana页面能开但一直显示无法连接ES症状Kibana容器状态正常端口也映射了但页面上显示类似Saved Objects或者首页一直报服务不可用。排查思路在Kibana容器里直接访问ES试试用docker exec -it kibana bash进入容器然后curl http://elasticsearch:9200看能不能通。如果不通大概率是网络没打通检查两个容器是不是同一个网络。还有一种情况是Kibana配置的ES地址写成了localhost:9200这肯定不行改成容器名。5.3 Logstash收集到的日志时间总是相差8小时症状Kibana里看到的日志时间戳比实际时间早了8小时。原因分析Logstash和ES容器内部的时区是UTC而你的业务日志生成时区是东八区。虽然我在启动参数里加了TZAsia/Shanghai但如果Logstash解析日志时间时的时区没有指定解析结果仍可能按UTC处理。解决办法在Logstash管道配置的date过滤器里明确指定时区date { match [log_time, ISO8601] target timestamp timezone Asia/Shanghai }这个参数配置对了时间就正常了。所有涉及时间的环节从采集、传输到展示时区必须全程一致否则你会在排查数据时多花很多无谓的时间。5.4 容器重建后丢数据症状容器删除重建后Kibana里之前收的数据全没了。原因启动容器时没有挂载数据卷或者挂载的目录不对。ES的数据在容器内是/usr/share/elasticsearch/dataLogstash的进度信息在/usr/share/logstash/data这些目录如果不挂载到宿主机容器一删数据就全没了。这属于基础问题但遇到的人真不少。5.5 Logstash配置改了半天不生效症状改了宿主机上的管道配置文件重启Logstash容器但新的逻辑没跑起来。排查思路先确认挂载有没有生效——文件真的被容器读取了吗进入容器里cat /usr/share/logstash/pipeline/你的配置.conf看看内容。然后确认Logstash加载的是哪个配置文件因为Logstash镜像里可能有默认配置目录和自定义目录同时存在的情况。有时候你修改的是logstash.yml但管道配置独立在pipeline目录两个地方都要对得上。最后配置文件的语法错误会导致整个管道起不来用docker logs logstash看有没有语法解析异常。6. 用Docker Compose编排告别一次敲三条命令手动启动三四个容器每次都要敲一长串参数虽然可行但很繁琐。环境变量写错一个还得删除容器重建。这里我更推荐用docker-compose.yml把整个环境管理起来。一个最小的编排文件长这样version: 3 services: elasticsearch: image: elasticsearch:7.17.10 container_name: elasticsearch environment: - discovery.typesingle-node - ES_JAVA_OPTS-Xms2g -Xmx2g - TZAsia/Shanghai ports: - 9200:9200 - 9300:9300 volumes: - /data/elk/es-data:/usr/share/elasticsearch/data - /data/elk/es-log:/usr/share/elasticsearch/logs networks: - elk-network logstash: image: logstash:7.17.10 container_name: logstash environment: - TZAsia/Shanghai ports: - 5044:5044 volumes: - /data/elk/logstash-pipeline:/usr/share/logstash/pipeline/ networks: - elk-network depends_on: - elasticsearch kibana: image: kibana:7.17.10 container_name: kibana environment: - ELASTICSEARCH_HOSTShttp://elasticsearch:9200 - TZAsia/Shanghai ports: - 5601:5601 volumes: - /data/elk/kibana-config:/usr/share/kibana/config/ networks: - elk-network depends_on: - elasticsearch几个要点说明一下。depends_on只是控制容器启动的先后顺序不等于健康检查。也就是说Kibana容器启动时ES可能还没完全就绪Kibana会有个重试机制等ES好了它自己就会连上不用太担心。networks里定义的elk-network会自动创建三个服务都在这个网络里互相用服务名elasticsearch、logstash、kibana访问就行。用Compose管理之后常用操作变得非常简单# 启动整套环境 docker compose up -d # 查看状态 docker compose ps # 查看某个服务的日志 docker compose logs -f logstash # 停止所有服务 docker compose stop # 删除所有服务数据卷还在数据不丢 docker compose down # 连数据卷一起删除慎用 docker compose down -v我一般会配一个别名或者写个脚本把docker compose up -d这种常用命令固化下来减少敲错的可能。Compose文件本身就相当于你的“部署文档”后续换机器、换环境把这个文件带过去就能复现整套环境比手敲命令可维护性高太多了。7. 后续扩展思路从单节点测试走向正式环境如果这套环境不是仅仅拿来测试而是要承载一定的业务日志有几个方向值得继续往下走。7.1 添加Filebeat作为轻量级采集器前面的方案里Logstash直接读文件这对于单机场景没问题但如果日志来源分布在多个服务器每个服务器都跑一个Logstash就太重了。更合理的架构是每个日志源部署一个轻量级采集器比如Filebeat由它负责读取文件并转发到中心Logstash。Filebeat的内存占用只有Logstash的一个零头部署成本低得多。配置好Filebeat后它往Logstash的5044端口发数据管道配置里beats这个输入就是为它准备的整体架构图是这样的各个应用服务器部署Filebeat采集本机日志Filebeat把日志发到中心LogstashLogstash做解析、清洗、结构化输出到Elasticsearch存储Kibana负责检索和可视化7.2 多节点Elasticsearch单节点ES有单点故障问题磁盘满了也没法水平扩展。正式环境至少需要3个节点组成一个集群节点之间通过前面提到的9300端口通信。Docker里扩展多节点时可以复制多个服务定义注意分配不同的节点角色master、data、ingest并确保discovery.type不再是single-node而要用discovery.seed_hosts等方式配置节点发现。这块复杂度会上一个台阶但思路仍然是围绕着容器网络和数据卷管理。7.3 索引生命周期管理日志索引是会不断增长的如果不做清理总有一天磁盘会满。Elasticsearch提供了索引生命周期管理ILM可以按索引大小、文档数量或时间自动滚动索引并且自动删除过期数据。比如设定“保留30天”那么30天以前的索引会被自动清理。这个能力直接在ES侧配置即可Logstash侧只需要让索引名匹配ILM策略指定的格式就行。7.4 监控与告警ELK本身也是需要被监控的。至少要看三个指标磁盘空间、ES集群健康状态、Logstash管道积压情况。磁盘空间可以通过简单的定时脚本检查ES健康状态通过访问/cluster/health接口获取Logstash管道信息可以通过其监控API查看。把这些指标接到你现有的告警系统里比出了问题再着急去翻日志要舒服得多。就我个人而言Docker跑ELK这套流程的价值不只是“把三个容器拉起来”更在于帮助你理解组件之间的依赖关系和数据流向。等你亲手把ES起来、看Logstash把数据推进去、再在Kibana界面里搜到一条日志这套系统的核心脉络就已经在你脑子里了。后面无论换成Kubernetes部署、还是引入全托管云服务你都知道每个组件在扮演什么角色、出了问题该去哪里查这就足够了。
