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。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 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验证语法；首次上线先跑一周影子模式（原始日志双写，新链路只读不阻断）。
