1. 这不是“又一个ELK教程”，而是你真正能搭起来的日志管道起点

如果你搜过“ELK 教程 合集-Beats 教程 - 01-基础入门”，大概率已经点开过不下五六个页面，结果发现要么是照搬官方文档的翻译腔，要么是直接甩出一串docker run -d -p 5601:5601 -p 9200:9200 -p 5044:5044 ...命令让你复制粘贴，连端口为什么是5044、Filebeat为什么不能直接写入Elasticsearch、Logstash在中间到底干了什么活儿都懒得解释。更别提那些标题写着“零基础入门”，内容却默认你已经会Linux权限管理、懂YAML缩进规则、知道什么是SSL证书链——这根本不是入门，这是“筛选幸存者”。

我做日志平台落地项目十年，亲手部署过从单机开发环境到上万节点的生产集群，也带过三十多个刚毕业的运维和开发新人。最常听到的一句话是：“老师，我按教程配好了，但Kibana里就是没数据，日志文件明明在那儿，Filebeat进程也在跑，可就是不显示。”问题从来不在命令本身，而在于没人告诉你：Filebeat不是个“搬运工”，它是个带脑子的“质检员+分拣员+快递员”三合一角色；Beats系列也不是ELK的附属品，它是整个日志采集层的现代基础设施底座；而所谓“ELK”，早就不只是Elasticsearch+Logstash+Kibana三个字母的拼凑，它是一套有明确分工、容错设计和演进路径的数据流架构。

这篇内容，就是从你第一次打开终端、敲下curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.17.3-amd64.deb那一刻开始写的。它不假设你会Docker，不预设你有Kubernetes集群，甚至不默认你装好了Java——因为Filebeat本身是Go语言编译的静态二进制，它连glibc都不依赖。我会带你亲手创建一个真实场景：一台Ubuntu 22.04服务器上，运行着一个模拟的Nginx服务，它的access.log每秒产生新行；我们要让Filebeat实时捕获这些日志，打上时间戳、主机名、服务类型等上下文标签，过滤掉健康检查的404请求，再安全地发送给本地运行的Elasticsearch（不走Logstash，先走最简路径），最后在Kibana里看到一条条可搜索、可聚合、可告警的结构化事件。整个过程，所有命令、所有配置项、所有报错信息，我都截过图、复现过、验证过。你不需要背概念，只需要跟着做，做完就能用。这才是真正的“01-基础入门”——不是知识的起点，而是能力的起点。

2. 为什么必须从Beats开始？绕不开的架构逻辑与历史包袱

2.1 ELK不是铁板一块，而是一条有明确分工的数据流水线

很多人把“ELK”当成一个软件包，就像安装Office套件一样一键搞定。这是最大的认知陷阱。真实的日志平台，本质是一条数据流水线（Data Pipeline），它由四个核心环节构成：采集（Ingestion）→ 传输（Transport）→ 处理（Processing）→ 存储与可视化（Storage & Visualization）。ELK这个叫法，其实只覆盖了后三个环节的代表组件，而最关键的“采集”环节，在早期是被严重忽视的。

• Elasticsearch是存储与检索引擎，它擅长快速索引、全文搜索、聚合分析，但它绝不适合直接接收原始日志流。想象一下，如果成百上千台服务器的Nginx日志、Java应用的log4j输出、系统syslog，全部通过HTTP POST直接怼到ES的9200端口，会发生什么？连接数爆炸、内存OOM、索引写入阻塞、甚至整个集群雪崩。ES的设计哲学是“稳、准、快”，不是“大吞吐、高并发、低延迟”的消息队列。

• Logstash是传统处理层，功能极其强大，支持上百种输入/过滤/输出插件，可以做复杂的字段解析、正则匹配、GeoIP查询、数据脱敏。但它也是整个链路中最重的一环：基于JVM，启动慢、内存占用高（默认堆内存1GB起步）、配置语法复杂（Ruby DSL）。在轻量级采集场景下，用Logstash去收Nginx access.log，就像用起重机吊起一颗螺丝钉——能干，但没必要，还费油。

• Kibana是可视化层，它不参与数据流转，只负责把ES里的数据“画”出来。没有前面两环的稳定输入，Kibana就是一座空城。

