接到 Spring 上，並算一次完整的帳

在 Spring Boot 3 專案上接可觀測性，第一步的投報比高到有點不合理：加兩個依賴、寫幾行設定，前面七章講的東西大部分就開始有資料了。

<!-- metrics -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

<!-- tracing（ch05）-->
<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>

management:
  endpoints.web.exposure.include: health,prometheus
  metrics.tags:
    application: ${spring.application.name}   # 對應 OTel 的 service.name（ch05）
  tracing.sampling.probability: 1.0            # 全收，取樣交給 Collector 做
  otlp.tracing.endpoint: http://otel-collector:4318/v1/traces

不用寫程式就有的指標

三個要立刻改的預設值

management:
  metrics.distribution:
    percentiles-histogram:
      http.server.requests: true      # ① 產生 bucket，才能正確聚合分位數（ch03）
    slo:
      http.server.requests: 100ms,300ms,1s   # ② bucket 邊界對齊 SLO 門檻（ch03/ch06）
  observations.annotations.enabled: true      # ③ 啟用 @Observed（ch05 的手動 span）

ch02 那場「一個 label 把 Prometheus 從 4GB 吃到 30GB」的事故，在 Spring 專案裡有一個非常具體的形態。

好消息：預設是安全的

Spring MVC 的自動埋點會用路徑模板當 uri tag：

GET /api/orders/8821  →  uri="/api/orders/{id}"   ✅ 有界

壞消息：三種情況會破功

// ❌ 每個租戶一條時序，租戶數無上限
Counter.builder("orders.created").tag("tenant_id", tenantId)

// ✅ 分級：把無界的維度收成有界的
.tag("tenant_tier", tier)   // free / pro / enterprise

兩道防線

// ① 應用端：設定 tag 上限（超過就合併成 "other"）
@Bean
MeterFilter uriCardinalityLimit() {
    return MeterFilter.maximumAllowableTags(
        "http.server.requests", "uri", 100, MeterFilter.deny());
}

// ② 也可以直接丟掉不需要的指標
@Bean
MeterFilter denyActuatorMetrics() {
    return MeterFilter.denyNameStartsWith("http.server.requests.actuator");
}

加上 ch02 說的第三道防線：Prometheus 端的 sample_limit 與 metric_relabel_configs。三道防線裡至少要有兩道。

ch01 說三本柱之間的橋比每一樣本身做得多好都重要。這一節是那些橋在 Spring 專案裡的具體接法。

橋一：trace_id 進日誌（ch04）

Spring Boot 3 + Micrometer Tracing 會自動把 traceId/spanId 放進 MDC，你只要在 pattern 裡取用：

<pattern>%d{HH:mm:ss} %-5level [%X{traceId:-},%X{spanId:-}] %logger{36} - %msg%n</pattern>

<!-- JSON encoder 則會自動把整個 MDC 展開成欄位（ch04 建議的做法） -->
<encoder class="net.logstash.logback.encoder.LogstashEncoder"/>

橋二：exemplar 把 metrics 接到 trace（ch05）

management:
  prometheus.metrics.export.properties:
    io.prometheus.exemplars.sampleIntervalMilliseconds: 1000

接好之後，Grafana 的延遲圖上會出現可點的小點，直接跳到那一次的 trace。Prometheus 端要啟用 exemplar 儲存（--enable-feature=exemplar-storage）。

橋三：三邊的名字要一致（ch05 的 semantic conventions）

spring.application.name: order-api

→ metrics 的 tag：  application="order-api"
→ trace 的屬性：    service.name="order-api"
→ 日誌的欄位：      service="order-api"

橋四：非同步邊界（ch05 的失敗場景）

// 執行緒池：讓 context 跟著任務走
@Bean
TaskDecorator otelTaskDecorator() {
    return runnable -> {
        Context ctx = Context.current();
        return () -> { try (Scope s = ctx.makeCurrent()) { runnable.run(); } };
    };
}

// @Async 的 executor 也要套用同一個 decorator
// Kafka：producer inject / consumer extract（ch05）

驗證這四座橋（一次走完）

走不通的那一段，就是你還沒接好的那座橋。這個檢查應該在每次新服務上線時做一次。

指標有了，接下來的問題是怎麼擺。而這件事有一個很實際的目標：讓一個沒看過這個服務的人，在 30 秒內判斷出「它現在有沒有事」。

每個服務一張標準版面（由上而下）

第一列  SLO 與錯誤預算：目前達成率、預算剩餘、burn rate      ← 唯一該先看的
第二列  RED：QPS / 錯誤率 / 延遲分位數（含 SLO 門檻的參考線）
第三列  依賴：對下游服務、DB、快取的 RED
第四列  USE：連線池 pending、執行緒池佇列、JVM 堆、GC pause
第五列  最近部署的標記（annotation）

PromQL 一律引用 recording rule（ch03）

儀表板不要直接寫 histogram_quantile(...)——ch03 那場事故就是儀表板裡的查詢寫錯而沒人發現。正確寫法固化成 recording rule，儀表板只引用名字。

儀表板腐化：一個沒有告警的失效模式

不要做的三件事

• 不要一張圖放 20 條線：per-pod 的線放在下鑽的圖裡，總覽只放聚合值與 max by (pod)（後者能抓出 ch03 那個「單一實例異常被平均掉」的情況）。
• 不要把所有服務塞進一張儀表板：一張總覽（每個服務一列 SLO 狀態）+ 每個服務一張詳細，是比較耐用的結構。
• 不要複製貼上就生一張新的：那是儀表板數量失控的主要來源，而且複製的同時也複製了裡面寫錯的查詢。

