Prometheus・Grafana の代替：自社運用を拡張するか、マネージドに移るか

Prometheus と Grafana でオンコール対応ができているなら、画面を変えるためだけに移行することは勧めません。メトリクスの容量が足りないならバックエンドを拡張する。ストレージ、更新、復旧を継続して担う人がいないならマネージドサービスを考える。プラットフォーム全体を見直す価値が出るのは、データはあるのに、障害のたびに複数のシステムで状況を組み立て直しているときです。

Prometheus と Grafana は役割が異なり、一緒に使えます。Prometheus はメトリクスの収集・保存・クエリと recording rule、アラートルールの評価を担います。Grafana はデータソースに接続し、探索、ダッシュボード、アラートを提供します。Prometheus・Grafana の代替を考えるときは、収集、保存、調査のどこを変えたいのかを先に決めます。Grafana の入れ替えだけでは、メトリクスのバックエンドは置き換わりません。Prometheus の構成 · Grafana のデータソース

Guance 編集部 · 2026 年 10 月 28 日。公式資料を基に、自社運用とマネージドサービスの技術面・運用面の違いを検討します。Guance も候補の一つです。計算には明示した仮定を用い、本番性能や顧客の削減額を示すものではありません。

変えたい運用の範囲を見つける

長期保存や複数クラスターの横断クエリが主な課題なら、Thanos、Mimir、VictoriaMetrics などのメトリクス基盤から検討できます。既存の exporter、PromQL、Grafana の操作を活かせる場合もあります。一方、選んだ構成要素の容量、可用性、更新、復旧は引き続きチームの仕事です。各プロジェクトは構成も互換性も異なり、メトリクスを受け取れることだけでログ、トレース、利用者体験まで揃うわけではありません。

Grafana を使い続けながらバックエンドの運用を減らしたいなら、Grafana Cloud や適切なクラウドのマネージド Prometheus が候補です。Grafana Cloud と自社運用の LGTM は別の提供形態です。Loki、Grafana、Tempo、Mimir で複数信号を扱えても、自社運用では各コンポーネントの更新と復旧まで担います。Elastic Observability や Guance のようなプラットフォームでは、信号をまたぐ調査と、実際に提供される範囲が判断の中心になります。

選択によって変わるのは、日々続ける仕事です。Prometheus は Apache 2.0、Grafana OSS は AGPLv3 を採用しています。使うディストリビューション、プラグイン、追加製品にはそれぞれの条件があります。自分で配備できることと、運用・連携の費用がかからないことは同じではありません。Prometheus のライセンス · Grafana のライセンス

単価の前に、時系列数と収集間隔を計算する

高カーディナリティはデータと一緒に移ります。リクエスト ID や利用者 ID をラベルにすると、ラベル値の組み合わせによる時系列が増え続ける場合があります。大きなバックエンドに移しても、残す次元を決める仕事は必要です。Prometheus のデータモデル

単純な仮定を置きます。20 サービスにそれぞれ 10 ルート、5 種類のステータスがあり、各組み合わせを 8 Pod が一つのスカラー指標として実際に生成するなら、20 × 10 × 5 × 8 = 8,000 時系列です。15 秒間隔では毎分約 32,000 サンプル、60 秒間隔では約 8,000 サンプルになります。時系列数は変わらず、サンプル量は 4 分の 1 です。この定常状態の例には再起動、時系列の入れ替わり、ヒストグラム、レプリカを含めていません。

次元を減らせば、その切り口で調べられなくなります。収集間隔を延ばせば時間分解能が下がります。受け入れられるかは、実際のクエリとアラートの時間窓で決まります。調査で使わない次元は集約や除外を考えられますが、Pod 単位の切り分けが必要なら、そのためのデータを残します。

Grafana Cloud Metrics の課金はアクティブ時系列と毎分データポイント数（DPM）に関係します。別のサービスは異なる単位を使うこともあり、バイト数、時系列、データポイントをそのまま換算できません。送る範囲、間隔、保存期間、必要なクエリを揃えてから料金を比較します。Grafana Cloud のメトリクス課金

remote write の接続後も、ルールと履歴の行き先は別にある

Prometheus server は remote write の送信先ごとにキューを持ち、WAL からサンプルを読んでシャード経由で送信します。受信側が遅くなれば未送信データが溜まります。ローカルでクエリできても、遠隔側が追いついているとは限りません。復旧後は新規データを上回る送信能力が必要であり、WAL も無期限のオフラインアーカイブではありません。remote write のキューと復旧

