"Grafana"
- 斷網環境的監控與可觀測性
Self-hosted 監控（Prometheus + Grafana）、離線 log 收集（Loki / ELK）、不能 phone home 的告警、NTP 時間同步
- LGTM Stack 組合運維：Loki + Grafana + Tempo + Mimir
說明 Grafana Stack 四個元件的責任分工、部署模式、常見故障與 dashboard provisioning
- Grafana Loki 設計與操作限制
說明 Loki 的 label-based 設計哲學、跟 Elasticsearch 的根本差異、label cardinality 限制、LogQL 查詢模式與成本模型
- 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
- Prometheus 指標的視覺化工具：視覺化層的責任，與內建介面、Grafana、Perses、Kibana／OpenSearch Dashboards、託管服務的取捨
自架 Prometheus 之後把指標畫成常駐畫面的那一層承擔哪些責任（查詢與呈現、儀表板定義的保存、存取控制、告警規則放在哪一層、多種資料來源、授權與資源），Grafana 逐項對照這些責任，內建介面、Perses、Kibana／OpenSearch Dashboards 與託管服務各自的定位與成立的前提，以及前提改變時改用哪一個
- Grafana 的對外存取：SSH 通道或 VPN、經由應用入口轉送的問題、監控主機上的反向代理，與登入保護和認證的位置
Grafana 只綁本機之後，讓其他人看到它的做法：看的人能不能經由 SSH 或 VPN 連進來、有沒有固定的來源網段時各自的存取方式，SSH 通道的連法，應用入口 Nginx 加上 Grafana 的轉送之後的兩個問題，監控主機上專用反向代理的 TLS、WebSocket、GF_SERVER_ROOT_URL 與來源限制，以及 Grafana 登入失敗的帳號鎖定與認證放置