PagerDutyへの支払いをやめよう：5ドルのVPSでGrafana OnCallをセルフホストする方法

Table of Contents

5分でクイックスタート：DockerでGrafana OnCallを実行する

1ユーザーあたり月額21ドルのPagerDutyの請求をなくすために、週末を丸ごと潰して移行作業をする必要はありません。DockerとDocker Composeの準備ができていれば、コーヒーが冷める前にGrafana OnCallのローカルインスタンスを立ち上げることができます。本番環境に移行する前に、チームの習慣にインターフェースが合うかどうかをローカルでテストするのが最も賢明な方法です。

まずは公式リポジトリをクローンし、デプロイ用フォルダに移動します：

git clone https://github.com/grafana/oncall.git
cd oncall/deploy/docker

.env.exampleファイルがあるはずです。これを.envにコピーしてください。ローカルテストではデフォルト設定でも動作しますが、リダイレクトループを避けるために、一意のSECRET_KEYを設定し、DOMAIN_NAMEをローカルIPまたはlocalhostに向ける必要があります。

cp .env.example .env
# .envを編集して DOMAIN_NAME=http://localhost:8080 を設定します

スタックを起動します：

docker-compose up -d

コンテナの状態がhealthy（正常）になったら、http://localhost:3000でGrafanaを開きます。OnCallプラグインを有効にし、http://oncall-engine:8080を指すように設定する必要があります。このDocker内部のアドレスにより、UIとロジックエンジンが即座にリンクされます。

各パーツの役割：アーキテクチャとコアコンポーネント

昨年、12人のエンジニアチームをPagerDutyからこのセットアップに移行させました。一番の不安は、最も必要な時にセルフホストツールがクラッシュすることでしたが、そんなことは起きませんでした。本番環境で14ヶ月使用していますが、信頼性の高い標準的な技術に基づいているため、システムは極めて安定しています。

Grafana OnCallは肥大化したモノリスではありません。個別にスケール可能な、以下のような特化型サービスの集合体です：

Engine (Django): 頭脳として機能します。スケジュール、エスカレーションロジック、APIリクエストを管理します。
Celery Workers: 実務を担います。Telegramメッセージの送信やPrometheusからの受信ウェブフックの処理など、重い処理を担当します。
Redis: 高速キャッシュおよびCeleryワーカーのメッセージブローカーとして機能します。
PostgreSQL: 信頼できる唯一の情報源（Source of Truth）です。すべてのユーザー、スケジュール、インシデントログがここに保存されます。

本番環境では、データベースとRedisをAWS RDSなどのマネージドサービスにオフロードすることをお勧めします。しかし、2vCPU、4GB RAMのVPS1台あれば、中規模のスタートアップのアラートを処理するには十分です。このセットアップにより、機密性の高いインシデントデータはサードパーティのサーバーではなく、自前のハードウェア内に留まります。

実戦的なレスポンスのためのエスカレーションチェーンとChatOps

チームが無視してしまうような通知ツールは役に立ちません。インスタンスが稼働したら、午前2時のデータベース停止をシステムがどう処理するかを定義する必要があります。ここで「エスカレーションチェーン」が、ノイズを実行可能なタスクへと変えてくれます。

「全員に通知」という罠は避けててください。燃え尽き症候群の原因になります。代わりに、次のような段階的な戦略を試してみてください：

レベル1（即時）： Telegramメッセージまたはモバイルアプリのプッシュ通知で、担当エンジニアに通知。
レベル2（5分後）： アラートが確認されない場合、担当エンジニアに自動電話をかける。
レベル3（10分後）： それでも反応がない場合、サブ担当エンジニアまたはエンジニアリングマネージャーにエスカレーション。

Telegram連携はスピードの面で大きなメリットがあります。チャットウィンドウから直接アラートの確認、解決、再割り当てができるため、若手エンジニアにも好まれます。セットアップするには、@BotFatherからボットトークンを取得し、.envに追加します：

# .envファイル内
TELEGRAM_TOKEN=あなたのボットトークンをここに
TELEGRAM_WEBHOOK_HOST=https://your-oncall-domain.com

サービスを再起動し、OnCall UIでTelegramアカウントをリンクします。これにより、単純なアラートが共同作業のスレッドに変わり、チーム全員がリアルタイムで修正状況を確認できるようになります。

本番環境の要塞化：ページャーを稼働させ続けるために

ページャーを自前でホストする場合、システムダウン時に通知が飛ばなかった時の責任は自分にあります。インスタンスを安定させるための私の手法は以下の通りです：

1. 監視システムを監視する

監視システムを単一障害点にしてはいけません。UptimeRobotのような無料의外部サービスを使って、60秒ごとにOnCallのヘルスエンドポイントをチェックしましょう。OnCallのUIがダウンした場合は、全く別の経路でバックアップのアラートを受け取る必要があります。

2. 賢いバックアップ

Dockerのアップデートにより、データベースのスキーマが壊れることが稀にあります。新しいイメージをプルする前に、必ずPostgreSQLのデータをダンプしてください。私は毎晩、オフサイトのS3バケットにpg_dumpを保存するcronジョブを実行しています。

# 手動バックアップの確認
docker exec oncall-postgres pg_dump -U admin oncall_db > backup_$(date +%F).sql

3. リソースのガードレール

アラートの嵐（50個のサービスが一度にダウンするような状況）が発生すると、メモリ使用量が急増することがあります。Celeryワーカーはリソースを大量に消費する可能性があります。危機的な状況でLinuxのOOMキラーによってシステムが停止するのを防ぐため、OnCallスタックには少なくとも2GBの専用RAMを割り当てています。

4. 認証の集約

ユーザーを手動で管理しないでください。チームがGitHubやGoogle Workspaceを使用している場合は、OAuth経由でGrafanaに接続しましょう。OnCallはそれらのユーザーを自動的に同期するため、手動でデータを入力することなく、新入社員を簡単にスケジュールに組み込むことができます。

インシデント管理をセルフホストするのは大きな一歩に感じられるかもしれませんが、それによって得られるコントロールは努力に見合う価値があります。インフラデータを自らの手で管理しながら、プロフェッショナルグレードのレスポンスツールを、ユーザーごとのライセンス料なしで利用できるのです。