徵狀

年度成本檢視時，財務部門標出了一筆異常：

• 可觀測性平台的年度費用，超過了所有應用服務運算成本的總和。
• 而同期的服務數量只成長了 40%，流量成長 60%——可觀測性成本卻成長了 380%。
• 更尷尬的是：Grafana 上有 214 張儀表板，過去 90 天有被開啟過的只有 23 張。

診斷

把帳單拆開來看（這件事本身就該每季做一次）：

根因：三個「預設值從來沒被檢視過」

修法（照投報比排序）

教訓

降本的優先順序（投報比由高到低）

三樣不能砍的東西

• SLI 相關的 metrics：它們是錯誤預算的原料，砍了等於失去 ch06 整套決策機制。而且 metrics 本來就是三者裡最便宜的。
• 錯誤與慢請求的 trace 與日誌：那正是你會去看的部分。降本要砍的永遠是「正常」的資料。
• 稽核與合規紀錄：它們有法定保留期，而且通常不能取樣。

把成本變成可管理的東西

① 每個服務設 ingest 配額（ch04）——同時防成本與防單一服務拖垮平台
② 對「日誌量」「時序數」的成長率設告警——不是絕對值，是斜率
③ 每季檢視：帳單拆解、TSDB top 10、儀表板使用率
④ 新服務上線的檢查表裡加一項：預估它會產生多少可觀測性資料

一個判斷保留期的簡單問題

把整軌收成一份可以直接跟著做的清單。新服務上線時照這個順序走，一天之內可以完成大部分。

第一天：能看見

□ actuator + micrometer-registry-prometheus，暴露 /actuator/prometheus
□ spring.application.name 設好，且與 trace、log 的服務名一致
□ percentiles-histogram: true（不是 percentiles）
□ SLO 門檻加進 bucket 邊界（例如 100ms,300ms,1s）
□ curl /actuator/prometheus | wc -l 檢查行數（幾萬行 = 有 cardinality 問題）
□ Prometheus 端加 sample_limit

第二天：能追蹤、能關聯

□ micrometer-tracing-bridge-otel，指向 Collector
□ logback JSON encoder，pattern 帶 traceId/spanId
□ 執行緒池套 TaskDecorator、MQ 兩端做 inject/extract
□ 開 exemplar
□ 走一次驗證：metrics → 點 exemplar → trace → 用 trace_id 查 log

第一週：能判斷、能通知

□ 定義 1~2 條關鍵旅程的 SLI（好事件/有效事件形式）
□ 觀察 4 週後再訂 SLO（先別急著訂數字）
□ 正確查詢固化成 recording rule
□ 一張標準版面的儀表板（SLO / RED / 依賴 / USE / 部署標記）
□ burn rate 多視窗告警 + runbook
□ dead man's switch
□ 每條 page 級告警都問過那七個檢查（ch07）

常見的順序錯誤

• 先做 trace 再做 metrics：連「有沒有事」都不知道時，trace 沒有入口（ch05）。
• 先訂 SLO 再看資料：拍腦袋訂的數字會變成 ch06 那場「永遠紅但沒人管」的事故。
• 先做儀表板再做告警：儀表板需要有人主動去看，而告警不用。如果只能做一個，做告警。
• 一次幫所有服務做：先在一個服務上把整條動線走通，再複製。模板做對了，後面 39 個服務是複製貼上；模板做錯了，那就是複製 39 份錯誤。

這一軌從「儀表板全綠但使用者在客訴」開始，走到 Spring 專案的設定檔。八章底下其實只有三件事。

① 測量本身有成本

可觀測性不是「收集越多越好」——每一種資料都在某個維度上付錢：

• ch02：metrics 的成本是維度的乘法，一個 label 就能讓時序數翻幾百倍。
• ch04：日誌的成本是流量的加法，而故障時流量最大。
• ch05：trace 的成本是 span 數 × 取樣率，而 head-based 取樣會丟掉你最需要的那些。
• ch07：告警的成本是人的注意力——最貴、最容易耗損、而且不會出現在帳單上。
• 本章：這些成本會隨服務數、流量、保留期相乘成長，而它自己沒有 SLO 約束自己。

② 症狀優先於原因

觀測點要站在使用者的位置，而不是機器的位置：

• ch01：白箱說一切正常時，要有一個站在使用者位置的觀測點來反駁它（TLS 那場事故）。
• ch06：SLI 從使用者旅程推導，不從機器指標推導；SLO 的驗證方式是「上次事故它有掉下來嗎」。
• ch07：對徵狀告警不對原因告警——使用者有沒有受影響，是唯一該叫醒人的理由。
• ch03：儀表板與使用者體驗矛盾時，先懷疑查詢，不要先懷疑使用者。

③ 三本柱是一條路徑，不是三個工具

metrics 發現異常 → trace 定位到哪一段 → log 確認細節。而三者之間的橋（trace_id、exemplar、統一的 service.name），比每一樣本身做得多好都重要——這條動線走不通的那一段，就是還沒接好的地方。

還有一條沒明說的線

這一軌在你的 SRE 路線上的位置

這是 SRE 補強計畫的第一軌（見 MIGRATION.md Step 11），而它被排在第一位是因為後面每一軌都會用到它的語言：

• Kubernetes：資源模型與驅逐要看飽和度指標、Pod 排查要看事件與探針——都是這一軌的方法在容器編排層的應用。
• Linux 效能診斷：USE 方法（ch01）就是那一軌的核心框架。
• CI/CD：金絲雀發布要靠 SLI 判斷「這批要不要繼續放量」，自動回滾的依據就是 burn rate（ch06）。