儀表板建置器 是做什麼的?
當任務是建置一個可供運維人員操作的儀表板時使用。
目標不是「顯示每個指標」,目標是回答:
- 系統健康嗎?
- 瓶頸在哪裡?
- 什麼變了?
- 應該採取什麼行動?
使用時機
- "建置 Kafka 監控儀表板"
- "為 Elasticsearch 建立 Grafana 儀表板"
- "為此服務建立 SigNoz 儀表板"
- "將這個指標清單轉換為真正的運維儀表板"
準則
- 不要從視覺佈局開始;要從運維問題開始
- 不要因為某個指標存在就包含它
- 不要將健康、吞吐量和資源面板混雜在一起而不加結構
- 不要發送沒有標題、單位和合理閾值的面板
工作流程
1. 定義運維問題
圍繞以下方面組織:
- 健康 / 可用性
- 延遲 / 效能
- 吞吐量 / 體積
- 飽和度 / 資源
- 服務特定的風險
2. 研究目標平台架構
首先檢查現有儀表板:
- JSON 結構
- 查詢語言
- 變數
- 閾值樣式
- 區段佈局
3. 建置最小可用儀表板
推薦結構:
- 概述
- 效能
- 資源
- 服務特定區段
4. 刪除虛榮面板
每個面板都應該回答一個實際問題。如果不能,就刪除它。
範例面板組
Elasticsearch
- 叢集健康狀態
- 分片分配
- 搜尋延遲
- 索引速率
- JVM 堆疊 / GC
Kafka
- 代理程式數量
- 副本不足的分區
- 訊息進 / 出
- 消費者滯後
- 磁碟與網路壓力
API 閘道器 / 入口
- 請求速率
- p50 / p95 / p99 延遲
- 錯誤率
- 上游健康狀態
- 活躍連線數
品質檢查清單
- 有效的儀表板 JSON
- 清晰的區段分組
- 標題和單位已存在
- 閾值 / 狀態顏色有意義
- 存在常見篩選條件的變數
- 預設時間範圍和重新整理間隔合理
- 沒有對運維無價值的虛榮面板
相關技能
research-opsbackend-patternsterminal-ops