日志就像系统的"日记本"，记录着系统运行的点点滴滴。对于运维人员来说，日志就是排查问题的"黄金线索"。但当服务器数量增多时，分散在各处的日志就像散落的拼图，难以快速获取完整信息。今天我们就来聊聊如何用 Rsyslog 和 ELK Stack 这套黄金组合，把 Linux 系统的日志集中管理起来，让运维工作事半功倍。
1. 为什么需要日志集中管理？
想象一下，你管理着50台服务器，突然接到用户反馈网站访问异常。你需要排查问题，但日志分散在50台机器上，难道要一台台登录查看吗？这效率太低了！
日志集中管理解决了三大痛点：
- 查找困难：不用再逐台服务器翻日志
- 分析不便：可以跨服务器关联分析日志
- 存储受限：单台服务器的磁盘空间有限
2. 技术方案选型：Rsyslog + ELK Stack
2.1 Rsyslog 简介
Rsyslog 是 Linux 系统自带的日志服务，相比传统的 syslog，它：
- 支持多种输入输出方式
- 高性能，每秒可处理百万级日志
- 支持丰富的过滤和转发规则
2.2 ELK Stack 简介
ELK 是 Elasticsearch、Logstash 和 Kibana 三件套的简称：
- Elasticsearch：分布式搜索引擎，负责存储和检索日志
- Logstash：数据处理管道，负责解析和转换日志
- Kibana：可视化平台，让日志变得直观易懂
3. 实战部署：从零搭建日志系统
3.1 环境准备
假设我们有3台服务器：
- 日志收集服务器：192.168.1.100（运行Rsyslog）
- ELK服务器：192.168.1.101
- 应用服务器：192.168.1.102（产生日志）
3.2 Rsyslog 服务端配置
首先在日志收集服务器(192.168.1.100)上配置 Rsyslog：
# 编辑Rsyslog主配置文件
sudo vim /etc/rsyslog.conf
# 取消以下注释，启用UDP和TCP监听
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
# 添加模板，定义接收日志的存储格式
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
# 重启Rsyslog服务
sudo systemctl restart rsyslog
配置说明：
imudp和imtcp模块启用网络日志接收功能- 模板
RemoteLogs定义了远程日志的存储路径和格式 %HOSTNAME%会被替换为发送日志的主机名%PROGRAMNAME%会被替换为产生日志的程序名
3.3 客户端配置
在应用服务器(192.168.1.102)上配置日志转发：
# 编辑Rsyslog配置文件
sudo vim /etc/rsyslog.conf
# 添加以下内容，将所有日志转发到收集服务器
*.* @192.168.1.100:514 # UDP方式
*.* @@192.168.1.100:514 # TCP方式(更可靠)
# 重启Rsyslog服务
sudo systemctl restart rsyslog
小技巧：生产环境建议使用TCP方式(@@)，因为UDP可能会丢包。
3.4 ELK Stack 安装与配置
在ELK服务器(192.168.1.101)上安装ELK组件：
# 安装Java环境(ELK依赖)
sudo apt install openjdk-11-jdk
# 下载并安装Elasticsearch
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.10.2-amd64.deb
sudo dpkg -i elasticsearch-7.10.2-amd64.deb
# 下载并安装Logstash
wget https://artifacts.elastic.co/downloads/logstash/logstash-7.10.2.deb
sudo dpkg -i logstash-7.10.2.deb
# 下载并安装Kibana
wget https://artifacts.elastic.co/downloads/kibana/kibana-7.10.2-amd64.deb
sudo dpkg -i kibana-7.10.2-amd64.deb
配置Logstash处理Rsyslog收集的日志：
# 创建Logstash配置文件
sudo vim /etc/logstash/conf.d/rsyslog.conf
# 添加以下内容
input {
file {
path => "/var/log/*/*.log"
start_position => "beginning"
sincedb_path => "/dev/null"
}
}
filter {
grok {
match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:message}" }
}
date {
match => [ "timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ]
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
index => "syslog-%{+YYYY.MM.dd}"
}
}
配置解析：
input部分配置从Rsyslog生成的日志文件中读取数据filter部分使用grok解析syslog格式的日志output部分将处理后的日志发送到Elasticsearch
4. 高级配置技巧
4.1 日志过滤与分类
有时候我们不需要收集所有日志，可以通过Rsyslog的过滤功能实现：
# 在客户端rsyslog.conf中添加
# 只转发error及以上级别的日志
*.error @192.168.1.100:514
# 排除特定程序的日志
:programname, isequal, "cron" ~ # 忽略cron日志
# 将nginx访问日志单独处理
if $programname == 'nginx' then {
action(type="omfile" file="/var/log/nginx/access.log")
stop
}
4.2 日志轮转配置
防止日志文件无限增长，需要配置logrotate：
# 创建logrotate配置
sudo vim /etc/logrotate.d/remote_logs
# 添加以下内容
/var/log/*/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
5. Kibana 可视化配置
安装完成后，访问 http://ELK服务器IP:5601 进入Kibana界面：
创建索引模式：
- 进入Management → Kibana → Index Patterns
- 输入
syslog-*作为索引模式 - 选择
@timestamp作为时间字段
创建可视化图表：
- 进入Visualize → Create new visualization
- 选择"Data Table"类型
- 配置聚合条件，如按hostname分组统计日志量
制作仪表盘：
- 将多个可视化图表组合到一个仪表盘中
- 可以添加过滤器，如只显示error级别的日志
6. 技术方案优缺点分析
6.1 优势
- 高性能：Rsyslog每秒可处理百万级日志条目
- 灵活性：支持多种日志格式和传输协议
- 可扩展：ELK Stack可以轻松扩展集群规模
- 可视化：Kibana提供丰富的可视化选项
6.2 局限性
- 资源消耗：Elasticsearch对内存需求较高
- 学习曲线：Logstash配置语法需要时间掌握
- 维护成本：需要定期维护索引和清理旧数据
7. 应用场景实例
7.1 安全审计
通过集中日志可以：
- 追踪异常登录尝试
- 监控敏感文件访问
- 分析攻击模式
7.2 故障排查
典型案例：
- 某服务突然崩溃，通过关联多台服务器日志发现是数据库连接池耗尽
- 网站响应变慢，通过日志分析定位到某个API接口性能下降
7.3 业务分析
非传统用法：
- 分析用户行为模式
- 统计系统使用高峰时段
- 追踪业务流程完成率
8. 注意事项与最佳实践
- 日志格式标准化：建议所有应用使用统一的日志格式
- 敏感信息过滤：避免在日志中记录密码等敏感信息
- 存储规划：根据日志量预估存储需求，通常保留7-30天
- 监控日志系统本身：别让日志系统成为单点故障
- 权限控制：确保只有授权人员能访问日志数据
9. 总结
通过Rsyslog和ELK Stack的组合，我们构建了一个强大的日志集中管理系统。这套方案不仅解决了日志分散的痛点，还通过强大的搜索和可视化功能，让日志数据真正产生价值。无论是故障排查、安全审计还是业务分析，都能从中受益。
实施时建议从小规模开始，逐步完善过滤规则和可视化方案。记住，一个好的日志系统应该是随着业务需求不断演进的，而不是一蹴而就的。
最后提醒一点：日志系统搭建只是第一步，更重要的是培养团队查看和分析日志的习惯，让数据驱动运维决策。
评论