日志设计方案

一、小型项目（单体应用，团队 <5 人，QPS < 1k）

✅ 推荐方案：

• 技术栈：SLF4J + Logback（Spring Boot 默认）
• 配置方式：application.yml 或 logback-spring.xml
• 日志格式：文本格式，带基础 MDC（如 traceId）
  • 本质：一个 线程本地（ThreadLocal）的 Map<String, String>。
  • 作用：在当前线程中存储诊断上下文信息（如 traceId、userId、requestId），这些信息会自动附加到每条日志中，实现请求追踪。
• 输出目标：控制台 + 按天滚动的本地文件
• 上下文传递：手动在 Controller/Service 中设置 MDC（或通过简单拦截器）

⚠️ 注意事项：

• 避免字符串拼接日志。(防止无谓的性能开销)
• 使用参数化日志（logger.info("msg: {}", var)），更高效安全。
• 开发环境开 DEBUG，生产环境设为 INFO。

✅ 为什么成熟？

• 零学习成本：Spring Boot 内置支持。
• 轻量可靠：Logback 性能足够，配置简单。
• 快速上线：无需额外依赖或运维。

二、中型项目（微服务架构，团队 520 人，QPS 1k10k）

✅ 推荐方案：

• 技术栈：SLF4J + Logback（或 Log4j2，若需更高性能）
• 日志格式：JSON 结构化日志（便于采集）
• 上下文：通过 MDC + 请求拦截器/Filter 自动注入 traceId、userId 等
• 输出目标：
  • 本地文件（按大小/时间滚动）
  • 异步 Appender 提升性能
  • 日志采集器（如 Filebeat / Fluentd）推送至 ELK（Elasticsearch + Logstash + Kibana） 或 Loki + Grafana
• 脱敏：自定义 JSON encoder 过滤敏感字段（如 password、身份证）

⚠️ 注意事项：

• MDC 必须在线程池/异步任务中传递（使用 MDC.getCopyOfContextMap() + MDC.setContextMap()）
• 避免在日志中记录大对象（如整个 Request Body）
• 设置合理的日志保留策略（如 7 天）

✅ 为什么成熟？

• 结构化日志 + ELK 是业界标准，支持全文检索、聚合分析、告警。
• 异步写日志 平衡性能与可靠性。
• 自动上下文注入 提升排查效率（链路追踪基础）。

三、大型项目（高并发、多团队、金融/电商级，QPS > 10k）

✅ 推荐方案：

• 技术栈：SLF4J + Log4j2（异步性能优于 Logback）
• 日志格式：严格规范的 JSON Schema（字段命名统一，如 trace_id, span_id, service_name）
• 上下文：
  • 全链路 traceId 透传（结合 OpenTelemetry / SkyWalking）
  • MDC 自动注入 + 线程池/异步/消息队列上下文传递
• 输出目标：
  • 异步日志队列（Log4j2 AsyncLogger + Disruptor）
  • 直接写入 Kafka（高吞吐、解耦）
  • 后端由 Flink/Spark 或日志平台消费，存入 ES、ClickHouse 或专用日志仓库
• 治理能力：
  • 动态调整日志级别（如通过 Apollo/Nacos）
  • 日志采样（高频接口按比例记录）
  • 敏感信息自动脱敏（正则/注解驱动）
  • 日志审计与合规（如 GDPR）

⚠️ 注意事项：

• 避免日志成为瓶颈：异步 + 批量 + 限流。
• 日志与监控/告警联动：ERROR 日志触发企业微信/钉钉告警。
• 成本控制：冷热数据分离，高频日志短期存储，关键日志长期归档。

✅ 为什么成熟？

• Log4j2 + Kafka + OpenTelemetry 是超大规模系统的事实标准。
• 高性能异步日志 支撑百万级 TPS。
• 与可观测性体系深度集成（Logging + Metrics + Tracing）。

📌 简短总结（重点抓取）

通用原则：始终用 SLF4J 解耦；结构化日志是趋势；MDC 是上下文追踪的基石；异步提升性能；日志即数据，需治理。

• 系统日志：用于给运维、开发排查使用，记录bug信息
• 用户操作日志：记录用户操作
• 审计日志：记录各种敏感操作，保留信息，比如：命题审题等