Linux日志治理需从前端输出强制标准化：新服务必须输出含7个必选字段的标准JSON日志，禁用自由文本；统一采集协议（优先journald）、禁用非必要syslog服务、远程转发启用TCP+TLS；入口部署校验节点，失败率超0.5%告警；日志格式纳入接口契约与SLO考核。
Linux日志格式不统一，根本原因不在“写得乱”，而在缺乏从应用层到系统层的结构化约定。治理不是靠后期清洗，而是从前端输出就强制标准化。
统一应用日志输出格式
所有新上线服务必须输出标准JSON日志，禁止自由文本拼接。每条日志强制包含7个字段：timestamp（ISO8601带毫秒与时区）、level（小写，仅debug/info/warn/error/fatal）、service（短名称，如user-api）、trace_id、span_id、host、message。业务参数全部收进fields对象，不混入message。
- Go用zerolog，Java用logback-json，Python用structlog——这些库原生支持字段注入和JSON序列化
- 容器环境直接输出到stdout/stderr，由containerd或kubelet自动打上pod_name、namespace等标签
- 禁用rsyslog的multiline解析器，避免破坏JSON结构
收敛系统级日志协议与配置
避免rsyslog、syslog-ng、journald多套并存。优先启用journald（systemd默认），再通过journalctl --output=json-seq导出结构化数据；若必须用rsyslog，统一配置RFC5424格式，并在/etc/rsyslog.conf中显式设置$ActionFileDefaultTemplate RSYSLOG_ForwardFormat。
- 关闭所有非必要syslog服务：systemctl stop syslog-ng && systemctl disable syslog-ng
- 禁止应用直接调用syslog()函数写入传统格式；改用journald socket或HTTP endpoint上报
- 远程转发时启用TCP+TLS，防止网络中间设备截断或重写日志内容
建立日志接入强校验机制
在日志管道入口部署轻量解析验证节点（如Fluentd filter或Vector transform），对每条日志做格式快检：JSON可解析？必选字段是否存在？timestamp是否合法？level是否在白名单内？不合规日志打标后隔离入单独topic，不丢弃但不进入主分析流。
- 使用Vector的parse_json + condition插件链，50ms内完成单条校验
- 告警规则绑定：1分钟内校验失败率＞0.5%即触发运维告警
- 定期抽样扫描已入库日志，反查fields中是否存在未注册的键名，推动应用补全schema文档
推动跨团队日志契约落地
把日志格式定义写进服务接口契约（如OpenAPI扩展x-log-schema），CI阶段用工具自动校验代码中日志语句是否符合字段清单。新服务上线前，需提供sample.log文件并通过日志Schema验证器测试。
- 内部提供log-schema-validator CLI工具，支持本地校验和Git Hook集成
- 在Kubernetes ConfigMap中托管各服务的log-schema.json，供采集端动态加载字段映射规则
- 将日志字段完整性纳入SLO考核：service-level log-field-compliance ≥ 99.95%
