本記事について
2026年4月にAzure Monitor Pipeline (以降、AMP)というハイブリッドクラウド環境における監視基盤がリリースしました。
本記事ではこのAMPがこれまでのハイブリッド環境の監視ソリューションとどう違うのか？どう活かすことができるのかを整理してみます。
環境構築については別記事にまとめていますので構築の流れを確認したい方、構築でハマった方はこちらもご参照ください。
Azure Monitor Pipelineの展開における注意点
AMPのドキュメントはこちらです。
Ingest at Scale, Securely — Azure Monitor pipeline Is Now Generally Available
MS Learn | Azure Monitor パイプラインとは
AMPを利用した監視の全体像
まず最初にAMPで実現できるハイブリッド環境の監視の全体像を見ると、Azure Arcを利用した仕組みであることがわかります。この構成のPointを抑えておきましょう。
※引用元：MS Learn | Azure Monitor パイプラインとは
Point 1: 対応するログはSyslogとOpenTelemetryログ
現在AMPが収集できるのはSyslogとOpenTelemetryログの2つです。(Opentelemetryログは2026/6時点でプレビュー)
これによりAzure Monitor Agentがインストールできないようなハードウェアやネットワーク機器、アプライアンスのログ監視基盤を構築することができます。
一方で、ネットワーク機器の監視で一般的に使われるようなSNMPTrapには対応しておらず、またping監視のようなPull型の監視もAMPのみでは実現できません。
Point 2: オンプレ内でのログはArc-enabled k8sで集約
AMPはk8s上で実行され、オンプレ環境で発生するログを一元的に集約してクラウドにアップロードします。
k8sで実行されることで、その可用性や運用管理の恩恵を受けつつ、またログ量に応じた柔軟なスケーリングが可能になります。
Point 3: オンプレからのアウトバウンド通信 (HTTPS)のみで実行
実行基盤のk8sはArc-enabled k8sとしてAzureに接続します。
おなじみAzure Arcの仕組みを利用していますので通信はすべてアウトバウンドのみ、かつHTTPSで暗号化された通信になります。
また、プロキシやArc Gatewayを介して通信することもできます。
AMPはなぜ便利なのか？ (AMPの特徴)
さて、次にAMPの特徴をこれまでのオンプレ監視のAzureソリューションと比較して理解していきます。
これまでのオンプレ監視のAzureソリューションとの比較
Azure Arc + Azure Monitor AgentによるログフォワーダーVMを利用した従来の仕組み
これまでもオンプレ環境で発生したログ情報をAzure Monitorに連携する仕組みとしては、Azure Monitor Agent (AMA)をインストールしたサーバ (Arc-enabled Servers)を介した方法がありました。
Syslogの収集ではLinuxサーバをSyslogフォワーダーとして構築し、このサーバのSyslogデータをSentinelを有効化したLog Analyticsワークスペースに収集するというものです。
※引用元：MS Learn | Microsoft Sentinelの AMA コネクタを介した Syslog と共通イベント形式 (CEF)
※CEF形式ではないSyslogであればSentinel不要でSyslogフォワーダーサーバ自身のSyslogにデータを集約することでLog AnalyticsワークスペースのSyslogテーブルに収集は可能・・・なはずです。(未検証)
また、SNMPTrapの収集も同様の構成で可能で、Arcで接続したLinuxサーバをSNMPのレシーバーとしつつ、LinuxサーバのSyslogやテキストファイルに書き込むことで、それらをLog Analyticsワークスペースに収集できます。
※引用元：MS Learn | Azure Monitor エージェントを使用して SNMP トラップ データを収集する
従来の仕組みの悩み
いずれの仕組みもLinuxサーバの管理が必要なことと、ログフォワーダーサーバの可用性を考えると前面にロードバランサーを立てるなど構成が複雑になる運用面の懸念がありました。
また、オンプレからクラウドへのネットワーク接続が途絶えた場合に監視やログ収集が止まってしまうこともネックでした。
こうした理由から、監視用のサーバをオンプレに残してサーバ運用するのであれば、専用の監視アプライアンスの運用を継続する方がハイブリッドクラウド環境での全体最適になりやすく、Azure Arcを推し進めづらい部分にもなっていると感じていました。
サーバ監視はAzure Arc + AMAで容易にAzure監視基盤に統合できるものの、ネットワーク機器等のAMA導入不可な機器の監視も考えると、なかなかすべてをAzureの仕組みに移行が難しい状況にありました。
従来の仕組みと比較したAMPのメリット
一方、AMPはSyslogとOpenTelemetryログのみと、SNMPTrapに対応していないことは残念ですが、これらをk8sの環境で集約してクラウドにアップロードできます。
AMPでは一時的なネットワークの接続断が発生し、クラウドへのアップロードが妨げられた際にもローカルストレージに一時的に保存しておき、ネットワークが回復した際にアップロードできる機能が備わっています。
加えて、k8sのノード数を増やすことで大規模な環境でも耐えうる拡張性の高い監視基盤を構築できることも特徴です。
k8sの運用をハードルが高いと感じるか、管理が楽になると感じるかはユーザーそれぞれなものの、ハイブリッドクラウドの監視構成の選択肢が増え、Azure Monitorに統一するモチベーションは上がったと感じます。
なお、Microsoft LearnではサイジングについてMicrosoftがテストした結果を指標として公開してくれています。
MS Learn | Azure Monitor パイプラインのパフォーマンスとサイジング
その他のAMPの特徴
上記以外にもAMPの特徴としては以下が挙げられます。
特にフィルタリングの機能はクラウドにアップロードする前という点で、Log Analytics取り込み時のデータ収集ルール (DCR)のフィルタリングと違いオンプレからの通信量自体を削減できる点が優れています。
- Syslog、CEF形式のメッセージを自動でテーブルのスキーマに変換
- AMP上でクラウドへのデータアップロード前にログをフィルタリング可能
- SyslogはTCP/UDPに加えて、TLSによる暗号化、mTLSによる相互認証対応
Pull型監視のAzureソリューション
ログフォワーダーVMの仕組み、AMPともにPushu型の監視ですが、AzureにはPull型の監視として接続モニターという仕組みがあります。
接続モニターもAzure Arcに対応していますので、オンプレ監視に利用できます。
接続モニターはAzure VMもしくはArc-enabled Serversから特定のエンドポイント (IPアドレス、FQDN、URL)宛てにICMP、TCP、HTTPの通信をおこない、その応答をチェックしてアラートを上げるNetwork Watcherの機能です。
AMPを採用する環境においても、例えばネットワーク機器の監視をAMPによるSyslog監視 + 接続モニターによるping監視のような監視構成を組むことが考えられます。(なお、接続モニターの起点とできるのはサーバですので、何らかサーバ1台を起点としてAzure Arcで接続しておく必要はあります)
MS Learn | 接続監視の概要
AMP利用の前提とサポート環境
AMPの前提とサポート環境にも触れておきます。
前述のとおりAzure Arcを使いますので実行基盤とするk8sはAzureへ接続できることが必須です。
また、k8sでサポートされているディストリビューションは2026/6現在は以下の3つになります。
VMwareやAzure Localを実行している環境であれば、対応するk8sの展開は容易かもしれません。加えてk3sをサポートしていますのでLinuxサーバを立ててそこで実行することも可能です。
- AKS Arc
- VMware Tanzu Kubernetes Grid (TKG)
- SUSE Rancher K3s
詳細なサポートバージョンとサポートリージョンはドキュメントを参照してください。
2026/6現在、東日本リージョンはサポートされていますが、西日本リージョンは未サポートです。
MS Learn | AMPのサポートされている構成
AMPを利用したハイブリッドクラウドの監視構成案
最後に、ここまでで紹介してきたAMPやその他のAzureサービスを活用してハイブリッドクラウド環境の監視をAzure Monitorに統合した場合の構成案を考えてみます。
まずAzure Arcが導入できるサーバはAzure Arc + AMAで直接サーバ監視をおこないます。
一方でネットワーク機器やハードウェアの監視はk8s上に構築するAMPによってSyslog/OpenTelemetryログ監視をおこないます。
最後にPush型ではカバーできないケースを想定して接続モニターを利用したPull型の監視も設定して完了です。
Syslog/OpenTelemetryログの監視で充足できるならば、AMPが入ったことでハイブリッドクラウド環境の監視をAzure Monitorにエンタープライズな可用性のもとで統合できる様になったと言えるのではないでしょうか。
まとめ
AMPはこれまでのログフォワーダーの仕組みからさらに一歩進んで、ハイブリッドクラウド環境の運用課題を変えてくれる可能性を感じる監視基盤サービスです。
現在はSyslog/OpenTelemetlyログのみ対応と、SNMPTrapがないなどの現在のオンプレ監視 (特にネットワーク機器等)のトレンドに不足する部分もありますが、AMP自体はOpenTelemetryのエコシステムの元に設計されているため将来性もあり、今後の拡充や監視対象機器側のトレンドの変化による追従が期待されます。
Azure Arcによるハイブリッドクラウド運用ツールの一つとしてぜひ抑えておきたいところです。