一、日志篇：从“乱码堆”到“数据金矿”

很多开发者的日志习惯是：System.out.println 或者随意打 logger.info。这在开发环境没问题，但在生产环境就是灾难。

必须使用结构化日志

传统文本日志难以被机器自动分析。在生产环境，JSON 格式是标准。

✅ 常用方法：引入 logstash-logback-encoder将日志输出为 JSON。

net.logstash.logback
logstash-logback-encoder
7.4

traceId


{"traceId": "%X{traceId}" }

日志级别

生产环境出现 Bug。需要临时开启 DEBUG 日志复现问题，难道要重新打包部署？NO，利用 Spring Boot Actuator 可以实时调节。

✅ 常用方法：

org.springframework.boot
spring-boot-starter-actuator

# application.yml
management:
endpoints:
web的观点是。exposure:
include: loggers # 只暴露日志控制端点，注意安全！endpoint:
loggers:
enabled: true

操作示例：

# 查看当前级别
curl http://localhost:8080/actuator/loggers/com.example.service
# 为 DEBUG
curl -X POST http://localhost:8080/actuator/loggers/com.example.service \
-H 'Content-Type: application/json' \
-d '{"configuredLevel":"DEBUG"}'

敏感数据脱敏

日志中严禁出现明文密码、手机号、身份证、银行卡号等敏感信息。不过，

✅ 常用方法：P​自定义 Converter 或使用脱敏工具类。在对象序列化前统一处理，

// 简单示例：在打印对象前处理
public class SensitiveInfoUtils {
public static String maskPhone {
if return null;// 将中间四位替换为 *
return phone.replaceAll\\d{4}","$1****$2");}
}
// 在 toString 或 JSON 序列化器中调用

二、监控篇：从“黑盒”到“透明玻璃房”

No monitoring = naked running. 你需要知道程序是否活着？是否慢，是否出错？否则半夜报警会让你手足无措。

主要指标程序

• RED : 针对微服务接口
  • P99/QPS:  每秒请求数
  • Error Rate:  错误率
  • P95/P99 Duration:  响应时间分位数
• USE : 针对底层资源 CPU、内存、磁盘 IO、带宽等。

集成 Promeus + Grafana

S​pring Boot Actuator 原生支持 Promeus，只需几行配置即可让指标跑进时序数据库。

✅ 配置步骤：

1. # 引入依赖

   
   i o.micrometer
   micrometer-registry-promeus
   
   

2. # 开启端点

   management:
   endpoints:
   从web来看。exposure:
   include: health,info,promeus,metrics
   metrics:
   说到tags，application: ${spring.application.name}
   

3. # 自定义业务指标

   @Component
   public class CustomMetrics {
   private final Counter orderCounter;private final Timer orderTimer;public CustomMetrics {
   this.orderCounter = Counter.builder
   .description
   .register;this.orderTimer = Timer.builder
   .description
   .register;
   }
   public void recordOrder {
   orderCounter.increment;orderTimer.record;}
   }
   

4. # 可视化 : 在 Grafana 中导入官方 “JVM Micrometer” Dashboard，或自行绘制业务面板。

健康检查与就绪探针

K8s 通过 Liveness 与 Readiness 判断容器是否可以继续提供服务。

management:
说到health，livenessState:
enabled: true
readinessState:
enabled: true
endpoint:
health这方面。probes:
enabled: true

• /actuator/health/liveness → 进程死锁、OOM 时返回 **DOWN**，K8s 自动重启容器。其实，
• /actuator/health/readiness → 依赖不可用时返回 **DOWN**。K8s 停止向该实例转发流量。

三、异常处理篇：从“堆栈爆炸”到“友好提示”

统一全局异常处理器

S​tandard practice is to hide raw stack traces from end‑users while still recording m for developers.

自定义业务异常 

Avoid generic RuntimeException – give your error a clear semantic meaning.


告警策略 

You don’t want every exception to ring pager.


✖  *忽略*: 参数校验错误，直接返回给前端即可；不触发告警，

⚠  *警告*: 可预期的业务错误，记录 WARN 日志即可；若频率激增可考虑阈值告警。话说回来，

❌  *严重*: 空指针、数据库连接超时、第三方服务不可用等；立即通过 PagerDuty / 钉钉 / 公司微信发送告警，并附带 TraceID 与调用链路快照。


Sentry / ELK Alerting 可实现同一错误一分钟内只报一次防止告警风暴。话说回来，

TIPS： 合理划分告警等级并配合聚合规则。可让运维团队在凌晨也能安然入睡。



四 、进阶 ： 链路追踪
在微服务架构中，一个请求可能穿越 N 个服务。哪里慢，哪里错？其实，**✅ 常用方法** ： 集成 Micrometer Tracing + Zipkin / Jaeger / SkyWalking
1️⃣ **引入依赖**
xml

io.micrometer<\/groupId>
micrometer-tracing‑bridge‑brave<\/artifactid>
1.0.5<\/version>
<\/dependency>

io.zipkin.reporter2<\/groudpid>
zipkin-reporter‑brave<\/spandependency
 \/depende
yaml
management:
  tracing:
    sampling:
     probability : 0.1 # 根据实际负载调低
   zipkin:
     tracing:
       endpoint : http://zipkin-server:/api/v2/spans
效果：


每个请求生成唯一 trace‑id 并随日志一起输出；

Zipkin UI 能看到完整调用拓扑图与耗时瀑布图。


五 、上线检查清单

在点击 “发布” 按钮前，请逐项确认：



"日志"


JSON 格式已开启?/li>

敏感字段已脱敏?/li>
，…






​