行业资讯
elasticsearch+kibana+logstash+filebeat链路部署流程
节点分配192.168.24.41 node1Elasticsearch Kibana存储展示层192.168.24.42 node2Logstash数据处理层192.168.24.43 node3Filebeat日志采集层一、整体架构与原理简述原理流程node3作为采集层、node2作为处理层、node1作为存储展示层全链路通过轻量协议串联支持断点续传和流量削峰。首先业务系统或系统服务如sshd、内核在node3上产生日志并写入/var/log/messages等文件Filebeat作为轻量采集器通过filestream插件实时监控文件变更将读取进度记录到registry文件避免重复采集再通过Beats私有协议把原始非结构化日志推送到node2的5044端口随后Logstash作为数据处理中枢先通过beats输入插件接收数据再用grok插件把杂乱的syslog文本解析为带syslog_timestamp、syslog_hostname、syslog_message的结构化字段date插件将日志自带的时间校准为timestamp作为官方时间戳mutate插件剔除agent.version、ecs这类冗余字段降低存储开销之前调试用的stdout插件就是把处理后的结构化日志打印到控制台方便验证解析规则是否正确最后通过elasticsearch输出插件把数据批量发送到node1的9200端口Elasticsearch作为分布式搜索引擎按logs-YYYY.MM.dd的规则按天创建索引将日志以JSON文档形式存储通过倒排索引实现毫秒级检索单节点模式下自动适配无副本的存储策略最终Kibana作为可视化前端通过REST API从ES拉取索引数据在Discover页面提供时间范围筛选、关键词搜索、字段过滤能力把结构化的JSON日志转化为可视化的表格还可进一步生成统计仪表盘、配置异常告警整套链路中Filebeat负责“轻量采集”、Logstash负责“清洗加工”、Elasticsearch负责“高效存储”、Kibana负责“直观展示”各环节解耦可独立扩缩容完美支撑从日志产生到问题排查的全生命周期需求。1.1 架构流程图1.2 核心原理组件核心逻辑遇到的坑Filebeat轻量采集器记录日志偏移量到registry避免重复采集① 两个output冲突 ② registry路径错 ③ 没权限读/var/log/messagesLogstash日志处理中枢ES8.x默认开启数据流传统index配置会被静默拒绝写入没加data_stream false导致ES一直没索引Elasticsearch分布式搜索引擎单节点默认创建1个副本无第二节点时副本无法分配索引显示yellow之前看到yellow索引是正常现象SELinux强制访问控制默认拦截Filebeat读取系统日志之前关了SELinux后才通二、前置准备所有节点执行2.1 基础环境配置1. 关闭SELinux、也可以打标签放行这里不是学习重点可以关闭# ★ 永久关闭避免重启后失效 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config setenforce 0 getenforce # 输出Permissive/Disabled才算成功2. 关闭防火墙/开放端口# 测试环境直接关 systemctl stop firewalld systemctl disable firewalld # 生产环境建议只开必要端口 # node1开9200/9300/5601node2开50443. 配置主机名解析所有节点都要做cat /etc/hosts EOF 192.168.24.41 node1 192.168.24.42 node2 192.168.24.43 node3 EOF4. 时间同步查看避免日志时间错乱yum install -y chrony systemctl enable --now chronyd chronyc sources -v # 看到^*开头说明同步成功时间同步配置1. 修改 node1 的 Chrony 配置作为Servervim /etc/chrony.conf添加或修改# 允许局域网内的节点同步 allow 192.168.24.0/24 # 即使断网也使用本地硬件时钟作为备用 local stratum 10重启systemctl restart chronyd2. 修改 node2 和 node3 的配置作为Clientvim /etc/chrony.conf注释掉公网 NTP指向 node1#pool 2.rhel.pool.ntp.org iburst server 192.168.24.41 iburst prefer 指定要同步的上游 NTP 服务器地址。 iburst 重点非常实用 作用加速初始同步。 prefer 优先级标记 作用标记为首选服务器重启systemctl restart chronyd3. 验证集群内同步在 node2 或 node3 上执行chronyc sources -v [rootnode3 ~]# chronyc sources MS Name/IP address Stratum Poll Reach LastRx Last sample ^* node1 2 6 17 19 -2149ns[ -17us] /- 36ms意义node2/node3 直接同步 node1时间源完全一致消除了公网延迟带来的微小差异。第四步硬件时钟同步防止重启后漂移系统时间Software重启后会丢失需要从硬件时钟RTC/BIOS读取。必须确保两者一致。# 1. 查看硬件时钟 hwclock -r # 2. 如果系统时间准但硬件时间不准把系统时间写入硬件非常重要 hwclock -w # 3. 设置系统时区ELK日志强烈建议使用UTC或统一时区 timedatectl set-timezone Asia/Shanghai # 或者统一用UTC推荐避免夏令时问题 # timedatectl set-timezone UTC第五步终极一致性验证你想要的“同一个时间”在三个节点上同时执行看时间戳是否大概一致有些许误差是能够接受的for i in 192.168.24.41 192.168.24.42 192.168.24.43; do echo -n $i: ssh $i date %Y-%m-%d %H:%M:%S.%3N done root192.168.24.41s password: 2026-07-22 19:29:47.650 root192.168.24.42s password: 2026-07-22 19:29:49.988 root192.168.24.43s password: 2026-07-22 19:29:52.2342.2 系统依赖与调优1. 安装JDKELK基于Java开发Java Downloads | Oraclednf install -y java-25-openjdk java -version # 验证安装成功 [rootnode1 ~]# java -version java version 25.0.3 2026-04-21 LTS Java(TM) SE Runtime Environment (build 25.0.39-LTS-195) Java HotSpot(TM) 64-Bit Server VM (build 25.0.39-LTS-195, mixed mode, sharing)2. 创建ELK专用用户禁止root运行安全要求useradd elk mkdir -p /opt/elk /opt/logs/{elasticsearch,logstash,filebeat} chown -R elk:elk /opt/elk /opt/logs3. 内核参数调优ES强制要求# 最大文件句柄数/进程数 cat /etc/security/limits.conf EOF elk soft nofile 65535 elk hard nofile 65535 elk soft nproc 40960 elk hard nproc 40960 EOF # 虚拟内存参数ES用mmap锁内存必须改 echo vm.max_map_count262144 /etc/sysctl.conf sysctl -p原理解释limits.conf里的配置是为elk用户专门设置的资源门槛nofile控制单进程最多能同时打开的文件句柄数Elasticsearch和Logstash需要频繁读写大量日志文件和网络连接默认1024的上限会直接导致服务崩溃65535是确保高并发下稳定运行的基础保障nproc则是限制用户能创建的最大进程数防止日志采集和处理的子进程耗尽系统资源。soft是运行时的软限制hard是系统允许的最高上限软限制不能超过硬限制。vm.max_map_count是Linux内核允许一个进程拥有的虚拟内存区域数量上限Elasticsearch重度依赖mmap内存映射技术将磁盘上的索引文件直接映射到内存中进行高效读写默认65530的数值远不能满足ES创建大量内存映射区的需求262144这个值是官方经过大规模测试验证的最低要求低于这个值ES会启动失败调整它能确保ES在索引和搜索海量日志时不会因为内存映射区不足而报错。三、分节点部署3.1 node1192.168.24.41Elasticsearch Kibana3.1.1 Elasticsearch部署Elasticsearch官方分布式搜索和分析引擎 | Elasticsu - elk cd /opt/elk wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.18.8-linux-x86_64.tar.gz tar -zxvf elasticsearch-8.18.8-linux-x86_64.tar.gz ln -s /opt/elk/elasticsearch-8.18.8 /opt/elk/elasticsearch exit2. 核心配置/opt/elk/elasticsearch/config/elasticsearch.ymlcluster.name: elk-cluster node.name: node1 path.data: /opt/logs/elasticsearch path.logs: /opt/logs/elasticsearch network.host: 0.0.0.0 http.port: 9200 # 单节点模式当前只有1个ES节点后续扩集群再改 discovery.type: single-node # 测试环境关闭安全认证生产环境务必开启 xpack.security.enabled: false xpack.security.enrollment.enabled: false xpack.security.http.ssl.enabled: false xpack.security.transport.ssl.enabled: false3. JVM内存配置根据你的机器内存调整不要超过物理内存50%vim /opt/elk/elasticsearch/config/jvm.options # 4G内存机器改这个 -Xms1g -Xmx1g4. 配置systemd服务cat /usr/lib/systemd/system/elasticsearch.service EOF [Unit] DescriptionElasticsearch Service Afternetwork.target [Service] Userelk Groupelk ExecStart/opt/elk/elasticsearch/bin/elasticsearch Restartalways RestartSec5 [Install] WantedBymulti-user.target EOF5. 启动验证systemctl daemon-reload systemctl enable --now elasticsearch # 等10秒后验证 curl http://192.168.24.41:9200 # 预期返回包含You Know, for Search的JSON tail -f /opt/logs/elasticsearch/elasticsearch.log # 看启动日志3.1.2 Kibana部署1. 下载解压su - elk cd /opt/elk wget https://artifacts.elastic.co/downloads/kibana/kibana-8.18.8-linux-x86_64.tar.gz tar -zxvf kibana-8.18.8-linux-x86_64.tar.gz ln -s /opt/elk/kibana-8.18.8 /opt/elk/kibana #这里相当于软链接的方式也可以和之前一样移动过去 exit2. 核心配置/opt/elk/kibana/config/kibana.yml需修改的地方server.port: 5601 server.host: 0.0.0.0 # ★ 指向你的node1的ES地址 elasticsearch.hosts: [http://192.168.24.41:9200] i18n.locale: zh-CN server.host: 0.0.0.0 表示让 Kibana 监听服务器上的所有网络接口。简单来说它告诉 Kibana“不管请求是从本机的回环地址127.0.0.1、内网网卡192.168.24.41还是其他任何网卡发过来的只要是访问 5601 端口的统统都要接受。” 这里一般生产按需求写不然就相当于裸奔很不安全但是只有一个如果ip变化也容易导致服务挂3. 配置systemd服务cat /usr/lib/systemd/system/kibana.service EOF [Unit] DescriptionKibana Service Afternetwork.target elasticsearch.service [Service] Userelk Groupelk ExecStart/opt/elk/kibana/bin/kibana Restartalways RestartSec5 [Install] WantedBymulti-user.target EOF4. 启动验证systemctl daemon-reload systemctl enable --now kibana ss -tlnp | grep 5601 # 验证端口监听 # 浏览器访问 http://192.168.24.41:5601 即可打开Kibana3.2 node2192.168.24.42Logstash部署3.2.1 基础部署1. 下载解压su - elk cd /opt/elk wget https://artifacts.elastic.co/downloads/logstash/logstash-8.18.8-linux-x86_64.tar.gz tar -zxvf logstash-8.18.8-linux-x86_64.tar.gz ln -s /opt/elk/logstash-8.18.8 /opt/elk/logstash exit2. 核心管道配置 /opt/elk/logstash/config/log-pipeline.confinput { beats { port 5044 # 接收Filebeat发送的日志 } } filter { # 只处理Filebeat标记的syslog类型日志 if [type] syslog { grok { match { message %{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message} } } date { # 用日志自带时间作为timestamp避免用采集时间 match [ syslog_timestamp, MMM d HH:mm:ss, MMM dd HH:mm:ss ] target timestamp } } mutate { # 删除冗余字段节省存储空间 remove_field [[agent][version], ecs] } } output { elasticsearch { # ★ 指向你的node1的ES地址 hosts [http://192.168.24.41:9200] index logs-%{YYYY.MM.dd} # ★ 之前卡的核心点关闭ES8.x默认的数据流否则写不进去 data_stream false } # 控制台输出调试之前就是在这里看到rubydebug日志的 #stdout { codec rubydebug } }注意注释掉 stdout { codec rubydebug } 是为了保障生产性能因为该配置会强制 Logstash 将每一条流经的日志同步打印到控制台在高并发场景下会造成严重的 I/O 瓶颈和 CPU 开销甚至导致日志堆积或进程崩溃它应当仅在排查数据解析异常、验证 Grok 规则或确认字段映射时临时打开作用是让你在不中断数据流的情况下直观地观测日志经过 Filter 处理后的原始数据结构从而快速定位配置错误。开启后你既能在终端前台运行时看到满屏的 JSON 日志也能通过journalctl -u logstash -f在后台实时追踪这些数据。3. JVM内存配置vim /opt/elk/logstash/config/jvm.options # 处理层内存不用太大512M足够 -Xms512m -Xmx512m4. 配置systemd服务cat /usr/lib/systemd/system/logstash.service EOF [Unit] DescriptionLogstash Service Afternetwork.target [Service] Userelk Groupelk # 指定自定义管道配置 ExecStart/opt/elk/logstash/bin/logstash -f /opt/elk/logstash/config/log-pipeline.conf Restartalways RestartSec5 [Install] WantedBymulti-user.target EOF5. 启动验证和查看管道状态systemctl daemon-reload systemctl enable --now logstash ss -tlnp | grep 5044 # 验证5044端口监听 tail -f /opt/elk/logstash/logs/logstash-plain.log # 看启动日志 [rootnode2 ~]# ss -lntup | grep 5044 tcp LISTEN 0 4096 *:5044 *:* users:((java,pid8147,fd122)) [rootnode2 logs]# curl -s http://localhost:9600/_node/stats/pipeline {path:/_node/stats/pipeline,status:404,error:{message:Not Found}}[rootnode2 logs]# curl -s http://localhost:9600/_node/pipelines/main?pretty { host : node2, version : 8.18.8, http_address : 127.0.0.1:9600, id : 841fe993-fccd-46e5-8de5-882e08990e09, name : node2, ephemeral_id : 03c83ae1-95b5-4ca0-bd38-f4227a5c7112, snapshot : false, status : green, pipeline : { workers : 4, batch_size : 125, batch_delay : 50 }, pipelines : { main : { ephemeral_id : 64639abe-9b50-462f-80f5-72452e0bb62c, hash : 822ca5d59d4db87e99ebf8a804dec461707e7a468d632b2ed11cf5d0c5f7bf07, workers : 4, batch_size : 125, batch_delay : 50, config_reload_automatic : false, config_reload_interval : 3000000000, dead_letter_queue_enabled : false } } }[rootnode2 logs]#看logstash是否接受到filebeat的数据[rootnode2 logs]# curl -s http://localhost:9600/_node/stats/events?pretty { host : node2, version : 8.18.8, http_address : 127.0.0.1:9600, id : 841fe993-fccd-46e5-8de5-882e08990e09, name : node2, ephemeral_id : 03c83ae1-95b5-4ca0-bd38-f4227a5c7112, snapshot : false, status : green, pipeline : { workers : 4, batch_size : 125, batch_delay : 50 }, events : { in : 1102, filtered : 1102, out : 1102, duration_in_millis : 4285, queue_push_duration_in_millis : 17 } in 0 且持续增长 → Logstash 确实在源源不断收到数据 in ≈ filtered ≈ out → 数据处理正常没有积压 如果 in 为 0 → 说明 Filebeat 根本没把数据送过来问题在 node3 或网络 例子 events: { in: 293658, // 收到的事件总数 filtered: 293658, // 经过 filter 处理的事件数 out: 293658 // 发送给 output 的事件数 }3.3 node3192.168.24.43Filebeat部署3.3.1 基础部署1. 下载解压su - elk cd /opt/elk wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.18.8-linux-x86_64.tar.gz tar -zxvf filebeat-8.18.8-linux-x86_64.tar.gz ln -s /opt/elk/filebeat-8.18.8 /opt/elk/filebeat exit2. 核心配置/opt/elk/filebeat/filebeat.yml###################### Filebeat inputs ######################### filebeat.inputs: # filestream 是 8.x 推荐的类型相比旧的 log 类型性能更好占用资源更低 - type: filestream enabled: true # 采集路径这里配置了两个目标 # /tmp/test_elk.log 是之前为了排除干扰创建的测试文件权限最松 # /var/log/messages 和 /secure 是正式的系统日志 paths: - /tmp/test_elk.log - /var/log/messages - /var/log/secure # 自定义字段给日志打上一个标记告诉 Logstash “这是 syslog” fields: type: syslog # ★ 关键配置将 fields 提到根级别 # 如果不设此项Logstash 里要用 [fields][type] 才能取到值 # 设了此项Logstash 里直接用 [type] 即可简化了 grok 的条件判断 fields_under_root: true ###################### Output (只留 Logstash) ######################### # ★ 核心点确保只有一个 output output.logstash: # 指向 node2 的 Logstash 地址 # Filebeat 会通过 Beats 协议将数据发送到此端口 hosts: [192.168.24.42:5044] ###################### Setup (全部关闭) ######################### # 关闭索引生命周期管理因为你使用的是自定义的 Logstash 索引名logs-* # 如果不关Filebeat 可能会尝试去连接 ES 管理策略导致冲突 setup.ilm.enabled: false # 关闭 Kibana 自动配置我们不通过 Filebeat 去配置 Kibana 的仪表盘 # 而是由我们在 Kibana 界面手动创建 Index Pattern setup.kibana.enabled: false ###################### Processors ######################### processors: # 添加主机元数据自动把 hostname、IP 地址等信息塞进日志里 # 这样你在 Kibana 里就能看到这条日志来自哪台机器 - add_host_metadata: # 过滤条件如果没有包含 forwarded 标签才执行这个 processor # 防止日志被多次转发时重复添加主机信息 when.not.contains.tags: forwarded ###################### Logging (排错用) ######################### # ★ 排错神器开启 Debug 模式 logging.level: debug # 指定 Debug 的范围只关心输入采集、收割读取文件、发布发送数据 # 不关心内部琐碎逻辑避免日志刷屏 logging.selectors: [input, harvester, publish] # 日志输出到文件而不是 stdout方便持久化查看 logging.to_files: true logging.files: # Filebeat 自己的日志存放路径 path: /opt/elk/filebeat/logs name: filebeat # 保留最近 7 个日志文件防止硬盘爆满 keepfiles: 73. 解决权限问题之前遇到的/var/log/messages读不了的问题# 把elk加入系统日志读取组 usermod -aG adm elk # 修改日志文件权限让elk能读 chmod 640 /var/log/messages /var/log/secure chown root:adm /var/log/messages /var/log/secure -aG是两个参数的组合。 -G修改用户的附加组Supplementary Groups。 -aappend追加极其重要。它表示“在原有附加组的基础上新增一个组”。 如果不加 -a直接执行 -G adm elk会把 elk 用户原本加入的其他附加组如果有的话全部清空只保留 adm 组容易造成事故。 adm是 Linux 系统的一个内置用户组。在 Debian/Ubuntu 和 RHEL/CentOS 系统中/var/log/ 目录下的多数日志文件如 messages、secure的属组通常都是 adm并且权限设置为 640root:adm 可读。4. 配置校验必做避免启动失败sudo -u elk /opt/elk/filebeat/filebeat test config -c /opt/elk/filebeat/filebeat.yml # 输出Config OK才算合格 [rootnode3 ~]# sudo -u elk /opt/elk/filebeat/filebeat test config -c /opt/elk/filebeat/filebeat.yml Config OK [rootnode3 logs]# sudo -u elk /opt/elk/filebeat/filebeat test output -c /opt/elk/filebeat/filebeat.yml logstash: 192.168.24.42:5044... connection... parse host... OK dns lookup... OK addresses: 192.168.24.42 dial up... OK TLS... WARN secure connection disabled talk to server... OK5. 配置systemd服务cat /usr/lib/systemd/system/filebeat.service EOF [Unit] DescriptionFilebeat Log Collector Afternetwork.target [Service] Userelk Groupelk ExecStart/opt/elk/filebeat/filebeat -c /opt/elk/filebeat/filebeat.yml Restartalways RestartSec5 [Install] WantedBymulti-user.target EOF6. 启动验证systemctl daemon-reload systemctl enable --now filebeat systemctl status filebeat # 状态为active (running) # 看Filebeat日志确认没有报错 journalctl -u filebeat -f四、全链路验证4.1 基础服务状态验证# node1验证 systemctl status elasticsearch kibana # node2验证 systemctl status logstash # node3验证 systemctl status filebeat所有服务均为active (running)。4.2 生成测试日志和你之前的操作一致在node3上写入唯一标识的测试日志echo ELK_TEST_$(date %s) /var/log/messages 或者 logger -t ELK_VERIFY CHAIN_OK_$(date %s)以下图片测试语句[rootnode3 logs]# logger -t ELK_FINAL_CHECK IF_YOU_SEE_THIS_IN_KIBANA_IT_IS_100_PERCENT_WORKING_$(date %s)4.3 Logstash侧验证在node2上执行tail -f /opt/elk/logstash/logs/logstash-plain.log4.4 ES侧验证在node1上执行curl -s http://192.168.24.41:9200/_cat/indices?v | grep logs [rootnode1 ~]# curl -s http://192.168.24.41:9200/_cat/indices?v | grep logs green open .internal.alerts-observability.logs.alerts-default-000001 tTry6Fj4RwezJru7i58OqA 1 0 0 0 249b 249b 249b yellow open logs-2026.07.21 4Q87_1qCS7GnsO3UpE1lng 1 1 6944 0 2.8mb 2.8mb 2.8mb yellow open logs-2026.07.22 zODPvn8KRESte0GwCVmOnQ 1 1 3825 0 1.9mb 1.9mb 1.9mb [rootnode1 ~]# logs-2026.07.22 业务日志yellow是单节点正常现象节点一 查询测试日志message自己改一下就行[rootnode1 ~]# curl -s http://192.168.24.41:9200/logs-2026.07.22/_search?pretty -H Content-Type: application/json -d {query:{match:{message:TEST}},size:1} { took : 0, timed_out : false, _shards : { total : 1, successful : 1, skipped : 0, failed : 0 }, hits : { total : { value : 1, relation : eq }, max_score : 12.600115, hits : [ { _index : logs-2026.07.22, _id : 7UcGip8B2Lbiy6X6gLYw, _score : 12.600115, _source : { version : 1, message : TEST_LOG_VIA_SSH: 1784727095, type : syslog, host : { architecture : x86_64, mac : [ 00-0C-29-49-94-58, 16-D7-54-06-48-C9, 3E-9B-46-61-8B-BE, 7A-89-D0-7E-A5-00, C2-28-AC-45-A8-5E, CE-81-17-7C-BF-88, F2-17-96-10-05-C3 ], id : 2007d48c709543b69c75168429fc3c77, hostname : node3, name : node3, os : { platform : rhel, codename : Coughlan, type : linux, version : 10.1 (Coughlan), family : redhat, name : Red Hat Enterprise Linux, kernel : 6.12.0-124.8.1.el10_1.x86_64 }, containerized : false, ip : [ 192.168.24.43, fe80::20c:29ff:fe49:9458, 172.17.0.1, 172.18.0.1, fe80::c028:acff:fe45:a85e, fe80::cc81:17ff:fe7c:bf88, fe80::7889:d0ff:fe7e:a500, fe80::f017:96ff:fe10:5c3, fe80::3c9b:46ff:fe61:8bbe ] }, timestamp : 2026-07-22T13:31:39.572Z, agent : { name : node3, id : 7a74921a-4792-4902-8e08-4550f1a20464, ephemeral_id : b3643330-abb2-4fde-a413-fc9507452bcc, type : filebeat } } } ] } } [rootnode1 ~]#4.5 Kibana侧验证访问http://192.168.24.41:5601打开Kibana左侧Discover时间范围选All time搜索KQL语句即可看到日志。或者左侧日志里面也有详细的内容查询测试日志左侧Discover一、为什么感觉“测试日志诞生得晚”测试时并不能马上查询到以下时间参考可能会更长1. Filebeat 的采集间隔最主要原因Filebeat 不是“文件一变就立刻读”而是有一个扫描周期默认scan_frequency: 10s。它每 10 秒才去检查一次/var/log/messages有没有新内容。你写入日志后最多可能要等 10 秒Filebeat 才会发现文件变了并开始读取。这是设计如此避免高频扫描拖垮磁盘 I/O。2. Logstash 的批处理机制次要原因Logstash 不是“收到一条就立刻转发一条”而是攒批pipeline.batch.size: 125要攒够 125 条才发一批。pipeline.batch.delay: 50最多等 50ms 凑批。如果你只写了一条测试日志Logstash 会等够 125 条或超时后才发给 ES。之前看到 ES 里一次性多了几千条就是因为之前积压的旧日志被批量刷过去了。3. Kibana 的刷新间隔Kibana Discover 页面默认不会自动刷新即使 ES 里已经有新数据你不点刷新按钮或改时间范围它就一直显示旧的查询结果。五.后续操作关掉Filebeat的Debug日志不然会占满磁盘vim /opt/elk/filebeat/filebeat.yml # 把 logging.level: debug 改成 logging.level: info systemctl restart filebeat把Logstash的batch_size改回默认值提高吞吐量vim /opt/elk/logstash/config/pipeline/log-pipeline.conf # 把 batch_size 1 改回 batch_size 125 systemctl restart logstash pipeline.workers: 4 # 默认是CPU核数不用改 pipeline.batch.size: 250 # 默认125日志量大可以翻倍 pipeline.batch.delay: 50 # 默认50ms攒批超时时间Kibana里保存查询模板在Discover页面搜TEST_LOG_VIA_SSH点击右上角「保存」以后直接打开就能看实时日志。扩展采集其他日志比如Nginx/Java/Docker日志只要在node3的filebeat.yml里加对应的paths比如采集Nginx访问日志paths: - /var/log/nginx/access.log - /var/log/nginx/error.log设置索引生命周期避免磁盘爆满在Kibana的Stack Management → Index Lifecycle Policies里给logs-*索引设置自动删除30天前的旧日志。
郑州网站建设
网页设计
企业官网
