Karma Dashboard: SREのためのAlertmanager集約術 – ITFROMZERO

Table of Contents

午前2時の悪夢と分散したアラート管理の課題

深夜2時、PagerDutyの呼び出し音が鳴り響きます。私は飛び起き、目をこすりながらノートPCを開きました。システムはマルチクラスター規模で大規模な障害に見舞われていました。私の会社ではAWS、Google Cloud、そしてオンプレミスのクラスターでKubernetesを運用しており、それぞれの環境に独自のPrometheusとAlertmanagerが構築されています。

その時、各クラスターの状況を確認するためにブラウザのタブを7つも開かなければなりませんでした。あるタブではデータベースのエラー、別のタブではレイテンシの急上昇。AlertmanagerのデフォルトUIは非常にシンプルすぎて、原因の特定に時間がかかりました。そこで気づいたのです。「アラート疲れ（Alert fatigue）」は、アラートの量だけでなく、管理ツールがバラバラであることも原因なのだと。

あの「忘れられない」夜の後、私はこれらすべての混乱を一画面に集約する方法を探し始めました。そして見つけた救世主が「Karma」です。

Alertmanager管理にどのツールを選ぶべきか？

Karmaに決める前に、いくつか有名な選択肢を検討しました。以下は私の実体験に基づく比較です：

1. AlertmanagerのデフォルトUI

メリット: 標準機能として提供されており、追加のリソースが不要。
デメリット: UIが古臭い。スマートなグルーピング機能がなく、複数のソースからのアラートを同時に表示することができない。

2. Grafanaへの統合

メリット: 見慣れた綺麗なダッシュボードを活用できる。
デメリット: Grafanaは可視化（visualization）には優れているが、アラートのライフサイクル管理には特化していない。100件以上のアラートが同時に発生すると操作が重くなり、迅速なサイレンス設定が難しい。

3. Karma Dashboard（最適な選択肢）

メリット: 非常に軽量でAlertmanagerに特化. 強力な正規表現フィルタリング、柔軟なラベルグルーピング、そして無制限のバックエンド接続をサポート。
デメリット: このサービスを維持するための運用コストがわずかに発生する。

なぜKarmaはSREにとって「運命のツール」なのか？

最も感動したのはフィルタリング（Filtering）機能です。システムが大規模になると、大量の「ゴミ」アラートに埋もれてしまいます. Karmaなら、@state=active severity=critical cluster=prod といった短いクエリを入力するだけで、最も重要なエラーを即座に、漏れなく抽出できます。

また、サイレンス管理（Silence management）機能も大幅な時短に繋がります。各クラスターに個別にログインしてアラートを一時停止（silence）する代わりに、Karma上で一括処理できます. 先月のシステムメンテナンスでは、この集中管理のおかげでクリック回数を80%削減できました。

Docker ComposeによるKarma Dashboardの構築

最も手軽に導入する方法はDockerを使用することです。以下は、ProductionとStagingの2つのAlertmanagerクラスターを管理するための構成例です。

ステップ1: karma.yaml 設定ファイルの作成

このファイルで、Karmaがデータを取得する接続先のAlertmanagerを指定します。

# karma.yaml
alertmanager:
  interval: 30s
  servers:
    - name: "Prod-Cluster"
      uri: "http://alertmanager-prod:9093"
      timeout: 10s
    - name: "Staging-Cluster"
      uri: "http://alertmanager-staging:9093"
      timeout: 10s

karma:
  name: "グローバルアラートダッシュボード"
  grouping:
    default:
      groupBy: ["alertname", "cluster", "instance"]

ui:
  refresh: 30s
  theme: dark

ステップ2: docker-compose.yaml によるサービス構築

version: '3.8'
services:
  karma:
    image: ghcr.io/prymitive/karma:latest
    container_name: karma-dashboard
    volumes:
      - ./karma.yaml:/karma.yaml
    environment:
      - CONFIG_FILE=/karma.yaml
    ports:
      - "8080:8080"
    restart: always

ステップ3: 起動

以下のコマンドを実行して開始します：

docker-compose up -d

http://localhost:8080 にアクセスすると、すべてのアラートが整理された状態で表示されます。

オンコールを乗り切るための秘訣

導入しただけでは不十分です。Karmaの力を最大限に引き出すために、私はいつも以下の2つのテクニックを使っています：

正規表現フィルタ（Regex Filter）の活用

Karmaの検索バーは非常に強力です。以下のコマンドを試してみてください：

alertname=~Cpu.*: CPUに関連するすべてのエラーを集約。
-cluster=dev: Dev環境のアラートを非表示にし、Prod環境に集中。
@state=suppressed: 現在サイレンス中のアラートを確認し、期限が切れそうなものがないかチェック。

インテリジェントなグルーピング

データベースがダウンすると、それに依存する数十のサービスが連鎖的にエラーを吐きます。適切にグループ化しないと、画面が真っ赤になりパニックに陥ります。私は通常、job や app でグループ化し、障害の「震源地」を特定しやすくしています。

# karma.yamlに追加
karma:
  grouping:
    default:
      groupBy: ["alertname", "service"]
      groupMagicLabel: "cluster" # アラートが異なるクラスターからの場合は自動的にグループを分割

現場からの実戦経験

SREになりたての頃は、アラートが出るたびに慌てて修正に走っていました。しかし、後にアラートの約50%はノイズであることに気づきました。Karmaは、そのノイズのパターンを素早く特定するのに非常に役立ちます。

例えば、毎日午前1時に発生しては消えるCPUアラートを見つけました。Karmaで確認すると、システムのバックアップスケジュールと完全に一致していることが判明しました。無意味に夜更かしする代わりに、KarmaのUIから定期的なサイレンスルール（Silence Rule）を作成して解決しました。

重要な注意点: Karmaにはデフォルトでログイン認証機能がありません。絶対にインターネット上に直接公開しないでください。VPNの背後に配置するか、NginxのBasic認証などを使用して、第三者が勝手にアラートをオフにできないように保護してください。

まとめ

すべてのアラートを一元管理することで、オンコール担当者の精神的な負担は劇的に軽減されます。タブを切り替える手間がなくなり、分散したシステム全体を俯瞰できるようになります。もし2つ以上のAlertmanagerを運用しているなら、自身の睡眠を守るために、今すぐKarmaを導入することをお勧めします。