クイックダウンロード:
インフラストラクチャの監視は、可観測性戦略の基盤となります。
-
サーバー、仮想マシン、コンテナ、データベース、ネットワーク機器の状況を把握できなければ、パフォーマンスの問題の根本原因を特定することはできません。
-
ハイブリッドインフラストラクチャと多数のデバイスを抱える企業環境では、オープンソースツール単体では提供できない機能、例えば統合ダッシュボード、機械学習ベースの異常検知、ベンダーによるSLAサポートなどが必要となる場合が多い。
-
適切な監視ツールは、購入後すぐにインフラストラクチャ全体をカバーし、インシデント管理システムと統合でき、イベント相関をサポートして、症状アラートを抑制する必要があります。
-
まずはインフラストラクチャのマッピングを行い、アラート発生時のエスカレーションプランを準備し、事業の成長に合わせて拡張可能なストレージバックエンドを選択することから始めましょう。
インフラ監視
インフラストラクチャ監視は、あらゆる統合監視および可観測性戦略の基盤となる要素です。最新の可観測性はインフラストラクチャ監視を基盤とし、合成監視やAPM(アプリケーションパフォーマンス監視)などの技術と連携することで、アプリケーション層の下で何が起こっているかをチームが完全に把握できるようにします。
インフラストラクチャ監視ツールは、組織のITインフラストラクチャシステム(オペレーティングシステム、仮想マシン、サーバー、ストレージボリューム、ネットワーク、データベース、アプリケーションメッセージングプラットフォームなど)からデータを収集、保存、分析します。インフラストラクチャ監視は、サーバーレス関数やKubernetesなどのコンテナオーケストレーションプラットフォームといったパブリッククラウドサービスも対象とするように進化しています。
クライアント/サーバー環境では、運用チームは主にパフォーマンスのボトルネックを検出するためにインフラストラクチャを監視していました。現代のアプリケーションがより複雑化し、動的になるにつれて(オートスケーリングやロードバランシングなど)、アプリケーション層監視、デジタルエクスペリエンス監視、分散トレーシングといった新たな可視性がその基盤の上に加わりました。現在では、インフラストラクチャ監視とアプリケーション監視が連携して機能しています。エンドユーザーのエクスペリエンスが低下した場合、インフラストラクチャ監視とメトリクス、ログ、トレース、AIによる相関分析を組み合わせることで、ユーザーから基盤となるシステムまで、根本原因を特定することができます。
以下のセクションでは、監視すべきインフラストラクチャオブジェクト、利用可能なデータタイプ(メトリクス、ログ、トレース)、コアツールの機能、オープンソースの選択肢、およびソリューションの選択と実装に関するベストプラクティスについて説明します。
インフラ監視の基本要素