那么，谁来承担那个“轻、快、稳、准”的第一道关卡？答案就是Beats。它不是Logstash的简化版，而是为现代云原生环境重新设计的专用数据采集器（Specialized Data Shippers）。Elastic公司2015年推出Beats，核心目标就一个：把Logstash从采集前线解放出来，让它专注做复杂的数据清洗和转换，而把“把日志从磁盘搬到网络”这个苦活、累活、高频活，交给更轻量、更可靠、更易管理的专用工具。

2.2 Beats家族不是“Filebeat一个顶俩”，而是各司其职的特种部队

Beats不是一个软件，而是一个开源项目家族，每个成员都是针对特定数据源深度优化的“特种兵”。理解它们的分工，是你避免后续踩坑的第一步：

• Filebeat：主力中的主力，专攻文件日志（File-based Logs）。它不读取整个文件，而是记录每个文件的inode和offset（偏移量），断电重启后能精准续传，绝不会丢日志、也不会重复。它内置了对Nginx、Apache、MySQL、PostgreSQL、Systemd Journal等数十种日志格式的模块（Modules），开箱即用，自动解析出status_code、response_time、user_agent等字段。这不是“解析”，这是“语义理解”。

• Metricbeat：专攻指标（Metrics）。它不碰日志文件，而是直接调用操作系统API（如/proc）、服务端点（如MySQL的SHOW STATUS）、或Prometheus Exporter，以极低开销（CPU<1%，内存<50MB）持续采集CPU、内存、磁盘IO、网络连接数、数据库QPS等指标。它输出的是结构化的时序数据，天然适配ES的@timestamp和metricset.name字段。

• Packetbeat：专攻网络流量（Network Traffic）。它工作在数据链路层，能抓包并深度解析HTTP、DNS、MySQL、Redis、TLS等协议，把一次Web请求的完整生命周期（DNS查询耗时、TCP握手耗时、SSL协商耗时、HTTP响应码、返回体大小）拆解成一条条事件。这玩意儿是排查微服务间调用瓶颈的神器，但需要CAP_NET_RAW权限，生产环境需谨慎。

• Winlogbeat：Windows专属，替代老旧的Event Log Forwarder，直接读取Windows事件日志（Security, Application, System），支持XML解析和字段映射。

• Auditbeat：Linux审计框架（auditd）的搭档，监控文件访问、进程执行、用户登录等安全敏感事件，是SOC团队的刚需。

所以，当你看到标题里写“Beats 教程”，它绝不是在教一个叫“Beats”的软件，而是在教一套面向不同数据源的、标准化的、可组合的采集范式。Filebeat是你的第一个队友，但绝不是唯一队友。今天学会Filebeat的filebeat.inputs配置，明天就能无缝切换到Metricbeat的metricbeat.modules，因为它们共享同一套配置语法、相同的输出机制、统一的监控接口。这种一致性，是Logstash永远无法提供的。

2.3 为什么是“01-基础入门”？从Filebeat切入的不可替代性

选择Filebeat作为Beats系列的第一个学习对象，不是随意的，而是由现实世界的日志生态决定的：

1. 覆盖率最高：90%以上的传统应用、中间件、数据库、系统服务，其日志输出首选仍是写入本地文件。Nginx的access.log、Tomcat的catalina.out、MySQL的error.log、Linux的/var/log/messages……这些都是Filebeat的“主战场”。你学了Filebeat，就掌握了日志采集的“基本盘”。

2. 学习曲线最平缓：Filebeat的核心配置只有三大块：inputs（从哪儿读）、processors（怎么加工）、output（发到哪儿）。没有复杂的Ruby语法，没有插件依赖管理，一个YAML文件搞定所有。它的错误日志极其友好，比如Failed to read file: permission denied，比Logstash的Pipeline aborted due to error直白一百倍。

3. 调试最直观：你可以随时用filebeat test config验证配置语法，用filebeat test output测试ES连接，用filebeat -e -d "publish"开启调试模式，看到它每秒读了多少行、解析出多少字段、发给了哪个ES节点。这种“所见即所得”的反馈，是新手建立信心的关键。

4. 生产就绪度最高：Filebeat是Beats家族中最早发布、使用最广、稳定性验证最充分的成员。它的内存占用常年稳定在20-50MB，CPU峰值不超过5%，支持优雅关闭、信号重载、自动重连、背压控制（当ES写入慢时，它会自动减缓读取速度，而不是疯狂堆积内存）。这些特性，不是“锦上添花”，而是“生死攸关”。

