作为十年运维老兵，我曾在凌晨三点被故障电话叫醒后，不得不在几十台服务器间来回翻找线索——这种痛苦经历让我深刻认识到集中日志管理的重要性。今天我们就来聊聊如何用Rsyslog+ELK这套黄金组合构建日志中枢系统，让故障排查变得像刷朋友圈一样简单。

一、硬件设备到虚拟机的完整技术栈

本次实验环境由三台CentOS 8设备组成：

  • 日志收集器：Rsyslog（192.168.1.100）
  • ELK服务器：Elasticsearch 7.10 + Logstash 7.10 + Kibana 7.10（192.168.1.101）
  • 测试客户端：Nginx服务器（192.168.1.102）

技术栈说明：这里选择Elastic官方仓库安装的同版本全家桶，避免版本兼容性问题

二、Rsyslog的三种转发模式深度解析

2.1 UDP高速传输模式

适合对时效性敏感的日志场景（每分钟>5万条日志）：

# /etc/rsyslog.conf
module(load="imudp")  # 启用UDP模块
input(type="imudp" port="514")  # 指定监听端口

*.* @192.168.1.100:514  # 客户端配置使用@符号转发

注意点：通过ss -unlp命令验证端口监听状态，netstat -su监控丢包情况

2.2 TCP可靠传输模式

适合财务系统等关键业务日志：

# 服务端配置
module(load="imtcp")
input(type="imtcp" port="10514")

# 客户端配置
*.* @@192.168.1.100:10514  # 双@符号表示TCP传输

调试技巧：tcpdump -i eth0 port 10514 -vvv实时捕获传输内容

2.3 RELP灾难恢复模式

金融行业的福音协议：

# 需要先安装rsyslog-relp模块
module(load="omrelp")
*.* :omrelp:192.168.1.100:1600

核心优势：断线自动重传+数据完整性校验，即使收集服务器宕机一小时也能恢复数据

三、让Logstash变身智能分拣员

我们需要把混杂的日志分类打标，这里示范Nginx访问日志解析：

# nginx-log.conf
input {
  tcp {
    port => 10515
    codec => json  # 直接解析Rsyslog转发来的结构化数据
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }  # 使用现成的正则模板
  }
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
}

output {
  elasticsearch { 
    hosts => ["localhost:9200"]
    index => "nginx-%{+YYYY.MM.dd}"  # 动态创建日级别索引
  }
}

异常处理：配置dead_letter_queue保存解析失败的日志，通过_grokparsefailure标签定位问题

四、Kibana可视化中的高级玩法

4.1 智能时间序列预测

在TSVB可视化中开启异常检测：

{
  "type": "timeseries",
  "params": {
    "threshold": {
      "value": 0.99,  // 置信度阈值
      "type": "dynamic"
    }
  }
}

4.2 安全事件关联分析

通过KQL语句快速定位攻击：

source.ip: 58.218.92.* AND response: 404 
AND (user_agent: "sqlmap" OR uri: "*select%20*%20from%20*")

五、双活架构下的心跳检测机制

# ElastAlert心跳检测规则示例
name: Rsyslog_Heartbeat
type: heartbeat
index: rsyslog-*
realert:
  minutes: 0

alert_text: |
  检测到日志中断设备:
  {host.name} 
  最后活动时间: {last_time}

alert: post
http_post_url: "http://监控平台/api/alert"

六、生产环境优化指南

6.1 磁盘IO三剑客配置

# elasticsearch.yml优化项
path.data: /data01,/data02  # 多磁盘分流
index.codec: best_compression  # 超强压缩比

# /etc/rsyslog.conf
$ActionQueueType LinkedList 
$ActionQueueFileName logq
$ActionResumeRetryCount -1

6.2 基于标签的智能分级存储

PUT _ilm/policy/hot_warm_cold
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "actions": {
          "allocate" : { 
            "require" : { "data": "warm" }
          }
        }
      }
    }
  }
}

七、典型应用场景实战解析

场景1：证券交易系统突发性能抖动

通过交易延迟>200ms指标定位到API网关，关联分析发现特定券商接口日志量突增500%，根源是该券商升级后未关闭调试日志

场景2：医院HIS系统数据篡改事件

根据药品库存变更日志追溯操作记录，结合Kibana地理信息图发现外省IP异常操作，最终锁定账号被盗事件

八、技术栈的AB面思考

优势矩阵：

  • 日均PB级吞吐能力
  • 原始日志原文追溯
  • 无损压缩节省75%存储
  • 多租户权限管控

应对挑战：

  • 时间戳乱序导致展示错乱
  • 日志注入攻击防御
  • T+1归档的时效性平衡
  • 敏感字段脱敏处理

九、来自踩坑者的九个忠告

  1. 日志轮转配置不当导致字段截断
  2. 忘记配置ulimit引发文件句柄泄漏
  3. 中文编码导致的JSON解析黑洞
  4. 未设置时区引发时间穿梭假象
  5. 正则表达式性能杀手（.*慎用）
  6. 索引模板映射的动态陷阱
  7. 冷数据迁移引发的IO风暴
  8. 不恰当的副本数耗尽磁盘空间
  9. APM与日志的关联缺失