最近在 Linux 服务器上部署了一套 Elasticsearch Kibana Logstash 的 8.x 组合用来统一收拢内部系统的访问日志和业务日志。标题里这三个东西就是常说的 ELK 三件套但它们各自承担的角色其实差别很大Elasticsearch 负责存储和检索Kibana 负责可视化展示Logstash 负责日志采集和加工。在 8.x 版本里默认开启安全认证、默认使用 HTTPS 自签名证书这两个变化会让很多照着 7.x 教程操作的人第一次启动就被卡住。这篇文章会把从服务器准备、安装配置到 Kibana 接入、Logstash 管道跑通的全过程记录下来适合准备在自己机器上搭一套完整日志检索分析环境的人参考。1. 项目概述与部署思路1.1 ELK 三件套各自职责从使用场景来说Elasticsearch 是整个链路的核心。日志数据被写入之后要靠它的倒排索引和分片机制完成海量数据下的快速检索Kibana 是面向使用者的窗口数据视图、仪表盘、图表都在这层配置Logstash 则像一个管道工负责把原始日志从文件、消息队列或者其他数据源捞出来做格式解析、字段清洗再交给 Elasticsearch。三者的关系可以简单理解成“采集 - 存储 - 展示”。这套组合最常见的落地场景是日志平台。系统每天产生大量访问日志、应用报错日志、安全审计日志如果靠 grep 和文件翻查定位一个问题可能要花很久。ELK 把日志集中到 Elasticsearch 以后可以用 Kibana 的搜索框做关键词过滤、按时间范围圈定、用聚合统计看趋势效率提升非常明显。对于没有现成商业化日志平台、又想自己掌控数据的中小型团队这套组合基本是首选方案。1.2 8.x 版本带来的关键变化8.x 和 7.x 之间最大的差异不是界面也不是 Logstash 的配置语法而是安全机制变了。8.x 从安装那一刻起就默认启用 xpack.securityElasticsearch 的 HTTP 接口默认走 HTTPS并且会自动生成自签名证书。以前 7.x 里那种直接curl http://localhost:9200的习惯在这里会直接碰到证书报错。另一个变化是账号体系。8.x 里内置了elastic超级用户第一次启动时系统会自动生成随机密码同时引入了服务账户令牌这个概念。Kibana 连接 Elasticsearch 不再推荐直接写死用户名密码而是用elastic/kibana这个服务账户下创建的 tokenLogstash 往 Elasticsearch 写数据也建议使用 API Key 或者专用账号。这些机制一开始会让人觉得繁琐但理解以后反而比裸奔式的部署更安全也更容易做权限隔离。还有一点要注意8.x 官方已经不再提供 OSS-only 发行版下载到的默认包就带安全功能。所以网上有些“把 xpack.security.enabled 改成 false 关掉安全”的老教程不是不能用但会绕开很多新版本默认能力。我建议新环境直接顺着安全机制走别一上来就关。1.3 单机版部署方案与目录规划我这次部署的是一个内部日志检索分析项目规模不大数据量在单机可承受范围内。为了让步骤可控采用一个经典的单机三合一拓扑Elasticsearch、Kibana、Logstash 都安装在同一台 Linux 服务器上。实际生产环境如果日志量上来Elasticsearch 节点需要独立拆出去Logstash 也可以单独部署成采集层但这套安装配置逻辑是通用的。目录规划也很重要我习惯把所有组件统一放在一个父目录下方便后续备份和权限管理。规划如下组件监听端口配置目录运行目录Elasticsearch9200 / 9300/opt/elastic/elasticsearch/config/opt/elastic/elasticsearchKibana5601/opt/elastic/kibana/config/opt/elastic/kibanaLogstash5044 / 9600/opt/elastic/logstash/config/opt/elastic/logstash这里统一使用/opt/elastic作为根目录实际环境中根据磁盘分区情况调整即可。如果服务器有单独的数据盘建议把 Elasticsearch 的 path.data 指到数据盘避免日志数据和操作系统共用一块磁盘导致 IO 竞争。2. 安装前的系统检查与参数调优2.1 内核参数和资源限制Elasticsearch 对系统参数有硬性要求这一关不提前处理好后面启动会直接失败。最常见的是vm.max_map_count这个参数限制进程能拥有的内存映射区域数量。Elasticsearch 内部使用 mmap 来映射索引文件默认的 65530 往往不够用启动时会有类似max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]的报错。我在这台机器上先执行了以下命令sudo sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 /etc/sysctl.conf sudo sysctl -p另一个容易踩坑的是文件描述符限制。Elasticsearch 需要同时打开大量文件如果 ulimit -n 不够运行一段时间后会出现Too many open files。临时环境可以用ulimit -n 65535调整但更要紧的是 systemd 服务里的 LimitNOFILE这个我放到后面的服务托管部分一起处理。如果你的环境启用并配置了 swap还要考虑是否关闭 swap 或设置bootstrap.memory_lock: true。我这次没有开 memory_lock但把堆内存设置得比物理内存的一半小很多避免系统频繁换页。2.2 JVM 堆内存规划Elasticsearch 和 Logstash 都是 Java 应用JVM 堆设置直接决定稳定性和性能上限。Elasticsearch 官方建议把堆内存设置为物理内存的一半左右且不要超过 32GB。比如服务器内存是 16GB堆设成 4GB 到 8GB 都是合理范围。我这边物理内存 16GB分配给 Elasticsearch 的堆是 4GB给 Logstash 留了 1GB剩下的留给操作系统和 Kibana。堆内存设置方式不是直接改启动脚本而是修改 config/jvm.options.d 目录下的文件。以 Elasticsearch 为例我在jvm.options.d下新建了一个heap.options-Xms4g -Xmx4g有一点要注意Xms 和 Xmx 最好设置成相同值避免 JVM 运行时动态扩展堆引起性能抖动。Logstash 默认堆是 1GB在日志量不大的场景下够用如果后续要处理大量并发日志可以参照同样的方式调大。2.3 运行用户和目录权限Elasticsearch 出于安全考虑明确禁止使用 root 用户启动。Kibana 和 Logstash 虽然没这个强制要求但同一套体系里最好也不要让它们跑在 root 下。我创建了一个专用账号elk把所有组件都交给这个账号管理。sudo useradd -r -s /sbin/nologin elk sudo mkdir -p /opt/elastic sudo chown -R elk:elk /opt/elastic这里有个细节如果后续要用 systemd 托管服务用户用/sbin/nologin完全没问题服务进程不需要登录交互。但如果你习惯手动切su - elk执行命令就需要改成能登录的 shell。我是先用 root 解压和改配置最后统一把所有权交给 elk这个顺序更不容易因为权限问题返工。3. Elasticsearch 8.x 安装与基础配置3.1 下载解压和主配置文件从产品官网下载对应的 Linux x86_64 tar.gz 包版本号建议选择 8.x 比较新的稳定版所有组件保持同一个版本。我这边下载的是 8.14.3解压到 /opt/elastic 并改了目录名cd /opt/elastic tar -zxf elasticsearch-8.14.3-linux-x86_64.tar.gz mv elasticsearch-8.14.3 elasticsearch chown -R elk:elk elasticsearch接下来修改config/elasticsearch.yml这是整个部署里最关键的一个文件。我这边用到的配置如下cluster.name: ops-log node.name: node-1 path.data: /opt/elastic/elasticsearch/data path.logs: /opt/elastic/elasticsearch/logs network.host: 0.0.0.0 http.port: 9200 discovery.type: single-nodediscovery.type: single-node是单节点部署必须的配置它的作用是跳过集群发现阶段的引导检查让这台机器自己当主节点。等以后要扩大集群时这个配置必须删掉改成discovery.seed_hosts和cluster.initial_master_nodes。network.host我这里设置成0.0.0.0表示监听所有网卡如果你只想让内网其他机器访问也可以写成具体的内网 IP。3.2 首次启动和安全初始化8.x 首次启动会自动完成安全初始化生成自签名 CA、HTTP 证书、transport 证书还会生成 elastic 用户的随机密码。这个机制对新手来说有点“黑盒”但好处是不用再手动跑证书生成工具。先启动一次看效果sudo -u elk /opt/elastic/elasticsearch/bin/elasticsearch -d -p /tmp/elasticsearch.pid这里-d是后台运行-p保存 PID。如果你的机器上之前没有运行过 Elasticsearch启动后日志里会出现密码提示。但为了留下可用的密码我推荐先停掉这个进程然后用交互式重置命令手动设置密码sudo -u elk /opt/elastic/elasticsearch/bin/elasticsearch-reset-password -u elastic -i这个命令会提示输入新密码设置完成后要牢牢记住。后续 Kibana 登录、Logstash 写入、curl 验证都会用到它。启动完成后验证集群状态curl -k -u elastic:你的密码 https://localhost:9200/_cluster/health这里-k很关键因为 Elasticsearch 默认使用自签名证书不加-k会直接报证书错误。返回结果里status为greennumber_of_nodes为 1说明 ES 已经正常工作了。如果加了-k还是不通过常见的原因是密码不对或者是 HTTPS 端口没起来。3.3 用 systemd 托管 Elasticsearch手动-d启动适合快速验证但线上环境我更推荐用 systemd 托管。创建一个服务文件/etc/systemd/system/elasticsearch.service[Unit] DescriptionElasticsearch Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Userelk Groupelk ExecStart/opt/elastic/elasticsearch/bin/elasticsearch Restarton-failure LimitNOFILE65535 LimitMEMLOCKinfinity [Install] WantedBymulti-user.targetTypesimple 表示进程在前台运行systemd 直接管理这个进程。相比 fork 模式这种方式更直观日志也能直接交给 journald。设置好之后执行systemctl daemon-reload再systemctl enable --now elasticsearch后续就通过systemctl status elasticsearch查看状态了。4. Kibana 8.x 接入与可视化配置4.1 Kibana 下载解压和基础配置Kibana 不依赖 JDK它自带 Node.js 运行时所以解压以后基本不用管环境变量。同样从官网下载与 Elasticsearch 相同版本的 tar.gz 包解压后改名cd /opt/elastic tar -zxf kibana-8.14.3-linux-x86_64.tar.gz mv kibana-8.14.3 kibana chown -R elk:elk kibanaKibana 的主配置在config/kibana.yml。最核心的部分是告诉它 Elasticsearch 在哪以及用什么令牌连接。我这里先做了一个最小配置server.port: 5601 server.host: 0.0.0.0 server.name: ops-kibana elasticsearch.hosts: [https://localhost:9200]注意elasticsearch.hosts里的地址必须是 HTTPS和 Elasticsearch 实际监听的协议保持一致。如果你在另一台机器上访问 Kibanaserver.host不要写成 127.0.0.1。Kibana 默认只监听本地这会让远程访问失败。此外我习惯顺手打开中文界面配置i18n.locale: zh-CN4.2 创建服务账户令牌而不是硬编码密码Kibana 连接 Elasticsearch 时传统的做法是在配置里写elasticsearch.username和elasticsearch.password。但 8.x 提供了更规范的服务账户方式我这次就用的服务账户令牌。在 Elasticsearch 节点上执行sudo -u elk /opt/elastic/elasticsearch/bin/elasticsearch-service-tokens create elastic/kibana kibana-tokenelastic/kibana是内置的系统服务账户kibana-token是我们给这个 token 取的名字。命令执行后会把完整的 token 值打印出来类似AAEAAW...这段值就是之后要填到 Kibana 配置里的凭据。把 token 填到 kibana.ymlelasticsearch.serviceAccountToken: AAEAAW...这里要注意token 只会显示一次如果没复制下来只能删掉重新创建。重新创建的命令是sudo -u elk /opt/elastic/elasticsearch/bin/elasticsearch-service-tokens delete elastic/kibana kibana-token然后再次执行 create 命令生成新的 token。服务账户令牌比密码更适合这里的场景因为它的权限范围被限制在 Kibana 系统账户职责内即使泄露也不会直接拿到 elastic 超级用户权限。4.3 启动 Kibana 和创建数据视图启动 Kibana 同样用 systemd 托管。服务文件内容很简单[Unit] DescriptionKibana Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Userelk Groupelk ExecStart/opt/elastic/kibana/bin/kibana Restarton-failure LimitNOFILE65535 [Install] WantedBymulti-user.target启动命令systemctl daemon-reload systemctl enable --now kibanaKibana 启动速度比 Elasticsearch 慢因为要加载大量静态资源和初始化内部状态。启动日志在/opt/elastic/kibana/logs/kibana.log看到http server running at字样的日志后就可以打开浏览器访问http://服务器IP:5601了。首次登录使用 elastic 用户和刚才设置的密码。登录成功后需要先创建数据视图。点击左侧菜单进入 Stack Management找到 Data Views创建一个匹配索引名的视图。比如 Logstash 后续写入的索引名是web-access-2024.08.21数据视图的索引模式就填web-access-*这样可以匹配所有按日期生成的索引。时间字段默认选择timestamp这个字段在 Logstash 解析日志时会自动生成。5. Logstash 8.x 数据管道配置5.1 Logstash 安装和 JAVA_HOME 配置Logstash 没有捆绑 JDK需要机器上有可用的 Java 运行环境。很多 Linux 服务器上未必预装 Java这时候不用急着额外下载 JDK直接复用 Elasticsearch 自带的 JDK 就行。Elasticsearch 8.x 的目录里有一个 jdk 目录路径是/opt/elastic/elasticsearch/jdk它本身就是完整可用的 JDK。下载并解压 Logstashcd /opt/elastic tar -zxf logstash-8.14.3-linux-x86_64.tar.gz mv logstash-8.14.3 logstash chown -R elk:elk logstash如果直接用命令行启动 Logstash需要先导出 JAVA_HOMEexport JAVA_HOME/opt/elastic/elasticsearch/jdk /opt/elastic/logstash/bin/logstash --versionLogstash 对于 JDK 版本有要求8.x 需要 JDK 17 或更高版本ES 自带的 JDK 正好是 17 以上版本所以版本匹配不用担心。这里有一点要提醒不要试图用/opt/elastic/logstash/bin/logstash直接启动却不设置 JAVA_HOME那样会得到一堆 “Could not find any viable java installation” 的报错非常劝退。5.2 一个标准管线示例采集 Web 访问日志Logstash 的核心是 pipeline一份 pipeline 配置由 input、filter、output 三部分组成。我这边先写一个采集 Web 服务器访问日志的配置作为演示管道。在/opt/elastic/logstash/pipeline目录下创建web-log.confinput { file { path [/var/log/webapp/access.log] start_position beginning sincedb_path /opt/elastic/logstash/.sincedb ignore_older 0 } } filter { grok { match { message %{COMBINEDAPACHELOG} } } date { match [ timestamp, dd/MMM/yyyy:HH:mm:ss Z ] target timestamp timezone 本地时区 } mutate { remove_field [message, path] } } output { elasticsearch { hosts [https://localhost:9200] user elastic password 你的elastic密码 index web-access-%{yyyy.MM.dd} ssl_certificate_authorities [/opt/elastic/elasticsearch/config/certs/http_ca.crt] } }先解释一下里面的关键点。file input 插件默认会记录读取位置这个位置保存在 sincedb_path 指定的文件里。第一次采集老日志时start_position beginning会从文件头开始读但如果这个 sincedb 文件已经记录了文件的偏移量Logstash 就不会重新读所以验证时如果没数据优先检查 sincedb 文件是否需要删除。filter 里的 grok 是 Logstash 最常用的解析插件。COMBINEDAPACHELOG是内置正则模式可以直接把常见的 Web 访问日志拆成clientip、timestamp、request、status、bytes等字段。如果你要解析的日志格式不是标准访问日志就需要自己写正则匹配这个场景后面有机会单独展开。output 是最容易出问题的地方。因为 ES 8.x 默认 HTTPS所以hosts必须写成https://同时必须把 ES 的 CA 证书路径配到ssl_certificate_authorities这个证书在/opt/elastic/elasticsearch/config/certs/http_ca.crt。如果不配置Logstash 会报 SSL certificate 相关的错误。用户名密码就是 elastic 用户和之前设置的密码。5.3 配置测试和启动 LogstashLogstash 启动前强烈建议先做配置检查语法错误在运行阶段才会暴露排查起来更麻烦。执行export JAVA_HOME/opt/elastic/elasticsearch/jdk cd /opt/elastic/logstash bin/logstash --path.settings /opt/elastic/logstash/config -f /opt/elastic/logstash/pipeline/web-log.conf --config.test_and_exit如果输出里出现Configuration OK说明配置通过。然后去掉--config.test_and_exit正常启动。我最终还是用 systemd 托管 Logstash服务文件如下[Unit] DescriptionLogstash Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Userelk Groupelk EnvironmentJAVA_HOME/opt/elastic/elasticsearch/jdk ExecStart/opt/elastic/logstash/bin/logstash --path.settings /opt/elastic/logstash/config Restarton-failure RestartSec10 [Install] WantedBymulti-user.targetLogstash 启动后可以通过curl -k -u elastic:密码 https://localhost:9200/_cat/indices?v查看索引是否生成。如果看到以web-access-开头的索引说明日志数据已经成功写入 Elasticsearch。此时回到 Kibana 的 Discover 页面选择刚才创建的数据视图就能看到日志条目了。6. 常见问题与排查技巧实录6.1 启动阶段问题汇总部署过程中最容易踩的坑基本集中在启动阶段我把这段时间遇到的典型问题整理成一张速查表现象原因解决办法ES 启动报max virtual memory areas vm.max_map_count系统 mmap 上限太低sysctl -w vm.max_map_count262144并写入 sysctl.confES 启动报can not run as rootElasticsearch 不允许 root 运行切换到 elk 用户检查目录属主Logstash 启动报Could not find any viable java installationJAVA_HOME 未设置在 systemd 或 shell 中指定 JAVA_HOMEKibana 登录页报 401token 过期、错误或服务没连上 ES重新生成 service account token 并检查 elasticsearch.hosts端口 5601 无法远程访问server.host还是 127.0.0.1改成0.0.0.0后重启 Kibana每一个问题都有对应的排查路径。ES 启动阶段如果报错第一步是打开/opt/elastic/elasticsearch/logs/elasticsearch.log看最后几十行报错原因基本都会明确写出来。Kibana 和 Logstash 同理日志比任何“看起来像是配置不对”的猜测都可靠。6.2 认证和证书相关排查8.x 的 HTTPS 和证书是很多人第一次接触的领域这里单独拎出来讲。Elasticsearch 自签名证书会让很多传统客户端工具报错比如如果你用 curl 访问 ES不带-k就会失败如果用 Logstash 写入不配置 CA 证书路径也会失败。日志里如果出现unable to verify the first certificate说明 Logstash 这一侧的 ssl_certificate_authorities 没有配或者路径写错了。排查思路是确认/opt/elastic/elasticsearch/config/certs/http_ca.crt这个文件是否存在同时确认 Logstash 进程是否有权限读取它。如果文件存在但权限不对用 root 执行chmod 644或调整属主即可。如果只是用 curl 测试访问最简单的办法是加-k跳过证书校验。但这只适合验证不建议在正式采集链路里用ssl_verification_mode none绕过因为那样等于把日志明文裸奔在网络上失去了 8.x 默认安全的意义。6.3 数据采集不到时的排查顺序数据采集不到是最让人头疼的问题但排查顺序很有规律。我一般按以下顺序查第一步确认 Logstash 进程还活着看日志有没有报错。第二步确认输入路径有没有写错或者文件是否新增了内容。第三步确认 sincedb 文件是不是之前的旧状态如果start_position beginning但文件已经被记录过偏移量新日志不会重新读。第四步确认输出端有没有报认证错误常见的是密码错误或者是 CA 证书路径问题。还有一个细节Logstash 的 date 插件解析时间时默认按 UTC 处理。如果日志里的时间戳是本地时间写入 Elasticsearch 后会比实际时间慢 8 小时。解决方式是在 date 插件里加timezone参数指定为你的本地时区。这个偏差在 Kibana 里看起来像数据延迟实际上是时区问题而不是采集延迟。6.4 资源占用和性能注意事项单机部署三件套时资源规划很重要。Elasticsearch 和 Logstash 都是 Java 进程Kibana 是 Node.js 进程三者加起来对内存的占用很容易超过预期。如果服务器内存只有 8GB我建议把 ES 堆设为 2GBLogstash 堆保持 1GB同时关闭 swap尽量不要在同一个环境里再跑重量级数据库或中间件。如果 Logstash 采集吞吐一直上不去可以关注pipeline.workers和pipeline.batch.size。默认配置对大多数场景是合理的不用一开始就盲目调大。我在生产环境见过有人把 batch.size 调到 10000结果内存飙升反而是副作用。7. 部署完成后的日常维护与扩展方向7.1 常用维护命令和健康检查这套组件跑起来之后日常维护不需要天天动它但有几条命令值得记住。查看集群健康状态curl -k -u elastic:你的密码 https://localhost:9200/_cluster/health?pretty这条命令会返回集群的 status、节点数、分片数等信息。status 是 green 表示所有主分片和副本都正常yellow 表示有未分配副本red 表示有主分片未分配。单节点环境出现 yellow 是正常的因为没有第二个节点可以放副本出现 red 则说明索引损坏或磁盘问题需要立即排查。查看所有索引的大小和数据量curl -k -u elastic:你的密码 https://localhost:9200/_cat/indices?vsindexpretty这个操作适合用来观察索引生命周期。如果某个索引每天增长好几个 GB就必须考虑索引生命周期管理策略或者定时清理否则磁盘会被填满。ES 8.x 自带 ILM 功能可以对索引设置 rollover 和 delete 策略这样日志数据就不会无限膨胀。7.2 从单节点向多节点扩展这套部署虽然是单机版但设计上给后续扩展留了余地。以后日志量增加需要扩成三节点集群时要做的事情主要有三件第一删掉所有节点配置里的discovery.type: single-node第二配置discovery.seed_hosts填写其他节点的地址第三重新规划证书体系因为单节点首次启动自动生成的证书只适用于当前节点多节点通信需要统一签发 CA 证书。这个过程听起来简单实际操作时最容易出问题的是证书。如果已经跑了一段时间再改集群数据迁移和证书切换的成本都比较高。所以我给新项目的一个建议是如果一开始就判断日志量可能增长最好在初始部署阶段就按多节点证书方案初始化不要贪图单机部署的省事。7.3 扩展数据采集源的思路Logstash 的 input 插件不止 file 一种它可以接收 Beats 系列采集器发来的数据也可以从 Kafka、Redis、Syslog、HTTP 等来源下载数据。我这次用的是 file input 直接读日志文件适合简单环境如果业务系统分布在多台服务器上更推荐的方案是在每台机器上安装一个轻量采集器把日志发送到集中式的 Logstash这样能避免每台机器都部署一套完整 Logstash 的沉重开销。Logstash 的 input beats 端口默认是 5044需要配置input { beats { port 5044 } }输出端保持不变采集端的配置也只需要几行。整体架构从“单机读文件”变成“多机采集 - 集中解析 - ES 存储”数据链路更清晰扩展也更方便。最后再分享一个我实际操作中的体会整套 ELK 8.x 部署的难点不在安装命令而在于理解安全机制和证书体系。只要把 Elasticsearch 的 HTTPS、服务账户令牌、CA 证书这三个概念弄明白后面的 Kibana 和 Logstash 配置都是顺理成章的事。部署完成后再用一段时间你就会发现日志检索从原来在服务器上翻文件变成了在 Kibana 里敲几个关键词效率提升是实打实的。