linux 日志集中化需构建采集—传输—存储—分析闭环，核心是分离关注点：采集端轻量稳定（rsyslog/syslog-ng 或 fluent-bit），传输层用 kafka 解耦路由并 etl 标准化，存储分层（热数据 es+ilm、冷数据 s3/loki），严格权限控制与全链路监控。
Linux 日志集中化不是简单地把日志“收过来”，而是构建一个可靠、可扩展、易维护的采集—传输—存储—分析闭环。核心在于分离关注点：采集端轻量稳定，传输链路安全可控，存储层支持检索与保留策略，查询界面直观高效。
采集层：轻量、统一、低侵入
避免在每台服务器上部署重型 Agent。推荐使用 rsyslog 或 syslog-ng 原生支持 TLS 转发，资源占用低、启动快、配置灵活。对于容器或微服务场景，可搭配 fluent-bit（轻量版 Fluentd）做前置过滤与标签注入。
- 所有主机统一配置日志格式（如 RFC5424），添加主机名、环境标签（prod/staging）、应用标识字段
- 禁用本地磁盘大量缓存，改用内存队列 + 有限重试，防止磁盘打满导致系统异常
- 敏感日志（如 auth.log 含密码尝试）启用 TLS 双向认证，仅允许日志服务器证书接入
传输层：可靠路由与初步处理
不建议客户端直连存储后端。中间需部署消息缓冲与路由组件，承担解耦、削峰、格式标准化职责。常用组合为 rsyslog → Kafka 或 fluent-bit → Kafka。
- Kafka Topic 按日志类型分（access_log、audit_log、app_error）或按环境分（prod-app-logs），便于 ACL 控制与消费隔离
- 在 Kafka 前或后嵌入轻量 ETL 环节（如 Logstash Filter 或 KSQL），完成时间解析、字段提取、等级映射（如将“WARN”转为“warning”）
- 设置合理 Retention（如 7 天）和 Replication=3，保障传输中断时数据不丢失
存储与检索：兼顾性能与合规
长期归档与实时查询需求不同，宜分层设计。热数据（Elasticsearch 支持全文检索与仪表盘；冷数据（>30 天）转入 S3 + Athena 或 MinIO + Loki + Promtail（对象存储适配版） 实现低成本保留。
- ES 索引按天滚动（logstash-%{+YYYY.MM.dd}），配合 ILM 策略自动降冷（转入 warm 节点）或删除
- 所有索引启用字段级别加密（如使用 OpenSearch 的 Field Masking 插件），隐藏身份证、手机号等 PII 字段
- 审计类日志（如 sudo、ssh）单独建索引并开启快照备份，满足等保 /ISO27001 对不可篡改性的要求
权限与可观测性：让日志真正可用
再好的架构，如果查不到、看不懂、不敢看，就失去价值。必须配套访问控制、元数据管理和健康监控。
- 通过 Kibana Spaces 或 OpenSearch Dashboards RBAC，按团队划分日志视图（运维可见 systemd，开发仅见 app-nginx）
- 为每条日志注入 trace_id（若应用已集成 OpenTelemetry），打通日志—指标—链路三体协同
- 监控采集链路本身：rsyslog 丢包数、Kafka lag、ES indexing rate、查询超时率，告警阈值写进 Prometheus AlertRules
不复杂但容易忽略：日志时间戳必须统一 NTP 校准，否则跨节点关联分析会错乱；所有配置文件纳入 Git 管理并 CI 验证语法；首次上线先跑一周影子模式（原始日志双写，新链路只读不阻断）。
