grafana-util docs

SRE / 維運角色導讀

這一頁給負責日常維運、健康檢查、回放與故障處理的人。先把 live / staged 兩套流程看懂,再把匯出、匯入與變更前檢查串起來。

適用對象

  • 值班 SRE、平台維運、Grafana operator
  • 需要做健康檢查、盤點、回放或漂移比對的人
  • 需要在變更前後做檢查把關的人

主要目標

  • 先用 status liveoverview live 確認現況
  • 先在 change inspectchange checkchange preview 擋掉不合理的變更包
  • 先用 --dry-run 看匯入結果,再決定要不要真的套用
  • 需要時才用 direct Basic auth 做 break-glass

採用前後對照

  • 以前:SRE 要靠一串零散指令自己拼出 readiness、scope 與 replay 風險。
  • 現在:先用可重複的 profile,接著走 live check、staged review,最後才進 apply。

成功判準

  • 你能判斷憑證到底看不看得到你要處理的範圍。
  • 你能分清楚 live read、staged review 和 apply 是不同路徑。
  • 你有一條能穩定處理 dashboard、alert 與 access 的維運路線。

失敗時先檢查

  • 如果 token scope 比任務還窄,先停下來換一張真的看得到該範圍的憑證。
  • 如果 live check 成功、apply 失敗,先檢查寫入權限與 staged input,不要先懷疑 renderer。
  • 如果你還說不出任務屬於哪條 lane,先回去看工作流章節,不要直接改 live。

典型維運任務

  • 維護前先做即時整備度檢查
  • 盤點跨 org 的 dashboard、data source 或 alert
  • 在 apply 之前先做 staged inspect、check、preview 與 dry-run
  • 在備份、漂移檢查或災難復原時做匯出與比對

建議的連線與秘密資料處理方式

  1. 日常維運優先用 --profile,並把密碼或 token 放在環境變數或 secret store。
  2. 出現緊急處理或尚未建立 profile 時,再用 direct Basic auth。
  3. token 只適合權限範圍很清楚的讀取或單一 org 自動化,不要假設它能完成所有管理動作。
  4. 跨 org、管理員層級與 service account 類作業,通常還是需要更完整的管理員憑證。

建議先跑的 5 個指令

# 用途:建議先跑的 5 個指令。
grafana-util status live --profile prod --output-format table
# 用途:建議先跑的 5 個指令。
grafana-util overview live --profile prod --output-format interactive
# 用途:建議先跑的 5 個指令。
grafana-util change inspect --workspace .
# 用途:建議先跑的 5 個指令。
grafana-util change check --workspace . --fetch-live --output-format json
# 用途:建議先跑的 5 個指令。
grafana-util change preview --workspace . --fetch-live --output-format json
# 用途:建議先跑的 5 個指令。
grafana-util dashboard export --output-dir ./backups --overwrite --progress

如果你要先處理存取層資產,可以把 dashboard export 換成:

# 用途:如果你要先處理存取層資產,可以把 dashboard export 換成。
grafana-util access org list --table

接下來先讀哪些章節

建議同時開著哪些指令頁

常見錯誤與限制

  • 不要把 status live 當成部署前的唯一檢查;change check 和 staged 驗證還是要跑。
  • 不要在匯入前略過 --dry-run,尤其是會覆寫既有資產時。
  • 不要假設 token 看得到所有 org,--all-orgs 與管理操作常會受 scope 限制。
  • 不要把 tokens.json 當一般輸出檔;它包含敏感資訊。
  • 不要直接進行破壞性操作,先 inspect、再 check、再 preview,最後才套用。

什麼叫做處於良好的維運姿勢

  • 你知道目前的 credential 到底能不能看見要處理的 org 或管理範圍
  • 你能分清楚即時讀取、staged review 與真正 apply 是三種不同流程
  • 重大變更前會先跑 preflight 或 dry-run
  • 問題一旦從 status 轉進 dashboard、alert 或 access,你知道要切到哪一頁

什麼時候切到更深的文件

下一步