"Observability"
- 可觀測性與 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 是可觀測性基礎設施 — 從 app_tunnel 的 W2 hotfix 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 的運行狀態透明可追蹤
- 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 分層治理
- 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 踩雷
- 0.12 觀測、可靠性與事故服務選型
從訊號、驗證與響應三層能力判斷操作控制服務的選型順序
- 4.12 Audit Log 邊界與 PII 治理
把稽核訊號從 operational log 拆出、按法規與不變性治理
- 4.C13 Discord：從儲存問題回推觀測缺口
每次儲存遷移都暴露觀測盲區，把儲存成長問題重新框架為訊號設計問題。
- 0.13 操作控制 vertical slice 實作入口
用一個服務串起觀測證據、可靠性驗證、事故決策與回寫閉環
- 4.13 Service Topology 與 Dependency Map
把跨服務依賴從文件變成自動發現的觀測訊號
- 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 反模式清單後的操作層
- 4.15 Cost Attribution / Chargeback
把 observability 成本拆到團隊、產品、環境維度
- 4.16 Observability Readiness Review
在服務上線、重大變更與演練前檢查 log / metric / trace / alert 是否可支援事故判讀
- 4.17 Telemetry Data Quality
把 missing signal、schema drift、sampling bias 與 timestamp skew 變成資料品質問題
- 4.18 Observability Operating Model
定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership
- 4.19 Debuggability by Design
把可診斷性前移到 API、async workflow、dependency call 與錯誤模型設計
- 4.20 LLM tracing 與 observability
OpenTelemetry GenAI semantic conventions、結構化 span 設計、cost / latency 監控、failure debug 流程、跟 LLM-as-judge eval 的串接
- 4.20 Observability Evidence Package
把 log、metric、trace、audit 與資料品質限制包成可交接證據
- 4.21 Rule-level CPU Signal Governance
把規則與策略執行成本變成可觀測訊號，避免控制面小變更在資料面形成 CPU 熱點。
- 4.22 Checkout API Evidence Package 實作示範
用 checkout 路徑示範 evidence package 如何交接給 release gate 與 incident decision。
- 4.23 觀測查詢設計
把觀測資料的讀取路徑當系統設計問題處理：三種查詢模式、storage tiering、pre-aggregation 與資源治理
- 4.24 Client-to-Server 端到端觀測串接
用一個結帳場景走完 browser click → trace context → server span → 統一 waterfall 的完整實作鏈路
- 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
說明證據包如何標示 confirmed、suspected 或 needs follow-up 的判讀信心
- Known Gap
說明證據包如何明確保存已知缺口，避免下游高估證據完整性
- Recording Rule
說明把 query-time 聚合計算推到寫入時的 pre-aggregation 機制
- Rollup / Downsampling
說明時間序列資料隨時間降低精度以控制儲存成本與查詢效能的機制
- Storage Tiering
說明按資料熱度分層儲存以平衡查詢速度、儲存成本與保留完整性的機制
- Materialized View
說明預先計算並儲存查詢結果以加速讀取的資料結構
- 終端機看 nginx 請求：GoAccess、ngxtop 與何時該用 pipeline 而非 TUI
在終端機即時看 nginx／web 伺服器請求的工具：GoAccess 即時儀表板、ngxtop top 風格，含 log 格式對齊的 gotcha；以及「當下排查用 TUI、持續監控用 metrics pipeline」的使用時機分界。
- SQLite Observability and Runbook
SQLite production runbook、backup evidence、WAL growth、busy errors、disk usage、restore drill 與 incident route