Grafana AgentからAlloyへのオブザーバビリティ収集パイプライン移行｜本番並走と切り戻し設計

GrafanaエコシステムにおけるAlloyへの移行背景

Grafana Labsは2024年にGrafana Agentのサポート終了（EOL）を正式発表し、後継としてGrafana Alloyを位置づけました。AlloyはコレクタアーキテクチャをOpenTelemetryの標準に準拠させながら、PrometheusのメトリクスもLokiのログもTempoのトレースも単一プロセスで扱える設計になっています。

既存のGrafana Agent（FlowモードおよびStaticモード）からAlloyへの移行は、単純な設定ファイルの置き換えにとどまりません。設定言語が.riverから.alloyファイルへと整理され、コンポーネント名も一部変更されています。本番で稼働中のパイプラインをダウンタイムなく切り替えるには、並走設計と検証フェーズを計画的に組み込む必要があります。

なお、Grafana Agent Staticモードを使っている環境ではAlloyへの直接移行よりもFlowモードを経由する段階移行が推奨されていましたが、2026年時点ではAlloyへの一括移行ツール（alloy convertコマンド）が整備されており、StaticモードからAlloyへの変換も自動化の対象になっています。

移行前の準備：現行パイプラインの棚卸しと変換

移行を始める前に、現行Grafana Agentが担っているパイプラインを明確にしておくことが重要です。確認すべき主な項目は以下のとおりです。

• 収集しているシグナル種別（メトリクス・ログ・トレース・プロファイル）
• 送信先エンドポイント（Cortex/Mimir、Loki、Tempo、Pyroscopeのアドレスと認証情報）
• リラベル・フィルタリングルールの有無
• scrape_configsやintegrations（node_exporter等）の利用状況

既存の設定ファイルをAlloy形式に変換するにはalloy convertコマンドを使います。FlowモードのRiverファイルを対象とする場合は次のように実行します。

alloy convert --source-format=flow --output=config.alloy agent-config.river

Staticモードの設定ファイルを変換する場合は--source-format=staticを指定します。変換後のconfig.alloyはそのまま本番適用せず、まずローカル環境や非本番ホストでalloy run config.alloyを実行して構文エラーや接続エラーがないかを確認します。変換ツールは変換できなかった設定を# Unsupportedコメントで残すため、変換後ファイルを目視して未移行項目がないかを必ず確認してください。

本番並走（デュアルコレクタ）設計のポイント

本番環境での移行リスクを最小化するには、既存のGrafana Agentを残したままAlloyを並列稼働させる期間を設ける設計が有効です。この並走フェーズの核心は「同じシグナルを両方のコレクタが送信してデータを比較できる状態を作ること」です。

ポート・サービス名の競合を避ける

同一ホストにGrafana AgentとAlloyを共存させる場合、listenポートが衝突することがあります。デフォルトでGrafana AgentはHTTPサーバを12345番ポートで、AlloyはUIを12345番で起動しようとするため、どちらか一方のポートを変更する必要があります。Alloy起動時に--server.http.listen-addr=0.0.0.0:12346のように引数を渡すか、設定ファイル内のlogging・prometheus.exporter.*コンポーネントのポートを確認して調整します。

メトリクスの二重送信と重複ラベルへの対処

並走期間中は同一メトリクスが2系統から送信されます。MimirやCortexの受信側でシリーズが重複すると集計クエリが2倍になる問題が起きることがあります。一般的な対処としては、AlloyからはMimirの別テナントまたは別のremote_writeエンドポイントへ送信し、本番用ダッシュボードには影響を与えないようにします。本番比較専用のGrafanaダッシュボードで既存AgentとAlloyのシリーズを横並びにして差分を確認するのが確実です。

並走期間の目安

一般的には1〜2週間の並走期間を設け、ビジネス上の重要な定例イベント（週次バッチ、月末処理など）を少なくとも1回は並走状態で通過させることが推奨されます。データが揃った段階で両系統の差異（欠損・遅延・ラベル不一致）がないことを確認してから切り替えに進みます。

Alloyの動作検証と切り替え判断基準

Alloyには組み込みのUIとデバッグエンドポイントがあります。http://<ホスト>:12345にブラウザでアクセスするとコンポーネントグラフ（DAG）と各コンポーネントの状態が確認できます。ここで各コンポーネントがHealthyになっているか、エラーカウントが増加していないかを確認します。

メトリクスの観点では、AlloyのPrometheusエクスポーターエンドポイント（/metrics）から以下のメトリクスを監視します。

