1. 项目概述为什么我们需要Filebeat如果你负责过线上系统的运维或者开发过需要追踪用户行为的应用肯定对“查日志”这件事又爱又恨。爱的是当系统出现一个诡异的Bug或者用户反馈某个功能不可用时日志往往是唯一能告诉你“当时发生了什么”的线索。恨的是日志文件通常散落在各个服务器上动辄几个G用grep、tail -f手工排查效率低下不说还容易遗漏关键信息。这就是日志收集工具存在的意义。而Filebeat作为Elastic Stack过去常叫ELK Stack中负责“搬运工”角色的轻量级代理它专门解决的就是“如何高效、可靠地把分散的日志文件数据统一收集并发送到中心化系统如Elasticsearch或Logstash进行后续分析”这个核心问题。简单来说它就像一个不知疲倦的快递员持续监控你指定的文件夹一旦有新的日志行“到货”就立刻打包发走。你可能会问类似的工具还有Logstash、Fluentd为什么是Filebeat关键在于它的**“轻量”与“专注”**。Filebeat用Go语言编写几乎不消耗系统资源它只专心做好一件事读取文件并转发。更复杂的过滤、解析、转换可以交给后端的Logstash或直接在Elasticsearch中用Ingest Node处理。这种架构使得它在生产环境中部署成千上万个实例时对主机性能的影响微乎其微稳定性极高。在接下来的内容里我会以一个多年运维的角度带你从零开始彻底搞懂Filebeat。不仅仅是下载、启动这些基础操作更重要的是理解其核心工作机制、如何针对不同日志类型进行高效配置以及如何利用“模块”功能快速接入常见服务。这些经验能让你在构建日志平台时少走很多弯路。2. Filebeat核心架构与工作原理解析要玩转一个工具不能只停留在“怎么用”还得明白它“为什么这么设计”。理解了Filebeat的内部机制你才能在各种复杂场景下做出正确的配置和排错。2.1 两大核心组件Harvester与InputFilebeat的工作流程可以想象成一个现代化的物流仓库系统其中两个核心角色至关重要Harvester收割器这是最前线的“搬运工”。每个Harvester负责一个文件。它的工作很简单打开文件从文件末尾或指定位置开始逐行读取内容然后将读取到的行发送到下游的“集散中心”。一个文件同一时间只能由一个Harvester处理。如果文件被删除或重命名对应的Harvester会关闭。Input输入Input是“仓库管理员”。它负责管理一组Harvester监控你配置的文件路径比如/var/log/*.log。Input会根据你定义的规则通配符去发现新的文件并为每个匹配到的文件启动一个Harvester。同时Input还负责处理一些全局策略比如当文件长时间没有新内容时是否要关闭Harvester以节省资源。它们如何协作当你启动Filebeat并配置了一个指向/var/log/nginx/access.log的输入后Filebeat会创建一个log类型的Input。这个Input会启动一个Harvester来跟踪这个文件。Harvester从上次读取的位置记录在一个叫registry的文件里开始读取新的日志行。读取到的每一行日志在内部会被封装成一个event事件对象这个对象除了日志内容本身还会被自动添加许多有用的元数据例如timestamp: 事件被收集的时间。host.name: 收集日志的主机名。log.file.path: 日志文件的完整路径。message: 原始的日志行内容。这些元数据对于后续在Kibana中进行筛选、聚合、可视化至关重要。2.2 关键机制至少一次送达保证与背压感知这是Filebeat在生产环境中可靠性的基石很多新手会在这里踩坑。至少一次送达保证At-Least-Once DeliveryFilebeat必须确保每一条日志事件都被成功发送到配置的输出端如Elasticsearch。它是如何做到的秘密就在于registry文件。这个文件默认位于数据目录如/var/lib/filebeat/registry它记录了每个被监控文件的唯一标识符inode和Harvester最后读取到的字节偏移量offset。工作流程Harvester读取一行日志 - 将该行日志事件发送到内部队列 - Filebeat从队列取出事件尝试发送到输出端如Elasticsearch- 如果Elasticsearch返回成功确认ACKFilebeat才会更新registry文件中该文件的偏移量。故障恢复如果Filebeat进程意外崩溃或者服务器重启当Filebeat再次启动时它会读取registry文件找到每个文件上次成功发送的位置然后从这个位置之后开始读取。这就保证了即使发生中断也不会丢失数据但有可能导致少量数据被重复发送因为最后一批发送成功但未及时更新registry的数据会被重新读取。这就是“至少一次”的含义。背压感知Backpressure-sensitive如果后端系统如Logstash或Elasticsearch处理速度跟不上Filebeat的发送速度怎么办Filebeat不会无脑地拼命发送导致后端雪崩。它的内部队列默认为内存队列有大小限制。当队列快满时Filebeat会感知到“背压”并主动降低Harvester的读取速度直到后端处理能力恢复。这是一种非常优雅的流量控制机制保障了整个日志管道的稳定性。实操心得registry文件极其重要在容器化部署时一定要将其持久化到Volume中否则容器重启后Filebeat会从头读取所有日志文件造成海量数据重复。同时定期清理或归档不再监控的日志文件的registry记录可以防止registry文件无限膨胀。3. 从零开始Filebeat的下载、安装与启动理论清楚了我们动手把它跑起来。这里以最常见的Linux系统为例Windows和macOS的步骤类似主要区别在于安装包和路径。3.1 下载与安装官方推荐使用APT或YUM仓库安装便于后续升级和管理。这里演示Debian/Ubuntu系和RHEL/CentOS系的安装方法。方法一使用APT仓库安装Debian/Ubuntu# 1. 导入Elastic的GPG密钥用于验证软件包 wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elastic-keyring.gpg # 2. 添加Elastic仓库到系统源列表 echo deb [signed-by/usr/share/keyrings/elastic-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main | sudo tee -a /etc/apt/sources.list.d/elastic-8.x.list # 3. 更新仓库缓存并安装Filebeat sudo apt-get update sudo apt-get install filebeat方法二使用YUM仓库安装RHEL/CentOS/Rocky/AlmaLinux# 1. 导入Elastic的GPG密钥 sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch # 2. 在/etc/yum.repos.d/目录下创建elasticbeat.repo文件 sudo tee /etc/yum.repos.d/elasticbeat.repo EOF [elastic-8.x] nameElastic repository for 8.x packages baseurlhttps://artifacts.elastic.co/packages/8.x/yum gpgcheck1 gpgkeyhttps://artifacts.elastic.co/GPG-KEY-elasticsearch enabled1 autorefresh1 typerpm-md EOF # 3. 安装Filebeat sudo yum install filebeat方法三直接下载压缩包如果你无法使用包管理器或者需要在无网络环境部署可以直接下载对应平台的tar.gz或zip包。# 以Linux 64位系统为例 wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.11.0-linux-x86_64.tar.gz tar -xzf filebeat-8.11.0-linux-x86_64.tar.gz cd filebeat-8.11.0-linux-x86_64/这种方式更灵活但需要手动管理服务启动和更新。注意事项生产环境强烈建议使用包管理器安装并锁定主要版本如8.x避免自动升级到不兼容的大版本。直接下载压缩包的方式更适合临时测试或CI/CD流水线中的容器镜像构建。3.2 核心配置文件详解filebeat.yml安装完成后配置文件通常位于/etc/filebeat/filebeat.yml。这是Filebeat的大脑所有行为都由它控制。我们拆解其中最关键的几个部分。# Filebeat inputs filebeat.inputs: - type: filestream enabled: false paths: - /var/log/*.logfilebeat.inputs: 这是定义日志输入的地方。例子中默认使用filestream类型7.x版本后推荐比旧的log类型更强大但被禁用了。paths支持通配符和Glob模式。关键配置encoding文件编码处理中文日志常用utf-8或gb18030、exclude_lines/include_lines用正则过滤行、multiline处理跨多行的异常堆栈日志。# Filebeat modules filebeat.config.modules: path: ${path.config}/modules.d/*.yml reload.enabled: false这是模块的配置加载路径。modules.d目录下的所有.yml文件都会被读取。reload.enabled如果设为trueFilebeat会动态重载模块配置无需重启。# Outputs #output.elasticsearch: #hosts: [localhost:9200] #username: elastic #password: changeme output.logstash: hosts: [localhost:5044]输出配置这是必须修改的部分Filebeat支持多种输出。最常见的是直接输出到Elasticsearch或者输出到Logstash进行更丰富的处理。如果直连Elasticsearch且开启了安全认证8.x默认开启必须配置username和password。如果使用API Key则配置api_key。输出到Logstash是更常见的生产架构因为Logstash可以做数据清洗、富化、转换减轻Elasticsearch负担。此时Filebeat使用Lumberjack协议也叫Beats协议与Logstash通信需要在Logstash侧配置对应的beats输入插件。# Processors processors: - add_host_metadata: when.not.contains.tags: forwarded - add_cloud_metadata: ~ - add_docker_metadata: ~ - add_kubernetes_metadata: ~处理器在事件发送前可以对其进行加工。例如add_host_metadata会自动添加主机名、IP、操作系统等信息。这些处理器非常有用可以根据环境按需启用或禁用。3.3 启动、停止与状态检查使用systemd管理服务是最规范的方式。# 启动Filebeat服务 sudo systemctl start filebeat # 设置开机自启 sudo systemctl enable filebeat # 查看服务状态 sudo systemctl status filebeat # 查看详细运行日志对于排错非常有用 sudo journalctl -u filebeat -f如果是直接下载的压缩包可以使用以下方式前台运行方便调试./filebeat -e -c filebeat.yml-e: 输出日志到标准错误输出stderr而不是系统日志。-c: 指定配置文件路径。首次启动前一个非常重要的步骤是测试配置文件语法和输出连接# 测试配置文件语法是否正确 sudo filebeat test config -c /etc/filebeat/filebeat.yml # 测试输出如Elasticsearch或Logstash连接是否正常 sudo filebeat test output -c /etc/filebeat/filebeat.yml这两个命令能帮你提前发现大部分配置错误避免服务启动后无声无息地失败。4. 实战配置自定义日志读取与解析现在我们来配置Filebeat收集一个真实的日志文件。假设我们有一个Spring Boot应用日志输出到/opt/myapp/logs/application.log。4.1 基础输入配置首先在filebeat.inputs部分启用并配置一个输入filebeat.inputs: - type: filestream id: my-springboot-app # 给这个输入一个唯一ID用于在registry中标识 enabled: true paths: - /opt/myapp/logs/application*.log # 支持通配符匹配滚动日志 fields: app_name: order-service # 添加自定义字段便于后续区分 log_type: application fields_under_root: true # 将自定义字段提升到事件根级别方便检索 encoding: utf-84.2 处理多行日志Java异常堆栈Java应用的异常堆栈信息是多行的但逻辑上属于一个事件。如果不处理Filebeat会把每一行当作独立事件发送破坏可读性。multiline配置就是用来解决这个问题的。multiline: pattern: ^\d{4}-\d{2}-\d{2} # 匹配新日志行的开始模式例如以日期开头 negate: true # 如果匹配成功是否视为新事件的开始true表示“是” match: after # 不匹配pattern的行即堆栈信息归属于上一行 max_lines: 500 # 最多合并多少行防止内存溢出 timeout: 5s # 多行事件组装的最大等待时间配置解读这个配置的意思是凡是不以日期时间开头的行negate: true都把它合并到前一行之后match: after。这样一个异常信息连同其堆栈就会被合并成一个完整的事件。4.3 使用Processors进行数据富化我们可以在Filebeat端就做一些简单的处理比如解析日志级别、添加地理位置等。processors: - add_host_metadata: # 添加主机信息 netinfo.enabled: true # 包含网络接口信息 - dissect: # 使用dissect解析结构化的日志行比grok性能更高 tokenizer: “[%{timestamp}] %{level} %{pid} --- [%{thread}] %{class} : %{message}” field: “message” target_prefix: “” # 解析后的字段直接放在事件根目录 - if: contains: level: “ERROR” then: - add_fields: target: ‘’ fields: alert: true else: - add_fields: target: ‘’ fields: alert: false这个处理器链做了三件事1. 添加主机元数据2. 用dissect解析日志格式假设日志格式固定3. 如果日志级别是ERROR则添加一个alert: true的标记字段。4.4 输出到Logstash的完整配置示例一个更贴近生产环境的配置将数据发送到Logstash并启用SSL加密传输。filebeat.inputs: - type: filestream id: app-log enabled: true paths: - /opt/myapp/logs/*.log multiline: { ... } # 参考上面的多行配置 fields: {app: ‘myapp’, env: ‘prod’} fields_under_root: true output.logstash: hosts: [“logstash-prod:5044”] ssl.certificate_authorities: [“/etc/filebeat/certs/ca.crt”] # CA证书 ssl.certificate: “/etc/filebeat/certs/client.crt” # 客户端证书 ssl.key: “/etc/filebeat/certs/client.key” # 客户端私钥 loadbalance: true # 如果配置了多个hosts启用负载均衡 processors: - add_host_metadata: - drop_event: # 可以丢弃一些不需要的事件比如健康检查日志 when: contains: message: “GET /health”对应的Logstash配置片段 (pipelines.yml或conf.d/下的文件)input { beats { port 5044 ssl true ssl_certificate_authorities [“/etc/logstash/certs/ca.crt”] ssl_certificate “/etc/logstash/certs/server.crt” ssl_key “/etc/logstash/certs/server.key” ssl_verify_mode “force_peer” # 强制验证客户端证书 } } filter { # 在这里进行更复杂的解析比如grok、mutate、geoip等 grok { match { “message” “%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{DATA:message}” } } date { match [“timestamp”, “ISO8601”] target “timestamp” } } output { elasticsearch { hosts [“http://es-node:9200”] index “filebeat-%{[fields.app]}-%{YYYY.MM.dd}” user “logstash_writer” password “${ES_PASSWORD}” } }5. 效率利器Filebeat模块的配置与使用Filebeat的“模块”功能是其最大的亮点之一。它针对MySQL、Nginx、Redis、Apache等数十种常见的服务和系统提供了开箱即用的配置。一个模块通常包含Filebeat输入配置预定义的paths、multiline规则等。Elasticsearch Ingest Pipeline用于解析和结构化原始日志的管道定义。Kibana仪表盘预制的可视化图表让你立刻能看到关键指标。5.1 模块的启用与禁用模块配置文件位于/etc/filebeat/modules.d/目录下。所有模块默认都以.disabled后缀禁用。# 查看所有可用模块 sudo filebeat modules list # 启用Nginx模块 sudo filebeat modules enable nginx # 启用MySQL模块 sudo filebeat modules enable mysql # 禁用某个模块 sudo filebeat modules disable nginx启用模块后/etc/filebeat/modules.d/nginx.yml.disabled会重命名为nginx.yml。5.2 配置一个模块以Nginx为例启用模块后你需要编辑其配置文件告诉Filebeat你的日志在哪里。sudo vim /etc/filebeat/modules.d/nginx.yml典型的配置内容如下你需要修改var.paths指向你实际的Nginx日志路径- module: nginx # Access logs access: enabled: true var.paths: [“/var/log/nginx/access.log*”] # 修改为你的路径 # Error logs error: enabled: true var.paths: [“/var/log/nginx/error.log*”]模块可能提供多个“文件集”fileset比如Nginx有access和error。你可以分别配置。5.3 运行模块并加载仪表盘配置好后需要将模块的资产Ingest Pipeline和Kibana仪表盘推送到Elasticsearch和Kibana。# 1. 初始化设置只需要运行一次或模块更新后运行 # 这会将pipeline和仪表板模板加载到Elasticsearch和Kibana sudo filebeat setup # 2. 如果你只想为特定模块加载仪表板可以使用--modules参数 sudo filebeat setup --modules nginx,mysql # 3. 重启Filebeat服务使模块配置生效 sudo systemctl restart filebeat执行filebeat setup后在Kibana的“Dashboard”页面你就能搜索到“Nginx access and error logs [Filebeat Nginx] ECS”等预制的仪表盘直接使用。5.4 模块的进阶使用与自定义模块的默认解析规则Ingest Pipeline可能不完全符合你的日志格式。例如你的Nginx访问日志可能使用了自定义的log_format。这时你可以覆盖模块的默认pipeline。查找默认pipeline在Filebeat安装目录的module/nginx/access/ingest/pipeline.json可以找到默认的pipeline定义。自定义pipeline在Elasticsearch中创建或修改一个名为filebeat-8.11.0-nginx-access-pipeline版本号可能不同的Ingest Pipeline。你可以通过Kibana的“Stack Management” - “Ingest Pipelines”界面来操作复制默认的然后修改其中的grok或dissect模式来匹配你的日志格式。让Filebeat使用自定义pipeline在nginx.yml中可以通过pipeline参数指定自定义的pipeline ID。但更常见的做法是在Logstash的filter中做解析或者在Elasticsearch索引生命周期策略中应用自定义pipeline。踩坑记录模块的仪表板依赖于ECSElastic Common Schema字段命名规范。如果你在自定义pipeline或Logstash filter中重命名字段例如把source.ip改成了client_ip可能会导致仪表板无法正常显示数据。最佳实践是尽量遵循ECS规范来定义字段名。6. 生产环境部署与性能调优指南在单台服务器上跑通Filebeat只是第一步。在生产环境中我们可能需要在成千上万的服务器、容器上部署这就需要考虑架构、资源和稳定性。6.1 部署模式选择每主机部署Sidecar模式在每台需要收集日志的物理机或虚拟机上安装一个Filebeat实例。这是最传统、最直接的方式资源消耗小配置独立。容器Sidecar模式在Kubernetes中可以为每个Pod部署一个Filebeat容器作为Sidecar专门收集该Pod内容器的日志并共享日志Volume。这种方式隔离性好但会略微增加资源开销。DaemonSet模式在Kubernetes集群中通过DaemonSet在每个Node节点上部署一个Filebeat Pod。这个Filebeat实例负责收集该Node上所有Pod的日志通常需要挂载主机的/var/log目录或容器运行时日志目录。这是K8s环境下最主流、最高效的日志收集方案。6.2 关键性能调优参数配置文件filebeat.yml中的以下参数对性能影响很大需要根据数据量调整。# 在内存中队列的大小用于缓冲尚未发送的事件。 queue.mem: events: 4096 # 队列可存储的事件数。增大此值可以应对突发流量但会增加内存使用。 flush.min_events: 2048 # 当队列中事件数达到此值时会触发批量发送。 flush.timeout: 1s # 即使未达到flush.min_events超过此时间也会触发发送。 # 输出配置中的批量发送参数 output.elasticsearch: # 或 output.logstash bulk_max_size: 50 # 每批发送的最大事件数。Elasticsearch建议在50-500之间需要测试。 worker: 4 # 用于发送事件的并发工作线程数。增加线程数可以提高吞吐但会增加CPU和网络连接数。 compression_level: 3 # 网络传输压缩级别 (0-9)。3-4是较好的权衡点能显著减少带宽CPU开销可接受。 # Filebeat自身资源限制 max_procs: 2 # 限制Filebeat可使用的CPU核心数。在容器环境中应配合K8s的requests/limits设置。调优建议监控Filebeat的memqueue使用情况可通过Filebeat监控API或Metricbeat获取。如果队列经常满说明后端处理能力不足或网络有瓶颈需要增加queue.mem.events并检查bulk_max_size和worker配置是否合理。同时观察主机内存确保events * 平均事件大小不会耗尽内存。6.3 监控Filebeat自身健康状态Filebeat提供了内置的HTTP端点用于监控在配置文件中启用http.enabled: true http.port: 5066 http.host: localhost然后可以通过curl http://localhost:5066/stats获取详细的运行时统计信息包括队列深度、发送成功/失败次数、各输入采集的文件状态等。这些数据可以方便地集成到Prometheus等监控系统中。6.4 资源限制与高可用考量资源限制在容器中运行务必设置CPU和内存的requests/limits。一个典型的Filebeat容器内存限制可设为100-200MiCPU限制0.2-0.5核。高可用Filebeat本身是无状态的状态保存在registry文件。高可用主要针对其输出端。输出到Logstash在output.logstash.hosts中配置多个Logstash节点地址并启用loadbalance: trueFilebeat会自动在节点间做负载均衡。某个节点故障会自动切换到其他节点。输出到Elasticsearch同样在output.elasticsearch.hosts中配置Elasticsearch集群的多个节点地址。Filebeat会自动处理节点的发现和故障转移。Registry文件管理定期检查registry文件大小。对于已经不再收集的旧日志文件其registry记录不会自动删除。可以编写一个定时任务定期清理长时间未修改的日志文件对应的registry条目需谨慎操作或直接按时间备份并清理整个registry文件Filebeat会从文件当前偏移量重新读取可能造成少量重复。7. 常见问题排查与实战技巧实录即使配置再仔细在生产环境中也难免遇到问题。这里记录几个我踩过的坑和对应的排查思路。7.1 Filebeat启动了但Kibana里看不到数据这是最常见的问题。请按照以下链条逐一排查检查Filebeat服务状态sudo systemctl status filebeat。确保状态是active (running)。检查Filebeat日志sudo journalctl -u filebeat -n 50 -f。这是最直接的排错入口任何配置错误、连接失败都会在这里体现。重点关注ERROR和WARN级别的日志。检查输入是否生效运行sudo filebeat test config和sudo filebeat test output。确保配置语法和输出连接都正常。检查Registry文件查看/var/lib/filebeat/registry默认路径的内容。确认你配置的日志文件路径是否被正确记录以及offset偏移量是否在增长。如果offset一直为0说明Filebeat没有读取到数据可能是文件权限问题或者paths配置有误。检查文件权限Filebeat进程通常是filebeat用户或root必须有权限读取你配置的日志文件。使用ls -l /path/to/your.log检查。检查输出端如果输出到Elasticsearch去Elasticsearch上查看是否有新索引创建。例如curl -u elastic:password ‘localhost:9200/_cat/indices?v | grep filebeat。如果输出到Logstash检查Logstash服务是否运行5044端口是否监听以及Logstash自身的日志是否有错误。检查Elasticsearch索引模板Filebeat在第一次启动时会尝试向Elasticsearch发送索引模板。如果网络或权限问题导致失败后续的数据可能因为映射错误而被拒绝。可以手动执行sudo filebeat setup --index-management来重新加载模板。7.2 日志重复发送这个问题几乎都和registry文件有关。场景一Filebeat非正常关闭如kill -9导致最后一批已发送的数据未来得及更新registry偏移量。重启后Filebeat会从旧的偏移量重新发送。这是“至少一次”语义的副作用通常可以接受。可以通过调小queue.flush.timeout和bulk_max_size来减少重复的数据量但无法根除。场景二在容器中运行Filebeat但registry文件未做持久化。容器重启后registry文件丢失Filebeat会从头读取所有日志文件。解决方案必须将registry文件路径挂载到宿主机或持久化Volume上。场景三同一个日志文件被多个Filebeat实例监控错误配置导致。确保你的paths配置没有重叠并且没有重复部署。7.3 如何处理日志文件轮转Rotate这是Filebeat的强项它天然支持日志轮转。无论是使用logrotate工具还是应用自身触发的重命名如application.log-application.log.2023-10-01Filebeat都能正确处理。其原理是Filebeat通过文件的inode和路径来唯一标识一个文件。当日志轮转发生时旧文件被重命名但inode不变Filebeat会继续读取直到文件被关闭如copytruncate模式。同时它会发现并开始读取新创建的、具有相同路径的新文件新inode。注意事项避免使用copytruncate模式进行日志轮转因为这可能导致日志丢失在复制和清空文件的瞬间新日志可能被写入清空后的文件而Filebeat可能还在读取旧副本。推荐使用create模式重命名旧文件创建新文件。7.4 CPU或内存使用过高CPU高通常是因为处理processors过于复杂或者multiline配置的正则pattern性能很差。优化正则表达式或者考虑将复杂的解析移到后端的Logstash或Elasticsearch Ingest Pipeline中执行。也可以使用dissect处理器替代grok前者性能高得多。内存高检查queue.mem.events是否设置过大。每个事件都会占用内存。估算公式内存占用 ≈ 队列中的事件数 × 平均事件大小。降低queue.mem.events和bulk_max_size可以控制内存使用。另外如果监控了非常多的小文件每个文件的Harvester也会占用少量内存。7.5 模块仪表板显示“No results found”原因一数据字段与仪表板不匹配。模块仪表板严格依赖ECS字段名。使用filebeat setup加载的默认pipeline会创建正确的字段。如果你自定义了解析请确保关键字段如source.iphttp.response.status_code的名称符合ECS规范。原因二数据尚未索引到正确的索引模式。在Kibana的“Stack Management” - “索引模式”中确认存在filebeat-*之类的索引模式并且其时间字段是timestamp。原因三时间范围选择不对。检查Kibana仪表板右上角的时间选择器是否覆盖了你的数据时间范围。最后一个小技巧在调试复杂的多行或解析规则时可以先用filebeat命令的-E参数临时覆盖配置并前台运行观察输出到控制台的事件格式是否正确。sudo filebeat -e -c /etc/filebeat/filebeat.yml -E “output.console.prettytrue”这会将事件以JSON格式漂亮地打印到控制台让你直观地看到Filebeat处理后的数据是什么样子是调试处理器和解析规则的利器。