因此，“01-基础入门”选Filebeat，不是因为它最简单，而是因为它最真实、最常用、最能体现Beats设计哲学的核心价值：用最轻的工具，做最确定的事。接下来的所有操作，都将围绕这个原则展开。

3. 实操前的硬核准备：环境、工具与避坑清单

3.1 环境要求：别被“最低配置”忽悠，实测推荐清单

很多教程一上来就说“只需一台4核8G的虚拟机”，听起来很美。但实际部署中，资源不足是导致“Kibana没数据”最隐蔽的元凶。我们来算一笔细账，基于Elasticsearch 8.17.3（当前最新稳定版）的官方要求和我的生产经验：

• Elasticsearch：

  • 内存：官方说“至少4GB”，但这仅指JVM Heap。真实需求 = JVM Heap + OS Page Cache + JVM Metaspace + Native Memory。对于单节点开发/测试，建议分配8GB物理内存，其中JVM Heap设为4GB（-Xms4g -Xmx4g）。Heap超过32GB会触发指针压缩失效，性能反而下降。
  • CPU：2核是底线，4核更稳妥。ES的Lucene索引合并（Merge）是CPU密集型任务，单核容易成为瓶颈。
  • 磁盘：必须使用SSD。HDD在大量小文件随机读写（日志索引的典型负载）下，IOPS可能不到100，而SSD轻松过10000。空间上，预留至少50GB，因为ES会为每个索引保留副本（即使单节点，index.number_of_replicas: 0也要手动设置，否则默认1，空间翻倍）。

• Kibana：

  • 内存：2GB足够，它只是个Node.js前端代理。
  • CPU：1核足矣。
  • 注意：Kibana 8.x强制要求HTTPS，必须配置TLS证书。自签名证书即可，但配置步骤不能跳过。

• Filebeat：

  • 内存：20-50MB，几乎可以忽略。
  • CPU：0.1核，后台静默运行。
  • 磁盘：它自身不占空间，但要确保日志源文件所在分区有足够空间（Filebeat只是读，不删不改）。

提示：如果你用的是VMware或VirtualBox，务必在虚拟机设置里勾选“启用嵌套虚拟化”（如果宿主机是Intel CPU）或“启用AMD-V/RVI”（如果宿主机是AMD CPU）。Elasticsearch 8.x 默认启用xpack.security.enabled: true，它依赖Java的-XX:+UseG1GC垃圾回收器，而某些老版本虚拟化软件会禁用G1GC所需的CPU特性，导致ES启动失败，报错Could not initialize class sun.nio.ch.NativeThread。这个坑，我带过的新人踩了三次才记住。

3.2 工具链安装：拒绝“一键脚本”，手把手掌控每一个环节

我们放弃Docker，选择原生包安装。原因很简单：Docker隐藏了太多底层细节。当你在docker logs filebeat里看到connection refused时，你是该查容器网络，还是该查ES是否监听了0.0.0.0:9200？原生安装，所有路径、端口、权限都暴露在你眼皮底下，debug时少绕十公里。

步骤1：安装Java 17（ES 8.x 强制要求）

# Ubuntu 22.04 自带OpenJDK 11，必须升级 sudo apt update sudo apt install -y openjdk-17-jdk-headless # 验证 java -version # 输出应为 openjdk version "17.0.1" ... # 设置JAVA_HOME（重要！ES启动脚本会读取） echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' | sudo tee -a /etc/profile.d/java.sh source /etc/profile.d/java.sh

步骤2：下载并安装Elasticsearch 8.17.3

# 创建专用用户（安全最佳实践，ES禁止root运行） sudo adduser --system --group --no-create-home --shell /usr/sbin/nologin elasticsearch # 下载（注意：官网下载链接会变，请以elastic.co/downloads/elasticsearch为准） curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.17.3-amd64.deb sudo dpkg -i elasticsearch-8.17.3-amd64.deb # 修改配置 sudo nano /etc/elasticsearch/elasticsearch.yml

关键配置项（请逐行修改，不要复制整段）：

# 1. 网络绑定：必须监听所有接口，否则Filebeat连不上 network.host: 0.0.0.0 # 2. HTTP端口：保持默认9200 http.port: 9200 # 3. 安全认证：8.x默认开启，生成密码 xpack.security.enabled: true # 4. TLS加密：必须开启，否则Kibana无法连接 xpack.security.http.ssl: enabled: true keystore.path: certs/http.p12 # 5. 发现机制：单节点模式，禁用集群发现 discovery.type: single-node # 6. 副本数：单节点必须设为0，否则索引无法分配 index.number_of_replicas: 0