• prometheus_remote_write_samples_total：送信サンプル数の推移
• prometheus_remote_write_queue_capacity：送信キューの詰まり状況
• otelcol_receiver_accepted_spans_total：OTLPトレース受信数（トレースを扱う場合）
• loki_write_sent_entries_total：Lokiへのログ送信数

切り替え判断の基準として、「並走期間中にAlloy側の送信数・欠損率が既存Agentと同等であること」「UIでエラーコンポーネントがゼロであること」「スクレイプターゲットの検出数が一致していること」の3点を確認できれば切り替えに進む根拠になります。

切り替え作業自体はGrafana Agentのsystemdサービスを停止してAlloyのサービスを本番用エンドポイントに向けて再起動するだけです。systemdを使っている場合は次のように実行します。

sudo systemctl stop grafana-agent
sudo systemctl enable alloy
sudo systemctl start alloy

切り戻し手順と設計上の注意点

切り替え直後にAlloyで問題が発生した場合、Grafana Agentのsystemdサービスを再起動するだけで元の状態に戻せます。ただし切り戻しを確実にするために、以下の準備を切り替え前に済ませておく必要があります。

• Grafana Agentのバイナリ・設定ファイル・systemdユニットファイルを削除せずに残す
• 切り替え前の設定ファイルをバックアップしてバージョン管理（Gitリポジトリ等）に保存する
• Alloy切り替え後のremote_write先をAgentと同一にした場合、切り戻し時に短期間の二重送信が発生することを把握しておく

切り戻し操作は次のとおりです。

sudo systemctl stop alloy
sudo systemctl start grafana-agent

よくあるつまずきとして、Alloyへの切り替え後にGrafana Agentのsystemdユニットをdisableだけしてmaskしていなかったケースでは、ホスト再起動時にAgentが自動起動しないことを確認できていない場合があります。切り替えが確定したらsystemctl mask grafana-agentを実行して誤起動を防ぐのが安全です。

また、Alloyのデフォルト設定ではWAL（Write-Ahead Log）ディレクトリが/var/lib/alloy/dataに作成されます。ディスク残量が少ないホストでは切り替え後にWALが肥大化してディスク使用量が問題になることがあります。prometheus.remote_writeコンポーネントのwal_optionsブロックでmax_segment_sizeとmin_keepalive_timeを明示的に設定することを検討してください。

2026年時点の現行環境差分と運用上の留意点

2026年11月時点で確認しておくべき主な環境差分は以下のとおりです。

Grafana Agent Staticモードのサポート状況

Grafana Agent Staticモードは2025年にセキュリティフィックスのみの対応となり、機能追加は停止されています。2026年時点では新規インストールにStaticモードを使う理由はほぼなく、既存環境の移行は優先度を上げて進めることが推奨されます。Grafana Agentのリポジトリ自体はアーカイブ予定がアナウンスされており、パッケージリポジトリからの提供が終了した場合のインストール手段も念頭に置いておく必要があります。

AlloyのOpenTelemetry対応の成熟

Alloy v1.x系ではOTLPレシーバのgRPCおよびHTTPエンドポイントが安定しており、アプリケーション側のインストルメンテーションをOpenTelemetry SDKに統一していく流れとも整合しています。Grafana Agent Flowでotelcol.*コンポーネントを使っていた場合、Alloyへの移行後もコンポーネント名はほぼそのまま引き継がれるため、トレース・ログのパイプラインは比較的移行コストが低くなっています。

クラスタモードと水平スケールの扱い

AlloyにはクラスタリングモードがありKubernetesのDaemonSetやStatefulSetとして複数インスタンスを並べてスクレイプターゲットをシャーディングする機能があります。これはGrafana Agent FlowのClustering機能を引き継いだものですが、設定構文が整理されているため、既存のclustering設定ブロックはそのままでは移行できないケースがあります。Kubernetes上でのスケールアウト構成を組んでいる場合はalloy convertの変換結果を特に慎重に確認してください。

Helmチャートを使ってKubernetes上にデプロイしている場合はgrafana/alloyチャートが公式に提供されており、values.yamlのalloy.configMapセクションにAlloy設定を直接記述する形式に変わっています。Grafana Agent用のHelmチャート（grafana/grafana-agent）とは別チャートになるため、並走期間中は両チャートを同一クラスタにデプロイして運用することになります。

オブザーバビリティ収集パイプラインの移行は一度に全シグナルを切り替えるのではなく、シグナル種別ごとに段階的に進めることで障害時の影響範囲を絞り込めます。本番環境では「まずメトリクスのみ切り替え、1週間後にログ、さらに1週間後にトレース」といった段階的な移行スケジュールが障害対応の観点からも現実的な選択肢となります。