収集側を残す利点はここにあります。全 exporter を交換する前に送信先を変えられます。ただし保存済み履歴、recording rule、アラートルール、Grafana ダッシュボードは別々の資産で、残す、取り込む、作り直すという判断がそれぞれ必要です。

HA のレプリカにも注意が必要です。Grafana Cloud Metrics は、共通の cluster 値とレプリカごとに異なる __replica__ 値で HA Prometheus を識別し、標準で重複排除します。これは受信側の規約であり、remote write プロトコルが全バックエンドに保証する動作ではありません。送信先を変えるときは、レプリカの識別、重複排除、実際に届く時系列をまとめて確認します。Grafana Cloud の HA 取り込み

Guance は DataKit の Prometheus Remote Write 受信機能を提供し、既存の収集経路を活かせます。フィールドの対応は先に決めます。measurement などの命名設定を上書きしていない場合、標準では go_memstats_heap_objects を measurement go とフィールド memstats_heap_objects に分け、keep_exist_metric_name = true で元の完全なフィールド名を保持できます。受信後も、元のクエリの名前と条件を新しいモデルに合わせる必要があります。MetricsQL のクエリも利用できますが、構文の互換性だけで実際の結果が正しいと判断はできません。

調査をつなぐのは、画面だけでなくデータの規約

Grafana は複数のデータソースに接続でき、Prometheus データソースでは exemplar からトレースへのリンクも設定できます。ログ・トレース基盤、安定した識別子、有効なリンクが揃っているなら、今の構成を改善するほうが全面移行より簡単な場合があります。Grafana の Prometheus データソース設定

継続する連携作業は、サービス名、環境、時刻、権限を各システムで揃えることです。エラー率アラートの service から同じサービスのログを絞れるか。ログの trace_id から、まだ保存されている Trace を開けるか。こうした条件が調査手順の実用性を決めます。

Guance のワークスペースはメトリクス、ログ、トレース、RUM を受け取り、トレース詳細には関連データへの入口があります。識別子が一致し、必要なデータが収集済みで検索可能なら、その入口から調査を続けられます。チームが個別のリンクや複数バックエンドを維持する作業を減らせますが、フィールドと保存期間は引き続き決める必要があります。収集しなかったリクエストが、統合したことで復元されるわけではありません。ログとトレースの関連付け

AI 支援も同じデータ経路の中で使います。Obsy Agent Teams は設定されたツールと許可されたデータでタスクを処理し、調査を進められます。引用されたイベント、条件、時間範囲は人がたどれる形で残すべきです。ツールに接続できたことと、根拠のある対処可能な原因が見つかったことは別の結果です。Agent Teams のタスク

アラート資産と継続費用から、移す範囲を決める

Alertmanager には重複排除、グループ化、ルーティング、サイレンス、抑制があります。クラスター障害で下流の通知が増えたら、抑制によって減らせます。担当、閾値、通知経路の誤りは移行後も直す必要があります。通知数だけを減らすのではなく、行動につながるアラートと手順を残します。Alertmanager

古い画面も用途で判断します。直近 90 日に開かれていないことだけを理由に、災害復旧やコンプライアンス監視を削除すべきではありません。移行するクエリでは、単位、集約、欠損、時間窓の意味を保ちます。アラートには評価間隔、保留時間、通知経路も含まれます。

初年度の費用は次のように整理できます。

初年度の投入額
= 12 ×（サービス料金 + 顧客側の収集リソース費
        + 通信費 + 残る運用費）
+ 一度だけ発生する移行費
+ 移行期間中の追加支出

エンジニアの時間と現金支出は分けて記録します。並行稼働は、定常状態を上回る追加分だけを数えて二重計上を避けます。Guance も選んだプランの取り込み、処理、保存、計算資源などを揃えて見積もり、一つの指標単価だけで全体を表さないようにします。Guance Enterprise の課金

制約がメトリクスのバックエンドなら、まずそこを拡張する。Grafana を残してバックエンドの運用を減らしたいなら、対応するマネージドサービスから見る。 信号をまたぐ調査と分散したシステムの維持に時間を使い続けているなら、Guance のような統合プラットフォームを比較する価値があります。止められる旧コンポーネント、維持できる調査能力、継続費用から、移す範囲を決められます。