注意：xpack.security.enabled: true开启后，ES首次启动会自动生成一个elastic用户的初始密码，并打印在控制台。你必须立刻复制保存这个密码！它长这样：Please remember to store this password as it will be required to configure Kibana and other Elastic Stack products.如果你错过了，只能删掉/var/lib/elasticsearch目录重装。这是新手最常犯的致命错误。

步骤3：启动ES并获取初始密码

sudo systemctl daemon-reload sudo systemctl enable elasticsearch sudo systemctl start elasticsearch # 查看启动日志，找到密码 sudo journalctl -u elasticsearch -f | grep "password for the elastic user" # 输出类似：Created password for user [elastic] : 1234567890abcdef1234567890abcdef

步骤4：安装Kibana（版本必须与ES严格一致！）

curl -L -O https://artifacts.elastic.co/downloads/kibana/kibana-8.17.3-amd64.deb sudo dpkg -i kibana-8.17.3-amd64.deb sudo nano /etc/kibana/kibana.yml

关键配置：

# 1. Kibana监听地址 server.host: "0.0.0.0" # 2. 连接ES（注意：必须用https，且端口是9200） elasticsearch.hosts: ["https://localhost:9200"] # 3. ES认证凭据（用上一步拿到的elastic密码） elasticsearch.username: "elastic" elasticsearch.password: "1234567890abcdef1234567890abcdef" # 4. Kibana自己的TLS（必须配置，否则浏览器会报不安全） server.ssl.enabled: true server.ssl.certificate: /etc/kibana/certs/kibana.crt server.ssl.key: /etc/kibana/certs/kibana.key # 5. 安全认证（与ES联动） xpack.security.encryptionKey: "a_very_long_and_random_string_here_at_least_32_chars" xpack.encryptedSavedObjects.encryptionKey: "another_very_long_random_string_32_chars"

步骤5：生成TLS证书（Kibana和ES都需要）Elastic官方提供了elasticsearch-certutil工具，但它的交互式流程对新手不友好。我们用一个更可控的方案：

# 进入ES配置目录 cd /usr/share/elasticsearch/ # 生成CA证书（一次生成，供ES和Kibana共用） sudo bin/elasticsearch-certutil ca --out config/certs/elastic-stack-ca.p12 --pass "" # 生成ES的HTTP证书 sudo bin/elasticsearch-certutil http --ca config/certs/elastic-stack-ca.p12 --ca-pass "" --out config/certs/http.p12 --ip 127.0.0.1 --dns localhost # 生成Kibana证书（需单独生成，不能复用ES的） sudo mkdir -p /etc/kibana/certs sudo cp config/certs/http.p12 /etc/kibana/certs/kibana.p12 # 将p12转换为kibana.crt和kibana.key（Kibana需要PEM格式） sudo openssl pkcs12 -in /etc/kibana/certs/kibana.p12 -clcerts -nokeys -out /etc/kibana/certs/kibana.crt sudo openssl pkcs12 -in /etc/kibana/certs/kibana.p12 -nocerts -nodes -out /etc/kibana/certs/kibana.key # 权限修复 sudo chown -R kibana:kibana /etc/kibana/certs sudo chmod 600 /etc/kibana/certs/kibana.key

步骤6：启动Kibana

sudo systemctl daemon-reload sudo systemctl enable kibana sudo systemctl start kibana # 检查状态 sudo systemctl status kibana

此时，你应该能在浏览器访问https://你的服务器IP:5601，输入elastic用户名和初始密码，进入Kibana欢迎页。恭喜，你的ELK后端基石已稳。接下来，才是Filebeat的主场。

4. Filebeat核心配置详解：从filebeat.yml到第一条日志入库

4.1 配置文件骨架：三大支柱，缺一不可

Filebeat的配置文件/etc/filebeat/filebeat.yml，其结构遵循一个黄金法则：Inputs → Processors → Output。任何偏离这个顺序的配置，都会导致行为不可预测。我们逐行拆解一个最小可用配置：

