Cover image for Observability as Code: Managing Dashboards and Alerts with Terraform

Samson Tanimawo

點擊操作式儀表板的問題

你的團隊擁有 200 個儀表板。你不知道它們屬於誰。一半已經損壞，其餘顯示的都是昨天的狀態。

這就是 click-ops 債務，而且累積速度比程式碼債務更快。

Observability as Code

每一個儀表板、警示以及 SLO 定義，都應該與你的服務程式碼一起存放在 Git 儲存庫中。

resource "datadog_dashboard" "api_gateway" {
  title       = "API Gateway - Golden Signals"
  description = "Owner: @platform-team"
  layout_type = "ordered"

  widget {
    timeseries_definition {
      title = "Request Rate (per second)"
      request {
        q = "sum:api.requests{service:gateway}.as_rate()"
      }
    }
  }

  widget {
    timeseries_definition {
      title = "P99 Latency"
      request {
        q = "max:api.latency{service:gateway}.as_count()"
      }
    }
  }
}

Enter fullscreen mode Exit fullscreen mode

這段程式碼會與服務的 main.tf 放在一起。當你部署服務時，也會一併部署可觀測性設定。

持續累積的效益

1. 擁有權清楚。 檔案會有 CODEOWNERS 設定，PR 需要經過審核。

2. 儀表板自動更新。 重新命名服務？Terraform 重構會自動套用到所有儀表板。

3. 漂移偵測。 有人在 UI 中點擊「另存新檔」，導致儀表板與程式碼不同步，terraform plan 會偵測到。

4. 正式環境前審核。 警示變更需經過 PR 審核，不再出現「誰設定這個門檻？」的情況。

各平台工具 

datadog:
  provider: DataDog/datadog
  resources: datadog_monitor, datadog_dashboard, datadog_slo

grafana:
  provider: grafana/grafana
  resources: grafana_dashboard, grafana_alert_rule

prometheus:
  approach: YAML files in Git, deployed by ArgoCD
  resources: alert rules, recording rules

new_relic:
  provider: newrelic/newrelic
  resources: newrelic_alert_policy, newrelic_dashboard

Enter fullscreen mode Exit fullscreen mode

選擇單一事實來源，不要混用。

實際範例

我們有一個模組，只要提供服務名稱，就能產生完整的可觀測性堆疊：

module "service_observability" {
  source = "./modules/observability"

  service_name = "payment-processor"
  team_slack   = "#payments"
  severity_map = {
    error_rate_pct = 1.0
    p99_latency_ms = 500
    saturation_pct = 80
  }

  slo_targets = {
    availability = 0.9995
    latency_p99  = 0.99
  }
}

Enter fullscreen mode Exit fullscreen mode

只需一次模組呼叫，就能建立：3 個儀表板、8 個警示、2 個 SLO、Slack 頻道綁定，以及 PagerDuty 升級政策。

最困難的部分

程式碼很容易撰寫，困難的地方在於：

  1. 遷移現有的 click-ops 儀表板 — 預估需 2 週
  2. 讓工程師改用 YAML/HCL 而非 UI — 預估需 3 個月的不斷提醒
  3. 封鎖 UI 編輯 — 部分工具允許將儀表板設為唯讀
  4. 審核警示變更 — PR 審核者需要足夠的上下文

要避免的反模式

不要為工程師想要的每個自訂圖表都撰寫 Terraform。那會導致出現 500 行、無人理解的儀表板模組。

相反地，請將標準儀表板（golden signals、RED/USE、SLO burn rate）定義為模組。如果工程師想要在 UI 中加入自訂儀表板，可以標記為「僅供探索」（不設定警示）。

核心可觀測性 = 程式碼。實驗性探索 = UI。

遷移策略

第 1 週：挑選 1 個服務，將其儀表板轉換為 Terraform
第 2 週：將警示 + SLO 加入 Terraform
第 3 週：刪除 UI 版本
第 4 週：根據模式建立模組
第 2 個月：推廣至另外 10 個服務
第 3 個月：要求所有新服務都使用該模組

六個月後，你的 click-ops 債務將消失，可觀測性也將變得可重現。

作者：Dr. Samson Tanimawo
BSc · MSc · MBA · PhD
Founder & CEO, Nova AI Ops. https://novaaiops.com