添加Grok规则重启Logstash后Filebeat连接失败求助

看起来你遇到的情况很典型：明明ELK各服务状态显示活跃，但Filebeat就是连不上Logstash的5044/5443端口。结合你是添加Grok规则后出现的问题，大概率是Grok语法错误导致Logstash配置加载失败——systemd显示服务"活跃"只是进程启动了，但Logstash因为配置问题根本没初始化监听端口。

下面是一步步的排查和解决步骤：

• 第一步：先测试Logstash配置的语法合法性
  这是最直接的排查方式，很多时候systemd的"活跃"状态会误导人，实际Logstash已经因为配置错误在后台崩溃了。运行以下命令检查你的syslog-filter.conf（如果是多文件配置，指定整个conf目录即可）：

  /usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/syslog-filter.conf
  # 若检查整个配置目录：
  # /usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/
  

  如果有语法错误（比如Grok pattern写错、字段引用错误），这里会直接输出具体的错误提示，修复后再重启Logstash。

• 第二步：查看Logstash的详细运行日志
  配置测试可能覆盖不了所有场景，查看Logstash的日志能找到更细节的崩溃原因：

  # 实时查看systemd日志
  journalctl -u logstash.service -f
  # 或者查看文件日志
  tail -f /var/log/logstash/logstash-plain.log
  

  重点找Failed to parse config、Grok parse failure、Could not start input plugin这类关键词，它们会明确告诉你哪里出了问题。

• 第三步：确认Logstash是否真的在监听端口
  用端口监听命令验证Logstash进程是否实际绑定了5044/5443：

  ss -tulpn | grep logstash
  

  如果输出里完全看不到这两个端口，说明Logstash确实没启动监听，问题肯定出在配置上（几乎就是你新增的那行Grok规则）。

• 第四步：检查Input配置是否被误改
  确认你在修改Grok规则时，没有不小心改动或注释掉Logstash的Beats监听配置。正常的Input配置应该类似这样：

  input {
    beats {
      port => 5044
      # 其他可选配置...
    }
    beats {
      port => 5443
      # 其他可选配置...
    }
  }
  

  确保这些端口监听的配置项完整且无语法错误。

• 第五步：排除防火墙/安全组干扰
  虽然之前服务正常，但重启后可能防火墙规则有变动。检查服务器是否允许5044/5443的入站连接：

  # firewalld环境
  firewall-cmd --list-ports | grep -E '5044|5443'
  # iptables环境
  iptables -L INPUT -n | grep -E '5044|5443'
  

  如果没有相关规则，添加并重启防火墙：

  firewall-cmd --add-port=5044/tcp --permanent
  firewall-cmd --add-port=5443/tcp --permanent
  firewall-cmd --reload
  

另外，从你的Filebeat日志看，libbeat.pipeline.events.active=4117说明已经堆积了不少待发送的事件，等Logstash恢复正常后，这些事件会自动补发，不用手动处理。

内容的提问来源于stack exchange，提问作者OMID