マルチクラウド監視ツールの選び方：リソースと調査経路を揃える

マルチクラウド監視ツールを選ぶとき、私は対応クラウドの数より、調査中に何度境界をまたぐかを先に見ます。AWS のリソースアラート、Azure のアプリケーショントレース、Google Cloud のログはそれぞれ開けても、アカウントを探し、時間範囲を合わせ、別の名前が同じサービスを指すか確認する作業は残ります。この繰り返しを減らすことに、統合の意味があります。

独立した業務を既存のクラウド監視で十分に運用できているなら、その仕組みを維持する判断は合理的です。クラウドをまたぐ呼び出しの調査が日常になったり、複数チームが収集・権限・アラートを重複して保守したりしている場合は、共通バックエンドやクエリの入口に価値が出てきます。Guance は調査の流れを共通化し、バックエンド運用を減らしたいチームの候補になります。ただし、ワークスペースとサイトの境界は設計に含める必要があります。

Guance 編集部 · 2026 年 10 月 28 日。公式資料を基に、マルチクラウド監視の仕組みと運用責任を比較しています。発行元の Guance も比較対象です。同一負荷での性能比較や顧客費用の実測は行っていません。

リソースとサービスの識別を揃える

クラウド請求ではアカウントとリージョンに属するホストが、Kubernetes では複数サービスを動かし、トレースではアプリケーション名だけで現れることがあります。同じ画面に並べても、それだけで関係が結び付くわけではありません。

まずプロバイダー固有のリソース識別子を残し、サービス、環境、担当者の共通ルールを加えます。次の表は正規化方針の例であり、製品が自動的に埋めるフィールドの一覧ではありません。

OpenTelemetry のクラウドリソース規約には、プロバイダー、アカウント、リージョン、固有リソース ID などの属性があります。収集後はバックエンドが使うフィールドへの対応付けも必要です。ログの service、OTel の service.name、クラウドタグが同じサービスを表す場合でも、似た文字列という理由だけで統合することはできません。

時間とサンプリングも同じくらい重要です。検索時間帯がずれていたり、失敗リクエストの Span が保存されていなかったりすると、調査には穴が残ります。識別子と記録が揃った上で、繰り返しの絞り込みをどれだけ減らせるかを見ると、共通画面の価値が分かります。

クラウド標準の監視は、検索範囲を理解して使う

AWS、Azure、Google Cloud には、複数リソースや複数プロジェクトを監視する仕組みがあります。「各クラウドに閉じていて連携できない」と整理すると、有効な既存投資を見落とします。

CloudWatch のクロスアカウントオブザーバビリティは、同一リージョン内で監視アカウントとソースアカウントを結び、設定したメトリクス、ログ、トレースなどを共有します。クロスリージョンのログ一元化は別の仕組みです。ルールによって新着ログを複製し、ルール作成前の履歴は自動で取り込みません。アカウントをまたぐ参照とリージョンをまたぐコピーでは、データ経路も費用も異なります。CloudWatch のログ一元化

Azure Monitor は、AWS、GCP、その他の場所で動くワークロードからもテレメトリーを収集できます。VM のゲスト情報には Azure Arc と Azure Monitor Agent、アプリケーションには該当する Application Insights の収集経路を使えます。監査ログでは対応するコネクターや製品も関係します。収集経路の導入、権限、保守は必要であり、マルチクラウド対応だけで全データが検索可能になるわけではありません。Azure のマルチクラウド監視

Google Cloud Monitoring の metrics scope は、あるプロジェクトがどのプロジェクトの時系列を表示・監視できるかを決めます。ログ検索の対象は Cloud Logging の log scope などで管理します。メトリクスのスコープから、ログ閲覧権限やログの集中保存まで推測してはいけません。メトリクスのスコープ · ログのスコープ

調査の大半がこうした範囲で完結し、チームが操作に慣れているなら、標準サービスは有力です。クラウド間の呼び出しを頻繁に追うようになったとき、入口、属性、権限を結ぶ作業を減らす必要性が高まります。

データとクエリをどこに置くか

コントロールプレーンは設定、ID、操作の入口を管理し、データプレーンは受信、保存、クエリ実行を担当します。両者の配置は分けて考えられます。複数リージョンで同じ製品を使うことと、全レコードを一か所に集めることは別です。複数地域のパネルが一画面にあっても、地域横断の明細結合ができるとは限りません。

フェデレーションが適した要件もあります。ただし、接続先が応答しないときに、エラー、タイムアウト、明示された部分結果のどれを返すかは決める必要があります。空のグラフを、そのまま「エラーなし」と受け取らせてはいけません。

Guance のワークスペース間データ認可では、受け手が認可された範囲のデータを参照します。サイトをまたぐ場合は認可パッケージの生成とインポートが必要で、1 回の横断クエリの対象は同じ宛先サイト内のワークスペースです。複数サイトの集計にはサイトごとのリクエストとクライアント側での結果統合が必要です。クライアントの実行場所と集約する項目も、データ経路の設計に含まれます。DQL クエリ API

