"Observability"
- 4.0 服務端監控的分層：容器與程序的自檢、服務網路內的探測、元件指標、應用層訊號、告警規則與分送、告警鏈的監看與使用者路徑的合成監控
以每一層監控檢查的對象、看不到的範圍與接手的那一層，把服務端監控串成一條監控鏈，以及拿它盤點一個服務時怎麼判讀缺口的性質（檢查範圍、位置、讀取與訊號失真），涵蓋自架主機、Kubernetes 與雲端託管的情形；使用者路徑那一層另寫合成監控與真實使用者監測的差別，以及盤點時各種缺口的補法
- 4.0.1 監控鏈事前偵測不到的異常：業務結果、資料正確性、到期事件、排程與背景工作、備份、安全、第三方依賴與成本的監看
監控鏈各層都正常時仍會發生的幾類異常：業務停了而程式回應正常、資料寫錯、TLS 憑證與網域到期、排程工作與佇列消費端沒跑、備份還原不回來、以帳號正常操作進行的攻擊、第三方業者停掉與帳單失控，各自要先定義的預期、檢查它的規則與承接的專章
- 4.0.2 以監控鏈盤點單機短網址服務：各層現有的監控、缺口的性質與補法，以及監控鏈事前偵測不到的異常
把一台主機上以 Docker Compose 跑的短網址服務現有的每一種監控放進監控鏈的各層，逐層判讀還開著的缺口屬於檢查範圍盲區、位置盲區、讀取缺口還是訊號失真，各自的補法，以及補上失效域以外的觀察者之前，主機整台停掉時沒有任何一層會通知的情形；另逐類查業務結果、資料正確性、安全、成本、到期事件與備份
- 4.0.3 以監控鏈盤點 Kubernetes 上的電商 checkout：叢集內的監控、託管資料庫與第三方金流各自的失效域，以及佇列消費端與外部依賴的缺口
把一個跑在託管 Kubernetes 上、有訊息佇列消費端、託管資料庫與第三方金流的電商 checkout 現有的監控放進監控鏈的各層，逐層判讀缺口與補法；另寫付款服務的 readiness 納入金流業者時對付款回呼的影響、失效域從主機換成叢集與雲端帳號之後觀察者要放在哪裡，以及業務結果、對帳、到期事件、消費端、備份、安全、第三方依賴與成本的逐類盤點
- 4.0.4 以監控鏈盤點交易撮合系統：觀察者讀數字的位置、沒有新委託時分辨市場安靜與路徑停住、分段量測延遲，以及委託序號、帳戶部位的對帳與其他監控鏈事前偵測不到的異常
把一個交易撮合系統的監控放進監控鏈的各層判讀缺口：撮合引擎單一執行緒時觀察者為什麼要從輸出日誌讀數字、沒有新委託時怎麼分辨市場安靜還是處理路徑停住、委託延遲怎麼依段量測與時鐘同步的前提、依序日誌多數節點與同一可用區的失效域，以及輸出序號的斷號、帳戶部位與行情資料的一致性這類監控鏈事前偵測不到的異常
- 可觀測性與 log 同生命週期管理
log group、metric、alarm 寫進建立資源的同一套 IaC，讓監控跟資源同生共滅，出事時追得到查得到
- 三層 log 設計
連線生命週期 log、protocol 訊息 log、使用者行為 log — 三層各自的職責、詳細程度和啟停控制
- LLM Tracing
把 LLM 應用的每次 LLM call / tool call / memory op 編成結構化 span、用 OpenTelemetry GenAI semantic conventions 標準化
- FinTech：審計證據鏈的可觀測性設計
把交易與存取事件轉成可回查證據，降低合規審核與事故判讀落差。
- 4.1 log schema 與搜尋規劃
整理 log 欄位、索引與搜尋策略
- 功能規格中的 log 點定義方法
把 log 點設計從 debug 階段前移到功能規格階段 — 每個功能的規格文件新增可觀測性欄位，列出啟動 / 步驟 / 錯誤 / 完成四類 log 點
- Gaming：高峰流量下的訊號新鮮度與 Cardinality
在高峰事件中控制訊號延遲與維度爆炸，維持告警與定位可信度。
- 4.2 metrics 與 SLI/SLO
整理 counter、gauge、histogram 與服務健康指標
- 4.3 tracing 與 context link
整理 trace id、span 與跨服務 context propagation
- 自架 log endpoint vs 商業方案的取捨判斷
自用工具用自架 log receiver（20 行 Go + grep）、商業 app 用 Sentry/Crashlytics — 判斷依據是使用者規模和 debug 需求
- Healthcare：存取可追溯性與保留邊界
在資料主權限制下，建立可追溯存取證據與分層保留策略。
- 4.4 dashboard 與 alert 設計
讓 dashboard 與 alert 對應 runbook 與容量趨勢
- 「事後補 log」vs「設計產物 log」的品質差異
事後補的 log 是救火工具、設計產物的 log 是可觀測性基礎設施 — 從一次實機修復補 log 的教訓拆解兩者在格式、覆蓋率、維護成本上的差異
- T.C4 Client-side log 缺失導致 debug 只能靠實機盲測
Flutter app 六個核心元件中只有兩個有 log（且全是 W2 hotfix 補的），連線失敗時開發者無法從任何 log 判斷失敗發生在哪一步 — 被迫用最昂貴的 debug 方式：插拔裝置反覆測試
- 4.C4 AWS：X-Ray 到 OpenTelemetry 轉換
觀測儀表從 vendor-specific SDK 轉向 OpenTelemetry 的治理重點。
- 4.5 可觀測性威脅建模（Threat Modeling）
從觀測盲區、告警失真與資料暴露風險，盤點 observability 的主要弱點
- 4.C5 Google Cloud：Cloud Trace 導入 OTLP 入口
觀測平台從專有入口擴展到 OTLP 標準通道的案例。
- 6.5 如何新增結構化記錄欄位
區分 operational log、domain event log 與狀態資料
- 可除錯的 bootstrap：把可觀測性內建進安裝腳本
安裝腳本中途失敗卻只能對著終端機捲動瞎找原因、想在 bootstrap 設計階段就讓失敗可定位時回來讀
- 4.6 SLI 量測與 SLO 訊號設計
把可靠性目標的訊號從 metric 端設計好、餵給 6.6 SLO 政策
- 4.C6 AWS：ADOT on EKS 管線遷移
從分散式 agent 組合轉成 OpenTelemetry collector 管線治理。
- 5.6 Hook 系統可觀測性設計
日誌架構、錯誤可見性、健康監控：讓 44 個 Hook 的運行狀態透明可追蹤
- Executions（執行項目）
Apps Script 平台記錄每一次函式執行的時間、耗時與狀態的頁面，用來判斷請求究竟有沒有抵達接收端
- 4.C7 Datadog：OTel 相容遷移實務
APM 採集從專有代理轉向 OTel 相容模式的治理案例。
- 4.7 Cardinality 治理與成本邊界
把 metric / log / trace 的 cardinality 與成本作為平台一級治理議題
- 4.8 訊號治理閉環
把 postmortem 揭露的偵測缺口回寫成新訊號、讓觀測能力隨事故學習成長
- 9.8 效能可觀測性
saturation metric、USE / RED method、cost dashboard
- 4.C8 Airbnb：Kubernetes 規模化下的觀測訊號治理
叢集擴縮與工作負載變動如何回寫觀測模型。
- 4.9 Continuous Profiling
把 CPU / memory / lock profile 從一次性除錯升級為持續訊號
- 4.C9 反例：OTel 遷移後訊號漂移
雙軌採集未對齊導致告警與 SLO 判讀失真。
- 4.10 Client-side / Synthetic / RUM
補 server-side 看不到的 user perceived 訊號
- Cloud Monitoring Metrics Model 與 MQL
說明 GCP Cloud Monitoring 的 monitored resource / metric descriptor 模型、MQL 與 PromQL 查詢、custom metrics 設計、alerting policy 與 Managed Prometheus 整合
- CloudWatch Logs Insights 查詢與日誌治理
說明 CloudWatch Logs Insights 查詢語法、log group 設計、retention policy、cross-account aggregation、subscription filter 與 cost governance
- Datadog 成本治理與 Agent 配置
說明 Datadog 的計價模型、custom metrics 成本控制、Agent 部署配置與常見故障模式
- High-Cardinality Query Model 與 BubbleUp
說明 Honeycomb 的 event-based 資料模型、high-cardinality 查詢設計、BubbleUp 異常偵測、SLO / burn rate、derived columns、dataset 設計與 OTLP ingestion
- Index Lifecycle Management 與 Log Pipeline
說明 Elasticsearch ILM policy 設計、data stream / rollover、Beats vs Elastic Agent 採集選擇、ingest pipeline 與 shard sizing、cross-cluster 策略與 cost governance
- LGTM Stack 組合運維：Loki + Grafana + Tempo + Mimir
說明 Grafana Stack 四個元件的責任分工、部署模式、常見故障與 dashboard provisioning
- Prometheus 容量規劃與故障模式
說明 Prometheus 單機容量邊界、cardinality 與 retention 的資源模型、常見故障模式與判讀方式
- Sentry Error Grouping 與 Fingerprinting 策略
說明 Sentry 預設 grouping 演算法、自訂 fingerprint rules、merge/unmerge 操作、grouping 不準的判讀與大量 unique errors 的治理
- OTel Collector 部署模式：agent / gateway / sidecar 與 pipeline 設計
說明 OpenTelemetry Collector 三種部署位置的責任分工、receivers/processors/exporters pipeline 設計，以及 collector 失效、記憶體壓力與 backpressure 的故障演練與容量邊界
- 4.C10 對照：規模差異下的觀測遷移
觀測遷移在不同規模團隊下的流程與風險差異。
- Datadog OTLP Ingestion 與 OTel 整合
說明 Datadog Agent 的 OTLP receiver 配置、OTel SDK 與 Datadog SDK 的 feature parity 差異、resource attribute mapping、常見故障與成本模型
- Grafana Loki 設計與操作限制
說明 Loki 的 label-based 設計哲學、跟 Elasticsearch 的根本差異、label cardinality 限制、LogQL 查詢模式與成本模型
- 4.C11 Uber：M3 大規模 Metrics 平台
從散落的 Prometheus 實例到統一 metrics 平台，處理 cardinality 爆炸、長期 retention 與跨叢集查詢的規模化挑戰。
- Cloud Logging 查詢、匯出與合規
說明 GCP Cloud Logging 的查詢語言、log router / sink 匯出架構、retention 設計、organization-level 聚合、audit log 與 PII / CMEK 合規治理
- CloudWatch Alarms 與 Composite Alarms 操作實務
說明 CloudWatch Metric Alarm、Anomaly Detection alarm、Composite Alarm 設計、alarm actions、missing data 處理與 cost 考量
- PromQL 與 Recording Rules 實務
說明 PromQL 常見查詢模式、recording rules 設計慣例、SLI 表達式寫法與效能陷阱的判讀方式
- Sentry Release Tracking 與 Session Replay
說明 Sentry release health、deploy tracking、session replay 隱私設定、performance monitoring 與 OTel 整合、self-hosted vs SaaS 取捨
- New Relic → Datadog：APM schema 對位 + agent 替換 + dashboard 重建
New Relic → Datadog 是 Type A schema diff migration — APM schema / NRQL ↔ Datadog query / agent / dashboard 全要對位；本文涵蓋 6-phase phased translation + 5 個 production 踩雷（NRQL 不直接對位 / synthetic alert 重建 / 計費模型反轉 / dashboard 自動轉失敗 / cross-platform metric 命名）
- Self-managed Prometheus → Grafana Cloud Metrics：feature × ops × cost 對照
Self-managed Prometheus → Grafana Cloud Metrics (Mimir-backed) 是 Type C operational redesign — Prometheus query API 完全相容、operational stack (HA / retention / scaling) 全託管；本文用 feature / ops / cost 三維對照表開頭、5 個 production 踩雷
- Sentry → Honeycomb：trace 不是 error、是不同 observability paradigm
Sentry → Honeycomb 是 paradigm shift — Sentry 主軸是 error tracking + transaction trace、Honeycomb 主軸是 high-cardinality wide-event observability；本文釐清 paradigm 邊界、5 個 production 踩雷（event schema 對位 / sampling 行為 / error grouping 失效 / cost 模型差 / alert paradigm shift）
- 4.11 Telemetry Pipeline 架構
把 log / metric / trace 的 agent → collector → ingest → storage → query 分層治理
- 11.12 API 消費者用量觀測：契約決策要的觀測維度、消費者身分的識別、欄位級用量與全量或抽樣的成本邊界
對外契約的變更決定各自需要的用量證據：觀測要建到什麼粒度、消費者身分怎麼認、哪些維度要全量常設、哪些可以抽樣或開取樣窗口，以及固定形狀 REST 拿不到欄位級用量的替代做法
- 4.C12 Cloudflare：內部觀測平台的三層能力
全球 300+ edge 節點的觀測架構，把 monitoring、analytics 與 forensics 拆成三個獨立能力層。
- Remote Write 與長期儲存整合
說明 Prometheus remote write 的配置、三家長期儲存後端比較（Mimir / Thanos / Cortex）、故障模式與容量規劃
- Datadog → Grafana Stack：把 $50K/month bill 拆解到 self-hosted observability
Datadog 五層計費（host APM / metric / log ingest / log retention / RUM）拆解、對位 Grafana Stack（Mimir / Loki / Tempo / Grafana / Alloy）的 5 層責任；OTel-based agent migration、5 個 production 踩雷（cardinality 爆 / log volume cost / dashboard 不直接轉 / alert routing 換邏輯 / SLO definition 差異）、cost reality check
- Self-managed ELK → Elastic Cloud：5 年 ELK 集群的 lifecycle 收尾
Self-managed ELK Stack → Elastic Cloud 是 Type C operational redesign — protocol drop-in、operational stack（cluster sizing / shard 治理 / upgrade / backup）全託管；本文按 5 年 ELK lifecycle (build → scale → degrade → save → migrate) 組織、5 個 production 踩雷
- 4.12 Audit Log 邊界與 PII 治理
把稽核訊號從 operational log 拆出、按法規與不變性治理
- 單機 Compose 的最小監控堆疊：各 exporter 的掛載、讀取設定與 Grafana 佈建
以 Docker Compose 在一台主機上接起 Prometheus、Alertmanager、Grafana 與主機、容器、資料庫、快取、入口各層的 exporter：每個掛載與旗標為什麼需要、讀取設定與規則的放法、Grafana 以檔案佈建、連接埠與帳號的權限，以及讀取對象全部 UP 時仍可能漏掉的監控
- 4.C13 Discord：從儲存問題回推觀測缺口
每次儲存遷移都暴露觀測盲區，把儲存成長問題重新框架為訊號設計問題。
- 0.12 觀測、可靠性與事故服務選型
從訊號、驗證與響應三層能力判斷操作控制服務的選型順序
- 4.13 Service Topology 與 Dependency Map
把跨服務依賴從文件變成自動發現的觀測訊號
- Prometheus 指標的視覺化工具：視覺化層的責任，與內建介面、Grafana、Perses、Kibana／OpenSearch Dashboards、託管服務的取捨
自架 Prometheus 之後把指標畫成常駐畫面的那一層承擔哪些責任（查詢與呈現、儀表板定義的保存、存取控制、告警規則放在哪一層、多種資料來源、授權與資源），Grafana 逐項對照這些責任，內建介面、Perses、Kibana／OpenSearch Dashboards 與託管服務各自的定位與成立的前提，以及前提改變時改用哪一個
- 4.14 Anomaly Detection
把 ML / statistical baseline 訊號跟 rule-based alert 整合
- 4.C14 觀測平台成本治理：從帳單驚嚇到可預測成本
觀測帳單持續超線性成長時，用 cost attribution、cardinality budget、log tiering 跟 adaptive sampling 建立可預測成本模型。
- 1.14 Production Slow Log Closed Loop
把 production slow log 從『偶爾看一下』變成『定期審視 + PR review 整合 + regression 偵測』的閉環、補 1.13 反模式清單後的操作層
- 0.13 操作控制 vertical slice 實作入口
用一個服務串起觀測證據、可靠性驗證、事故決策與回寫閉環
- 多台主機的指標收集：讀取架構、主機標籤、目標清單、監控主機的位置與主機消失的偵測
服務分到多台主機之後，Prometheus 怎麼讀到每一台：exporter 的部署位置與連接埠、中央直接讀取與各主機先收再推送的架構、代表主機的 host 標籤加在哪裡、目標清單由什麼產生，主機停掉與主機從清單上消失各自怎麼偵測，以及監控元件放在哪一台、compose 檔怎麼依主機角色拆開；附在單機上模擬第二台主機的驗證
- 4.C15 SRE Book：叫醒人的觀測路徑必須 simple and robust
觀測系統跟被觀測系統一樣複雜就會一起變 fragile；把 alerting 關鍵路徑做到最簡是切開失效域的規範根據
- 4.15 Cost Attribution / Chargeback
把 observability 成本拆到團隊、產品、環境維度
- 9.16 負載超過容量時服務的表現：變慢、請求失敗、無回應、程序終止，尖峰過去或應對切換之後仍持續的停在失效、擺盪與第二波湧入，以及應對選出的降級回應，各自的判斷標準、成因、應對與看得到它的監控層
負載超過容量（過載）時，服務呈現的結果分成變慢、請求失敗（抵達後被拒與根本沒有抵達）、無回應、程序終止，以及尖峰過去、依賴恢復或應對切換之後仍持續的停在失效、擺盪與第二波湧入；每一種的判斷標準、通常的成因與應對，哪一種先出現由先耗盡的資源與等待是否設有上限決定，影響範圍怎麼隨時間擴大，服務端監控的各層各自看得到哪一種，降級回應怎麼計數，過載在資料上造成的重複寫入、接受後遺失與讀到舊資料，以及描述一次過載要寫出的項目
- Grafana 的對外存取：SSH 通道或 VPN、經由應用入口轉送的問題、監控主機上的反向代理，與登入保護和認證的位置
Grafana 只綁本機之後，讓其他人看到它的做法：看的人能不能經由 SSH 或 VPN 連進來、有沒有固定的來源網段時各自的存取方式，SSH 通道的連法，應用入口 Nginx 加上 Grafana 的轉送之後的兩個問題，監控主機上專用反向代理的 TLS、WebSocket、GF_SERVER_ROOT_URL 與來源限制，以及 Grafana 登入失敗的帳號鎖定與認證放置
- 4.C16 Cardinality 事故爆炸：被觀測系統的異常 label 耗盡觀測後端的記憶體
事故時 error / user / request-id 維度從低基數 spike 成高基數、每個 unique 值生一條新 series、TSDB 在最需要查詢的時刻記憶體耗盡而 crash
- 4.16 Observability Readiness Review
在服務上線、重大變更與演練前檢查 log / metric / trace / alert 是否可支援事故判讀
- Alertmanager 的通知管道：路由樹與分組、webhook 與 ntfy、email 與 Slack、私密網址的檔案、心跳與通知送不出去的偵測
Alertmanager 從只在網頁上看告警，到依嚴重度送到手機與信箱：路由樹怎麼決定一則告警送到哪裡、分組與 group_wait、group_interval、repeat_interval 各控制什麼，以 webhook 接 ntfy 推播與它的訊息範本，email 與 Slack 的設定，私密網址為什麼要放在檔案裡（設定檔不展開環境變數），以及 Watchdog 心跳與通知送不出去時的偵測
- 4.C17 GitLab 2017：告警靜默失效、公開儀表板無法處理事故期間的使用者流量
備份失敗的通知信被 DMARC 拒收、沒人知道觀測已死；事故時公開監控頁無法處理同一波事故帶來的使用者流量 — 兩層共命運
- 4.17 Telemetry Data Quality
把 missing signal、schema drift、sampling bias 與 timestamp skew 變成資料品質問題
- 第三方心跳監看與外部探測服務：挑選條件、healthchecks 的 ping 與 /fail、Alertmanager 的接法與演練
以第三方服務當作監控主機失效域以外的觀察者：心跳監看服務的挑選條件與送出的告警資料留在哪裡，healthchecks 的 ping 網址、週期與寬限、/fail 與自架和託管版的回應差異，Alertmanager 送心跳與送失敗通知的 receiver 與路由順序、驗收與暫停，停掉 Alertmanager 的演練，以及外部探測服務的挑選條件
- 4.C18 Datadog 2023：觀測廠商自己掛、客戶 monitors 停止告警
monitoring-as-a-dependency 的純粹形態：把「我有沒有事」外包給單一觀測供應商、供應商跨區同時更新一起垮
- 4.18 Observability Operating Model
定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership
- 在 Kubernetes 上接上監控：kube-prometheus-stack 的元件、ServiceMonitor 與 PrometheusRule 的選取、節點標籤、儀表板 sidecar、Alertmanager 的預設路由、控制平面的讀取與單節點叢集的資源用量
在 Kubernetes 上以 kube-prometheus-stack 接上監控：chart 裝了哪些元件與 CRD，讀取對象與告警規則改以 ServiceMonitor、PrometheusRule 宣告之後由誰轉成 Prometheus 的設定，release 標籤決定哪些宣告會被選中，主機標籤改成節點標籤，儀表板經由 ConfigMap 與 sidecar 載入，Alertmanager 預設不送任何通知，以及控制平面元件只綁本機時讀不到的原因、單節點叢集上的資源用量與記憶體不足時的表現
- 4.C19 Watchdog / dead man's switch：訊號消失即告警
永遠觸發的告警交給獨立失效域的外部偵測器、它消失才代表告警管線本身死了；搭配 blackbox 外部探測互補
- 4.19 Debuggability by Design
把可診斷性前移到 API、async workflow、dependency call 與錯誤模型設計
- 4.C20 獨立 status page：對外狀態源的失效域隔離
主站掛時自建 status page 跟著掛；事故溝通通道的可用性不能依賴被溝通的那個系統、要放在獨立 domain 與 infra
- 4.20 Observability Evidence Package
把 log、metric、trace、audit 與資料品質限制包成可交接證據
- 4.C21 Tail sampling：採樣壓力下保留 error 與尾延遲樣本
head sampling 在資訊不全時就決定去留、高錯誤率下丟掉你要的 error trace；tail sampling 看完整條才依 policy 保留高診斷價值樣本
- 4.20 LLM tracing 與 observability
OpenTelemetry GenAI semantic conventions、結構化 span 設計、cost / latency 監控、failure debug 流程、跟 LLM-as-judge eval 的串接
- 4.21 Rule-level CPU Signal Governance
把規則與策略執行成本變成可觀測訊號，避免控制面小變更在資料面形成 CPU 熱點。
- 4.C22 SRE Workbook：預寫模板、mitigation-first、活文件
盲飛下把不依賴當下狀態的決策提前固化：預寫溝通模板、先止血再理解、人維護的活文件替代失效儀表板
- 4.22 Checkout API Evidence Package 實作示範
用 checkout 路徑示範 evidence package 如何交接給 release gate 與 incident decision。
- 4.C23 Google Home：客訴是監控失效時唯一生效的訊號源
內部監控沒有發現的部分失效、客訴累積約四天才把 bug 優先度推到最高、團隊始終沒有宣告事故；consumer 回報作為 telemetry 替代品的正反面實證，以及客訴沒有寫成升級條件的代價
- 4.23 觀測查詢設計
把觀測資料的讀取路徑當系統設計問題處理：三種查詢模式、storage tiering、pre-aggregation 與資源治理
- 4.C24 PagerDuty Customer Liaison：客訴的雙向 out-of-band 管道
專責角色把客戶回報聚合成 IC 可用的 scope 訊號、把確認過的狀態往外送；never lie never guess 在盲飛時尤其關鍵
- 4.24 Client-to-Server 端到端觀測串接
用一個結帳場景走完 browser click → trace context → server span → 統一 waterfall 的完整實作鏈路
- 4.25 觀測共命運失效：工具退化時的訊號與人層設計
觀測系統跟被觀測系統共享失效域、在最需要時一起退化；out-of-band 訊號、優雅降級、以及工具盲飛時客服與工程師怎麼還能應對
- 4.26 單機容器服務的流量與資源監控：各層的訊號、Prometheus 與 exporter、監控所在層的盲區
健康檢查之外的流量與資源監控：入口、應用程式、容器、主機與資料庫等服務內部各層的訊號從哪裡收、用哪一個 exporter，Prometheus 加 exporter、單一 agent、開箱即用工具與臨時查看指令的取捨，單次取樣與時間窗的差別，監控裝在虛擬機裡時看不到主機的 CPU 負載、看到的磁碟要分清是哪一顆，以及每接上一個來源的驗收與偵測容器停止的寫法；cAdvisor 與 node_exporter 在 OrbStack 上實測過
- 4.27 主機過載時的監控告警：可用與變慢分開判斷、依原因抑制、監控自身的等待
多個服務共用一台主機而主機過載時，各服務的探測與告警會一起失敗：可用性與延遲分成兩個判斷的寫法、間歇的條件怎麼持續成立、以主機飽和抑制各服務變慢的規則與它的取捨、以合成告警驗證抑制、抑制藏起各服務受影響程度的差別、探測與 Prometheus 自己也在等 CPU 時的訊號，以及讓監控不比服務先失效的資源隔離；以一次開發環境的過載為例
- 4.28 單台主機的監控盲區與失效域以外的觀察者：主機停機、使用者路徑中斷與告警鏈中斷，心跳監看與外部探測各自回答的問題與位置，以及與內部探測並排的判讀
服務與監控放在同一台主機時監控結構上看不到的故障：主機整台停掉、使用者到主機的路徑中斷、告警鏈停掉與通知送不出去；從失效域以外送出訊號的心跳監看與外部探測各自回答的問題與成立條件，觀察者由第三方服務、另一個失效域的主機（含兩台主機互相監看）或另一個業者的排程平台提供時的差別，以及心跳監看、外部探測與主機內部探測並排時的判讀
- 4.29 值班的例行檢查：接班檢查與每週營運會議讀的訊號、交班紀錄的內容，以及例行檢查項目改寫成告警規則的條件
告警刻意不呼叫值班的訊號由值班定時讀：接班時讀上一班的交班紀錄、生效中的告警靜音、只送通知的 warning、error budget 的走向、排程工作與心跳檢查項目、到期事件、容量走向、近期變更與客服單量，各自防的是哪一種情形；交班紀錄要寫的內容；每週營運會議讀的告警雜訊、值班負擔與重複出現的客服回報；以及一個檢查項目什麼時候該改寫成告警規則
- Log Schema
說明結構化 log 欄位如何支援搜尋、關聯與事故排查
- Metrics
說明指標如何描述服務趨勢、容量與健康狀態
- SLI / SLO
說明服務品質指標與服務品質目標如何連接產品承諾
- Trace Context
說明跨服務 request 如何用 trace context 串起路徑與耗時
- 監控資料的雙重用途：行為分析與訊號治理
同一份 event data 如何同時服務行為分析（funnel / cohort / attribution）和訊號治理（cardinality / cost / signal governance）— 格式交叉、治理衝突與分流架構
- Retention
說明資料或事件保留多久，以及保留期限如何影響重放與成本
- Histogram
說明 histogram 如何用分桶統計延遲、大小與分布
- Percentile
說明 p95 與 p99 如何描述長尾延遲與使用者體驗
- Error Budget
說明 SLO 允許的失敗額度如何影響發版與可靠性投入
- Burn Rate
說明 error budget 消耗速度如何支援告警與事故分級
- Correlation ID
說明跨事件或跨服務的關聯識別碼如何支援排障
- Trace ID
說明分散式追蹤中同一條呼叫路徑的識別碼
- Span
說明 trace 中一段工作如何記錄耗時、狀態與關聯
- Symptom-Based Alert
說明告警應優先偵測使用者可感知症狀
- Alert Fatigue
說明過多低品質告警如何降低 on-call 反應品質
- Trace
說明 trace 如何重建跨服務請求的路徑、耗時與依賴關係
- Dashboard
說明 dashboard 如何把關鍵訊號組成可判讀的服務狀態畫面
- Alert
說明 alert 如何把需要處理的服務症狀轉成可行動通知
- Runbook
說明 runbook 如何把事故判斷與操作步驟標準化
- Search Index
說明搜尋索引如何承擔全文檢索、排序與查詢體驗
- Incident Timeline
說明事故時間線如何支援判斷、溝通與復盤
- On-Call
說明值班制度如何承接告警、事故分級與升級流程
- Ownership
說明 ownership 如何把問題、決策與交接責任固定到可執行角色
- Continuous Profiling
在 production 持續取得低 overhead profile 的觀察方法
- Action Item Closure
說明事故行動項如何被驗證完成，而不是只停留在待辦清單
- Time Range
說明證據、查詢與事故判讀如何用時間窗保留可回放上下文
- Query Link
說明證據包如何保存可重跑查詢入口，而不是只保留截圖或口頭結論
- Data Quality
說明證據欄位如何標示 completeness、freshness、sampling 與資料限制
- Confidence
要在證據包、事故候選紀錄或決策紀錄上標示證據可信到什麼程度，或遇到 needs follow-up 與 external-only 兩種值不知道怎麼對應時，查各等級的意思與兩套值域的關係
- Known Gap
說明證據包如何明確保存已知缺口，避免下游高估證據完整性
- Recording Rule
說明把 query-time 聚合計算推到寫入時的 pre-aggregation 機制
- Rollup / Downsampling
說明時間序列資料隨時間降低精度以控制儲存成本與查詢效能的機制
- Storage Tiering
說明按資料熱度分層儲存以平衡查詢速度、儲存成本與保留完整性的機制
- Materialized View
說明預先計算並儲存查詢結果以加速讀取的資料結構
- Coverage vs Completion Rate（覆蓋率與完成率）
說明同一個百分比的分母由誰列舉，決定它衡量的是全體的覆蓋率還是管理範圍內的完成率
- Query Log（SQL 語句記錄）
要確認 ORM 或資料存取函式庫實際送出了哪些 SQL、交易的 begin 與 commit 有沒有送出，或在正式環境追查慢查詢與某一筆資料被誰改過時，查應用程式端與資料庫端的語句記錄各記了什麼
- Prometheus Exporter（指標轉接程式）
要監控一個不會自己輸出 Prometheus 指標的系統（主機、容器、資料庫、快取、Nginx）時，查 exporter 做什麼、它和應用程式自己開的 /metrics 差在哪，以及 exporter 讀得到資料卻缺標籤、或者讀不到它所在層以外的機器時怎麼發現
- Load Average（負載平均）
看到 uptime 或 node_load1 的數字、要判斷主機是不是在排隊時，查 load average 算的是什麼、除以核心數怎麼讀、Linux 為什麼把等磁碟的行程也算進去，以及在虛擬機與容器裡量到的值代表誰
- CPU Steal Time（被虛擬化層拿走的 CPU 時間）
雲端虛擬機的服務沒有改動、CPU 用量也不高卻變慢時，查 steal time 記的是什麼、怎麼從 node_exporter 算出比例、什麼環境量不到它，以及升高時的處置
- Alert Inhibition（告警抑制）
同一個原因觸發一串症狀告警、值班人員被淹沒，或要在 Alertmanager 寫 inhibit_rules 時，查抑制做什麼、它和分組與靜音的差別、哪些症狀適合被抑制，以及它安靜失效的幾種條件
- Relabeling（標籤改寫）
Prometheus 的讀取對象少了、多了、帶錯標籤，或想在寫入前丟掉某些指標時，查 relabel 規則在哪幾個時間點執行、各自讀得到哪些標籤，以及規則沒有生效時怎麼逐條看出是哪一條規則丟掉或改寫了它
- Failure Domain（失效域）
判斷兩個元件會不會因為同一件事一起停掉、備援或監控是否獨立於被保護的對象時，查它們共用了哪些會失效的依賴
- Dead Man's Switch（心跳監看）
需要知道監控或排程工作自己停掉了、而它停掉時發不出任何告警時，以「時限內沒收到訊號就通知」反過來判斷
- Synthetic Monitoring（合成監控）
要知道使用者從外面連不連得到服務、或分不清某個「外部探測」從哪裡發出時，查合成監控以排程的請求模擬使用者的做法、探測端的位置怎麼決定它量得到什麼，以及它與真實使用者監測的差別
- White-box and Black-box Monitoring（白箱與黑箱監控）
分不清一個監控是從外部行為判斷還是讀取內部狀態、或把「黑箱探測」當成一定站在服務以外的觀察者時，查白箱與黑箱監控各回答什麼問題、各自看不到什麼，以及黑箱為什麼不等於在失效域以外
- Alert Silence（告警靜音）
維護期間要暫停某些告警的通知、或懷疑告警該響而沒響時，查 Alertmanager 的 silence 做什麼、它與抑制及週期性靜音時段的差別、它過期之前會藏住什麼，以及怎麼列出與監看還沒過期的靜音
- Step Change（步階變化）
判斷一個指標或一項設定的改變能不能從量測的趨勢預測、要用趨勢外推還是跟基準比對才偵測得到時，區分步階變化與逐步累積的變化
- 終端機看 nginx 請求：GoAccess、ngxtop 與何時該用 pipeline 而非 TUI
要在終端機即時看 nginx／web 伺服器請求、在 GoAccess 與 ngxtop 之間選、或判斷該用當下排查的 TUI 還是持續監控的 metrics pipeline 時回來讀
- SQLite Observability and Runbook
SQLite production runbook、backup evidence、WAL growth、busy errors、disk usage、restore drill 與 incident route