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天前的旧日志。

相关新闻

C++多复数混合运算库实现:类型安全与零开销抽象

C++多复数混合运算库实现:类型安全与零开销抽象

1. 项目概述&#xff1a;为什么我们需要一个多复数混合运算库&#xff1f;在C的日常开发中&#xff0c;尤其是涉及信号处理、图形学、控制系统仿真或物理引擎等领域&#xff0c;复数运算几乎是绕不开的话题。标准库<complex>提供的std::complex模板类固然强大&#xff0c…

2026/7/23 5:09:20阅读更多 →
Godot脚本语言全解析:GDScript、C#与扩展语言选型指南

Godot脚本语言全解析:GDScript、C#与扩展语言选型指南

1. 项目概述&#xff1a;为什么需要一份Godot脚本语言对比指南&#xff1f;如果你刚开始接触Godot引擎&#xff0c;或者从Unity、Cocos等引擎转过来&#xff0c;面对Godot的脚本语言选择&#xff0c;大概率会有点懵。GDScript、C#、VisualScript&#xff0c;甚至还能用C和第三方…

2026/7/23 5:09:20阅读更多 →
VC++获取Windows系统路径:从API演进到实战源码解析

VC++获取Windows系统路径:从API演进到实战源码解析

1. 项目概述&#xff1a;为什么获取系统路径是VC开发者的基本功在Windows平台下进行VC开发&#xff0c;无论是开发桌面应用、系统工具还是游戏&#xff0c;有一个场景几乎无法避免&#xff1a;你需要知道系统把那些关键的文件和目录放在哪里了。是用户的文档文件夹&#xff1f;…

2026/7/23 5:09:20阅读更多 →
【免费赠书活动】吃透大模型底层数学,从公式原理到产业实战,打通AI进阶全链路

【免费赠书活动】吃透大模型底层数学,从公式原理到产业实战,打通AI进阶全链路

人工智能大模型数学基础从数学公式到智能模型&#xff0c;打通AI底层逻辑——线性代数、微积分、概率与统计三大支柱&#xff0c;结合BERT、GPT、Stable Diffusion等前沿实战&#xff0c;带你从理论推导到代码落地&#xff0c;真正掌握大模型的数学引擎。本书特点基础→进阶→A…

2026/7/23 21:51:35阅读更多 →
TVA驱动的具身智能迭代逻辑(3)

TVA驱动的具身智能迭代逻辑(3)

前沿技术探索&#xff1a;AI智能体视觉&#xff08;TVA&#xff0c;Transformer-based Vision Agent&#xff09;是依托Transformer架构与“因式智能体”理论所构建的颠覆性工业视觉技术&#xff0c;是集深度强化学习&#xff08;DRL&#xff09;、卷积神经网络&#xff08;CNN…

2026/7/23 21:51:35阅读更多 →
AI大模型与数学 第7课:复合函数求导、链式法则(AI梯度反向传播核心)

AI大模型与数学 第7课:复合函数求导、链式法则(AI梯度反向传播核心)

本课是整系列最重要一课&#xff01; 前面所有课程都是“铺垫”&#xff0c;从本课开始&#xff0c;你彻底看懂神经网络、看懂GPT训练原理。 我们生活中面临的事情不是一件&#xff0c;我们今天的生活也是过往众多的选择&#xff0c;众多事情的叠加&#xff0c;一件事情的成功与…

2026/7/23 21:51:35阅读更多 →
TVA驱动的具身智能迭代逻辑(4)

TVA驱动的具身智能迭代逻辑(4)

前沿技术探索&#xff1a;AI智能体视觉&#xff08;TVA&#xff0c;Transformer-based Vision Agent&#xff09;是依托Transformer架构与“因式智能体”理论所构建的颠覆性工业视觉技术&#xff0c;是集深度强化学习&#xff08;DRL&#xff09;、卷积神经网络&#xff08;CNN…

2026/7/23 21:51:35阅读更多 →
CNAS认证测试报告:软件企业质量信任的基石

CNAS认证测试报告:软件企业质量信任的基石

在软件项目交付、招投标、验收、上架、融资尽调和政企采购中&#xff0c;一份测试报告常常不只是“技术附件”。它会影响客户是否信任产品&#xff0c;也会影响企业是否能顺利完成交付。对软件企业来说&#xff0c;引用CNAS认证的软件测试报告&#xff0c;核心价值在于用更被认…

2026/7/23 21:51:35阅读更多 →
企业AI内容中台建设白皮书(含GPT-4o/DeepSeek-V3双模型适配方案):已验证于17个垂直行业

企业AI内容中台建设白皮书(含GPT-4o/DeepSeek-V3双模型适配方案):已验证于17个垂直行业

