Linux 日志分析：Syslog 配合 ELK 系统架构

Syslog与ELK是互补协作关系：Syslog（如rsyslog）负责标准化采集与可靠转发，ELK负责集中存储、深度解析与可视化分析；需通过TCP/UDP或omelasticsearch打通数据链路，并用Filebeat或Logstash清洗日志。

Linux 日志分析中，Syslog 与 ELK 并非替代关系，而是天然互补的协作组合：Syslog 负责日志的标准化采集与初步路由，ELK 负责集中存储、深度解析与交互式分析。关键在于打通两者的数据通路，并合理分工。

Syslog 作为 ELK 的可靠日志入口

Syslog（尤其是 rsyslog）是 Linux 系统最成熟、最稳定的日志转发层。它不直接参与分析，但承担着“守门人”角色——统一接收 kernel、auth、daemon 等各类本地日志，按规则过滤、格式化，并安全地推送到 ELK 生态。

1. rsyslog 可通过 omelasticsearch 模块直连 Elasticsearch，适合轻量级场景；更常见的是配置为 TCP/UDP 输出到 Logstash 或 Filebeat 监听端口（如 514 或自定义端口）
2. 务必启用 $ActionFileDefaultTemplate RSYSLOG_ForwardFormat 或使用 template 定义 JSON 格式输出，避免 Logstash 解析时字段丢失
3. 对远程传输启用 TLS 加密和队列缓存（queue.filename），防止网络抖动导致日志丢失

ELK 各组件如何承接 Syslog 数据

从 Syslog 流入的数据需经 ELK 各环节协同处理，才能发挥价值：

1. Elasticsearch 接收结构化日志后，自动识别 @timestamp、host、syslog_facility、syslog_severity 等字段，支持按服务类型（如 auth）、严重等级（err）、时间范围快速检索
2. Logstash 或 Filebeat 承担关键清洗任务：用 Grok 解析传统 syslog 格式（如 %{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:host} %{DATA:program}(?:[%{POSINT:pid}])?: %{GREEDYDATA:message}），提取 IP、用户、操作动作等语义字段
3. Kibana 中可基于 syslog_program 创建服务维度看板，用 syslog_severity 设置告警阈值（例如连续 5 条 emerg 级日志触发通知）

典型部署链路与配置要点

一条稳定高效的路径是：系统日志 → rsyslog（本地收集+TCP转发） → Filebeat（轻量接收+JSON增强） → Elasticsearch → Kibana。该链路兼顾性能与可控性。

1. rsyslog 配置示例（/etc/rsyslog.d/90-elk.conf）：

   *.* @10.0.1.20:5044;RSYSLOG_SyslogProtocol23Format

2. Filebeat 输入监听 UDP/TCP 5044，启用 decode_syslog 插件自动解析 RFC5424 标头，无需手写 Grok
3. 在 Elasticsearch 中为 syslog 索引设置生命周期策略（ILM），热数据保留 7 天、冷数据归档至低成本存储，避免磁盘撑爆

为什么不用 journald 直连 ELK？

systemd-journald 虽然集成度高，但二进制格式与 ELK 生态兼容性弱。若必须使用，推荐通过 journalctl -o json 实时导出或部署 Journalbeat（专为 journald 设计的 Beats），而非让 Logstash 直接读取二进制日志文件——后者易因 journal 文件轮转而丢日志。