Azure マネージド Grafana（AMG）で VictoriaMetrics / VictoriaLogs のデータソースを使いたいのに、ポータルの「Plugin management」に項目が見当たらない――本記事はこの“あるある”に対して、最新の状況整理とすぐ実践できる回避策、運用のベストプラクティスまでを一気通貫で解説します。結論から言えば、現時点ではAMGで公式に追加できません。ではどう動くべきか、確度の高い選択肢と判断基準を具体的に示します。
目次
Azure マネージド Grafana で VictoriaMetrics / VictoriaLogs を追加したい
質問の背景と課題
- 課題: AMG の「Plugin management」に VictoriaMetrics と VictoriaLogs のデータソースが表示されない。インストール手段も見当たらない。
- 知りたいこと:
- これらプラグインを公式に追加する方法は存在するか？
- 将来的に追加される予定（ロードマップ）は公開されているか？
結論（ショートアンサー）
- 現状では未サポート: 2025年9月時点、AMG のプラグイン一覧に VictoriaMetrics / VictoriaLogs のエントリはなく、ポータルからのインストール手段も提供されていません。AMG は Microsoft が事前承認した “ホワイトリスト” 方式でプラグインを公開しており、すべてのサードパーティ プラグインを自由に追加できるわけではありません。
- ロードマップは未公開: 公式に「いつ追加されるか」を示すスケジュールは公表されていません。
ただし、プラグイン自体（VictoriaMetrics / VictoriaLogs）は Grafana の署名済みプラグインとして一般公開されており、セルフホスト Grafana や Grafana Cloud では即時利用が可能です。したがって技術的適合性は高く、残るボトルネックは Azure 側の承認と優先度の問題という整理になります。
いま取れる選択肢と比較
| 方策 | 概要 | 向いているケース | 留意点 |
|---|---|---|---|
| セルフホスト Grafana | Azure VM / Azure Container Apps / AKS 等に独自で Grafana を構築し、マーケットプレイスからプラグインを導入。 | MetricsQL・LogsQL を今すぐフル機能で使いたい。 | 可用性・セキュリティ・パッチ適用などの運用を自社で担う。 |
| 既存データソースで代用 | VictoriaMetrics を Prometheus 互換 API として公開し、AMG 標準の Prometheus データソースからクエリ。ログは要件次第で Loki/Elasticsearch 互換経由を検討。 | 一部のクエリ機能制限を許容して、AMG の管理性を維持したい。 | MetricsQL/LogsQL 固有機能は利用不可。互換APIの差異に注意。 |
| サポート/フィードバック提出 | Azure portal から機能要望を提出し、AMG への公式対応をリクエスト。 | 中期的に AMG に統合したい。社内コンプライアンス上、フルマネージドが必須。 | 採用まで時間を要する。ビジネスインパクトの具体性が鍵。 |
| 他社マネージド Grafana を評価 | クラウドベンダーによりプラグイン取り扱い方針が異なるため、要件合致を検証。 | マルチクラウドや移行を許容できる。 | 運用/コストの再評価が必要。カバレッジ差異に注意。 |
AMG のプラグインが自由に入れられない理由（仕組みの理解）
- セキュリティ基準: AMG はエンタープライズに向け、Microsoft 側で検証・署名・脆弱性影響の確認を行ったプラグインのみを公開します。これはマルチテナント運用での安全性と安定性、SLA への責任を守るための措置です。
- 運用一貫性: Azure RBAC、Managed Identity、Azure Monitor 連携、バックアップ/アップグレードの自動化において、予見可能性を確保する必要があるため、インストール可能なモジュールが制限されます。
- OSS 版との違い: OSS や Grafana Cloud はユーザー/プロバイダーが責任を負いますが、AMG は Microsoft がサービス提供者として品質を担保するため、受け入れハードルが高くなる傾向があります。
代替案を深掘り：どのパターンを選ぶべきか
意思決定フレーム（判断チャート）
| 要件 | Yes の場合 | No の場合 |
|---|---|---|
| MetricsQL / LogsQL をすぐ使いたい | セルフホスト Grafana を推奨 | AMG + Prometheus/Loki 互換で暫定運用 |
| 運用を極力持ちたくない | AMG で待つ／互換接続で妥協 | セルフホストで自由度を優先 |
| SSO/RBAC を Azure 標準で統一したい | AMG 継続（将来の公式追加を待つ） | セルフホスト＋IdP 連携で代替 |
| ログ/メトリクスの集約に VM* 系を中核とする | ハイブリッド（AMG と併存）が現実的 | AMG に寄せて Azure Monitor を主軸に |
セルフホスト Grafana での実装手順（最短ルート）
ここでは Docker 前提で最短セットアップを例示します。Azure VM、Azure Container Apps（ACA）、AKS いずれにも応用可能です。
1. Docker で Grafana を起動（プラグイン自動インストール）
環境変数 GF_INSTALL_PLUGINS にプラグイン ID を指定します。プラグイン ID はプラグインカタログに記載の正確な ID を使用してください（以下は一例）。
docker run -d --name grafana \
-p 3000:3000 \
-e GF_SECURITY_ADMIN_USER=admin \
-e GF_SECURITY_ADMIN_PASSWORD='<強固なパスワード>' \
-e GF_INSTALL_PLUGINS='victoriametrics-datasource,victorialogs-datasource' \
grafana/grafana:latest
2. プロビジョニングでデータソースを自動登録
コンテナにマウントする /etc/grafana/provisioning/datasources/datasource.yaml の例です。URL は実環境に合わせて変更してください。
apiVersion: 1
datasources:
- name: VictoriaMetrics
type: victoriametrics-datasource
access: proxy
url: http://victoriametrics:8428
editable: true
- name: VictoriaLogs
type: victorialogs-datasource
access: proxy
url: http://victorialogs:9428
editable: true
3. Azure への載せ替え（例：Azure Container Apps）
ACA を使うと自動スケール・ゼロスケール・マネージド TLS を簡易に確保できます。シークレットは ACA のシークレット機能に保存し、環境変数に参照させます。VNet 連携を有効化し、VictoriaMetrics / VictoriaLogs へのアウトバウンドをプライベート経路で確保しておくとより安全です。
4. セキュリティの要点
- 認証管理: 管理者パスワードは Azure Key Vault などで集中管理。OIDC/SAML を使い、SSO とチームベース RBAC を早期に適用。
- 通信保護: 可能ならプライベートエンドポイントやリバースプロキシで外部公開を最小化。TLS 証明書は自動更新の仕組みを。
- 更新運用: 月例の Grafana 更新とプラグイン更新を CI/CD に組み込み、検証→本番の二段階で適用。
AMG での暫定運用：Prometheus/Loki 互換でつなぐ
AMG の強み（Azure RBAC、Managed Identity、Azure Monitor ワンクリック連携）を活かしつつ、VictoriaMetrics / VictoriaLogs を“互換 API”経由で参照するパターンです。
Prometheus データソースで VictoriaMetrics を引く
- AMG 画面で Data sources → Prometheus を選択。
- HTTP URL に VictoriaMetrics の Prometheus 互換エンドポイント（例：
http://<host>:8428）を指定。 - 必要に応じて認証ヘッダーや TLS 設定を追加。
- クエリは PromQL を使用（MetricsQL 固有演算子は利用不可）。
ログ側の代替
VictoriaLogs は独自の LogsQL を備えますが、AMG でそのまま使うことはできません。要件に応じて、
- Loki 互換 API や Elasticsearch 互換 API を介した参照を検討（互換範囲は実装/バージョンによって異なるため要検証）。
- ダッシュボードは AMG の Loki または Elasticsearch データソースを用い、取得できるメタデータやクエリ構文に合わせて作り分け。
機能差の要約
| 観点 | AMG + 互換API | セルフホスト + 公式プラグイン |
|---|---|---|
| クエリ言語 | PromQL（ログは Loki/ES の構文） | MetricsQL / LogsQL をフル活用 |
| ダッシュボード移植性 | 既存 PromQL ダッシュボードは流用しやすい | VM* 固有機能も表現可能 |
| 導入スピード | AMG があれば早い | インフラ構築が必要 |
| 運用負荷 | 低い（AMG 管理） | 中〜高（自社管理） |
プラグイン側の準備状況と期待値コントロール
- 署名済み・一般公開済み: VictoriaMetrics / VictoriaLogs の Grafana プラグインは署名済みプラグインとして公開されています。セルフホスト版や Grafana Cloud ではワンクリックで導入できます。
- AMG 側の承認待ち: 技術的には動作可能でも、AMG で公開されるかは Azure 側の審査・優先度次第です。セキュリティレビュー、サポート体制、更新頻度などの観点で評価されます。
ハイブリッド構成のすすめ（現実解）
VictoriaMetrics/Logs を中核としたいが、ガバナンスや SSO は Azure に寄せたい――そんな要件には次のハイブリッドが実用的です。
- 可視化分担: VM* 固有分析（MetricsQL/LogsQL）はセルフホスト Grafana、Azure リソース監視や組織共通ダッシュボードは AMG。
- リンク統合: AMG のパネルやナビゲーションからセルフホスト Grafana の深掘りダッシュボードへリンクアウト。
- 認証統一: 両者とも同じ IdP（Azure AD など）で SSO・グループベース RBAC を揃える。
- ネットワーク: Azure Private DNS / Private Link / VNet ピアリングで双方向の経路を最小権限で設計。
実装の作法：ダッシュボード・クエリの移植ノウハウ
PromQL → MetricsQL の考え方
- まずは PromQL で要件を満たせるかを評価。互換接続で AMG を継続できる可能性があります。
- MetricsQL 固有の関数・ロールアップを活かす分析はセルフホスト Grafana で実現し、AMG 側はサマリと運用視点に絞ると整合が取りやすいです。
LogsQL の取り扱い
- AMG 直下で LogsQL は使えないため、ログ深掘りはセルフホスト側に寄せる。
- AMG では Loki/ES 互換で“入口”を用意し、ユースケース別に到達点（どこまで見られればよいか）を明確化します。
検証（PoC）チェックリスト
| 項目 | 目的 | 合格条件 |
|---|---|---|
| 互換 API の動作確認 | AMG から VM* へのクエリ可否を確認 | 主要ダッシュボードのメトリクスが遅延なく描画 |
| 権限制御 | SSO とフォルダ/データソース権限の整合 | 最小権限で運用者/閲覧者が期待通りにアクセス |
| アラート | しきい値/異常検知の配信とノイズ抑制 | 誤検知率・見逃し率が SLA/SLO の範囲内 |
| コスト | 保管期間・サンプリングで最適化 | TCO が運用要件に見合う |
| 可用性/バックアップ | 更新/障害時の復旧手順確認 | RTO/RPO を満たす |
トラブルシューティング（よくある落とし穴）
- プラグインが見つからない: AMG では未公開。セルフホスト/Grafana Cloud を検討。
- ダッシュボードでエラー: MetricsQL/LogsQL の関数・構文が AMG の互換データソースでは解釈できない可能性。PromQL/Loki/ES の構文に置き換え。
- 接続失敗: ネットワーク経路（VNet/Firewall/Proxy）や TLS、認証ヘッダーの欠落を確認。
- タイムスケール差異: ロールアップ/補間の既定が異なるとグラフ差異が出ます。パネル側で明示設定。
- アラート閾値のブレ: 評価窓/ステップ幅の差に留意。両環境で同一設定に合わせる。
サポート/フィードバックの通し方（採用率を上げる書き方）
要望は「ユースケースの具体性」が肝です。単に「使いたい」では通りにくく、次の観点を盛り込むと優先度が上がります。
- 規模感: 対象システム数、メトリクス/ログの毎秒流量、保持期間、利用ユーザー数。
- ビジネス影響: SLI/SLO に対する影響、インシデント MTTR/MTTD の短縮効果。
- 代替不可性: MetricsQL/LogsQL の固有機能（例：高度なロールアップ/フィルタ）でなければ達成できない根拠。
- セキュリティ/コンプラ: データ所在、暗号化、監査要件への適合性。
コスト/運用の比較（TCO 観点）
| 項目 | AMG + 互換API | セルフホスト + 公式プラグイン |
|---|---|---|
| 初期導入 | 最小（設定中心） | 中（インフラ構築） |
| 運用保守 | 低（マネージド） | 中〜高（パッチ/監視/バックアップ） |
| 機能自由度 | 中（互換範囲） | 高（MetricsQL/LogsQL） |
| 将来拡張 | AMG の公開状況に依存 | 自律的に拡張可能 |
実践テンプレート（参考スニペット）
Docker Compose（開発/検証用）
version: "3.9"
services:
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_USER=admin
- GF_SECURITY_ADMIN_PASSWORD=<強固なパスワード>
- GF_INSTALL_PLUGINS=victoriametrics-datasource,victorialogs-datasource
volumes:
- ./provisioning:/etc/grafana/provisioning
victoriametrics:
image: victoriametrics/victoria-metrics:latest
ports:
- "8428:8428"
command:
- "--storageDataPath=/vm-data"
victorialogs:
image: victoriametrics/victoria-logs:latest
ports:
- "9428:9428"
注: 上記は学習/検証目的の最小構成です。本番では永続ボリューム、TLS、認証、スケール設計、監視/バックアップ等を必ず追加してください。プラグイン ID やポート番号は利用バージョンにより異なることがあります。
将来の見通しとアップデートの追い方
- AMG のリリースノート: 新規対応プラグインはまずここに現れます。
- プラグイン側の更新: サポート Grafana バージョンの更新があるため、セルフホストでは Grafana 本体とプラグインの互換性マトリクスを定期点検。
- 社内ガバナンス: 将来 AMG に公式追加された際の移行計画（ダッシュボード/データソースの移し替え）をプレイブック化しておくとスムーズです。
まとめ（要点の再掲）
- 現状未サポート／ロードマップ非公開: AMG での VictoriaMetrics / VictoriaLogs 公式プラグイン追加は、2025年9月時点で未提供・未公表。
- いますぐ機能が必要ならセルフホスト: 公式プラグインを即利用でき、MetricsQL/LogsQL を最大限活かせます。
- AMG 継続なら互換 API で暫定運用: Prometheus/Loki/ES 互換を使えば管理性を保ちつつ可視化を継続可能。ただし機能差は理解して設計。
- ハイブリッドが現実解: 組織のガバナンスと観測要件を両立しやすく、将来の公式追加にも柔軟に乗り換えられます。
- 要望は定量化して伝える: 規模・SLO/SLI 影響・代替不可性を具体的に示すと優先度が上がります。
本記事が、Azure マネージド Grafana における VictoriaMetrics / VictoriaLogs 未対応の現状整理と、実務に落とし込める判断・設計の基準になれば幸いです。
付録：チェックリスト（コピペ用）
- ［ ］ 現行ダッシュボードのクエリ言語棚卸（PromQL / MetricsQL / LogsQL）
- ［ ］ AMG 継続範囲（Prometheus/Loki/ES 互換で表現できる要件）
- ［ ］ セルフホスト側のSLO（RTO/RPO・可用性・復旧手順）
- ［ ］ ネットワーク設計（Private Link / VNet / FW / Proxy）
- ［ ］ 秘密情報の管理（Key Vault / シークレットスコープ）
- ［ ］ 更新フロー（ステージング→本番の自動化、回帰テスト）
- ［ ］ 監査要件（アクセスログ、設定変更履歴、アラート証跡）
- ［ ］ コスト最適化（保持期間、圧縮、サンプリング、低頻度層）
コメント