# ============================== Filebeat inputs =============================== filebeat.inputs: - type: filestream # 必须！Filebeat 7.16+废弃了log类型，全面转向filestream enabled: true paths: - /var/log/nginx/access.log # 你要监控的日志路径，支持通配符，如 /var/log/nginx/*.log fields: # 为所有从此input读取的事件添加固定字段 service: nginx environment: production fields_under_root: true # 关键！让fields下的字段直接成为顶级字段，而非嵌套在fields{}里 # tail_files: true # 可选，默认false。设为true表示从文件末尾开始读，适合新日志；false则从头读（用于补录历史日志） # ================================= Processors ================================= processors: - add_host_metadata: # 自动添加主机名、IP、MAC等元数据 when.not.contains.tags: "forwarded" - add_cloud_metadata: ~ # 如果在云环境（AWS/Azure/GCP），自动添加云平台元数据 - add_docker_metadata: ~ # 如果在Docker中运行，自动添加容器ID、镜像名等 - drop_event: # 过滤器：丢弃包含特定字符串的事件 when.regexp: message: "^127\.0\.0\.1 - - \[.*\] \"GET \/healthz HTTP.*\" 200" # 过滤Nginx健康检查日志 - dissect: # 结构化解析：将message字段按分隔符切分成多个字段 tokenizer: "%{clientip} - %{ident} \[%{timestamp}\] \"%{method} %{url} %{protocol}\" %{status} %{size}" field: "message" target_prefix: "" # 解析出的字段直接放在根层级 # ================================== Output =================================== output.elasticsearch: hosts: ["https://localhost:9200"] # ES地址，必须与ES的network.host和http.port匹配 username: "elastic" # ES用户名 password: "1234567890abcdef1234567890abcdef" # ES密码，与ES启动时生成的密码一致 ssl.verification_mode: "none" # 开发环境可设为none，跳过证书校验；生产环境必须用full并配置CA # index: "nginx-access-%{+yyyy.MM.dd}" # 可选：自定义索引名，%{+yyyy.MM.dd}是日期格式化

这个配置看似简单，但每一行背后都有深意：

• type: filestream：这是Filebeat 7.16之后的唯一推荐输入类型。它取代了老旧的log类型，底层使用了更高效的文件监控机制（inotify + polling混合），对日志轮转（logrotate）的支持更好，能准确识别access.log.1.gz这样的归档文件。如果你还在用type: log，说明你参考的教程已经过时两年以上。

• fields和fields_under_root: true：这是实现“多租户日志隔离”的基石。假设你同时监控Nginx和MySQL日志，给Nginx的events加service: nginx，给MySQL的加service: mysql，那么在Kibana里，你就可以用service: nginx精确筛选，或者用service.keyword做聚合统计。fields_under_root: true是关键开关，没有它，所有字段都会被包裹在fields.service里，Kibana的Discover界面就找不到service这个字段了。

• drop_event和dissect：这两个Processor展示了Filebeat的“轻量级ETL”能力。drop_event是过滤（Filter），dissect是解析（Parse）。它们都在Filebeat进程内完成，无需Logstash介入。dissect比正则grok快10倍以上，因为它不做回溯匹配，只做简单的字符串切分。上面的tokenizer，就是把Nginx的127.0.0.1 - - [10/Jan/2024:12:34:56 +0000] "GET /api/users HTTP/1.1" 200 1234，精准切分为clientip,ident,timestamp,method,url,protocol,status,size八个字段。这八个字段，就是你在Kibana里做status: 500筛选、url: "/api/*"聚合、size > 10000告警的全部依据。

4.2 配置验证与调试：让Filebeat自己告诉你哪里错了

永远不要在修改完filebeat.yml后，直接sudo systemctl restart filebeat。必须先做两件事：

第一步：语法验证

sudo filebeat test config # 输出：Config OK 表示YAML语法无误 # 输出：Exiting: error loading config file: error parsing YAML... 表示缩进、冒号、引号有误

YAML对空格极其敏感。一个常见的错误是：

# 错误！processors下面的-前面多了两个空格 processors: - add_host_metadata: ~ # 正确！-必须顶格或与上一级同级缩进 processors: - add_host_metadata: ~

第二步：输出连通性测试

sudo filebeat test output # 输出：Connection test successful! 表示能连上ES，认证通过 # 输出：Error connecting to Elasticsearch: Get "https://localhost:9200": x509: certificate signed by unknown authority 表示SSL证书校验失败，需检查ssl.verification_mode或CA配置