サーバー
サーバーはインフラストラクチャハードウェアの根幹を成すものです。最新のサーバーには、プロセッサ、メモリ、ストレージ、ネットワーク、ファンなどのコンポーネントの状態を直接確認できる管理モジュール(HPサーバーのiLOやDellサーバーのiDRACなど)が搭載されています。現代の環境では、サーバーはハイパーバイザ上で動作することが一般的です。
ハイパーバイザー
ハイパーバイザーとは、オペレーティングシステムとアプリケーションを基盤となる物理ハードウェアから分離するソフトウェア層です。代表的なハイパーバイザーには、VMware ESXi、Xen、Linux KVM、Microsoft Hyper-Vなどがあります。
ハイパーバイザーは、サーバーと同様に、自身の状態や稼働中のサーバーに関する情報を提供する管理モジュールを備えています。単一の管理システムに統合されたハイパーバイザーは、仮想マシンの健全性を維持するための幅広い機能を提供します。潜在的または既存の問題を明らかにするために、パフォーマンスと健全性に関する指標を収集することが重要です。
仮想マシン
仮想マシンとは、ソフトウェアによって定義されるコンピュータまたはサーバーのことです。仮想マシンからメトリックデータを収集することで、ハイパーバイザーから必要なリソースが供給されない場合や、その他のパフォーマンス上の問題が発生している場合を特定することが可能になります。
オペレーティングシステム
オペレーティングシステムとは、コンピュータのリソースを管理し、ユーザーとのやり取りを整理するために設計された一連のプログラムです。ほとんどの環境では、まずCPU、メモリ、ディスク、ネットワークの使用率、システムサービスの状態、およびログイベントから確認を始めます。
コンテナ
コンテナとは、アプリケーションの実行に必要なコード、ランタイム、システムツール、システムライブラリ、設定などすべてを含む、軽量でスタンドアロンの実行可能なソフトウェアパッケージです。Dockerは一般的なコンテナ形式です。コンテナ側からリソース使用率のメトリクスを収集したり、実行中に生成されたログを取得したりできます。コンテナオーケストレーションツール(Kubernetes、OpenShift、Nomadなど)の使用により、単一のコンテナが動作しなくてもアプリケーションやサービスのパフォーマンスに影響しない可能性があるため、監視はより高いレベルに移行する必要があります。
データベース管理システム
データベース管理システム(DBMS)とは、データベースの作成やデータの操作(挿入、更新、選択、削除)を可能にするプログラム群です。代表的な製品としては、MySQL、PostgreSQL、Microsoft SQL Server、Oracle Databaseなどがあります。ほとんどのアプリケーションはデータベースに依存しているため、可用性とクエリパフォーマンスはサービスの健全性にとって非常に重要です。DBMSを使用すると、応答時間、オープン接続数、クエリ実行速度、トランザクションロックとデッドロック、バッファとキャッシュの使用状況など、幅広いメトリックを収集できます。
メッセージブローカー
メッセージブローカーとは、複雑なシステム内の個々のモジュール/アプリケーション間でメッセージを送受信するアプリケーションのことです。代表的な製品としては、RabbitMQやKafkaなどが挙げられます。メッセージブローカーの主要な監視指標は、キュー内のメッセージ数とメモリ使用量です。
データストレージシステム
データストレージシステムは、大量の情報を保存および処理するために設計された、ハードウェアとソフトウェアを組み合わせた単一のソリューションです。ストレージハードウェアコンポーネントの健全性に関する標準的な指標に加えて、ストレージパフォーマンスを評価する上で、次の3つの指標が重要となります。
- サービス時間 ―しばしばレイテンシーまたは応答時間と呼ばれる
- IO/秒 – 1秒あたりの入出力操作数
- MB /秒 -1秒あたりに転送されるメガバイト数。
ネットワークデバイス
これらは、コンピュータ、サーバー、データストレージシステム、その他のデバイスを接続し、データやリソースを共有できるようにするために使用されるコンポーネント(ルーター、スイッチ、アクセスポイント、ファイアウォールなど)です。ネットワークデバイスを使用すると、SNMP(Simple Network Management Protocol)を介して、重要なメトリック(ポートの状態と使用率、エラー、パケット損失など)を取得できます。また、NetFlowプロトコルを使用して詳細なトラフィック情報を受信したり、Syslogを使用して多くのネットワークデバイスからログをキャプチャしたりすることも可能です。
パブリッククラウド
パブリッククラウドは、コンピューティング、ストレージ、ネットワーク、その他のリソースへのアクセスを提供するインフラストラクチャモデルです。ほとんどのパブリッククラウドサービスプロバイダーは独自の監視ツールを提供していますが、パブリッククラウドのリソースが自社のITインフラストラクチャの一部である場合は、それらを直接監視する必要があります。
メトリクス、ログ、トレースを理解する
インフラ監視は、主に3種類のデータに依存している。
- メトリック 監視対象システムの状況や動作を捉える定量的な測定値。例えば、CPU使用率、メモリ消費量、エラー率、その他類似の信号など。
- ログ – システムまたはアプリケーションの動作記録を含むファイル
- 形跡 分散システムにおけるリクエストの通過を追跡します。トレースは、親トレースと子スパンからなるツリー構造です。リクエストトレースは複数のサービスを対象とし、さらにスパンと呼ばれるより小さな断片に分割されます。各断片は、操作または機能に対応します。
インフラストラクチャ監視の主要機能
インフラ監視ツールは通常、以下の機能を備えています。
債権回収業者
監視エージェントは、システムおよび実行中のアプリケーションに関する情報を収集する、軽量な特殊アプリケーションです。監視エージェントを使用することで、監視システムのコアへの負荷を軽減し、ノードから直接チェックを実行できます。また、アプリケーションやサービスが依存するネットワークリソースにアクセス可能かどうかを確認することもできます。一部の監視システムでは、監視システムが利用できない場合、エージェントがデータを蓄積し、システムが利用可能になったときにそのデータを返却することができます。
メトリクスとログの保存
監視システムの中には、データを保存するエンジンを内蔵しているものもあれば、データベース管理システムをデータ保存用に構成できるものもある。
メトリックの種類ごとにストレージポリシーを設定でき、高解像度データを短期間保持し、ダウンサンプリングされたデータを長期間保持できるような監視ツールを探しましょう。
アラート
監視の主な目的の一つは、問題が発生した際にアラートを生成することです。監視インフラストラクチャツールでは、アラートをトリガーするルールと、アラートがアクティブ化された際に実行されるワークフローを設定できる必要があります。例えば、アラートの連絡先、アラートチャネル(メール、SMS、Slackメッセージなど)、アラートの送信タイミング(即時、5分後、1時間後など)を定義することは、インフラストラクチャ監視ツールの必須機能です。
システムによっては、アラート間の依存関係を設定することで、大規模な障害(例えば、ネットワーク障害)発生時のアラート数を減らすことも可能です。
ダッシュボード
ダッシュボードは、重要な情報を1つまたは複数の画面にまとめて表示するインタラクティブなパネルです。ダッシュボードを使用すると、複数のデータソースからのデータをグループ化できます。ダッシュボードを使えば、インフラストラクチャの状態マップ、ネットワークマップ、サービス接続マップなどを実装できます。
レポート
通常、インフラストラクチャ監視ツールには、その状態や発生したイベントに関する事前設定済みのレポートが複数含まれています。レポートエンジンを使用すると、ユーザーはレポートをカスタマイズして、データを自動的かつ定期的に取得できます。
分析と機械学習
分析と機械学習モジュールを備えたインフラストラクチャ監視システムを使用すると、履歴データと検出された依存関係に基づいて問題を特定できます。メトリックの動作パターンを分析することで、正常な動作からの逸脱を自動的に検出できます。ログ、トレース、および インターネットパフォーマンス監視 データ、 AI支援による相関分析 インフラストラクチャの異常とサービスレベルへの影響を関連付けることができ、この機能の高度なバージョンでは、一部の問題を事前に予測することも可能です。
オープンソースのインフラストラクチャ監視ツール
これらの機能は、程度の差こそあれ、複数のオープンソースソリューションによってカバーされている。
ザビックス
Zabbixは、分散環境全体にわたるネットワークパラメータ、サーバーの状態、および整合性を監視するオープンソースの分散監視ソリューションです。設定可能なアラートルーティング(メール、SMS、カスタムスクリプト)をサポートし、過去の時系列データからのレポート作成とデータ可視化を提供します。ポラー(メトリックをアクティブに収集)とトラッパー(メトリックをパッシブに取得)の両方をサポートしています。
流入DB
InfluxDBは、メトリクス、イベント、分析データを記録するためのオープンソースの時系列データベースです。完全なインフラストラクチャ監視ソリューションではありませんが、メトリクスを保存するための効果的なエンジンです。
プロメテウス
Prometheusは、ディメンションデータモデル、柔軟なクエリ言語、効率的な時系列データベース、最新のアラート機能を備えたオープンソースの監視ソリューションです。Prometheusは、動的なアーキテクチャのアプリケーション(マイクロサービス)からメトリクスを収集するのに最適です。Prometheus自体にはダッシュボードモジュールは含まれていませんが、チームはすべてのPrometheusデータをGrafanaで視覚化できます。
エラスティック
Elasticsearchは、分散型のRESTful検索・分析エンジンであり、データを一元的に保存することで、高速な検索、きめ細やかな関連性の確保、そして容易な拡張性を備えた強力な分析を実現します。アプリケーションログの保存によく利用され、データ可視化のためにKibanaと組み合わせて使用されるのが一般的です。
グラファナ
Grafanaは、オープンソースのマルチプラットフォーム対応Webベースの分析およびインタラクティブな可視化アプリケーションです。対応するデータソースに接続することで、Web上でチャート、グラフ、アラートを提供します。Grafanaのダッシュボードは柔軟性が高く、技術チームだけでなく、経営陣を含む非技術系の関係者にも対応できます。
インフラストラクチャ監視ツールの選択と実装に関するベストプラクティス
インフラストラクチャ監視ツールを選定・導入する際には、以下の4つの領域に留意してください。
- インフラストラクチャ計画を準備し、監視ユーティリティが標準機能でインフラストラクチャの要素をどの程度カバーしているかを確認してください。監視ツールをカスタマイズする前にカバーできる要素が多いほど、インフラストラクチャ全体を完全にカバーするのにかかる時間を短縮できます。
- インフラストラクチャ監視ソリューションによって生成されたアラートに対するエスカレーション計画を、以下の点を考慮して作成してください。
- アラートの転送先(例:Slack、メール、PagerDuty、コンソール)
- 即時対応を必要としないアラートを延期するための戦略
- インシデント管理システムとの統合
- 基本的な修復措置を実行できる自動化システムとの統合
- 選択した監視ツールが複数のデータベースシステム(リレーショナル、NoSQL、クラウドベースなど)をサポートしている場合は、長期的に見て拡張性が高くコスト効率の良いものから始めましょう。データベースシステムの変更は複雑で困難な作業なので、事前に慎重に検討しておくことが重要です。
- インフラストラクチャアラートでよくある問題は、その膨大な量です。イベント相関をサポートするツール、あるいは既存のツールにイベント相関機能を追加することを検討してください。こうした技術は、症状アラートを抑制し、通知の洪水を防ぎます。例えば、ネットワーク経路がダウンした場合、到達不能なネットワークセグメントごとにアラートを生成するのではなく、単一のアラートを生成するようになります。
結論
インフラストラクチャ監視は、現代の環境におけるパフォーマンス問題の根本原因を特定するための基礎的なツールです。これは、アプリケーションサービスの物理的および仮想的な配信を担うサーバーとすべてのミドルウェアシステムを網羅する、統合的な監視および可観測性アプローチをサポートします。
インフラストラクチャ層の劣化はエンドユーザーエクスペリエンスに影響を及ぼすことが多いため、最新のオブザーバビリティ戦略は、インフラストラクチャ監視を置き換えるのではなく、それを基盤として構築されます。すぐに環境をカバーし、インシデント管理ワークフローと統合でき、ストレージ移行を必要とせずに拡張可能なツールを選択してください。 LogicMonitorの 統合プラットフォームは、LM Envision を介してインフラストラクチャ テレメトリをインターネット パスおよびエンド ユーザー エクスペリエンスの可視性に接続します。 キャッチポイントユーザーから基盤となるインフラストラクチャに至るまでの盲点を減らす。 エドウィン AI さらに、インテリジェントなオーケストレーション機能を追加し、複数のレイヤーにわたるメトリクス、ログ、トレースを関連付けることで、インフラストラクチャからエンドユーザーエクスペリエンスまでを単一のビューでチームに提供します。
インフラストラクチャのあらゆるレイヤーを完全に可視化します。
LogicMonitorの統合プラットフォームは、サーバー、仮想マシン、コンテナ、データベース、ネットワーク、クラウドのリソースを単一のビューでカバーし、インターネット経路やエンドユーザーエクスペリエンスから基盤となるインフラストラクチャまで、可視性を拡張します。また、アラート機能、分析機能、AIを活用したイベント相関機能も内蔵しています。
よくあるご質問
インフラストラクチャ監視とアプリケーション監視の違いは何ですか?
インフラストラクチャ監視は、アプリケーションを支える基盤システム(サーバー、仮想マシン、コンテナ、データベース、ネットワーク、ストレージなど)の健全性とパフォーマンスに焦点を当てます。アプリケーション監視(APM)は、応答時間、エラー率、ユーザートランザクションなど、アプリケーション自体の動作とパフォーマンスを追跡します。これら2つのアプローチは、統合された可観測性戦略の一環として相互に補完し合います。APMがサービス低下を検出すると、インフラストラクチャ監視は、根本原因がリソース制約、ネットワークの問題、ハードウェア障害のいずれであるかを特定するのに役立ちます。ログ、トレース、インターネットパスの可視性と組み合わせることで、エンドユーザーエクスペリエンスからインフラストラクチャ層まで、チームに包括的な状況把握を提供します。
インフラ監視を設定する際に、どの指標を優先すべきでしょうか?
監視対象オブジェクトごとに、CPU、メモリ、ディスク、ネットワークの使用状況といったコアリソース利用率の指標から始めましょう。データベースの場合は、応答時間、オープン接続数、クエリ実行速度を追加します。ストレージシステムの場合は、サービス時間(レイテンシ)、IO/秒、MB/秒を追跡します。ネットワークデバイスの場合は、SNMPとNetFlowを使用してポートの状態、使用率、エラー、パケット損失を監視します。エンドユーザーエクスペリエンスとサービス可用性に直接関連する指標を優先的に監視してください。
インフラ監視におけるアラートノイズを低減するにはどうすればよいですか?
イベント相関を利用して、症状アラートを抑制しましょう。例えば、ネットワーク経路がダウンした場合、優れた相関エンジンは到達不能セグメントごとにアラートを生成するのではなく、単一のアラートを生成します。また、下流の障害によって個別の通知がトリガーされないように、アラートの依存関係を設定してください。緊急性の低い問題に対するアラートの遅延や、インシデント管理システムとの連携を含むエスカレーション計画を策定しましょう。
オープンソースのインフラ監視ツールは、エンタープライズ規模で機能するだろうか?
Zabbix、Prometheus、Grafanaといったオープンソースツールは大規模なシステムにも対応できますが、ハイブリッドインフラストラクチャ、多数のデバイス、複雑なアラート要件を持つエンタープライズ環境では、データソース全体にわたる統合ダッシュボード、機械学習ベースの異常検知、ガバナンスに基づく自動化、ベンダーサポート付きのSLAなど、追加の機能が必要となることがよくあります。オープンソースのみのアプローチを採用する前に、カバレッジ要件、統合ニーズ、運用上のオーバーヘッドを評価してください。