更多请点击&#xff1a; https://kaifayun.com 第一章&#xff1a;AI 自动化内容生产 AI 自动化内容生产正重塑数字内容的创作范式&#xff0c;从新闻摘要、技术文档生成到营销文案批量输出&#xff0c;大语言模型&#xff08;LLM&#xff09;已具备端到端的内容理解、结构化重…

2026/7/23 21:49:35阅读更多 →
Go语言静态资源打包方案对比与实践指南

Go语言静态资源打包方案对比与实践指南

1. 项目背景与核心需求在Go语言开发中&#xff0c;我们经常需要处理静态资源文件的打包问题。无论是Web应用的模板文件、前端资源&#xff0c;还是配置文件、证书等&#xff0c;都需要随程序一起分发。传统做法是将这些文件与编译后的二进制文件放在同一目录下&#xff0c;但这…

2026/7/23 0:56:31阅读更多 →
Go语言实现高性能LDAP认证服务的架构与实践

Go语言实现高性能LDAP认证服务的架构与实践

1. 项目背景与核心价值LDAP&#xff08;轻量级目录访问协议&#xff09;作为企业级身份认证的黄金标准&#xff0c;已经服务了超过80%的财富500强公司。我在金融科技领域实施统一认证体系时&#xff0c;发现传统Java方案存在启动慢、内存占用高等痛点。而Go语言凭借其协程并发模…

2026/7/23 0:56:31阅读更多 →
【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

更多请点击&#xff1a; https://intelliparadigm.com 第一章&#xff1a;AI面试官实战指南的核心价值与适用场景 AI面试官并非替代人类HR的“黑箱工具”&#xff0c;而是以可解释、可审计、可迭代的方式&#xff0c;赋能招聘全链路的关键基础设施。其核心价值在于将主观经验沉…

2026/7/23 0:56:31阅读更多 →
Chitchatter完整指南:免费开源的终极点对点安全聊天工具

Chitchatter完整指南:免费开源的终极点对点安全聊天工具

Chitchatter完整指南&#xff1a;免费开源的终极点对点安全聊天工具 【免费下载链接】chitchatter Secure peer-to-peer chat that is serverless, decentralized, and ephemeral 项目地址: https://gitcode.com/gh_mirrors/ch/chitchatter Chitchatter是一款革命性的安…

2026/7/23 0:00:28阅读更多 →
从单点好评到指数级传播:AI副业主理人必须掌握的4层口碑渗透模型(含ROI测算表)

从单点好评到指数级传播:AI副业主理人必须掌握的4层口碑渗透模型(含ROI测算表)

更多请点击&#xff1a; https://intelliparadigm.com 第一章&#xff1a;从单点好评到指数级传播&#xff1a;AI副业主理人必须掌握的4层口碑渗透模型&#xff08;含ROI测算表&#xff09; 当AI副业主理人不再仅满足于单次服务交付&#xff0c;而是主动构建可复用、可裂变、可…

2026/7/23 0:00:28阅读更多 →
油泥处理设备哪里能买到

油泥处理设备哪里能买到

油泥处理设备哪里有&#xff1f;这是许多从事油田、炼化、清罐业务的从业者最关心的问题。根据河南三丰环保设备有限公司的行业经验&#xff0c;选购油泥处理设备的核心在于设备能否适配当地环保法规与原料特性&#xff0c;而非单纯看价格。该公司总经理王钦田先生指出&#xf…

2026/7/23 0:00:28阅读更多 →
YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

如果你在部署 YOLOv8 时&#xff0c;发现推理速度只有可怜的 1-2 FPS&#xff0c;而别人的演示视频却能跑到 30 FPS 以上&#xff0c;那么问题很可能不在模型本身&#xff0c;而在于你的整个处理链路。很多开发者拿到一个训练好的 YOLOv8 模型后&#xff0c;会直接使用官方示例…

2026/7/22 22:56:18阅读更多 →
Coze与Dify对比指南:低代码AI应用开发从入门到实战

Coze与Dify对比指南:低代码AI应用开发从入门到实战

1. 从零到一&#xff1a;为什么你需要了解 Coze 和 Dify&#xff1f;如果你对 AI 应用开发感兴趣&#xff0c;但一看到“大模型”、“智能体”、“工作流”这些词就头疼&#xff0c;觉得门槛太高&#xff0c;那这篇文章就是为你准备的。很多开发者&#xff0c;包括我自己&#…

2026/7/23 18:58:18阅读更多 →
AI生图工具怎么选?2026年6月版实测对比

AI生图工具怎么选?2026年6月版实测对比

做自媒体的朋友应该都有体会&#xff1a;配图一直是个让人头疼的问题。2026年&#xff0c;AI生图工具已经非常成熟了&#xff0c;但工具太多反而不知道怎么选。以下是截至2026年6月我对主流AI生图工具的实测对比。Midjourney V8.1&#xff1a;速度之王2026年6月11日&#xff0c…

2026/7/23 18:58:18阅读更多 →