第三步：启动并观察实时日志

# 停止服务，以前台模式运行，看到最详细的日志 sudo systemctl stop filebeat sudo filebeat -e -d "publish" # -e表示输出到stderr，-d "publish"开启publish模块的debug日志

你会看到类似这样的输出：

2024-01-10T12:34:56.789+0000 INFO [monitoring] log/log.go:145 Non-zero metrics in the last 30s {"monitoring": {"metrics": {"beat":{"cpu":{"system":{"ticks":12345,"time":{"ms":12}},"total":{"ticks":67890,"time":{"ms":67},"value":67890},"user":{"ticks":55545,"time":{"ms":55}}},"handles":{"open":12,"open_limit":{"hard":1048576,"soft":1048576}},"info":{"ephemeral_id":"abc123","uptime":{"ms":30000}},"memstats":{"gc_next":12345678,"memory_alloc":9876543,"memory_total":123456789,"rss":23456789},"runtime":{"go_version":"go1.21.5","num_goroutine":23}},"filebeat":{"harvester":{"open_files":1,"running":1}},"libbeat":{"config":{"module":{"running":0}},"output":{"type":"elasticsearch"},"pipeline":{"clients":1,"events":{"active":0}}}}}} 2024-01-10T12:34:56.790+0000 DEBUG [publish] pipeline/processor.go:300 Publish event: { "@timestamp": "2024-01-10T12:34:56.789Z", "@metadata": {"beat":"filebeat","type":"_doc","version":"8.17.3"}, "agent": {"ephemeral_id":"abc123","hostname":"my-server","id":"def456","name":"my-server","type":"filebeat","version":"8.17.3"}, "clientip": "127.0.0.1", "ident": "-", "message": "127.0.0.1 - - [10/Jan/2024:12:34:56 +0000] \"GET /api/users HTTP/1.1\" 200 1234", "method": "GET", "service": "nginx", "status": "200", "url": "/api/users" }

看到Publish event:后面跟着完整的JSON，就证明Filebeat成功读取了一行日志，完成了字段解析，并准备发送给ES。这是你离成功最近的时刻。

4.3 在Kibana中确认数据：从“空白屏幕”到“满屏日志”

Filebeat启动后，数据不会立刻出现在Kibana的Discover界面。因为ES需要时间创建索引、应用mapping（字段映射）。耐心等待1-2分钟，然后按以下步骤操作：

1. 打开Kibana (https://your-ip:5601)，用elastic用户登录。
2. 左侧菜单，点击Stack Management → Index Patterns。
3. 点击Create index pattern。
4. 在Index pattern name框中，输入filebeat-*（Filebeat默认索引名前缀），点击Next step。
5. 在Time field下拉框中，选择@timestamp（这是所有Beats事件的统一时间戳字段），点击Create index pattern。
6. 创建成功后，左侧菜单切换到Discover。
7. 在右上角时间选择器，选择Last 15 minutes。
8. 在搜索框，输入service: nginx，按回车。

如果一切顺利，你应该看到一个表格，每一行代表一条Nginx访问日志，列名包括@timestamp,clientip,method,url,status,service等。点击任意一行右侧的>, 展开详情，你能看到所有被dissect解析出来的字段，以及add_host_metadata添加的host.name、host.ip等。

注意：如果Discover里是空的，请立即检查：

• Filebeat日志里是否有ERR级别的错误？最常见的就是Failed to connect to backoff(elasticsearch(...))，说明ES地址或密码错了。
• 在Kibana的Stack Management → Index Management里，查看filebeat-*索引是否存在？如果不存在，说明Filebeat根本没连上ES。
• 在Kibana的Dev Tools → Console里，执行GET /filebeat-*/_count，看返回的count是否大于0。如果为0，说明数据没进来；如果报错index_not_found_exception，说明索引根本没创建。

5. 常见问题与独家排错技巧：那些教程里永远不会写的坑

5.1 “Kibana里没数据”问题速查表

这个问题占据了我日常答疑的70%。下面这张表，是我根据十年经验总结的、最可能的原因和对应解决方案，按发生概率从高到低排序：

5.2 文件权限：Linux世界里最沉默的杀手

这是新手最容易栽跟头的地方。Filebeat默认以filebeat用户身份运行（Debian/Ubuntu包安装），而Nginx日志通常由root或www-data用户写入，权限