こんにちは！毎日のKubernetes（K8s）運用、本当にお疲れ様です。
「Podがクラッシュループしているけれど、ログが膨大すぎて何が原因か分からない…」
「PrometheusでCPU使用率のスパイク（急上昇）を検知したけれど、その瞬間にアプリケーションで何のエラーが起きていたのか、点と点が繋がらない…」
K8sという強力なプラットフォームを使っていると、誰もが一度はこのような「インフラ（Prometheus）とアプリケーション（エラートラッキング）のサイロ化」という壁にぶつかります。インフラの健康状態（バイタル）は見えているのに、アプリアラートの原因（病因）がすぐに見特定できない状態です。
でも、安心してください。この2つの世界は、美しく統合することができます。
この記事では、世界中で愛されるエラートラッキングツール「Rollbar（ロールバー）」と、K8s監視のデファクトスタンダードである「Prometheus（プロメテウス）」を組み合わせ、「インフラの負荷状況と、コードレベルのエラー発生率を同じ時間軸で重ね合わせて分析する極上の監視環境」を構築します。
この記事を最後まで読めば、初心者の方でも「ポッドごとのエラーとリソースの相関関係」を1つのダッシュボードで一目瞭然にする方法がマスターできます。毎日のトラブルシューティングが、驚くほどラクに、そして楽しくなりますよ。
それでは、一緒に第一歩を踏み出しましょう！
—
1. なぜ「Rollbar × Prometheus」なのか？ 統合の思想
具体的な手順に入る前に、なぜこの2つを組み合わせるのか、その「思想」を整理しておきましょう。
- Prometheus（インフラのバイタルサイン）:
CPU、メモリ、ネットワークトラフィックなどの「数値（メトリクス）」を時系列で追跡します。いわば、システムの「体温計」です。「熱がある（負荷が高い）」ことは分かりますが、「なぜ熱が出ているのか（どのコードがバグっているのか）」までは教えてくれません。
- Rollbar（アプリの痛みの訴え）:
例外（Exception）やエラーログをスタックトレース付きでリアルタイムに収集・分類します。いわば、システムの「自覚症状のカルテ」です。「どのファイルの何行目で、どんなエラーが出たか」をピンポイントで教えてくれます。
【従来の監視】
Prometheus「CPUが100%です！」 ──(別々の画面)──> Rollbar「データベース接続エラー！」
※「これって同じ原因？それとも別々？」と人間が迷う
【統合された監視】
Grafanaダッシュボード
├── [メトリクス] CPU使用率がスパイク 📈 （Prometheus）
└── [イベント] 同じ瞬間に「NullReferenceException」が100件発生 💥 （Rollbar）
➡ 「あ、このエラーの例外処理が無限ループしてCPUを食いつぶしたんだ！」と1秒で確信できる
この2つのデータを、K8sの最小単位である「Pod（ポッド）」をキーにして紐付けること。これが、本記事で実現する究極のオブザーバビリティです。
—
2. 統合アーキテクチャの全体像
今回は、初心者の方でも手元ですぐに試せるよう、以下の構成でハンズオンを行います。
1. サンプルアプリ（Python / Flask）: K8s上で動作し、意図的にエラーを発生させられるアプリ。
2. K8s Downward API: Podの名前やNamespaceをアプリに注入し、Rollbarへ送るエラー情報に「どのPodで起きたか」を自動付与します（★超重要プロテクニック！）。
3. Prometheus & Grafana: インフラのメトリクスを収集・可視化します。
4. Grafana Annotations（注釈）: RollbarのAPIからエラーイベントを直接Grafanaに引っ張り、Prometheusのグラフ上に「赤い縦線（エラー発生イベント）」として重ね合わせます。
—
3. Step 1: K8s上のアプリにRollbarを仕込む（メタデータの極意）
まずは、K8s上で動くPythonアプリを作成します。
ここでプロとして妥協できないのが、「エラーが発生したPodの名前（`pod_name`）をRollbarに伝えること」です。これが抜けると、後から「どのPodの負荷と相関しているか」が追えなくなります。
3.1. アプリケーションコード（`app.py`）
シンプルなFlaskアプリです。Rollbar SDKの初期化時に、環境変数からPod名を取得して設定します。
import os
import rollbar
from flask import Flask
app = Flask(__name__)
Rollbarの初期化
環境変数からトークンと環境名、そして「Pod名」を取得します
ROLLBAR_ACCESS_TOKEN = os.environ.get(“ROLLBAR_ACCESS_TOKEN”)
ENVIRONMENT = os.environ.get(“ENVIRONMENT”, “production”)
POD_NAME = os.environ.get(“POD_NAME”, “unknown-pod”)
rollbar.init(
access_token=ROLLBAR_ACCESS_TOKEN,
environment=ENVIRONMENT,
# カスタムデータとして、エラーが発生したPod名を常時送信するようにします
payload_handler=lambda payload: payload.setdefault(“data”, {}).setdefault(“custom”, {})
.update({“pod_name”: POD_NAME}),
)
@app.route(“/”)
def hello():
return “Hello, K8s and Rollbar! /error にアクセスするとエラーが発生します。”
@app.route(“/error”)
def trigger_error():
try:
# 意図的にゼロ除算エラーを発生させます
result = 1 / 0
except ZeroDivisionError as e:
# Rollbarにエラーを送信（スタックトレースと、Pod名が自動送信されます）
rollbar.report_exc_info()
raise e # アプリ側でもエラーを発生させて500エラーにする
return f”Result: {result}”
if __name__ == “__main__”:
app.run(host=”0.0.0.0″, port=8080)
3.2. Kubernetesマニフェスト（`deployment.yaml`）
ここが最大のポイントです。K8sの`Downward API`を使って、コンテナ内の環境変数`POD_NAME`に、実際のPod名を動的に注入します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: rollbar-demo-app
labels:
app: rollbar-demo
spec:
replicas: 2
selector:
matchLabels:
app: rollbar-demo
template:
metadata:
labels:
app: rollbar-demo
spec:
containers:
- name: app
image: <あなたのDockerイメージ> # 上記のapp.pyをビルドしたイメージ
ports:
- containerPort: 8080
env:
# Rollbarのアクセストークン（書き換えてください）
- name: ROLLBAR_ACCESS_TOKEN
value: “YOUR_ROLLBAR_POST_SERVER_ITEM_TOKEN”
- name: ENVIRONMENT
value: “production”
# 【神設定】Downward APIを使って、Pod自身の名前を環境変数に注入！
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
これをデプロイすることで、Rollbarに送られるすべてのエラーログに「どのPodで起きたか（例: `rollbar-demo-app-67bf7c47d-abcde`）」が100%正確に記録されます。
—
4. Step 2: Prometheusでインフラメトリクスを収集する
Prometheusは、K8sクラスターの標準的な監視設定（Prometheus OperatorやHelmの `kube-prometheus-stack` など）が導入されている前提とします。
もし手元にない場合は、以下のコマンドで一瞬でGrafana付きの環境が手に入ります。
Helmを使ってPrometheusとGrafanaをインストール
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack
これで、各PodのCPU使用率（`container_cpu_usage_seconds_total`）やメモリ使用量が自動的にPrometheusに収集され始めます。
—
5. Step 3: GrafanaでRollbarとPrometheusを「合体」させる
さて、ここからが魔法の時間です。
Grafanaの「Annotations（注釈）」という強力な機能を使って、Prometheusの「CPU使用率グラフ」の上に、Rollbarで検知した「エラー発生イベント」を重ね合わせます。
これにより、「CPUが跳ね上がったまさにその瞬間、Rollbarでエラーが発生していたか？」が視覚的に一発でわかるようになります。
設定手順
1. Grafanaを開き、ダッシュボードを作成する
Prometheusをデータソースとして、対象PodのCPU使用率グラフを作成します。
- PromQLクエリ例:
sum(rate(container_cpu_usage_seconds_total{container=”app”}[1m])) by (pod)
これで、PodごとのCPU使用率がきれいな折れ線グラフで表示されます。
2. Annotations（注釈）の設定を開く
- ダッシュボード上部のギアアイコン（Dashboard settings）をクリックします。
- 左メニューから 「Annotations」 を選択し、「Add annotation query」 をクリックします。
3. Rollbar APIからイベントを取得する設定を行う
Grafanaには、RollbarのAPIから直接イベントを取得するプラグイン、または「JSON Data Source / Webhook」を介してイベントを描画する機能があります。今回は最もシンプルで堅牢な「HTTP (JSON) API」を使った連携を設定します。
- Name: `Rollbar Errors`
- Data source: `– Dashboard –`（または、シンプルなHTTP JSONプラグイン、またはGraphQLデータソースなどを使用。今回は標準の「Infinity Data Source」または「JSON API」プラグインを使うと非常に簡単です）
- API URL: `https://api.rollbar.com/api/1/items`
- HTTP Header:
- `X-Rollbar-Access-Token`: `YOUR_ROLLBAR_READ_TOKEN`（※プロジェクト設定から「read」権限のトークンを取得してください）
> 💡 もっと簡単な「現場の裏技」
>
> もし複雑なAPI設定を避けたい場合、RollbarのWebhook機能を使って、エラー発生時にSlackや汎用Webhook経由でGrafanaにイベントをプッシュ送信する手法も極めて有効です。
> また、Rollbarが提供する「Prometheus Exporter」を自作/導入し、Rollbarのエラー発生件数自体をPrometheusのメトリクスとしてスクレイプ（収集）する方法もあります。
>
>
> [Rollbar Webhook] ──> [Prometheus Pushgateway] ──> [Prometheus]
>
>
> この構成をとると、`rollbar_errors_total{pod=”pod-name”}` というメトリクスがPrometheus内に生成されるため、Grafana上では「同じPrometheusデータソースだけ」を使って、CPUとエラー数を完全に一枚のグラフに同居させることができます！
—
6. 運命の瞬間：動作確認（Hello World!）
すべての設定が完了したら、実際にエラーを発生させて、統合監視が機能しているか確認しましょう！
1. 意図的にエラーを発生させる
デプロイしたサンプルのFlaskアプリの `/error` エンドポイントに、ブラウザや `curl` コマンドでアクセスします。
Podへのポートフォワード（ローカルでテストする場合）
kubectl port-forward deployment/rollbar-demo-app 8080:8080
何回かアクセスして、エラーを連発させます
curl http://localhost:8080/error
curl http://localhost:8080/error
curl http://localhost:8080/error
2. Rollbarの画面を確認する
Rollbarのダッシュボードを開くと、ほぼリアルタイム（数秒以内）で `ZeroDivisionError: division by zero` が検知されているはずです。
ここで、エラーの詳細画面（Occurrence）を開いてみましょう。
画面の下部に、私たちが仕込んだ「神設定」の成果が現れています！
“custom”: {
“pod_name”: “rollbar-demo-app-67bf7c47d-abcde”
}
「どのPodで起きたか」が、完璧に記録されていますね！
3. Grafanaの「奇跡の瞬間」を見届ける
さあ、Grafanaのダッシュボードに戻りましょう。
時間を「Last 15 minutes（過去15分）」にし、ブラウザをリロードします。
そこには、Prometheusが描く「CPU使用率の小さなスパイク」と、その真上にRollbarから届いた「赤い縦線（注釈イベント）」が、寸分の狂いもなくピッタリと同じ時刻で重なり合っているダッシュボードが表示されているはずです！
その赤い線にマウスカーソルを合わせると、こう表示されます。
> Rollbar Error Detected
> Message: `ZeroDivisionError: division by zero`
> Pod: `rollbar-demo-app-67bf7c47d-abcde`
> Environment: `production`
これで、原因究明のために何枚ものタブを行き来する必要はなくなりました。この画面を見た瞬間に、すべての状況が脳内で繋がります。
—
7. 現場で差がつくプロの知恵
最後に、この運用をスケールさせるための「本物の知恵」を2つお伝えします。
① Pod名だけでなく「Gitのコミットハッシュ」も載せる
K8sのデプロイ時に、コンテナの環境変数にGitのコミットハッシュ（`GIT_SHA`）も注入しておきましょう。これをRollbarの `code_version` として設定すると、「このエラーは、5分前のどのデプロイ（コミット）から発生し始めたか」が完璧に特定できるようになります。
② Prometheus Alertmanagerとの連携
Rollbarで「特定のエラーが5分間に10回以上発生した」というトリガーを検知した際、RollbarからPrometheusのAlertmanager（または直接Slack/PagerDuty）に通知を飛ばすようにします。これにより、インフラの死活監視とアプリのバグ検知の通知窓口が1つに美しく統合されます。
—
まとめ
お疲れ様でした！
今回は、Kubernetesという複雑なオーケストレーション環境において、「Rollbar」と「Prometheus」を紐解き、Grafanaというハブを通じてインフラとアプリケーションの監視を統合するアプローチを解説しました。
一見難しそうに見える「インフラとアプリの相関分析」も、Downward APIによるPod名の注入とGrafanaでのイベント重ね合わせという本質を押さえれば、驚くほどシンプルに実現できます。
これをマスターしたあなたのチームでは、明日から障害復旧スピードが劇的に向上するはずです。
「監視の力」で、開発と運用の毎日をもっとスマートで快適なものにしていきましょう！
何か分からないことがあれば、いつでも気軽に