"Prometheus"
- 斷網環境的監控與可觀測性
Self-hosted 監控（Prometheus + Grafana）、離線 log 收集（Loki / ELK）、不能 phone home 的告警、NTP 時間同步
- Prometheus 容量規劃與故障模式
說明 Prometheus 單機容量邊界、cardinality 與 retention 的資源模型、常見故障模式與判讀方式
- 4.C11 Uber：M3 大規模 Metrics 平台
從散落的 Prometheus 實例到統一 metrics 平台，處理 cardinality 爆炸、長期 retention 與跨叢集查詢的規模化挑戰。
- PromQL 與 Recording Rules 實務
說明 PromQL 常見查詢模式、recording rules 設計慣例、SLI 表達式寫法與效能陷阱的判讀方式
- 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 踩雷
- Remote Write 與長期儲存整合
說明 Prometheus remote write 的配置、三家長期儲存後端比較（Mimir / Thanos / Cortex）、故障模式與容量規劃
- 單機 Compose 的最小監控堆疊：各 exporter 的掛載、讀取設定與 Grafana 佈建
以 Docker Compose 在一台主機上接起 Prometheus、Alertmanager、Grafana 與主機、容器、資料庫、快取、入口各層的 exporter：每個掛載與旗標為什麼需要、讀取設定與規則的放法、Grafana 以檔案佈建、連接埠與帳號的權限，以及讀取對象全部 UP 時仍可能漏掉的監控
- Prometheus 指標的視覺化工具：視覺化層的責任，與內建介面、Grafana、Perses、Kibana／OpenSearch Dashboards、託管服務的取捨
自架 Prometheus 之後把指標畫成常駐畫面的那一層承擔哪些責任（查詢與呈現、儀表板定義的保存、存取控制、告警規則放在哪一層、多種資料來源、授權與資源），Grafana 逐項對照這些責任，內建介面、Perses、Kibana／OpenSearch Dashboards 與託管服務各自的定位與成立的前提，以及前提改變時改用哪一個
- 多台主機的指標收集：讀取架構、主機標籤、目標清單、監控主機的位置與主機消失的偵測
服務分到多台主機之後，Prometheus 怎麼讀到每一台：exporter 的部署位置與連接埠、中央直接讀取與各主機先收再推送的架構、代表主機的 host 標籤加在哪裡、目標清單由什麼產生，主機停掉與主機從清單上消失各自怎麼偵測，以及監控元件放在哪一台、compose 檔怎麼依主機角色拆開；附在單機上模擬第二台主機的驗證
- Grafana 的對外存取：SSH 通道或 VPN、經由應用入口轉送的問題、監控主機上的反向代理，與登入保護和認證的位置
Grafana 只綁本機之後，讓其他人看到它的做法：看的人能不能經由 SSH 或 VPN 連進來、有沒有固定的來源網段時各自的存取方式，SSH 通道的連法，應用入口 Nginx 加上 Grafana 的轉送之後的兩個問題，監控主機上專用反向代理的 TLS、WebSocket、GF_SERVER_ROOT_URL 與來源限制，以及 Grafana 登入失敗的帳號鎖定與認證放置
- Alertmanager 的通知管道：路由樹與分組、webhook 與 ntfy、email 與 Slack、私密網址的檔案、心跳與通知送不出去的偵測
Alertmanager 從只在網頁上看告警，到依嚴重度送到手機與信箱：路由樹怎麼決定一則告警送到哪裡、分組與 group_wait、group_interval、repeat_interval 各控制什麼，以 webhook 接 ntfy 推播與它的訊息範本，email 與 Slack 的設定，私密網址為什麼要放在檔案裡（設定檔不展開環境變數），以及 Watchdog 心跳與通知送不出去時的偵測
- 第三方心跳監看與外部探測服務：挑選條件、healthchecks 的 ping 與 /fail、Alertmanager 的接法與演練
以第三方服務當作監控主機失效域以外的觀察者：心跳監看服務的挑選條件與送出的告警資料留在哪裡，healthchecks 的 ping 網址、週期與寬限、/fail 與自架和託管版的回應差異，Alertmanager 送心跳與送失敗通知的 receiver 與路由順序、驗收與暫停，停掉 Alertmanager 的演練，以及外部探測服務的挑選條件
- 在 Kubernetes 上接上監控：kube-prometheus-stack 的元件、ServiceMonitor 與 PrometheusRule 的選取、節點標籤、儀表板 sidecar、Alertmanager 的預設路由、控制平面的讀取與單節點叢集的資源用量
在 Kubernetes 上以 kube-prometheus-stack 接上監控：chart 裝了哪些元件與 CRD，讀取對象與告警規則改以 ServiceMonitor、PrometheusRule 宣告之後由誰轉成 Prometheus 的設定，release 標籤決定哪些宣告會被選中，主機標籤改成節點標籤，儀表板經由 ConfigMap 與 sidecar 載入，Alertmanager 預設不送任何通知，以及控制平面元件只綁本機時讀不到的原因、單節點叢集上的資源用量與記憶體不足時的表現
- 4.26 單機容器服務的流量與資源監控：各層的訊號、Prometheus 與 exporter、監控所在層的盲區
健康檢查之外的流量與資源監控：入口、應用程式、容器、主機與資料庫等服務內部各層的訊號從哪裡收、用哪一個 exporter，Prometheus 加 exporter、單一 agent、開箱即用工具與臨時查看指令的取捨，單次取樣與時間窗的差別，監控裝在虛擬機裡時看不到主機的 CPU 負載、看到的磁碟要分清是哪一顆，以及每接上一個來源的驗收與偵測容器停止的寫法；cAdvisor 與 node_exporter 在 OrbStack 上實測過
- 4.27 主機過載時的監控告警：可用與變慢分開判斷、依原因抑制、監控自身的等待
多個服務共用一台主機而主機過載時，各服務的探測與告警會一起失敗：可用性與延遲分成兩個判斷的寫法、間歇的條件怎麼持續成立、以主機飽和抑制各服務變慢的規則與它的取捨、以合成告警驗證抑制、抑制藏起各服務受影響程度的差別、探測與 Prometheus 自己也在等 CPU 時的訊號，以及讓監控不比服務先失效的資源隔離；以一次開發環境的過載為例
- Prometheus Exporter（指標轉接程式）
要監控一個不會自己輸出 Prometheus 指標的系統（主機、容器、資料庫、快取、Nginx）時，查 exporter 做什麼、它和應用程式自己開的 /metrics 差在哪，以及 exporter 讀得到資料卻缺標籤、或者讀不到它所在層以外的機器時怎麼發現
- Relabeling（標籤改寫）
Prometheus 的讀取對象少了、多了、帶錯標籤，或想在寫入前丟掉某些指標時，查 relabel 規則在哪幾個時間點執行、各自讀得到哪些標籤，以及規則沒有生效時怎麼逐條看出是哪一條規則丟掉或改寫了它