架构实战：使用 EFK + Kafka 收集与分析 H3C 三层交换机 Syslog

架构实战：使用 EFK + Kafka 收集与分析 H3C 三层交换机 Syslog

在日常的企业网络运维中，核心交换机的日志（Syslog）对于排查网络抖动、安全攻击以及硬件故障至关重要。本文将记录如何复用现有的 Filebeat -> Kafka -> Logstash -> ES 日志流架构，零资源增加，完美收集并分析 H3C（华三）三层交换机的网络日志。

一、 整体架构思路

交换机无法像服务器一样安装 Filebeat 客户端，但几乎所有网络设备都支持标准的 Syslog 协议。因此，我们的核心思路是：让交换机通过 UDP 协议主动把日志推送到 Filebeat 的监听端口上。

数据流向如下： H3C 交换机 (UDP 5140) -> Filebeat (Syslog Input) -> Kafka (Topic: elk) -> Logstash (按类型分流) -> Elasticsearch -> Kibana

二、 采集端：Filebeat 多路输入配置

为了不浪费服务器资源，我们可以直接复用现有的 Filebeat。Filebeat 天生支持同时运行多个 Input。

修改 Filebeat 配置文件（如 kafka.yml），在原有的日志收集下方，追加 syslog 模块：

filebeat.inputs:
# 原有的业务日志收集 (如 Nginx)
- type: filestream
  enabled: true
  paths:
    - /var/log/nginx/access.log
  fields:
    log_type: nginx_access
  fields_under_root: true

# 【新增】H3C 交换机 Syslog 收集
- type: syslog
  protocol.udp:
    host: "0.0.0.0:5140"    # 避开系统默认的 514 端口，防止权限问题或 rsyslog 冲突
  fields:
    log_type: h3c_syslog    # 添加自定义标签，方便下游 Logstash 路由
  fields_under_root: true

output.kafka:
  hosts: ["10.20.30.188:9092"]
  topic: "elk"              # 所有日志统一发往同一个 topic

重启 Filebeat 进程生效，并通过 netstat -anup | grep 5140 确认端口监听成功。

三、 消费端：Logstash 动态路由配置

由于 Kafka 的 elk Topic 里现在混杂了 Nginx 和 交换机 两种日志，我们需要在 Logstash 里通过刚才打上的 log_type 标签进行精准分流。

input {
  kafka {
    bootstrap_servers => "10.20.30.188:9092"
    topics => ["elk"]
    group_id => "logstash_elk_group"
    codec => "json"                   # 关键配置：识别 Filebeat 传来的 JSON
  }
}

filter {
  # 交换机 Syslog 不需要额外解析，Filebeat 已自动拆解 facility, severity 等标准 Syslog 头
  if [log_type] == "h3c_syslog" {
    # 如果遇到 VIP 高可用架构导致的已知 IP 冲突刷屏告警，可以在此拦截
    if [message] =~ "ARP_DUPLICATE_IPADDR_DETECT" and [message] =~ "10.20.30.199" {
      drop { }
    }
  }
}

output {
  if [log_type] == "nginx_access" {
    elasticsearch {
      hosts => ["10.20.30.XXX:9200"]
      index => "nginx-access-%{+YYYY.MM.dd}"
    }
  }
  else if [log_type] == "h3c_syslog" {
    elasticsearch {
      hosts => ["10.20.30.XXX:9200"]
      index => "h3c-syslog-%{+YYYY.MM.dd}"
    }
  }
}

四、 设备端：H3C 交换机配置 (踩坑预警)

进入 H3C 交换机的系统视图进行配置。

🚨 避坑 1：时区穿越问题

如果交换机的时间不同步，或者没有设置时区，交换机会将 UTC（零时区）时间发送给 EFK，导致 Kibana 里的日志永远“慢 8 个小时”，甚至出现 2000 年的穿越日志。必须先配置 NTP 和 北京时区！

# 1. 设置时区为北京时间 (UTC+8)
[H3C] clock timezone Beijing add 08:00:00

# 2. 配置 NTP 同步
[H3C] ntp-service enable
[H3C] ntp-service unicast-server 10.20.30.250

开启信息中心并推送日志

# 3. 开启信息中心
[H3C] info-center enable

# 4. 强制要求发送 ISO 标准时间戳（极度推荐，便于 EFK 解析）
[H3C] info-center timestamp loghost iso

# 5. 指定日志服务器 IP 和 我们自定义的 5140 端口
[H3C] info-center loghost 10.20.30.100 port 5140 facility local7

# 6. (可选) 全量放行：将默认发送级别从 informational(6) 放宽到 debugging(7)
[H3C] info-center source default channel loghost log level debugging

[H3C] save force

五、 排错与验证小技巧

如果你配置完后在 Kibana 里没看到索引，可以按照以下思路排查：

  1. 终端伪造日志测试： 直接在 Filebeat 所在的机器上，向 5140 端口打入一条测试 UDP 报文，以此隔离交换机问题： echo "<189> %Sep 16 22:00:00 2026 H3C TEST_LOG: Please work" | nc -w 1 -u 127.0.0.1 5140
  2. 检查 Kafka 消费堆积： 使用 Kafka 脚本检查数据是否到达： /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server IP:9092 --topic elk --max-messages 5

总结

借助 Filebeat 原生的 syslog Input 和 Logstash 的灵活路由，我们可以在现有的应用日志流中轻松并入网络设备的监控。最终，只需在 Kibana 中输入 syslog.severity <= 3 即可监控所有严重硬件故障，输入 message: "UPDOWN" 即可监控核心链路抖动，大幅提升了网络可视化与排障效率！

评论