他製品にも境界があります。Datadog はサイトが独立しており、サイト間でデータを共有できないと説明しています。Grafana Cloud は対応する外部データソースに接続できますが、通信経路、認証情報、クエリ動作は実際のバックエンドに依存します。パネルを並べただけで、サイト間で結合できる一組のレコードになるわけではありません。Datadog Sites · Grafana の外部データソース

保存先、バックアップ、エクスポート、リモートアクセス、クエリ結果まで含めて、組織のデータ処理方針を考えます。地域サービスは保存場所の選択肢になりますが、具体的な要件はデータ、アクセス方法、契約によって変わり、地名だけで適合性は判断できません。

調査の周辺作業を減らす

AWS 上のサービスが Azure の依存先を呼ぶ例を考えます。サービス名は担当者を見つける手掛かりになり、trace ID は個々のリクエストを区別します。リソースの識別情報から、その時点のホスト、コンテナ、ネットワークへと調査を進めます。それぞれ根拠が異なり、一つの「マルチクラウドタグ」で置き換えることはできません。

Guance のトレース詳細は trace_id によるログ関連付けや、関連するホスト、コンテナ、Pod などの情報への参照を提供します。対象データが収集済みで、サービス属性、インデックスの対応付け、時間範囲、権限が一致している必要があります。ログの保存期間を長くしても、期限切れのトレースは復元されません。トレース詳細と関連分析

プラットフォーム保守を減らしたいチームにとって、マネージドの調査経路には具体的な意味があります。収集と業務ルールの設定からログ、トレース、リソースの調査へ進めるため、別のバックエンド構築プロジェクトを前提にしなくて済みます。サービス命名、コンテキスト伝播、アラート担当はチームに残り、サービス側がバックエンド運用と文書化された分析機能を担います。

成熟したプラットフォームチームなら、自主管理も続けられます。Prometheus federation は選択した時系列を収集し、Thanos Query は対応する StoreAPI のデータソースを読み取ります。これらはメトリクスの経路なので、ログとトレースには別途バックエンドが必要です。HA レプリカの重複系列、リージョンのタイムアウト、部分応答も、実際のクエリ設定で扱います。Prometheus federation · Thanos Query

既存基盤が安定しているなら、移行によって実際に減るコンポーネントと保守時間を比べます。送信先を変えても旧システムをすべて残す間は、二重送信と履歴参照の費用が増えます。

クラウド料金と監視基盤の料金を分けて読む

費用には、業務ワークロードを動かす費用と、それを観測する費用の二層があります。アカウント、リソース、請求期間で対応付けられますが、更新時刻と計量単位は同じではありません。

たとえば Guance の AWS Billing 連携では、対応する Cost Explorer 権限に加え、コレクターの extra_tags に account_name と account_id を設定します。リソース単位のデータには AWS 側の設定も必要で、この連携は前日分（T-1）の請求データを収集します。過去の費用変化とリソース使用を見直す用途であり、稼働中リソースのリアルタイム価格情報ではありません。

タグの対応関係も保守対象です。リソースの再作成、アカウントの移動、コストセンター変更があっても、過去の請求の帰属まで書き換わるとは限りません。現在のタグで履歴を再集計する場合は、元の請求期間と識別子を残すことで、配賦基準の変化を説明できます。

監視サービスでは、実際に使う信号と機能を計量します。ホスト、アクティブなメトリクス系列、取り込みバイト、インデックス付きイベント、保存期間、クエリ、RUM セッション、追加計算は異なる入力です。「200 台のホストと 1 日 200 GB のログ」だけでは、SaaS 月額全体は求められません。

総投入
= 各リージョンのプラットフォーム料金の合計
+ 顧客側で運用する収集・保存・通信の費用
+ 共通クエリと ID 連携の保守投入
+ 移行期間の二重送信と履歴参照の費用

プランに含まれるものは二重に加算せず、顧客が運用する部分は漏らさず計上します。通常月とピーク月を分け、同じ調査範囲と保存結果で比較します。作業時間と現金支出を分けておくと、サービス料金によってどれだけ運用負担を減らせるかが見えます。

手間の大きい調査経路からまとめる

私は、機能しているクラウド標準監視を残しつつ、頻繁に使うクロスクラウド調査のサービス識別、アラートの入口、証拠へのリンクから揃えます。ベンダー名を統一するために全履歴を移さなくても、絞り込みの繰り返しを減らせます。

大半の作業が各クラウドや地域で完結するなら、標準サービスと、責任者の明確な少数の連携で足りる場合があります。クラウド間調査が日常化し、検索・保存・関連付けのバックエンドを維持する余力がないなら、Guance のようなマネージド基盤を検討する価値が高まります。調査の経路が短くなり、自分たちで提供するバックエンドが減ることが、その価値です。

基盤リソースを自ら管理する必要があり、サービス全体を長期運用できるチームは、自主管理の構成を発展させられます。どの方法でも、共通のリソース識別とデータの意味を残します。サービスや信号を移す際は、対応する権限、クエリ、アラートも一緒に移します。すべてのクラウドを覆うように見えるダッシュボードより、人が理解し、保守を続けられるマルチクラウド構成の方が役立ちます。