システムの監視とトラブルシューティングは、ITチームの基本的な責任範囲となる業務です。NISTやITILなどのコンプライアンスフレームワークは、監視のためのガイドラインです。しかし、これらの標準には、異なる解釈の余地があるため、監視のための戦略は実施が困難になる場合があります。以下のセクションでは、IT環境の監視について、いつ、誰が、何をどのようにすべきなのか概要を説明します。
IT環境を監視する際の1つの方法として、次の3つのカテゴリのデータの検討が挙げられます。
1つ目はログデータです。これは、共通の構造であるか、単純なテキストであるかに関わらず、ログファイルに書き込まれるデータとして定義できます。ログデータは、IT環境全体で発生するトランザクションの詳細な記録です。 2つ目は資産データです。資産から直接取得されたデータを指します。CPUやメモリなどの基本的なリソースメトリックから、特定のIT資産で実行されているプロセスやアプリケーションに関する情報までさまざまなものがあります。 資産データは、通常は標準のログファイルに記録されないイベントを監視するときに特に役立ちます。最後にネットワークデータがあります。帯域幅、ネットワーク接続の詳細、ルーティング動作など、ネットワークパフォーマンスに固有のデータです。
これら3つのデータタイプすべての監視は、成熟したIT運用の基本です。システムモニタリングは通常、特にログデータと資産データの分析に焦点を当てています。
監視対象となり得るシステムは多数あります。対象として選択するシステムは最終的には環境に依存します。 次のような選択肢があります。
サーバー：サーバー監視は、アプリケーションをホストしているサーバー、Active Directoryドメインコントローラー、ファイル共有、電子メールサーバーなど、幅広いシステムを対象としています。Windows、Linux、Macのいずれのマシンであっても、ほとんどのサーバーはある程度のイベントログを提供します。
データベース：多くのデータベースは、管理者がエラーをデバッグし、将来の問題を特定するのに役立つさまざまなログレベルを提供します。データベースからログに記録される一般的なイベントには、遅延クエリとSQLタイムアウト、行制限、メモリ制限、キャッシュの問題などがあります。
アプリケーション：プリケーションには、購入したサードパーティアプリケーションと社内で開発されたアプリケーションの両方が含まれます。サードパーティアプリケーションによっては、ホストにログを書き込むためログを収集できます。社内チームが開発したアプリケーションも、キャプチャ可能な重要なイベントをログに記録するように構築する必要があります。 アプリケーションが顧客向けなのか従業員向けなのか考慮してください。アプリケーションの対象が誰であるか問わずアプリケーションのパフォーマンスの監視は重要です。顧客向けのアプリケーションとサービスではより詳細なログを記録する必要がある場合があります。
クラウドサービス：クラウドサービスで、とりわけAWSやAzureなどのIaaSリューションは、システム監視計画に役立ちます。サービス自体がログ表示機能を提供している場合がありますが、サービスの外部でログを収集して保存することも可能です。すべてのログを1つの場所に収集して保存すると、後で情報を見つけやすくなります。
コンテナ：コンテナは、Dockerなどのサービスが登場した結果、アプリケーションとインフラストラクチャの両方の設計とホスティングのアプローチとして一般的になってきています。インフラストラクチャが物理マシンよりも細分化され、ライフサイクルが短くなり、コードへの依存が大きくなると、 コンテナの監視はシステムの健全性に大きく影響を与えてきます。
従業員のワークステーション：従業員のマシン上のソフトウェアもしくはプロセスが競合している場合、あるいはネットワークにパケットがあふれている場合、従業員のワークステーションで何が実行されているか確認できるようにする必要があります。 物理的な資産は、追跡に時間がかかったり、追跡ができなかったりするので、リモートで確認できるようにすることが重要になります。
エラー：アプリケーションエラーとシステムエラーの記録は簡単です。「エラー」をキーワードにしてIT環境を調査することが往々にして良い出発点になり得ます。システムによっては、エラーをタイプ別に分類し、どのイベントに注意すべきか表示が可能です。
CRUDイベント：一般に、情報の作成、読み取り、更新、削除のタイミングをキャプチャすることは、とりわけアプリケーションの問題のデバッグに役立ちます。イベントからは、問題を直接把握することができない場合が多いのですが、問題について根本原因までさかのぼる際、非常に役に立つ情報源になる可能性があります。
トランザクション： 「トランザクション」は、多くの場合、購入、サブスクリプション、キャンセル、送信などの重要なイベントを指します。個々のトランザクションについて、失敗したトランザクションと不完全なトランザクションについて厳密に監視する必要があります。システムによっては、トランザクションの問題の原因に関する重要な情報とともにエラーコードが記録される場合があります。 Microsoft SQL Serverなどシステムによっては、それらの情報を1つのログにキャプチャするための専用のトランザクションログを提供しています。そうでないシステムでは、それらの情報を自分で一元化する必要がでてくる場合があります。
アクセス要求とアクセス許可の変更： Active Directoryなどのサービスからログを記録すると、環境内のユーザーの行動に関する重要な情報を表示できます。アクセス許可の変更などのデータを監視し収集しておけば、意図していない管理者権限をユーザーが取得してしまうのを防ぐのに役立ちます。 このタイプの監視は、特定のコンプライアンス基準を満たすためにしばしば必要となります。
システムメトリック：CPU、メモリ、ディスク使用率などのシステムメトリックは、システムの障害を防ぐために常に綿密に監視する必要があります。 これらの値に劇的な変化が生じている場合、システム停止やシステム停止に近づいた状態になっている可能性があります。長期間にわたってこれらのメトリックを収集しておけば、将来のシステムのキャパシティを計画するのに役立ちます。
監視対象のシステム、イベント、メトリックが広範囲にわたっていることを考慮すると、とりわけシステムがダウンした場合、唯一のデータソースに一元化して集中管理するのが良いかもしれません。 容易にログの検索、可視化、アラートの生成ができるように、ログの収集、集中化、整理ができる、ログ管理ソリューションというものがあります。
監視ソリューションなら、単なるログ管理だけでなく、個々のIT資産の監視ができます。 リソース使用率メトリックの継続的な測定と、資産で実行されているソフトウェアとプロセスの追跡などが監視できます。ソフトウェアの使用状況は、従来のログに記録されることはあまりありません。しかし、システムの問題の根本的な原因に対する重要な手がかりを得ることが可能です。IT資産データを測定可能なだけでなく、結果をログに記録できれば、IT環境全体の可視性が大幅に向上します。
つまり、システムの一定の可用性を維持する必要があるのであれば、24時間365日システムを監視する必要があります。多くの場合、監視はバックグラウンドで行われ、常に注意を払う必要がありません。 ところが、次のような場合には、システムデータを積極的に監視することが求めらます。
システムの更新：システムが更新されるたびに、更新が失敗したり、更新が意図しないような複合的な問題を生じさせるリスクがあります。
アプリケーションの展開とロールバック：コード（またはロールバックコード）をアプリケーションに展開する場合、すべての単体テストと受け入れテストに合格しても、予期しない問題が発生する可能性があります。
移行：データの移行は課題が生じる場合が多く、データタイプの不一致、検証の問題などが発生するケースがあります。
ピークトランザクション時間 ：企業によっては、休日や販売中のeコマース会社など、トランザクションが増加する特定の期間があることが知られています。れらのピーク時に発生する可用性の問題は、すぐに発見されなければ重大な結果をもたらす可能性があります。
ITシステムの監視とトラブルシューティングには多くの要素があります。監視する必要のあるシステムとイベントにIT環境を分割することが、組織にとって最適な監視戦略とソリューションを決定するための第一歩となります。