Observability as Code: Managing Dashboards and Alerts with Terraform のカバー画像

Samson Tanimawo

Click-Opsダッシュボードの問題

チームには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の隣に置かれます。サービスをデプロイするとき、observabilityも一緒にデプロイします。

複利効果のある利点

1. 所有権が明確。 ファイルにはCODEOWNERSエントリがあり、PRにはレビューが必要です。

2. ダッシュボードが自動更新される。 サービス名を変更すると？Terraformのリファクタリングがすべてのダッシュボードに反映されます。

3. ドリフト検知。 誰かがUIで「save as」をクリックしてダッシュボードが同期されなくなった場合、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

1つの信頼できる情報源を選びましょう。混在させないでください。

実例

サービス名を受け取り、完全なobservabilityスタックを生成するモジュールがあります。

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

1回のモジュール呼び出しで、3つのダッシュボード、8つのアラート、2つのSLO、Slackチャンネルの紐付け、PagerDutyのエスカレーションポリシーが作成されます。

一番難しい部分

コードは簡単です。難しいのは：

  1. 既存のclick-opsダッシュボードの移行 — 2週間を見積もる
  2. エンジニアにUIではなくYAML/HCLを編集させる — 3ヶ月間のリマインダーを見積もる
  3. UI編集のブロック — 一部のツールではダッシュボードを読み取り専用に設定できます
  4. アラート変更のレビュー — PRレビュアーには文脈が必要です

避けるべきアンチパターン

エンジニアが欲しいカスタムチャートごとにTerraformを書かないでください。誰も理解できない500行のダッシュボードモジュールにつながります。

代わりに、標準ダッシュボード（golden signals、RED/USE、SLO burn rate）をモジュールとして定義しましょう。エンジニアが独自のカスタムダッシュボードをUIで追加したい場合は追加させても構いませんが、「explore-only」（アラート対象外）とマークしてください。

コアobservability = コード。実験的な探索 = UI。

移行戦略

週1：1つのサービスを選び、そのダッシュボードをTerraformに変換
週2：Terraformにアラート＋SLOを追加
週3：UI版を削除
週4：パターンからモジュールを作成
2ヶ月目：さらに10のサービスに展開
3ヶ月目：すべての新規サービスにモジュールの使用を必須化

6ヶ月後にはclick-opsの負債はなくなり、observabilityは再現可能になります。

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