監視と診断のガイダンス

Azure Monitor

クラウドで実行されている分散アプリケーションとサービスは、その性質上、多くの可動部分を構成する複雑なソフトウェアです。 運用環境では、ユーザーがシステムを使用する方法を追跡し、リソース使用率をトレースし、システムの正常性とパフォーマンスを一般的に監視できることが重要です。 ここに記載する情報を診断に使用して、問題の検出と修正を行うことができます。さらに、潜在的な問題を見つけてその発生を防止するために役立てることもできます。

監視と診断のシナリオ

監視を使用すると、システムがどの程度正常に機能しているかについての分析情報を得ることができます。 監視は、サービス品質目標を維持するうえで重要な部分です。 監視データを収集する一般的なシナリオは次のとおりです。

• システムが正常な状態を維持していることを確認します。
• システムとそのコンポーネント要素の可用性の追跡。
• 作業量の増加に伴ってシステムのスループットが予期せず低下しないように、パフォーマンスを維持する。
• システムが顧客と確立されたサービス レベル アグリーメント (SLA) を満たしていることを保証します。
• システム、ユーザー、およびデータのプライバシーとセキュリティを保護する。
• 監査または規制目的で実行される操作を追跡します。
• システムの日常的な使用状況を監視し、対処されていない場合に問題につながる可能性がある傾向を見つけます。
• 最初のレポートから考えられる原因の分析、修正、結果的なソフトウェア更新プログラム、展開まで、発生した問題を追跡します。
• 操作のトレースとソフトウェア リリースのデバッグ。

注

このリストは包括的なものではありません。 このドキュメントでは、監視を実行するための最も一般的な状況として、これらのシナリオに焦点を当てています。 他にも、あまり一般的ではない、または環境に固有のものもあります。

次のセクションでは、これらのシナリオについて詳しく説明します。 各シナリオの情報については、次の形式で説明します。

1. シナリオの簡単な概要。
2. このシナリオの一般的な要件。
3. シナリオをサポートするために必要な生のインストルメンテーション データと、この情報の考えられるソース。
4. この生データを分析して組み合わせて、意味のある診断情報を生成する方法。

健康状態の監視

システムが実行中で、要求を処理できる場合、システムは正常です。 正常性監視の目的は、システムのすべてのコンポーネントが期待どおりに機能していることを確認できるように、システムの現在の正常性のスナップショットを生成することです。

正常性監視の要件

システムの一部が異常と見なされた場合、オペレーターは (数秒以内に) 迅速にアラートを受け取る必要があります。 オペレーターは、システムのどの部分が正常に機能していて、どの部分で問題が発生しているかを確認できる必要があります。 システムの正常性は、信号システムを介して強調表示できます。

• 異常の場合は赤 (システムが停止しました)
• 部分的に正常な黄色 (システムは機能が低下して実行されています)
• 完全に健康のための緑

包括的な正常性監視システムを使用すると、オペレーターはシステムをドリルダウンして、サブシステムとコンポーネントの正常性状態を表示できます。 たとえば、システム全体が部分的に正常であると示されている場合、オペレーターはズームインし、現在使用できない機能を判断できる必要があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

正常性の監視をサポートするために必要な生データは、次の結果として生成できます。

• ユーザー要求の実行のトレース。 この情報を使用して、成功した要求、失敗した要求、および各要求にかかる時間を判断できます。
• 代理ユーザーの監視。 このプロセスは、ユーザーが実行するステップをシミュレートし、定義済みの一連の手順に従います。 各ステップの結果をキャプチャする必要があります。
• 例外、エラー、警告のログ記録。 この情報は、トレース ステートメントがアプリケーション コードに埋め込まれた結果としてキャプチャされるだけでなく、システムが参照するすべてのサービスのイベント ログから情報を取得した結果としてキャプチャできます。
• システムが使用するサード パーティサービスの正常性の監視。 この監視には、これらのサービスが提供する正常性データの取得と解析が必要になる場合があります。 この情報にはさまざまな形式が使用される場合があります。
• エンドポイントの監視。 このメカニズムの詳細については、「可用性の監視」セクションを参照してください。
• バックグラウンド CPU 使用率や I/O (ネットワークを含む) アクティビティなどのアンビエント パフォーマンス情報の収集。

正常性データの分析

正常性監視の主な焦点は、システムが実行されているかどうかを迅速に示することです。 重要なコンポーネントが異常として検出された場合、即時データのホット分析によってアラートがトリガーされる可能性があります。 (たとえば、連続する一連の ping に応答できません)。その後、オペレーターは適切な是正措置を取ることができます。

より高度なシステムには、最近および現在のワークロードに対してコールド分析を実行する予測要素が含まれる場合があります。 コールド分析では、傾向を特定し、システムが正常な状態を維持する可能性があるかどうか、またはシステムに追加のリソースが必要かどうかを判断できます。 この予測要素は、次のような重要なパフォーマンス メトリックに基づく必要があります。

• 各サービスまたはサブシステムに送信される要求のレート。
• これらの要求の応答時間。
• 各サービスとの間で送受信されるデータの量。

メトリックの値が定義されたしきい値を超えた場合、システムはアラートを生成して、オペレーターまたは自動スケール (使用可能な場合) が、システムの正常性を維持するために必要な予防措置を実行できるようにします。 これらのアクションには、リソースの追加、失敗している 1 つ以上のサービスの再起動、優先順位の低い要求への調整の適用が含まれる場合があります。

可用性の監視

真に正常なシステムでは、システムを構成するコンポーネントとサブシステムが使用可能である必要があります。 可用性の監視は、正常性の監視と密接に関連しています。 ただし、正常性の監視はシステムの現在の正常性をすぐに確認できるのに対し、可用性の監視は、システムとそのコンポーネントの可用性を追跡してシステムのアップタイムに関する統計情報を生成することに関係します。

多くのシステムでは、重大な障害や接続の損失が発生した場合に迅速なフェールオーバーを可能にするために、一部のコンポーネント (データベースなど) が組み込みの冗長性で構成されています。 理想的には、ユーザーはこのようなエラーが発生したことを認識しないようにする必要があります。 ただし、可用性の監視の観点からは、このような障害に関するできるだけ多くの情報を収集して原因を特定し、再発を防ぐための是正措置を講じる必要があります。

可用性の追跡に必要なデータは、いくつかの下位レベルの要因によって異なります。 これらの要因の多くは、アプリケーション、システム、および環境に固有である可能性があります。 効果的な監視システムは、これらの低レベルの要因に対応する可用性データをキャプチャし、それらを集計してシステムの全体像を把握します。 たとえば、eコマース システムでは、顧客が注文を行えるビジネス機能は、注文の詳細が格納されているリポジトリと、これらの注文に対する支払いのために通貨トランザクションを処理する支払システムによって異なります。 したがって、システムの注文配置部分の可用性は、リポジトリと支払サブシステムの可用性の機能です。

可用性の監視の要件

また、オペレーターは、各システムとサブシステムの可用性の履歴を表示し、この情報を使用して、1 つ以上のサブシステムが定期的に失敗する可能性のある傾向を特定できる必要があります。 (ピーク処理時間に対応する特定の時刻にサービスが失敗し始めますか?

監視ソリューションでは、各サブシステムの可用性または使用不能性の即時および履歴ビューを提供する必要があります。 また、1 つ以上のサービスが失敗したとき、またはユーザーがサービスに接続できない場合に、オペレーターに迅速にアラートを送信することもできます。 これは、各サービスを監視するだけでなく、サービスとの通信を試みたときにこれらのアクションが失敗した場合に各ユーザーが実行するアクションを調べることの問題です。 ある程度、ある程度の接続エラーは正常であり、一時的なエラーが原因である可能性があります。 ただし、特定の期間中に発生した特定のサブシステムへの接続エラーの数に関するアラートをシステムが生成できるようにすると便利な場合があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

正常性の監視と同様に、可用性の監視をサポートするために必要な生データは、発生する可能性のある例外、障害、警告を合成ユーザーが監視してログに記録した結果として生成できます。 さらに、エンドポイントの監視を実行することで可用性データを取得できます。 アプリケーションは、1 つ以上の正常性エンドポイントを公開できます。各テストでは、システム内の機能領域にアクセスできます。 監視システムは、定義されたスケジュールに従って各エンドポイントに ping を実行し、結果 (成功または失敗) を収集できます。

すべてのタイムアウト、ネットワーク接続エラー、接続の再試行を記録する必要があります。 すべてのデータにタイムスタンプを付ける必要があります。

可用性データの分析

次の種類の分析をサポートするには、インストルメンテーション データを集計して関連付ける必要があります。

• システムとサブシステムの即時可用性。
• システムとサブシステムの可用性エラー率。 オペレーターは、障害を特定のアクティビティ (システムが失敗したときに何が起こっていたか) と関連付けることができるのが理想的です。
• 指定した期間におけるシステムまたはサブシステムの障害率と、障害が発生したときのシステムの負荷 (ユーザー要求の数など) の履歴ビュー。
• システムまたはサブシステムが使用できない理由。 たとえば、サービスが実行されていない、接続が失われた、接続されているがタイムアウト、接続されているがエラーが返されるなどの理由が考えられます。

次の数式を使用して、一定期間のサービスの可用性の割合を計算できます。

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

これは SLA の目的で役立ちます。 (SLA の監視 については、このガイダンスの後半で詳しく説明します)。 ダウンタイム の定義は、サービスによって異なります。 たとえば、Visual Studio Team Services Build Service では、ビルド サービスが使用できない期間 (合計累積分数) としてダウンタイムが定義されます。 1 分間を通して顧客が開始した操作を実行するために Build Service に対するすべての継続的な HTTP 要求でエラー コードが発生した場合、または応答が返されない場合、1 分間は使用できないと見なされます。

パフォーマンスの監視

(ユーザーの量を増やすことで) システムがますますストレスを受けるにつれて、これらのユーザーがアクセスするデータセットのサイズが大きくなり、1 つ以上のコンポーネントの障害が発生する可能性が高くなります。 多くの場合、コンポーネントの障害の前にパフォーマンスが低下します。 このような減少を検出できる場合は、状況を解決するための予防的な手順を実行できます。

システムのパフォーマンスは、さまざまな要因によって異なります。 各要因は通常、主要業績評価指標 (KPI) (1 秒あたりのデータベース トランザクション数や、指定された時間枠内で正常に処理されたネットワーク要求の量など) によって測定されます。 これらの KPI の中には、特定のパフォーマンス メジャーとして使用できる KPI もあれば、メトリックの組み合わせから派生した KPI もあります。

注

パフォーマンスの低下または良好なパフォーマンスを判断するには、システムを実行できるパフォーマンスのレベルを理解する必要があります。 これには、システムが一般的な負荷の下で機能している間にシステムを監視し、一定期間にわたって KPI ごとにデータをキャプチャする必要があります。 これには、テスト環境でシミュレートされた負荷の下でシステムを実行し、運用環境にシステムをデプロイする前に適切なデータを収集することが含まれる場合があります。

また、パフォーマンスを目的とした監視がシステムの負担にならないようにする必要があります。 パフォーマンス監視プロセスが収集するデータの詳細レベルを動的に調整できる場合があります。

パフォーマンス監視の要件

システムのパフォーマンスを調べるには、オペレーターは通常、次を含む情報を確認する必要があります。

• ユーザー要求の応答率。
• 同時ユーザー要求の数。
• ネットワーク トラフィックの量。
• ビジネス トランザクションが完了するレート。
• 要求の平均処理時間。

また、オペレーターが次のような相関関係を見つけるのに役立つツールを提供すると便利です。

• 同時ユーザー数と要求待機時間 (ユーザーが要求を送信した後に要求の処理を開始するのにかかる時間)。
• 同時ユーザーの数と平均応答時間 (処理を開始した後に要求が完了するまでにかかる時間)。
• 要求の量と処理エラーの数。

この高度な機能情報と共に、オペレーターはシステム内の各コンポーネントのパフォーマンスの詳細なビューを取得できる必要があります。 通常、このデータは、次のような情報を追跡する低レベルのパフォーマンス カウンターを通じて提供されます。

• メモリ使用率。
• スレッドの数。
• CPU 処理時間。
• 要求キューの長さ。
• ディスクまたはネットワークの I/O レートとエラー。
• 書き込みまたは読み取りを行ったバイト数。
• キューの長さなどのミドルウェア インジケーター。

すべての視覚化では、オペレーターが期間を指定できるようにする必要があります。 表示されるデータは、現在の状況のスナップショットまたはパフォーマンスの履歴ビューである可能性があります。

オペレーターは、指定した時間間隔中に、指定した値に対する任意のパフォーマンスメジャーに基づいてアラートを生成できる必要があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

ユーザーの要求が到着してシステムを通過する際の進行状況を監視することで、高レベルのパフォーマンス データ (スループット、同時実行ユーザーの数、ビジネス トランザクションの数、エラー率など) を収集できます。 これには、タイミング情報と共に、アプリケーション コードの重要なポイントにトレース ステートメントを組み込む必要があります。 エラー、例外、および警告はすべて、それらを原因となった要求と関連付けるのに十分なデータでキャプチャする必要があります。 インターネット インフォメーション サービス (IIS) ログは、もう 1 つの便利なソースです。

可能であれば、アプリケーションが使用する外部システムのパフォーマンス データもキャプチャする必要があります。 これらの外部システムは、パフォーマンス データを要求するための独自のパフォーマンス カウンターまたはその他の機能を提供する場合があります。 これが不可能な場合は、外部システムに対して行われた各要求の開始時刻や終了時刻などの情報を、操作の状態 (成功、失敗、警告) と共に記録します。 たとえば、ストップウォッチアプローチを使用して要求を時刻に設定できます。要求の開始時にタイマーを開始してから、要求が完了したときにタイマーを停止します。

システム内の個々のコンポーネントの低レベルのパフォーマンス データは、Windows パフォーマンス カウンターや Azure Diagnostics などの機能やサービスを通じて利用できる場合があります。

パフォーマンス データの分析

分析作業の多くは、ユーザー要求の種類または各要求の送信先となるサブシステムまたはサービスによるパフォーマンス データの集計で構成されます。 ユーザー要求の例として、ショッピング カートにアイテムを追加したり、e コマース システムでチェックアウト プロセスを実行したりします。

もう 1 つの一般的な要件は、選択したパーセンタイルのパフォーマンス データの概要です。 たとえば、オペレーターは、要求の 99%、要求の 95%、および要求の 70% の応答時間を決定できます。 各パーセンタイルに SLA ターゲットまたはその他の目標が設定されている可能性があります。 進行中の結果は、即時の問題の検出に役立つほぼリアルタイムで報告する必要があります。 結果は、統計目的で長い時間にわたって集計する必要もあります。

パフォーマンスに影響する待機時間の問題が発生した場合、オペレーターは、各要求が実行する各ステップの待機時間を調べることで、ボトルネックの原因をすばやく特定できる必要があります。 したがって、パフォーマンス データは、特定の要求に関連付けるために、各ステップのパフォーマンスメジャーを関連付ける手段を提供する必要があります。

視覚化の要件によっては、生データのビューを含むデータ キューブを生成して格納すると便利な場合があります。 このデータ キューブを使用すると、パフォーマンス情報の複雑なアドホック クエリと分析を行うことができます。

セキュリティの監視

機密データを含むすべての商用システムは、セキュリティ構造を実装する必要があります。 通常、セキュリティ メカニズムの複雑さは、データの機密性の関数です。 ユーザーを認証する必要があるシステムでは、次の情報を記録する必要があります。

• 失敗した場合でも成功した場合でも、すべてのサインイン試行。
• 認証されたユーザーによって実行されるすべての操作 (およびアクセスされるすべてのリソースの詳細)。
• ユーザーがセッションを終了してサインアウトしたとき。

監視は、システムに対する攻撃を検出するのに役立つ場合があります。 たとえば、サインイン試行に失敗した回数が多い場合は、ブルート フォース攻撃を示している可能性があります。 要求の予期しない急増は、分散型サービス拒否 (DDoS) 攻撃の結果である可能性があります。 これらの要求のソースに関係なく、すべてのリソースに対するすべての要求を監視するように準備する必要があります。 サインインの脆弱性があるシステムでは、ユーザーが実際にサインインしなくても、リソースが外部に誤って公開される可能性があります。

セキュリティ監視の要件

セキュリティ監視の最も重要な側面により、オペレーターは次の作業をすばやく実行できます。

• 認証されていないエンティティによる侵入の試行を検出します。
• アクセス権が付与されていないデータに対して操作を実行するエンティティによる試行を特定します。
• システムまたはシステムの一部が外部または内部からの攻撃を受けているかどうかを判断します。 (たとえば、悪意のある認証済みユーザーがシステムを停止しようとしている可能性があります)。

これらの要件をサポートするには、次の場合にオペレーターに通知する必要があります。

• 1 つのアカウントで、指定した期間内にサインイン試行が繰り返し失敗します。
• 1 つの認証済みアカウントは、指定された期間中に禁止されているリソースへのアクセスを繰り返し試行します。
• 指定された期間中に多数の認証されていない要求または未承認の要求が発生します。

オペレーターに提供される情報には、各要求のソースのホスト アドレスを含める必要があります。 特定の範囲のアドレスからセキュリティ違反が定期的に発生した場合、これらのホストがブロックされる可能性があります。

システムのセキュリティを維持する上で重要な部分は、通常のパターンから逸脱したアクションをすばやく検出できることです。 失敗したサインイン要求や成功したサインイン要求の数などの情報を視覚的に表示して、異常なタイミングでアクティビティが急増しているかどうかを検出するのに役立ちます。 (このアクティビティの例として、ユーザーは午前 3 時にサインインし、稼働日が午前 9 時に開始されたときに多数の操作を実行します)。 この情報は、時間ベースの自動スケールの構成にも使用できます。 たとえば、オペレーターが特定の時間帯に多数のユーザーが定期的にサインインすることを確認した場合、オペレーターは、作業量を処理するために追加の認証サービスを開始するように手配し、ピークが過ぎたときにこれらの追加サービスをシャットダウンすることができます。

データ ソース、インストルメンテーション、およびデータ収集の要件

セキュリティは、ほとんどの分散システムの包括的な側面です。 関連するデータは、システム全体の複数のポイントで生成される可能性があります。 アプリケーション、ネットワーク機器、サーバー、ファイアウォール、ウイルス対策ソフトウェア、およびその他の侵入防止要素によって発生したイベントの結果として発生するセキュリティ関連の情報を収集するには、セキュリティ情報イベント管理 (SIEM) アプローチを採用することを検討する必要があります。

セキュリティ監視には、アプリケーションの一部ではないツールからのデータを組み込むことができます。 これらのツールには、外部機関によるポート スキャン アクティビティを識別するユーティリティや、アプリケーションとデータへの認証されていないアクセスの試行を検出するネットワーク フィルターが含まれます。

いずれの場合も、収集されたデータを使用して、管理者が攻撃の性質を判断し、適切な対策を講じる必要があります。

セキュリティ データの分析

セキュリティ監視の機能は、データが発生するさまざまなソースです。 さまざまな形式と詳細レベルでは、多くの場合、キャプチャされたデータを複雑に分析して、一貫性のある情報スレッドに結び付ける必要があります。 最も単純なケース (多数の失敗したサインインの検出、重要なリソースへの不正アクセスの繰り返しの試行など) とは別に、セキュリティ データの複雑な自動処理を実行できない場合があります。 代わりに、このデータをタイムスタンプ付きで書き込むのではなく、元の形式で安全なリポジトリに書き込んで、専門家による手動分析を可能にすることをお勧めします。

SLA の監視

有料顧客をサポートする多くの商用システムでは、SLA の形式でシステムのパフォーマンスが保証されます。 基本的に、SLA は、合意された時間内に、重要な情報を失うことなく、定義された作業量をシステムが処理できることを示しています。 SLA の監視は、システムが測定可能な SLA を満たすことができることを保証することに関係しています。

注

SLA の監視は、パフォーマンスの監視と密接に関連しています。 ただし、パフォーマンスの監視はシステムが 最適に機能することを保証することに関係していますが、SLA 監視は、 実際に何が最適 かを定義する契約上の義務によって管理されます。

SLA は、多くの場合、次の点で定義されます。

• システムの全体的な可用性。 たとえば、組織では、システムが 99.9% の時間使用可能であることが保証される場合があります。 これは、1 年あたり 9 時間以下、または週に約 10 分のダウンタイムに相当します。
• 運用スループット。 この側面は、多くの場合、システムが最大 100,000 件の同時ユーザー要求をサポートできることや、10,000 件の同時ビジネス トランザクションを処理できることを保証するなど、1 つ以上の高ウォーター マークとして表されます。
• 運用応答時間。 システムでは、要求が処理される速度が保証される場合もあります。 たとえば、すべてのビジネス トランザクションの 99% が 2 秒以内に完了し、1 回のトランザクションに 10 秒を超える時間はかからなくなります。

注

商用システムの一部の契約には、カスタマー サポート用の SLA も含まれる場合があります。 たとえば、すべてのヘルプ デスク要求が 5 分以内に応答を引き出し、すべての問題の 99% が 1 営業日以内に完全に対処されるということです。 効果的な 問題の追跡 (このセクションで後述) は、このような SLA を満たす上で重要です。

SLA 監視の要件

最高レベルでは、オペレーターは、システムが合意された SLA を満たしているかどうかを一目で判断できる必要があります。 そうでない場合は、オペレーターがドリルダウンし、基になる要因を調べて、標準以下のパフォーマンスの理由を判断できる必要があります。

視覚的に示すことができる一般的な高レベルインジケーターは次のとおりです。

• サービスのアップタイムの割合。
• アプリケーションのスループット (1 秒あたりの成功したトランザクションまたは操作の観点から測定)。
• 成功/失敗したアプリケーション要求の数。
• アプリケーションとシステムの障害、例外、警告の数。

これらのインジケーターはすべて、指定された期間でフィルター処理できる必要があります。

クラウド アプリケーションは、多くのサブシステムとコンポーネントで構成される可能性があります。 演算子は、高レベルのインジケーターを選択し、基になる要素の正常性からどのように構成されているかを確認できる必要があります。 たとえば、システム全体のアップタイムが許容される値を下回った場合、オペレーターは拡大し、この障害の原因となっている要素を特定できる必要があります。

注

システムのアップタイムは慎重に定義する必要があります。 冗長性を使用して最大限の可用性を確保するシステムでは、要素の個々のインスタンスが失敗する可能性がありますが、システムは機能したままにすることができます。 正常性の監視によって示されるシステムのアップタイムは、各要素の全体的なアップタイムを示す必要があり、システムが実際に停止したかどうかは必ずしもありません。 さらに、エラーが分離される可能性があります。 そのため、特定のシステムが使用できない場合でも、機能が低下しても、システムの残りの部分は使用可能なままになる可能性があります。 (eコマース システムでは、システムの障害により顧客が注文できない場合がありますが、顧客は製品カタログを参照できる可能性があります)。

アラートの目的で、高レベルインジケーターのいずれかが指定されたしきい値を超えた場合、システムはイベントを発生させる必要があります。 高レベルインジケーターを構成するさまざまな要因の下位レベルの詳細は、アラート システムのコンテキスト データとして使用できる必要があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

SLA 監視をサポートするために必要な生データは、正常性と可用性の監視の一部の側面と共に、パフォーマンスの監視に必要な生データに似ています。 (詳細については、これらのセクションを参照してください)。このデータは、次の方法でキャプチャできます。

• エンドポイント監視の実行。
• 例外、エラー、警告のログ記録。
• ユーザー要求の実行をトレースします。
• システムが使用するサードパーティサービスの可用性の監視。
• パフォーマンス メトリックとカウンターの使用。

すべてのデータに時間とタイムスタンプを設定する必要があります。

SLA データの分析

インストルメンテーション データを集計して、システムの全体的なパフォーマンスの図を生成する必要があります。 集計データでは、基になるサブシステムのパフォーマンスを調べるためにドリルダウンもサポートする必要があります。 たとえば、次のことが可能になります。

• 指定した期間中のユーザー要求の合計数を計算し、これらの要求の成功率と失敗率を決定します。
• ユーザー要求の応答時間を組み合わせて、システム応答時間の全体的なビューを生成します。
• ユーザー要求の進行状況を分析して、要求の全体的な応答時間を、その要求内の個々の作業項目の応答時間に分割します。
• 特定の期間のアップタイムの割合として、システムの全体的な可用性を決定します。
• システム内の個々のコンポーネントとサービスの利用可能時間の割合を分析します。 これには、サードパーティのサービスによって生成されたログの解析が含まれる場合があります。

多くの商用システムでは、一定の期間 (通常は 1 か月) の合意された SLA に対して実際のパフォーマンス数値を報告する必要があります。 この情報は、その期間中に SLA が満たされない場合に、顧客に対するクレジットやその他の形式の返済を計算するために使用できます。 可用性データの分析セクションで説明されている手法を使用して、サービスの 可用性を計算できます。

内部的な目的で、組織は、サービスの失敗の原因となったインシデントの数と性質を追跡する場合もあります。 これらの問題を迅速に解決する方法、または完全に解消する方法を学習すると、ダウンタイムを短縮し、SLA を満たすのに役立ちます。

監査

アプリケーションの性質によっては、ユーザーの操作を監査し、すべてのデータ アクセスを記録するための要件を指定する法的または他の法的規制が存在する場合があります。 監査は、顧客を特定の要求にリンクする証拠を提供できます。 否認は、アプリケーションまたはサービスを担当する顧客と組織との間の信頼を維持するために役立つ多くの電子ビジネス システムにおいて重要な要素です。

監査の要件

アナリストは、ユーザーのアクションを再構築できるように、ユーザーが実行している一連のビジネス操作を追跡できる必要があります。 これは、単に記録の問題として、またはフォレンジック調査の一環として必要な場合があります。

監査情報は機密性が高い。 システムのユーザーを識別するデータと、実行しているタスクが含まれる可能性があります。 このため、ほとんどの場合、監査情報は、グラフィカル操作のドリルダウンをサポートする対話型システムとしてではなく、信頼できるアナリストのみが使用できるレポートの形式になります。 アナリストは、さまざまなレポートを生成できる必要があります。 たとえば、レポートには、指定した期間内に発生したすべてのユーザーのアクティビティが一覧表示されたり、1 人のユーザーのアクティビティの時系列が詳細に表示されたり、1 つ以上のリソースに対して実行された一連の操作が一覧表示されたりすることがあります。

データ ソース、インストルメンテーション、およびデータ収集の要件

監査の主な情報ソースは次のとおりです。

• ユーザー認証を管理するセキュリティ システム。
• ユーザー アクティビティを記録するトレース ログ。
• 識別可能で識別できないすべてのネットワーク要求を追跡するセキュリティ ログ。

監査データの形式と格納方法は、規制要件によって推進される場合があります。 たとえば、どのような方法でもデータをクリーンアップできない場合があります。 (元の形式で記録する必要があります。改ざんを防ぐために、リポジトリが保持されているリポジトリへのアクセスを保護する必要があります。

監査データの分析

アナリストは、元の形式で生データ全体にアクセスできる必要があります。 一般的な監査レポートを生成する要件とは別に、このデータを分析するためのツールは特殊化され、システムの外部に保持される可能性があります。

使用状況の監視

使用状況の監視では、アプリケーションの機能とコンポーネントの使用方法を追跡します。 オペレーターは、収集されたデータを使用して次のことができます。

• どの機能が頻繁に使用されているかを判断し、システム内の潜在的なホットスポットを決定します。 トラフィックの多い要素は、負荷をより均等に分散させるために、機能パーティション分割やレプリケーションの恩恵を受ける可能性があります。 また、オペレーターは、この情報を使用して、使用頻度の低い機能を確認し、将来のバージョンのシステムで提供終了または置換の候補となる可能性を確認することもできます。

• 通常の使用中のシステムの運用イベントに関する情報を取得します。 たとえば、eコマース サイトでは、トランザクションの数と顧客の量に関する統計情報を記録できます。 この情報は、顧客の数が増えるにつれて容量計画に使用できます。

• システムのパフォーマンスまたは機能に対するユーザーの満足度を (場合によっては間接的に) 検出します。 たとえば、eコマース システムの多数の顧客が定期的にショッピング カートを放棄する場合、これはチェックアウト機能の問題が原因である可能性があります。

• 課金情報を生成します。 商用アプリケーションまたはマルチテナント サービスでは、使用するリソースに対して顧客に課金される場合があります。

• クォータを適用します。 マルチテナント システムのユーザーが、指定した期間中に処理時間またはリソース使用量の支払いクォータを超えた場合、アクセスを制限したり、処理を調整したりできます。

使用状況の監視の要件

システムの使用状況を調べるには、オペレーターは通常、次を含む情報を表示する必要があります。

• 各サブシステムによって処理され、各リソースに送信される要求の数。
• 各ユーザーが実行している作業。
• 各ユーザーが占有するデータ ストレージのボリューム。
• 各ユーザーがアクセスしているリソース。

演算子はグラフも生成できる必要があります。 たとえば、グラフには、リソースが最も多いユーザー、または最も頻繁にアクセスされるリソースまたはシステム機能が表示される場合があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

使用状況の追跡は、比較的高いレベルで実行できます。 各要求の開始時刻と終了時刻、および要求の性質 (対象のリソースに応じて読み取り、書き込みなど) をメモできます。 この情報は、次の方法で取得できます。

• ユーザー アクティビティのトレース。
• 各リソースの使用率を測定するパフォーマンス カウンターのキャプチャ。
• 各ユーザーによるリソース消費量の監視。

測定の目的で、どのユーザーがどの操作を実行する責任があり、これらの操作で使用されるリソースを識別できる必要もあります。 収集された情報は、正確な課金を可能にするために十分に詳細である必要があります。

問題の追跡

システムで予期しないイベントや動作が発生した場合、お客様やその他のユーザーが問題を報告する場合があります。 問題の追跡は、これらの問題の管理、システム内の根本的な問題の解決への取り組みと関連付け、考えられる解決策をお客様に通知することに関係しています。

問題の追跡の要件

オペレーターは、ユーザーが報告する問題の詳細を記録して報告できる別のシステムを使用して、多くの場合、問題の追跡を実行します。 これらの詳細には、ユーザーが実行しようとしたタスク、問題の症状、イベントのシーケンス、および発行されたエラーまたは警告メッセージが含まれます。

データ ソース、インストルメンテーション、およびデータ収集の要件

問題追跡データの初期データ ソースは、最初に問題を報告したユーザーです。 ユーザーは、次のような追加データを提供できる場合があります。

• クラッシュ ダンプ (アプリケーションにユーザーのデスクトップで実行されるコンポーネントが含まれている場合)。
• 画面スナップショット。
• エラーが発生した日時と、ユーザーの場所などのその他の環境情報。

この情報は、デバッグ作業を支援し、ソフトウェアの将来のリリース用のバックログを構築するのに役立ちます。

問題追跡データの分析

異なるユーザーが同じ問題を報告する場合があります。 問題追跡システムでは、一般的なレポートを関連付ける必要があります。

デバッグ作業の進行状況は、各問題レポートに対して記録する必要があります。 問題が解決されると、顧客にソリューションを通知できます。

問題追跡システムで既知の解決策を持つ問題をユーザーが報告した場合、オペレーターはソリューションをすぐにユーザーに通知できる必要があります。

操作のトレースとソフトウェア リリースのデバッグ

ユーザーが問題を報告すると、多くの場合、ユーザーは自分の操作に対する即時の影響のみを認識します。 ユーザーは、独自のエクスペリエンスの結果のみを、システムの保守を担当するオペレーターに報告できます。 通常、これらのエクスペリエンスは、1 つ以上の基本的な問題の目に見える症状にすぎません。 多くの場合、アナリストは、問題の根本原因を確立するために、基になる操作の時系列を調べる必要があります。 このプロセスは 根本原因分析と呼ばれます。

注

根本原因分析は、アプリケーションの設計の非効率性を明らかにする可能性があります。 このような状況では、影響を受ける要素を再作業し、後続のリリースの一部として展開できる場合があります。 このプロセスには慎重な制御が必要であり、更新されたコンポーネントは注意深く監視する必要があります。

トレースとデバッグの要件

予期しないイベントやその他の問題をトレースするには、監視データが十分な情報を提供して、アナリストがこれらの問題の発生元までトレースし、発生した一連のイベントを再構築できるようにすることが重要です。 この情報は、アナリストが問題の根本原因を診断できるようにするために十分である必要があります。 その後、開発者は必要な変更を加えて、定期的な作業を防ぐことができます。

データ ソース、インストルメンテーション、およびデータ収集の要件

トラブルシューティングでは、操作の一部として呼び出されるすべてのメソッド (およびそのパラメーター) をトレースして、顧客が特定の要求を行ったときにシステムを介した論理フローを示すツリーを構築する必要があります。 このフローの結果としてシステムによって生成される例外と警告をキャプチャしてログに記録する必要があります。

デバッグをサポートするために、システムは、オペレーターがシステム内の重要なポイントで状態情報をキャプチャできるようにするフックを提供できます。 または、選択した操作の進行状況に応じて、詳細なステップ バイ ステップ情報を提供できます。 この詳細レベルでデータをキャプチャすると、システムに追加の負荷が発生する可能性があり、一時的なプロセスである必要があります。 オペレーターは主に、非常に異常な一連のイベントが発生してレプリケートが困難な場合、または 1 つ以上の要素をシステムに新しくリリースするときに、要素が期待どおりに機能することを確認するために注意深く監視する必要がある場合に、このプロセスを使用します。

監視と診断のパイプライン

大規模な分散システムの監視は、大きな課題です。 前のセクションで説明した各シナリオは、必ずしも単独で考慮する必要はありません。 状況ごとに必要な監視データと診断データに大きな重複がある可能性がありますが、このデータはさまざまな方法で処理および提示する必要があります。 これらの理由から、監視と診断の全体像を把握する必要があります。

図 1 に示すステージを構成するパイプラインとして、監視と診断のプロセス全体を想定できます。

図 1 - 監視と診断パイプラインのステージ。

図 1 は、監視と診断のためのデータがさまざまなデータ ソースから取得される方法を示しています。 インストルメンテーションと収集の段階では、データをキャプチャする必要があるソースの特定、キャプチャするデータの決定、キャプチャ方法、およびデータを簡単に調べることができるように書式設定する方法が関係します。 分析/診断ステージは生データを取得し、それを使用して、オペレーターがシステムの状態を判断するために使用できる意味のある情報を生成します。 オペレーターは、この情報を使用して、実行できるアクションに関する決定を行い、結果をインストルメンテーションとコレクションのステージに戻すことができます。 視覚化/アラート ステージ フェーズでは、システム状態の消耗品ビューが表示されます。 一連のダッシュボードを使用して、ほぼリアルタイムで情報を表示できます。 また、レポート、グラフ、グラフを生成して、長期的な傾向を特定するのに役立つデータの履歴ビューを提供できます。 KPI が許容範囲を超える可能性が高いと情報が示されている場合、このステージではオペレーターにアラートをトリガーすることもできます。 場合によっては、アラートを使用して、自動スケールなどの是正措置を実行しようとする自動化されたプロセスをトリガーすることもできます。

これらの手順は、ステージが並行して発生する連続フロー プロセスを構成します。 理想的には、すべてのフェーズを動的に構成する必要があります。 特にシステムが新しくデプロイされた場合や問題が発生している場合は、より頻繁に拡張データを収集することが必要になる場合があります。 それ以外の場合は、基本レベルの重要な情報のキャプチャに戻して、システムが正常に機能していることを確認できます。

さらに、監視プロセス全体は、フィードバックの結果として微調整と改善の対象となる、ライブで継続的なソリューションと見なす必要があります。 たとえば、多くの要因を測定してシステムの正常性を判断し始める場合があります。 時間の経過に伴う分析は、関連性のないメジャーを破棄すると絞り込みにつながる可能性があります。これにより、バックグラウンド ノイズを最小限に抑えながら、必要なデータをより正確に絞り込める可能性があります。

監視と診断データのソース

図 1 に示すように、監視プロセスで使用される情報は、いくつかのソースから取得できます。 アプリケーション レベルでは、情報はシステムのコードに組み込まれたトレース ログから取得されます。 開発者は、コードを通じて制御のフローを追跡するための標準的なアプローチに従う必要があります。 たとえば、メソッドへのエントリは、メソッドの名前、現在の時刻、各パラメーターの値、およびその他の関連情報を指定するトレース メッセージを出力できます。 入退室時間の記録も役立ちます。

すべての例外と警告をログに記録し、入れ子になった例外と警告の完全なトレースを保持する必要があります。 理想的には、コードを実行しているユーザーを識別する情報とアクティビティの関連付け情報 (システムを通過する要求を追跡するため) もキャプチャする必要があります。 また、メッセージ キュー、データベース、ファイル、その他の依存サービスなど、すべてのリソースへのアクセス試行をログに記録する必要があります。 この情報は、測定と監査の目的で使用できます。

多くのアプリケーションでは、ライブラリとフレームワークを使用して、データ ストアへのアクセスやネットワーク経由の通信などの一般的なタスクを実行します。 これらのフレームワークは、独自のトレース メッセージと未加工の診断情報 (トランザクションレート、データ転送の成功や失敗など) を提供するように構成できます。

注

多くの最新のフレームワークでは、パフォーマンス イベントとトレース イベントが自動的に発行されます。 この情報をキャプチャすることは、処理および分析できる場所で取得して格納する手段を提供するだけの問題です。

アプリケーションが実行されているオペレーティング システムは、I/O レート、メモリ使用率、CPU 使用率を示すパフォーマンス カウンターなど、システム全体の低レベルの情報のソースになる可能性があります。 オペレーティング システム エラー (ファイルを正しく開けませんでした) も報告される場合があります。

また、システムが実行される基になるインフラストラクチャとコンポーネントも考慮する必要があります。 仮想マシン、仮想ネットワーク、ストレージ サービスはすべて、重要なインフラストラクチャ レベルのパフォーマンス カウンターやその他の診断データのソースになります。

アプリケーションで Web サーバーやデータベース管理システムなどの他の外部サービスを使用している場合、これらのサービスは独自のトレース情報、ログ、パフォーマンス カウンターを発行する可能性があります。 たとえば、SQL Server データベースに対して実行された操作を追跡するための SQL Server 動的管理ビューや、Web サーバーに対して行われた要求を記録するための IIS トレース ログなどがあります。

システムのコンポーネントが変更され、新しいバージョンがデプロイされるため、問題、イベント、メトリックを各バージョンに属性付けできることが重要です。 この情報は、特定のバージョンのコンポーネントに関する問題をすばやく追跡して修正できるように、リリース パイプラインに関連付ける必要があります。

セキュリティの問題は、システム内の任意の時点で発生する可能性があります。 たとえば、ユーザーが無効なユーザー ID またはパスワードを使用してサインインを試みる場合があります。 認証されたユーザーは、リソースへの承認されていないアクセスを取得しようとする可能性があります。 または、ユーザーが、暗号化された情報にアクセスするために無効なキーまたは古いキーを提供する場合があります。 成功した要求と失敗した要求のセキュリティ関連の情報は、常にログに記録する必要があります。

アプリケーションのインストルメント化のセクションには、キャプチャする必要がある情報に関するガイダンスが含まれています。 ただし、さまざまな戦略を使用して、この情報を収集できます。

• アプリケーション/システムの監視。 この戦略では、アプリケーション、アプリケーション フレームワーク、オペレーティング システム、インフラストラクチャ内の内部ソースを使用します。 アプリケーション コードは、クライアント要求のライフサイクル中に注目すべきポイントで独自の監視データを生成できます。 アプリケーションには、状況に応じて選択的に有効または無効になる可能性があるトレース ステートメントを含めることができます。 診断フレームワークを使用して、診断を動的に挿入することもできます。 通常、これらのフレームワークには、コード内のさまざまなインストルメンテーション ポイントにアタッチし、これらのポイントでトレース データをキャプチャできるプラグインが用意されています。

  さらに、コードまたは基になるインフラストラクチャによって、重要なポイントでイベントが発生する可能性があります。 これらのイベントをリッスンするように構成されている監視エージェントは、イベント情報を記録できます。

• 実際のユーザー監視。 この方法では、ユーザーとアプリケーションの間の相互作用を記録し、各要求と応答のフローを観察します。 この情報は、2 つの目的を持つことができます。これは、各ユーザーによる使用状況の測定に使用できます。また、ユーザーが適切なサービス品質を受け取っているかどうかを判断するために使用できます (たとえば、応答時間の短縮、待機時間の短縮、最小限のエラーなど)。 キャプチャされたデータを使用して、障害が最も頻繁に発生する問題の領域を特定できます。 また、データを使用して、アプリケーションのホットスポットやその他の形式のボトルネックが原因でシステムの速度が低下する要素を特定することもできます。 この方法を慎重に実装すると、デバッグとテストの目的でアプリケーションを通じてユーザーのフローを再構築できる可能性があります。

  重要

  機密資料が含まれる可能性があるため、実際のユーザーを監視することによってキャプチャされるデータは機密性が高いと考える必要があります。 キャプチャしたデータを保存する場合は、安全に保存します。 パフォーマンスの監視またはデバッグの目的でデータを使用する場合は、まずすべての個人データを取り除きます。

• 代理ユーザーの監視。 この方法では、ユーザーをシミュレートし、構成可能だが一般的な一連の操作を実行する独自のテスト クライアントを作成します。 テスト クライアントのパフォーマンスを追跡して、システムの状態を判断できます。 また、ロード テスト操作の一環として、テスト クライアントの複数のインスタンスを使用して、システムがストレス下でどのように応答するか、およびこれらの条件下で生成される監視出力の種類を確立することもできます。

  注

  メソッド呼び出しやその他のアプリケーションの重要な部分の実行をトレースして時間を記録するコードを含めることで、実際のユーザー監視と合成ユーザー監視を実装できます。

• プロファイリング。 このアプローチは、主にアプリケーションのパフォーマンスの監視と向上を目的とします。 実際のユーザー監視と合成ユーザー監視の機能レベルで動作するのではなく、アプリケーションの実行時に下位レベルの情報をキャプチャします。 プロファイリングを実装するには、アプリケーションの実行状態の定期的なサンプリングを使用します (特定の時点でアプリケーションが実行されているコードの部分を決定します)。 また、重要なタイミング (メソッド呼び出しの開始と終了など) にプローブをコードに挿入し、呼び出されたメソッド、呼び出しの時間、各呼び出しにかかった時間を記録するインストルメンテーションを使用することもできます。 その後、このデータを分析して、アプリケーションのどの部分がパフォーマンスの問題を引き起こす可能性があるかを判断できます。

• エンドポイントの監視。 この手法では、監視を有効にするためにアプリケーションが公開する 1 つ以上の診断エンドポイントを使用します。 エンドポイントは、アプリケーション コードへの経路を提供し、システムの正常性に関する情報を返すことができます。 異なるエンドポイントは、機能のさまざまな側面に集中できます。 これらのエンドポイントに定期的な要求を送信し、応答を同化する独自の診断クライアントを作成できます。 詳細については、「 正常性エンドポイントの監視パターン」を参照してください。

カバレッジを最大限に高める場合は、これらの手法を組み合わせて使用する必要があります。

アプリケーションのインストルメント化

インストルメンテーションは、監視プロセスの重要な部分です。 システムのパフォーマンスと正常性に関して意味のある決定を行うことができるのは、これらの決定を行うことができるデータを最初にキャプチャする場合のみです。 インストルメンテーションを使用して収集する情報は、リモート運用サーバーにサインインしてトレース (およびデバッグ) を手動で実行しなくても、パフォーマンスの評価、問題の診断、意思決定を行うために十分である必要があります。 インストルメンテーション データは、通常、トレース ログに書き込まれるメトリックと情報で構成されます。

トレース ログの内容は、アプリケーションによって書き込まれたテキスト データの結果、またはアプリケーションが Windows イベント トレーシング (ETW) を使用している場合、トレース イベントの結果として作成されるバイナリ データです。 また、Web サーバーなどのインフラストラクチャの一部から発生したイベントを記録するシステム ログから生成することもできます。 多くの場合、テキスト ログ メッセージは人間が判読できるように設計されていますが、自動システムで簡単に解析できる形式で記述する必要もあります。

ログも分類する必要があります。 すべてのトレース データを 1 つのログに書き込むのではなく、個別のログを使用して、システムのさまざまな運用面からのトレース出力を記録します。 その後、1 つの長いファイルを処理する必要なく、適切なログから読み取ることで、ログ メッセージをすばやくフィルター処理できます。 異なるセキュリティ要件 (監査情報やデバッグ データなど) を持つ情報を同じログに書き込むことはありません。

注

ログはファイル システム上のファイルとして実装されるか、BLOB ストレージ内の BLOB などの他の形式で保持される場合があります。 ログ情報は、テーブル内の行など、より構造化されたストレージにも保持される場合があります。

メトリックは通常、特定の時点におけるシステム内の一部の側面またはリソースのメジャーまたはカウントで、1 つ以上のタグまたはディメンション ( サンプルと呼ばれることもあります) が関連付けられます。 メトリックの 1 つのインスタンスは、通常、単独では役に立ちません。 代わりに、時間の経過と同時にメトリックをキャプチャする必要があります。 考慮すべき重要な問題は、記録するメトリックと頻度です。 メトリックのデータを生成する頻度が高すぎると、システムに大きな負荷がかかる可能性があります。一方、メトリックをキャプチャする頻度が低いと、重大なイベントにつながる状況を見逃す可能性があります。 考慮事項は、メトリックによって異なります。 たとえば、サーバー上の CPU 使用率は 2 番目から 2 番目に大きく異なる場合がありますが、使用率が高い場合は、数分にわたって有効期間が長い場合にのみ問題になります。

データの関連付けに関する情報

個々のシステム レベルのパフォーマンス カウンターを簡単に監視し、リソースのメトリックをキャプチャし、さまざまなログ ファイルからアプリケーション トレース情報を取得できます。 ただし、一部の形式の監視では、複数のソースから取得されたデータを関連付けるために、監視パイプラインの分析と診断の段階が必要です。 このデータは生データに複数の形式を取る場合があり、分析プロセスには、これらの異なる形式をマップできる十分なインストルメンテーション データを提供する必要があります。 たとえば、アプリケーション フレームワーク レベルでは、タスクはスレッド ID によって識別される場合があります。 アプリケーション内では、同じ作業が、そのタスクを実行しているユーザーのユーザー ID に関連付けられている可能性があります。

また、非同期操作では同じスレッドを再利用して複数のユーザーに代わって操作を実行する可能性があるため、スレッドとユーザー要求の間に 1 対 1 のマッピングを行う可能性はほとんどありません。 さらに複雑にするために、実行がシステムを通過するにつれて、1 つの要求が複数のスレッドによって処理される場合があります。 可能であれば、各要求を、要求コンテキストの一部としてシステム経由で伝達される一意のアクティビティ ID に関連付けます。 (トレース情報にアクティビティ ID を生成して含める手法は、トレース データのキャプチャに使用されるテクノロジによって異なります)。

すべての監視データは、同じ方法でタイムスタンプを付ける必要があります。 一貫性を保つには、協定世界時を使用して、すべての日付と時刻を記録します。 これは、イベントのシーケンスをより簡単にトレースするのに役立ちます。

注

異なるタイム ゾーンとネットワークで動作しているコンピューターが同期されない場合があります。 複数のマシンにまたがるインストルメンテーション データを関連付けするためにタイムスタンプのみを使用することに依存しないでください。

インストルメンテーション データに含める情報

収集する必要があるインストルメンテーション データを決定するときは、次の点を考慮してください。

• トレース イベントによってキャプチャされた情報がマシンであり、人間が判読できることを確認します。 この情報に対して明確に定義されたスキーマを採用して、システム間でのログ データの自動処理を容易にし、ログを読む運用およびエンジニアリング スタッフに一貫性を提供します。 デプロイ環境、プロセスが実行されているマシン、プロセスの詳細、呼び出し履歴などの環境情報を含めます。

• プロファイリングは、システムに大きなオーバーヘッドが発生する可能性があるため、必要な場合にのみ有効にします。 インストルメンテーションを使用したプロファイリングでは、発生するたびにイベント (メソッド呼び出しなど) が記録されますが、サンプリングでは選択したイベントのみが記録されます。 選択できるのは、時間ベース ( n 秒ごとに 1 回) または頻度ベース ( n 個の要求ごとに 1 回) です。 イベントが非常に頻繁に発生する場合、インストルメンテーションによるプロファイリングによって負担が大きくなりすぎて、それ自体が全体的なパフォーマンスに影響を与える可能性があります。 この場合、サンプリングアプローチが望ましい場合があります。 ただし、イベントの頻度が低い場合は、サンプリングによって見落とされる可能性があります。 この場合、インストルメンテーションの方が適している可能性があります。

• 開発者または管理者が各要求のソースを特定できるようにするための十分なコンテキストを提供します。 これには、要求の特定のインスタンスを識別する何らかの形式のアクティビティ ID が含まれる場合があります。 また、このアクティビティを実行された計算作業と使用されるリソースと関連付けるために使用できる情報も含まれる場合があります。 この作業は、プロセスとマシンの境界を越える可能性があることに注意してください。 測定の場合、コンテキストには、要求を行う原因となった顧客への参照 (直接または他の相関情報を介して間接的に) も含める必要があります。 このコンテキストは、監視データがキャプチャされたときのアプリケーションの状態に関する重要な情報を提供します。

• すべての要求と、これらの要求の作成元となる場所またはリージョンを記録します。 この情報は、場所固有のホットスポットがあるかどうかを判断する際に役立つ場合があります。 この情報は、アプリケーションを再パーティション分割するか、使用するデータを再パーティション分割するかを決定する際にも役立ちます。

• 例外の詳細を注意深く記録してキャプチャします。 多くの場合、重要なデバッグ情報は、例外処理が不十分な結果として失われます。 内部例外やその他のコンテキスト情報など、アプリケーションがスローする例外の完全な詳細をキャプチャします。 可能であれば、呼び出し履歴を含めます。

• これは、イベントの分析やユーザー要求との関連付けに役立つ可能性があるため、アプリケーションのさまざまな要素がキャプチャするデータの一貫性を保つ必要があります。 開発者がシステムのさまざまな部分を実装するのと同じアプローチを採用するかどうかに応じてではなく、包括的で構成可能なログ パッケージを使用して情報を収集することを検討してください。 実行されている I/O のボリューム、ネットワーク使用率、要求の数、メモリ使用量、CPU 使用率など、主要なパフォーマンス カウンターからデータを収集します。 一部のインフラストラクチャ サービスでは、データベースへの接続数、トランザクションの実行速度、成功または失敗したトランザクションの数など、独自のパフォーマンス カウンターが提供される場合があります。 アプリケーションでは、独自のパフォーマンス カウンターを定義することもできます。

• データベース システム、Web サービス、インフラストラクチャの一部である他のシステム レベルのサービスなど、外部サービスに対して行われたすべての呼び出しをログに記録します。 各呼び出しの実行にかかった時間と、呼び出しの成功または失敗に関する情報を記録します。 可能であれば、発生した一時的なエラーに対するすべての再試行と失敗に関する情報をキャプチャします。

テレメトリ システムとの互換性の確保

多くの場合、インストルメンテーションによって生成される情報は一連のイベントとして生成され、処理と分析のために別のテレメトリ システムに渡されます。 テレメトリ システムは通常、特定のアプリケーションやテクノロジに依存しませんが、情報は通常スキーマによって定義される特定の形式に従うことを想定しています。 このスキーマは、テレメトリ システムが取り込むことができるデータ フィールドと型を定義するコントラクトを効果的に指定します。 スキーマは、さまざまなプラットフォームやデバイスからデータを受信できるように一般化する必要があります。

共通スキーマには、イベント名、イベント時刻、送信者の IP アドレス、他のイベント (ユーザー ID、デバイス ID、アプリケーション ID など) との関連付けに必要な詳細など、すべてのインストルメンテーション イベントに共通するフィールドを含める必要があります。 任意の数のデバイスでイベントが発生する可能性があるため、スキーマはデバイスの種類に依存しないように注意してください。 さらに、さまざまなデバイスが同じアプリケーションのイベントを発生させる可能性があります。アプリケーションは、ローミングまたはその他の形式のクロスデバイス分散をサポートしている可能性があります。

スキーマには、異なるアプリケーション間で一般的な特定のシナリオに関連するドメイン フィールドも含まれる場合があります。 これは、例外、アプリケーションの開始イベントと終了イベント、および Web サービス API 呼び出しの成功または失敗に関する情報である可能性があります。 同じドメイン フィールドのセットを使用するすべてのアプリケーションは、同じ一連のイベントを出力し、一連の一般的なレポートと分析を構築できるようにする必要があります。

最後に、スキーマには、アプリケーション固有のイベントの詳細をキャプチャするためのカスタム フィールドが含まれている場合があります。

アプリケーションのインストルメント化のベスト プラクティス

次の一覧は、クラウドで実行されている分散アプリケーションをインストルメント化するためのベスト プラクティスをまとめたものです。

• ログを読みやすく、簡単に解析できるようにします。 可能な場合は、構造化ログを使用します。 ログ メッセージでは簡潔でわかりやすいものにします。

• すべてのログで、ソースを識別し、各ログ レコードが書き込まれるとき、コンテキストとタイミングの情報を提供します。

• すべてのタイムスタンプに同じタイム ゾーンと形式を使用します。 これは、異なる地理的リージョンで実行されているハードウェアとサービスにまたがる操作のイベントを関連付けるのに役立ちます。

• ログを分類し、適切なログ ファイルにメッセージを書き込みます。

• システムに関する機密情報やユーザーに関する個人情報を開示しないでください。 ログに記録される前にこの情報をスクラブしますが、関連する詳細が保持されていることを確認してください。 たとえば、データベース接続文字列から ID とパスワードを削除しますが、残りの情報をログに書き込んで、システムが正しいデータベースにアクセスしていることをアナリストが判断できるようにします。 すべての重大な例外をログに記録しますが、管理者はログ記録のオンとオフを切り替えて、より低いレベルの例外と警告を有効にします。 また、すべての再試行ロジック情報をキャプチャしてログに記録します。 このデータは、システムの一時的な正常性を監視する場合に役立ちます。

• 外部 Web サービスやデータベースへの要求など、プロセス外の呼び出しをトレースします。

• 同じログ ファイルに、異なるセキュリティ要件を持つログ メッセージを混在させる必要はありません。 たとえば、デバッグと監査の情報を同じログに書き込まないとします。

• 監査イベントを除き、すべてのログ記録呼び出しが、ビジネス操作の進行状況をブロックしないファイア アンド フォーゲット操作であることを確認します。 監査イベントは、ビジネスにとって重要であり、ビジネス運用の基本的な部分として分類できるため、例外的です。

• ログ記録が拡張可能であり、具体的なターゲットへの直接的な依存関係がないことを確認します。 たとえば、 System.Diagnostics.Trace を使用して情報を書き込むのではなく、ログ 記録メソッドを公開し、任意の適切な方法で実装できる抽象インターフェイス ( ILogger など) を定義します。

• すべてのログ記録がフェールセーフであり、連鎖エラーがトリガーされないようにしてください。 ログは例外をスローしてはなりません。

• インストルメンテーションを継続的な反復プロセスとして扱い、問題が発生した場合だけでなく、ログを定期的に確認します。

データの収集と格納

監視プロセスの収集ステージでは、インストルメンテーションによって生成される情報の取得、分析/診断ステージでの使用が容易になるようにこのデータを書式設定し、変換されたデータを信頼性の高いストレージに保存することが関係しています。 分散システムのさまざまな部分から収集するインストルメンテーション データは、さまざまな場所とさまざまな形式で保持できます。 たとえば、アプリケーション コードによってトレース ログ ファイルが生成され、アプリケーション イベント ログ データが生成されるのに対し、アプリケーションで使用されるインフラストラクチャの主要な側面を監視するパフォーマンス カウンターは、他のテクノロジを使用してキャプチャできます。 アプリケーションが使用するサードパーティ製のコンポーネントとサービスは、個別のトレース ファイル、BLOB ストレージ、またはカスタム データ ストアを使用して、さまざまな形式でインストルメンテーション情報を提供する場合があります。

多くの場合、データ収集は、インストルメンテーション データを生成するアプリケーションから自律的に実行できるコレクション サービスを介して実行されます。 図 2 は、インストルメンテーション データ収集サブシステムを強調するこのアーキテクチャの例を示しています。

図 2 - インストルメンテーション データの収集。

これは簡略化されたビューであることに注意してください。 コレクション サービスは必ずしも 1 つのプロセスではなく、次のセクションで説明するように、異なるマシンで実行される多くの構成要素で構成される場合があります。 さらに、一部のテレメトリ データの分析を迅速に実行する必要がある場合 (このドキュメントの後半の「 ホット、ウォーム、コールド分析のサポート 」セクションで説明されているように、ホット分析)、コレクション サービスの外部で動作するローカル コンポーネントは、すぐに分析タスクを実行する可能性があります。 図 2 は、選択したイベントに対するこの状況を示しています。 分析処理の後、結果を視覚化およびアラート サブシステムに直接送信できます。 ウォーム分析またはコールド分析の対象となるデータは、処理を待機している間、ストレージに保持されます。

Azure アプリケーションとサービスの場合、Azure Diagnostics には、データをキャプチャするための 1 つの可能なソリューションが用意されています。 Azure Diagnostics は、コンピューティング ノードごとに次のソースからデータを収集し、集計して Azure Storage にアップロードします。

• IIS ログ
• IIS の失敗した要求ログ
• Windows イベント ログ
• 性能カウンター
• クラッシュ ダンプ
• Azure Diagnostics インフラストラクチャ ログ
• カスタム エラー ログ
• .NET EventSource
• マニフェスト ベースの ETW

詳細については、 Azure: テレメトリの基本とトラブルシューティングに関する記事を参照してください。

インストルメンテーション データを収集するための戦略

クラウドのエラスティックな性質を考慮し、システム内のすべてのノードからテレメトリ データを手動で取得する必要を回避するには、データを中央の場所に転送して統合するように手配する必要があります。 複数のデータセンターにまたがるシステムでは、最初にリージョンごとにデータを収集、統合、格納してから、リージョン データを 1 つの中央システムに集約すると便利な場合があります。

帯域幅の使用を最適化するために、バッチとして、より緊急度の低いデータをチャンクで転送することを選択できます。 ただし、特に時間に依存する情報が含まれている場合は、データを無期限に遅延してはなりません。

インストルメンテーション データのプルとプッシュ

インストルメンテーション データ収集サブシステムは、アプリケーションの各インスタンス ( プル モデル) のさまざまなログやその他のソースからインストルメンテーション データをアクティブに取得できます。 または、アプリケーションの各インスタンス ( プッシュ モデル) を構成するコンポーネントからデータが送信されるのを待機するパッシブ レシーバーとして機能することもできます。

プル モデルを実装する方法の 1 つは、アプリケーションの各インスタンスでローカルに実行される監視エージェントを使用することです。 監視エージェントは、ローカル ノードで収集されたテレメトリ データを定期的に取得 (プル) し、アプリケーションのすべてのインスタンスが共有する集中型ストレージに直接この情報を書き込む別のプロセスです。 これは、Azure Diagnostics が実装するメカニズムです。 Azure Web ロールまたは worker ロールの各インスタンスは、ローカルに格納されている診断およびその他のトレース情報をキャプチャするように構成できます。 各インスタンスと共に実行される監視エージェントは、指定されたデータを Azure Storage にコピーします。 このプロセスの詳細については、 Azure Cloud Services と Virtual Machines での診断の有効化 に関する記事を参照してください。 IIS ログ、クラッシュ ダンプ、カスタム エラー ログなどの一部の要素は、BLOB ストレージに書き込まれます。 Windows イベント ログ、ETW イベント、およびパフォーマンス カウンターからのデータは、テーブル ストレージに記録されます。 図 3 は、このメカニズムを示しています。

図 3 - 監視エージェントを使用して情報をプルし、共有ストレージに書き込む。

注

監視エージェントの使用は、データ ソースから自然にプルされるインストルメンテーション データのキャプチャに最適です。 たとえば、SQL Server 動的管理ビューからの情報や、Azure Service Bus キューの長さなどです。

前述の方法を使用して、限られた数のノードで実行されている小規模なアプリケーションのテレメトリ データを 1 つの場所に格納できます。 ただし、複雑で拡張性の高いグローバル クラウド アプリケーションでは、何百もの Web ロールと worker ロール、データベース シャード、その他のサービスから大量のデータが生成される可能性があります。 この大量のデータは、1 つの中央の場所で利用できる I/O 帯域幅を簡単に上回る可能性があります。 そのため、テレメトリ ソリューションは、システムの拡張に合わせてボトルネックとして機能しないようにスケーラブルである必要があります。 システムの一部が失敗した場合に、重要な監視情報 (監査や課金データなど) を失うリスクを軽減するために、ソリューションに冗長性の程度を組み込むのが理想的です。

これらの問題に対処するために、図 4 に示すように、キューを実装できます。 このアーキテクチャでは、ローカル監視エージェント (適切に構成できる場合) またはカスタム データ収集サービス (そうでない場合) は、データをキューにポストします。 非同期的に実行されている別のプロセス (図 4 のストレージ書き込みサービス) は、このキュー内のデータを受け取り、共有ストレージに書き込みます。 メッセージ キューは、ポスト後にキューに格納されたデータが失われないようにするのに役立つ "少なくとも 1 回" のセマンティクスを提供するため、このシナリオに適しています。 ストレージ書き込みサービスは、別の worker ロールを使用して実装できます。

図 4 - キューを使用してインストルメンテーション データをバッファー処理する。

ローカル データ収集サービスは、受信した直後にキューにデータを追加できます。 キューはバッファーとして機能し、ストレージ書き込みサービスは独自のペースでデータを取得および書き込むことができます。 既定では、キューは先入れ先出しで動作します。 ただし、より迅速に処理する必要があるデータがメッセージに含まれている場合は、メッセージに優先順位を付けてキューを介してメッセージを高速化できます。 詳細については、「 優先順位キューパターン」を参照してください。 または、必要な分析処理の形式に応じて、異なるチャネル (Service Bus トピックなど) を使用してデータをさまざまな宛先に転送することもできます。

スケーラビリティのために、ストレージ書き込みサービスの複数のインスタンスを実行できます。 大量のイベントがある場合は、イベント ハブを使用して、処理とストレージのために異なるコンピューティング リソースにデータをディスパッチできます。

インストルメンテーション データの統合

データ収集サービスがアプリケーションの 1 つのインスタンスから取得するインストルメンテーション データにより、そのインスタンスの正常性とパフォーマンスがローカライズされたビューに表示されます。 システムの全体的な正常性を評価するには、ローカル ビューでデータのいくつかの側面を統合する必要があります。 これは、データが格納された後で実行できますが、場合によっては、データの収集時に実現することもできます。 インストルメンテーション データは、共有ストレージに直接書き込まれるのではなく、データを結合し、フィルターおよびクリーンアップ プロセスとして機能する個別のデータ統合サービスを通過できます。 たとえば、アクティビティ ID など、同じ相関関係情報を含むインストルメンテーション データを組み合わせることができます。 (ユーザーが 1 つのノードでビジネス操作の実行を開始した後、ノード障害が発生した場合、または負荷分散の構成方法に応じて別のノードに転送される可能性があります)。このプロセスでは、重複したデータを検出して削除することもできます (テレメトリ サービスがメッセージ キューを使用してインストルメンテーション データをストレージにプッシュする場合は常に発生する可能性があります)。 図 5 は、この構造の例を示しています。

図 5 - 別のサービスを使用してインストルメンテーション データを統合およびクリーンアップする。

インストルメンテーション データの格納

前の説明では、インストルメンテーション データを格納する方法のかなり単純なビューを示しました。 実際には、各型の使用方法に最も適したテクノロジを使用して、さまざまな種類の情報を格納することが理にかなっています。

たとえば、Azure BLOB とテーブル ストレージには、アクセス方法にいくつかの類似点があります。 ただし、それらの操作を使用して実行できる操作には制限があり、保持するデータの細分性はまったく異なります。 より多くの分析操作を実行する必要がある場合や、データに対してフルテキスト検索機能が必要な場合は、特定の種類のクエリとデータ アクセス用に最適化された機能を提供するデータ ストレージを使用する方が適切な場合があります。 例えば次が挙げられます。

• パフォーマンス カウンター データを SQL データベースに格納して、アドホック分析を有効にすることができます。
• トレース ログは、Azure Cosmos DB に格納することをお勧めします。
• セキュリティ情報は HDFS に書き込むことができます。
• フルテキスト検索を必要とする情報は、Elasticsearch を使用して格納できます (豊富なインデックス作成を使用して検索を高速化することもできます)。

図 6 に示すように、共有ストレージからデータを定期的に取得し、その目的に従ってデータをパーティション分割してフィルター処理し、適切なデータ ストアセットに書き込む追加のサービスを実装できます。 別の方法として、統合とクリーンアップのプロセスにこの機能を含め、中間共有記憶域に保存するのではなく、取得したデータをこれらのストアに直接書き込みます。 各アプローチには長所と短所があります。 個別のパーティション分割サービスを実装すると、統合およびクリーンアップ サービスの負荷が軽減され、必要に応じて (共有ストレージに保持されるデータの量に応じて) 少なくとも一部のパーティション分割データを再生成できます。 ただし、追加のリソースが消費されます。 また、各アプリケーション インスタンスからインストルメンテーション データを受信してから、このデータを実用的な情報に変換するまでに遅延が発生する可能性があります。

図 6 - 分析とストレージの要件に従ったデータのパーティション分割。

複数の目的で同じインストルメンテーション データが必要になる場合があります。 たとえば、パフォーマンス カウンターを使用して、時間の経過に伴うシステム パフォーマンスの履歴ビューを提供できます。 この情報を他の使用状況データと組み合わせて、顧客の課金情報を生成する場合があります。 このような状況では、同じデータが複数の宛先に送信される場合があります。たとえば、課金情報を保持するための長期的なストアとして機能するドキュメント データベースや、複雑なパフォーマンス分析を処理するための多次元ストアなどです。

また、データが必要な緊急性も考慮する必要があります。 アラートに関する情報を提供するデータにすばやくアクセスする必要があるため、アラート システムが実行するクエリを最適化するために、高速データ ストレージに保持し、インデックスを作成または構造化する必要があります。 場合によっては、各ノード上のデータを収集するテレメトリ サービスが、アラート システムのローカル インスタンスが問題を迅速に通知できるように、データの書式設定と保存をローカルで行う必要がある場合があります。 前の図に示したストレージ書き込みサービスに同じデータをディスパッチし、他の目的にも必要な場合は一元的に格納できます。

より考慮された分析、レポート、履歴の傾向を特定するために使用される情報は、緊急性が低く、データ マイニングとアドホック クエリをサポートする方法で格納できます。 詳細については、このドキュメントの後半の「 ホット、ウォーム、コールド解析のサポート 」セクションを参照してください。

ログローテーションとデータリテンション期間

インストルメンテーションでは、大量のデータを生成できます。 このデータは、生のログ ファイル、トレース ファイル、および各ノードでキャプチャされたその他の情報から、共有ストレージに保持されているこのデータの統合、クリーニング、パーティション分割されたビューまで、複数の場所に保持できます。 場合によっては、データが処理されて転送された後、元の生ソース データを各ノードから削除できます。 それ以外の場合は、生の情報を保存することが必要な場合や、単純に役立つ場合があります。 たとえば、デバッグ目的で生成されたデータは、生の形式で使用可能なままにするのが最適ですが、バグが修正された後すぐに破棄できます。

多くの場合、パフォーマンス データの寿命が長くなり、パフォーマンスの傾向を見つけ出したり、容量を計画したりするために使用できます。 このデータの統合ビューは、通常、高速アクセスを可能にするために、有限期間オンラインで保持されます。 その後、アーカイブまたは破棄できます。 測定と課金のために収集されたデータは、無期限に保存する必要がある場合があります。 さらに、監査とセキュリティの目的で収集された情報もアーカイブして保存する必要がある場合があります。 まが、このデータは機密性が高く、改ざんを防ぐために暗号化またはその他の方法で保護する必要がある場合もあります。 ユーザーのパスワードや、ID 詐欺を行うために使用される可能性のあるその他の情報を記録しないでください。 このような詳細は、格納する前にデータからスクラブする必要があります。

ダウン サンプリング

履歴データを格納すると、長期的な傾向を見つけることができます。 古いデータ全体を保存するのではなく、データをダウンサンプリングして解像度を下げ、ストレージ コストを節約できる場合があります。 たとえば、分単位の業績評価指標を保存するのではなく、1 か月以上前のデータを統合して時間単位のビューを形成できます。

ログ情報を収集して格納するためのベスト プラクティス

次の一覧は、ログ情報をキャプチャして格納するためのベスト プラクティスをまとめたものです。

• 監視エージェントまたはデータ収集サービスは、アウトプロセス サービスとして実行する必要があり、デプロイが簡単である必要があります。

• 監視エージェントまたはデータ収集サービスからの出力はすべて、コンピューター、オペレーティング システム、またはネットワーク プロトコルに依存しない形式にする必要があります。 たとえば、ETL/ETW ではなく、JSON、MessagePack、Protobuf などの自己記述形式で情報を出力します。 標準形式を使用すると、システムは処理パイプラインを構築できます。合意された形式でデータを読み取り、変換、および送信するコンポーネントを簡単に統合できます。

• 監視とデータ収集のプロセスは、フェールセーフである必要があり、連鎖エラー状態をトリガーしてはなりません。

• データ シンクに情報を送信するときに一時的な障害が発生した場合は、最新の情報が最初に送信されるように、テレメトリ データを並べ替えるために監視エージェントまたはデータ収集サービスを準備する必要があります。 (監視エージェント/データ収集サービスでは、独自の判断で、古いデータを削除するか、ローカルに保存して後で送信して追いつくことを選択する場合があります)。

データの分析と問題の診断

監視と診断プロセスの重要な部分は、収集されたデータを分析して、システムの全体的な幸福の画像を取得することです。 独自の KPI とパフォーマンス メトリックを定義する必要があり、分析要件を満たすために収集されたデータを構造化する方法を理解することが重要です。 また、さまざまなメトリックとログ ファイルにキャプチャされたデータがどのように関連付けられるかを理解することも重要です。これは、この情報が一連のイベントを追跡し、発生した問題の診断に役立つ鍵となる可能性があるためです。

インストルメンテーション データの統合に関するセクションで説明したように、通常、システムの各部分のデータはローカルにキャプチャされますが、通常はシステムに参加している他のサイトで生成されたデータと組み合わせる必要があります。 この情報を使用するには、データを正確に結合するために慎重な相関関係が必要です。 たとえば、操作の使用状況データは、ユーザーが接続する Web サイトをホストするノード、この操作の一部としてアクセスされる別のサービスを実行するノード、および別のノードに保持されているデータ ストレージにまたがる場合があります。 操作のリソースと処理の使用状況の全体像を提供するには、この情報を結び付ける必要があります。 データの一部の前処理とフィルター処理は、データがキャプチャされるノードで発生する可能性がありますが、集約と書式設定は中央ノードで発生する可能性が高くなります。

ホット、ウォーム、およびコールドの分析のサポート

視覚化、レポート、アラートの目的でデータを分析および再フォーマットすることは、独自のリソース セットを使用する複雑なプロセスになる可能性があります。 一部の形式の監視はタイム クリティカルであり、データの即時分析を有効にする必要があります。 これは ホット分析と呼ばれます。 たとえば、アラートに必要な分析や、セキュリティ監視の一部の側面 (システムへの攻撃の検出など) があります。 これらの目的に必要なデータは、効率的な処理のために迅速に利用でき、構造化されている必要があります。 場合によっては、データが保持されている個々のノードに分析処理を移動することが必要になる場合があります。

その他の形式の分析は、タイム クリティカルが少なく、生データを受信した後に何らかの計算と集計が必要になる場合があります。 これは ウォーム分析と呼ばれます。 パフォーマンス分析は、多くの場合、このカテゴリに分類されます。 この場合、分離された単一のパフォーマンス イベントが統計的に有意である可能性は低くなります。 (急激なスパイクやグリッチが原因である可能性があります)。一連のイベントからのデータは、システム パフォーマンスのより信頼性の高い画像を提供する必要があります。

ウォーム分析を使用して、正常性の問題を診断することもできます。 通常、正常性イベントはホット分析によって処理され、すぐにアラートを生成できます。 オペレーターは、ウォーム パスからのデータを調べることで、正常性イベントの理由を詳しく調べることができる必要があります。 このデータには、正常性イベントの原因となった問題に至るまでのイベントに関する情報が含まれている必要があります。

一部の種類の監視では、より長期的なデータが生成されます。 この分析は、事前に定義されたスケジュールに従って、後日実行できます。 場合によっては、分析で、一定期間にわたってキャプチャされた大量のデータの複雑なフィルター処理を実行することが必要になる場合があります。 これは コールド分析と呼ばれます。 重要な要件は、データがキャプチャされた後に安全に格納されるということです。 たとえば、使用状況の監視と監査では、通常の時点でのシステムの状態を正確に把握する必要がありますが、この状態情報を収集した直後に処理できる必要はありません。

オペレーターは、コールド分析を使用して、予測正常性分析用のデータを提供することもできます。 オペレーターは、指定した期間にわたって履歴情報を収集し、現在の正常性データ (ホット パスから取得) と組み合わせて使用して、間もなく正常性の問題を引き起こす可能性のある傾向を特定できます。 このような場合は、修正アクションを実行できるようにアラートを生成する必要があります。

データの関連付け

インストルメンテーションによってキャプチャされるデータは、システム状態のスナップショットを提供できますが、分析の目的は、このデータを実行可能にすることです。 例えば次が挙げられます。

• 特定の時刻にシステム レベルで I/O の読み込みが激しくなる原因は何ですか?
• 大量のデータベース操作の結果ですか?
• これは、データベースの応答時間、1 秒あたりのトランザクション数、およびアプリケーションの応答時間に同じタイミングで反映されますか?

その場合、負荷を軽減する修復アクションの 1 つは、より多くのサーバーにデータをシャード化することです。 さらに、システムの任意のレベルで障害が発生した結果、例外が発生する可能性があります。 1 つのレベルで例外が発生すると、多くの場合、上記のレベルで別のエラーがトリガーされます。

このような理由から、システムの状態とその上で実行されているアプリケーションの全体的なビューを生成するには、各レベルのさまざまな種類の監視データを関連付けることができる必要があります。 その後、この情報を使用して、システムが正常に機能しているかどうかに関する決定を行い、システムの品質を向上させるために何ができるかを決定できます。

「データを関連付ける情報」セクションで説明されているように、未加工のインストルメンテーション データに、イベントを関連付けるために必要な集計をサポートするための十分なコンテキストとアクティビティ ID 情報が含まれていることを確認する必要があります。 さらに、このデータは異なる形式で保持される場合があり、この情報を解析して、分析のために標準化された形式に変換することが必要になる場合があります。

問題のトラブルシューティングと診断

診断には、根本原因分析の実行など、障害の原因や予期しない動作を特定する機能が必要です。 通常、必要な情報には次のものが含まれます。

• イベント ログとトレースからの詳細情報(システム全体または指定された時間枠内の指定されたサブシステムに関する情報)。
• 指定した期間内にシステム内または指定されたサブシステム内で発生した、指定されたレベルの例外と障害に起因するスタック トレースを完了します。
• システム内の任意の場所、または指定した時間枠内の指定したサブシステムの失敗したプロセスのクラッシュ ダンプ。
• アクティビティ ログには、指定した期間中にすべてのユーザーまたは選択したユーザーが実行した操作が記録されます。

トラブルシューティングのためにデータを分析するには、多くの場合、システム アーキテクチャとソリューションを構成するさまざまなコンポーネントに関する深い技術的な理解が必要です。 その結果、多くの場合、データを解釈し、問題の原因を特定し、それらを修正するための適切な戦略を推奨するために、大量の手動介入が必要になります。 この情報のコピーを元の形式で保存し、専門家によるコールド分析に使用できるようにするのが適切な場合があります。

データの視覚化とアラートの生成

監視システムの重要な側面は、オペレーターが傾向や問題をすばやく特定できるような方法でデータを提示できることです。 また、重要なのは、注意が必要な重要なイベントが発生した場合にオペレーターに迅速に通知できることです。

データの表示には、ダッシュボード、アラート、レポートを使用した視覚化など、いくつかのフォームを使用できます。

ダッシュボードを使用した視覚化

データを視覚化する最も一般的な方法は、一連のグラフ、グラフ、またはその他の図として情報を表示できるダッシュボードを使用することです。 これらの項目はパラメーター化でき、アナリストは特定の状況で重要なパラメーター (期間など) を選択できる必要があります。

ダッシュボードは階層的に整理できます。 最上位レベルのダッシュボードでは、システムの各側面の全体像を確認できますが、オペレーターは詳細にドリルダウンできます。 たとえば、システムのディスク I/O 全体を示すダッシュボードでは、アナリストが個々のディスクの I/O レートを表示して、1 つまたは複数の特定のデバイスがトラフィックの不均衡なボリュームを占めるかどうかを確認できるようにする必要があります。 理想的には、ダッシュボードには、この I/O を生成している各要求のソース (ユーザーまたはアクティビティ) などの関連情報も表示する必要があります。 この情報を使用して、デバイス間でより均等に負荷を分散させるかどうか (および方法) と、デバイスが追加された場合にシステムのパフォーマンスが向上するかどうかを判断できます。

ダッシュボードでは、色分けやその他の視覚的な手掛かりを使用して、異常に見える値や予期される範囲外の値を示すこともできます。 前の例を使用します。

• 長期間にわたって最大容量に近づいている I/O レートのディスク (ホット ディスク) は赤で強調表示できます。
• 短い期間にわたって定期的に最大制限で実行される I/O レートのディスク (ウォーム ディスク) は、黄色で強調表示できます。
• 通常の使用量を示すディスクは、緑色で表示できます。

ダッシュボード システムを効果的に機能させるには、使用する生データが必要です。 独自のダッシュボード システムを構築する場合、または別の組織によって開発されたダッシュボードを使用している場合は、収集する必要があるインストルメンテーション データを、どのレベルの細分性で、ダッシュボードが使用できるように書式設定する必要があるかを理解する必要があります。

優れたダッシュボードは情報を表示するだけでなく、アナリストがその情報に関するアドホックな質問を行うこともできます。 一部のシステムには、オペレーターがこれらのタスクを実行し、基になるデータを探索するために使用できる管理ツールが用意されています。 または、この情報を保持するために使用されるリポジトリによっては、このデータを直接クエリしたり、Microsoft Excel などのツールにインポートして詳細な分析やレポートを行ったりすることもできます。

注

この情報は商業的に機密性の高い可能性があるため、承認された担当者にダッシュボードへのアクセスを制限する必要があります。 また、ダッシュボードの基になるデータを保護して、ユーザーが変更できないようにする必要もあります。

アラートの発生

アラートは、監視データとインストルメンテーション データを分析し、重要なイベントが検出された場合に通知を生成するプロセスです。

アラートは、システムが正常で応答性が高く、セキュリティで保護された状態を維持するのに役立ちます。 これは、データをすぐに操作する必要があるユーザーに対してパフォーマンス、可用性、プライバシーの保証を行うシステムの重要な部分です。 オペレーターには、アラートをトリガーしたイベントの通知が必要な場合があります。 アラートは、自動スケールなどのシステム関数を呼び出すためにも使用できます。

アラートは通常、次のインストルメンテーション データによって異なります。

• セキュリティ イベント。 イベント ログに、認証または承認の失敗が繰り返し発生していることが示されている場合は、システムが攻撃を受けている可能性があり、オペレーターに通知する必要があります。
• パフォーマンス メトリック。 特定のパフォーマンス メトリックが指定されたしきい値を超えた場合、システムはすぐに応答する必要があります。
• 可用性情報。 障害が検出された場合は、1 つ以上のサブシステムをすばやく再起動するか、バックアップ リソースにフェールオーバーすることが必要な場合があります。 サブシステムで障害が繰り返し発生すると、より深刻な問題が発生する可能性があります。

オペレーターは、電子メール、ポケットベル デバイス、SMS テキスト メッセージなど、多くの配信チャネルを使用してアラート情報を受信する場合があります。 アラートには、状況がどれほど重要であるかを示す情報も含まれる場合があります。 多くのアラート システムではサブスクライバー グループがサポートされており、同じグループのメンバーであるすべてのオペレーターが同じアラート のセットを受け取ることができます。

アラート システムはカスタマイズ可能で、基になるインストルメンテーション データの適切な値をパラメーターとして指定できます。 この方法を使用すると、オペレーターはデータをフィルター処理し、関心のある値のしきい値または組み合わせに焦点を当てます。 場合によっては、生のインストルメンテーション データをアラート システムに提供できます。 その他の状況では、集計データを提供する方が適切な場合があります。 (たとえば、ノードの CPU 使用率が過去 10 分間に 90% を超えた場合にアラートをトリガーできます)。 アラート システムに提供される詳細には、適切な概要とコンテキスト情報も含まれている必要があります。 このデータは、誤検知イベントがアラートをトリップする可能性を減らすのに役立ちます。

レポーティング

レポートは、システムの全体的なビューを生成するために使用されます。 現在の情報に加えて履歴データが組み込まれる場合があります。 レポート要件自体は、運用レポートとセキュリティ レポートという 2 つの大きなカテゴリに分類されます。

運用レポートには、通常、次の側面が含まれます。

• 指定された時間枠内のシステム全体または指定されたサブシステムのリソース使用状況を把握するために使用できる統計を集計します。
• 指定された期間におけるシステム全体または指定されたサブシステムのリソース使用状況の傾向を特定します。
• 指定した期間中にシステム全体または指定されたサブシステムで発生した例外を監視する。
• デプロイされたリソースの観点からアプリケーションの効率を判断し、リソースの量 (およびそれに関連するコスト) を不必要にパフォーマンスに影響を与えることなく削減できるかどうかを理解します。

セキュリティ レポートは、お客様によるシステムの使用の追跡に関係します。 次のものが含まれます。

• ユーザー操作の監査。 これには、各ユーザーが実行する個々の要求を日付と時刻と共に記録する必要があります。 データは、管理者が指定した期間にユーザーが実行する一連の操作をすばやく再構築できるように構造化する必要があります。
• ユーザーによるリソースの使用の追跡。 これには、ユーザーの各要求がシステムを構成するさまざまなリソースにアクセスする方法と、その期間を記録する必要があります。 管理者は、このデータを使用して、指定した期間にわたってユーザーによる使用状況レポートを生成できる必要があります(場合によっては課金目的)。

多くの場合、バッチ プロセスでは、定義されたスケジュールに従ってレポートを生成できます。 (通常、待機時間は問題ではありません)。ただし、必要に応じて、アドホックベースで生成することもできます。 たとえば、Azure SQL Database などのリレーショナル データベースにデータを格納する場合は、SQL Server Reporting Services などのツールを使用して、データを抽出して書式設定し、一連のレポートとして表示できます。

次のステップ

• Azure Monitor の概要
• Microsoft Azure Storage の監視、診断、およびトラブルシューティング
• Microsoft Azure のアラートの概要
• Azure Portal を使用したサービス正常性通知の表示
• Application Insights とは
• Azure 仮想マシンのパフォーマンス診断
• Visual Studio 用 SQL Server Data Tools (SSDT) をダウンロードしてインストールする

関連リソース

• 自動スケール ガイダンス では、オペレーターがシステムのパフォーマンスを継続的に監視し、リソースの追加または削除に関する決定を行う必要性を減らすことで、管理オーバーヘッドを削減する方法について説明します。
• 正常性エンドポイント監視パターン では、外部ツールが一定の間隔で公開されたエンドポイントを介してアクセスできる機能チェックをアプリケーション内に実装する方法について説明します。
• 優先順位キュー パターン は、緊急の要求を受信し、緊急性の低いメッセージの前に処理できるように、キューに登録されたメッセージに優先順位を付ける方法を示します。

クラウドで実行されている分散アプリケーションとサービスは、その性質上、多くの可動部分を構成する複雑なソフトウェアです。 運用環境では、ユーザーがシステムを使用する方法を追跡し、リソース使用率をトレースし、システムの正常性とパフォーマンスを一般的に監視できることが重要です。 ここに記載する情報を診断に使用して、問題の検出と修正を行うことができます。さらに、潜在的な問題を見つけてその発生を防止するために役立てることもできます。

監視と診断のシナリオ

監視を使用すると、システムがどの程度正常に機能しているかについての分析情報を得ることができます。 監視は、サービス品質目標を維持するうえで重要な部分です。 監視データを収集する一般的なシナリオは次のとおりです。

• システムが正常な状態を維持していることを確認します。
• システムとそのコンポーネント要素の可用性の追跡。
• 作業量の増加に伴ってシステムのスループットが予期せず低下しないように、パフォーマンスを維持する。
• システムが顧客と確立されたサービス レベル アグリーメント (SLA) を満たしていることを保証します。
• システム、ユーザー、およびデータのプライバシーとセキュリティを保護する。
• 監査または規制目的で実行される操作を追跡します。
• システムの日常的な使用状況を監視し、対処されていない場合に問題につながる可能性がある傾向を見つけます。
• 最初のレポートから考えられる原因の分析、修正、結果的なソフトウェア更新プログラム、展開まで、発生した問題を追跡します。
• 操作のトレースとソフトウェア リリースのデバッグ。

注

このリストは包括的なものではありません。 このドキュメントでは、監視を実行するための最も一般的な状況として、これらのシナリオに焦点を当てています。 他にも、あまり一般的ではない、または環境に固有のものもあります。

次のセクションでは、これらのシナリオについて詳しく説明します。 各シナリオの情報については、次の形式で説明します。

1. シナリオの簡単な概要。
2. このシナリオの一般的な要件。
3. シナリオをサポートするために必要な生のインストルメンテーション データと、この情報の考えられるソース。
4. この生データを分析して組み合わせて、意味のある診断情報を生成する方法。

健康状態の監視

システムが実行中で、要求を処理できる場合、システムは正常です。 正常性監視の目的は、システムのすべてのコンポーネントが期待どおりに機能していることを確認できるように、システムの現在の正常性のスナップショットを生成することです。

正常性監視の要件

システムの一部が異常と見なされた場合、オペレーターは (数秒以内に) 迅速にアラートを受け取る必要があります。 オペレーターは、システムのどの部分が正常に機能していて、どの部分で問題が発生しているかを確認できる必要があります。 システムの正常性は、信号システムを介して強調表示できます。

• 異常の場合は赤 (システムが停止しました)
• 部分的に正常な黄色 (システムは機能が低下して実行されています)
• 完全に健康のための緑

包括的な正常性監視システムを使用すると、オペレーターはシステムをドリルダウンして、サブシステムとコンポーネントの正常性状態を表示できます。 たとえば、システム全体が部分的に正常であると示されている場合、オペレーターはズームインし、現在使用できない機能を判断できる必要があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

正常性の監視をサポートするために必要な生データは、次の結果として生成できます。

• ユーザー要求の実行のトレース。 この情報を使用して、成功した要求、失敗した要求、および各要求にかかる時間を判断できます。
• 代理ユーザーの監視。 このプロセスは、ユーザーが実行するステップをシミュレートし、定義済みの一連の手順に従います。 各ステップの結果をキャプチャする必要があります。
• 例外、エラー、警告のログ記録。 この情報は、トレース ステートメントがアプリケーション コードに埋め込まれた結果としてキャプチャされるだけでなく、システムが参照するすべてのサービスのイベント ログから情報を取得した結果としてキャプチャできます。
• システムが使用するサード パーティサービスの正常性の監視。 この監視には、これらのサービスが提供する正常性データの取得と解析が必要になる場合があります。 この情報にはさまざまな形式が使用される場合があります。
• エンドポイントの監視。 このメカニズムの詳細については、「可用性の監視」セクションを参照してください。
• バックグラウンド CPU 使用率や I/O (ネットワークを含む) アクティビティなどのアンビエント パフォーマンス情報の収集。

正常性データの分析

正常性監視の主な焦点は、システムが実行されているかどうかを迅速に示することです。 重要なコンポーネントが異常として検出された場合、即時データのホット分析によってアラートがトリガーされる可能性があります。 (たとえば、連続する一連の ping に応答できません)。その後、オペレーターは適切な是正措置を取ることができます。

より高度なシステムには、最近および現在のワークロードに対してコールド分析を実行する予測要素が含まれる場合があります。 コールド分析では、傾向を特定し、システムが正常な状態を維持する可能性があるかどうか、またはシステムに追加のリソースが必要かどうかを判断できます。 この予測要素は、次のような重要なパフォーマンス メトリックに基づく必要があります。

• 各サービスまたはサブシステムに送信される要求のレート。
• これらの要求の応答時間。
• 各サービスとの間で送受信されるデータの量。

メトリックの値が定義されたしきい値を超えた場合、システムはアラートを生成して、オペレーターまたは自動スケール (使用可能な場合) が、システムの正常性を維持するために必要な予防措置を実行できるようにします。 これらのアクションには、リソースの追加、失敗している 1 つ以上のサービスの再起動、優先順位の低い要求への調整の適用が含まれる場合があります。

可用性の監視

真に正常なシステムでは、システムを構成するコンポーネントとサブシステムが使用可能である必要があります。 可用性の監視は、正常性の監視と密接に関連しています。 ただし、正常性の監視はシステムの現在の正常性をすぐに確認できるのに対し、可用性の監視は、システムとそのコンポーネントの可用性を追跡してシステムのアップタイムに関する統計情報を生成することに関係します。

多くのシステムでは、重大な障害や接続の損失が発生した場合に迅速なフェールオーバーを可能にするために、一部のコンポーネント (データベースなど) が組み込みの冗長性で構成されています。 理想的には、ユーザーはこのようなエラーが発生したことを認識しないようにする必要があります。 ただし、可用性の監視の観点からは、このような障害に関するできるだけ多くの情報を収集して原因を特定し、再発を防ぐための是正措置を講じる必要があります。

可用性の追跡に必要なデータは、いくつかの下位レベルの要因によって異なります。 これらの要因の多くは、アプリケーション、システム、および環境に固有である可能性があります。 効果的な監視システムは、これらの低レベルの要因に対応する可用性データをキャプチャし、それらを集計してシステムの全体像を把握します。 たとえば、eコマース システムでは、顧客が注文を行えるビジネス機能は、注文の詳細が格納されているリポジトリと、これらの注文に対する支払いのために通貨トランザクションを処理する支払システムによって異なります。 したがって、システムの注文配置部分の可用性は、リポジトリと支払サブシステムの可用性の機能です。

可用性の監視の要件

また、オペレーターは、各システムとサブシステムの可用性の履歴を表示し、この情報を使用して、1 つ以上のサブシステムが定期的に失敗する可能性のある傾向を特定できる必要があります。 (ピーク処理時間に対応する特定の時刻にサービスが失敗し始めますか?

監視ソリューションでは、各サブシステムの可用性または使用不能性の即時および履歴ビューを提供する必要があります。 また、1 つ以上のサービスが失敗したとき、またはユーザーがサービスに接続できない場合に、オペレーターに迅速にアラートを送信することもできます。 これは、各サービスを監視するだけでなく、サービスとの通信を試みたときにこれらのアクションが失敗した場合に各ユーザーが実行するアクションを調べることの問題です。 ある程度、ある程度の接続エラーは正常であり、一時的なエラーが原因である可能性があります。 ただし、特定の期間中に発生した特定のサブシステムへの接続エラーの数に関するアラートをシステムが生成できるようにすると便利な場合があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

正常性の監視と同様に、可用性の監視をサポートするために必要な生データは、発生する可能性のある例外、障害、警告を合成ユーザーが監視してログに記録した結果として生成できます。 さらに、エンドポイントの監視を実行することで可用性データを取得できます。 アプリケーションは、1 つ以上の正常性エンドポイントを公開できます。各テストでは、システム内の機能領域にアクセスできます。 監視システムは、定義されたスケジュールに従って各エンドポイントに ping を実行し、結果 (成功または失敗) を収集できます。

すべてのタイムアウト、ネットワーク接続エラー、接続の再試行を記録する必要があります。 すべてのデータにタイムスタンプを付ける必要があります。

可用性データの分析

次の種類の分析をサポートするには、インストルメンテーション データを集計して関連付ける必要があります。

• システムとサブシステムの即時可用性。
• システムとサブシステムの可用性エラー率。 オペレーターは、障害を特定のアクティビティ (システムが失敗したときに何が起こっていたか) と関連付けることができるのが理想的です。
• 指定した期間におけるシステムまたはサブシステムの障害率と、障害が発生したときのシステムの負荷 (ユーザー要求の数など) の履歴ビュー。
• システムまたはサブシステムが使用できない理由。 たとえば、サービスが実行されていない、接続が失われた、接続されているがタイムアウト、接続されているがエラーが返されるなどの理由が考えられます。

次の数式を使用して、一定期間のサービスの可用性の割合を計算できます。

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

これは SLA の目的で役立ちます。 (SLA の監視 については、このガイダンスの後半で詳しく説明します)。 ダウンタイム の定義は、サービスによって異なります。 たとえば、Visual Studio Team Services Build Service では、ビルド サービスが使用できない期間 (合計累積分数) としてダウンタイムが定義されます。 1 分間を通して顧客が開始した操作を実行するために Build Service に対するすべての継続的な HTTP 要求でエラー コードが発生した場合、または応答が返されない場合、1 分間は使用できないと見なされます。

パフォーマンスの監視

(ユーザーの量を増やすことで) システムがますますストレスを受けるにつれて、これらのユーザーがアクセスするデータセットのサイズが大きくなり、1 つ以上のコンポーネントの障害が発生する可能性が高くなります。 多くの場合、コンポーネントの障害の前にパフォーマンスが低下します。 このような減少を検出できる場合は、状況を解決するための予防的な手順を実行できます。

システムのパフォーマンスは、さまざまな要因によって異なります。 各要因は通常、主要業績評価指標 (KPI) (1 秒あたりのデータベース トランザクション数や、指定された時間枠内で正常に処理されたネットワーク要求の量など) によって測定されます。 これらの KPI の中には、特定のパフォーマンス メジャーとして使用できる KPI もあれば、メトリックの組み合わせから派生した KPI もあります。

注

パフォーマンスの低下または良好なパフォーマンスを判断するには、システムを実行できるパフォーマンスのレベルを理解する必要があります。 これには、システムが一般的な負荷の下で機能している間にシステムを監視し、一定期間にわたって KPI ごとにデータをキャプチャする必要があります。 これには、テスト環境でシミュレートされた負荷の下でシステムを実行し、運用環境にシステムをデプロイする前に適切なデータを収集することが含まれる場合があります。

また、パフォーマンスを目的とした監視がシステムの負担にならないようにする必要があります。 パフォーマンス監視プロセスが収集するデータの詳細レベルを動的に調整できる場合があります。

パフォーマンス監視の要件

システムのパフォーマンスを調べるには、オペレーターは通常、次を含む情報を確認する必要があります。

• ユーザー要求の応答率。
• 同時ユーザー要求の数。
• ネットワーク トラフィックの量。
• ビジネス トランザクションが完了するレート。
• 要求の平均処理時間。

また、オペレーターが次のような相関関係を見つけるのに役立つツールを提供すると便利です。

• 同時ユーザー数と要求待機時間 (ユーザーが要求を送信した後に要求の処理を開始するのにかかる時間)。
• 同時ユーザーの数と平均応答時間 (処理を開始した後に要求が完了するまでにかかる時間)。
• 要求の量と処理エラーの数。

この高度な機能情報と共に、オペレーターはシステム内の各コンポーネントのパフォーマンスの詳細なビューを取得できる必要があります。 通常、このデータは、次のような情報を追跡する低レベルのパフォーマンス カウンターを通じて提供されます。

• メモリ使用率。
• スレッドの数。
• CPU 処理時間。
• 要求キューの長さ。
• ディスクまたはネットワークの I/O レートとエラー。
• 書き込みまたは読み取りを行ったバイト数。
• キューの長さなどのミドルウェア インジケーター。

すべての視覚化では、オペレーターが期間を指定できるようにする必要があります。 表示されるデータは、現在の状況のスナップショットまたはパフォーマンスの履歴ビューである可能性があります。

オペレーターは、指定した時間間隔中に、指定した値に対する任意のパフォーマンスメジャーに基づいてアラートを生成できる必要があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

ユーザーの要求が到着してシステムを通過する際の進行状況を監視することで、高レベルのパフォーマンス データ (スループット、同時実行ユーザーの数、ビジネス トランザクションの数、エラー率など) を収集できます。 これには、タイミング情報と共に、アプリケーション コードの重要なポイントにトレース ステートメントを組み込む必要があります。 エラー、例外、および警告はすべて、それらを原因となった要求と関連付けるのに十分なデータでキャプチャする必要があります。 インターネット インフォメーション サービス (IIS) ログは、もう 1 つの便利なソースです。

可能であれば、アプリケーションが使用する外部システムのパフォーマンス データもキャプチャする必要があります。 これらの外部システムは、パフォーマンス データを要求するための独自のパフォーマンス カウンターまたはその他の機能を提供する場合があります。 これが不可能な場合は、外部システムに対して行われた各要求の開始時刻や終了時刻などの情報を、操作の状態 (成功、失敗、警告) と共に記録します。 たとえば、ストップウォッチアプローチを使用して要求を時刻に設定できます。要求の開始時にタイマーを開始してから、要求が完了したときにタイマーを停止します。

システム内の個々のコンポーネントの低レベルのパフォーマンス データは、Windows パフォーマンス カウンターや Azure Diagnostics などの機能やサービスを通じて利用できる場合があります。

パフォーマンス データの分析

分析作業の多くは、ユーザー要求の種類または各要求の送信先となるサブシステムまたはサービスによるパフォーマンス データの集計で構成されます。 ユーザー要求の例として、ショッピング カートにアイテムを追加したり、e コマース システムでチェックアウト プロセスを実行したりします。

もう 1 つの一般的な要件は、選択したパーセンタイルのパフォーマンス データの概要です。 たとえば、オペレーターは、要求の 99%、要求の 95%、および要求の 70% の応答時間を決定できます。 各パーセンタイルに SLA ターゲットまたはその他の目標が設定されている可能性があります。 進行中の結果は、即時の問題の検出に役立つほぼリアルタイムで報告する必要があります。 結果は、統計目的で長い時間にわたって集計する必要もあります。

パフォーマンスに影響する待機時間の問題が発生した場合、オペレーターは、各要求が実行する各ステップの待機時間を調べることで、ボトルネックの原因をすばやく特定できる必要があります。 したがって、パフォーマンス データは、特定の要求に関連付けるために、各ステップのパフォーマンスメジャーを関連付ける手段を提供する必要があります。

視覚化の要件によっては、生データのビューを含むデータ キューブを生成して格納すると便利な場合があります。 このデータ キューブを使用すると、パフォーマンス情報の複雑なアドホック クエリと分析を行うことができます。

セキュリティの監視

機密データを含むすべての商用システムは、セキュリティ構造を実装する必要があります。 通常、セキュリティ メカニズムの複雑さは、データの機密性の関数です。 ユーザーを認証する必要があるシステムでは、次の情報を記録する必要があります。

• 失敗した場合でも成功した場合でも、すべてのサインイン試行。
• 認証されたユーザーによって実行されるすべての操作 (およびアクセスされるすべてのリソースの詳細)。
• ユーザーがセッションを終了してサインアウトしたとき。

監視は、システムに対する攻撃を検出するのに役立つ場合があります。 たとえば、サインイン試行に失敗した回数が多い場合は、ブルート フォース攻撃を示している可能性があります。 要求の予期しない急増は、分散型サービス拒否 (DDoS) 攻撃の結果である可能性があります。 これらの要求のソースに関係なく、すべてのリソースに対するすべての要求を監視するように準備する必要があります。 サインインの脆弱性があるシステムでは、ユーザーが実際にサインインしなくても、リソースが外部に誤って公開される可能性があります。

セキュリティ監視の要件

セキュリティ監視の最も重要な側面により、オペレーターは次の作業をすばやく実行できます。

• 認証されていないエンティティによる侵入の試行を検出します。
• アクセス権が付与されていないデータに対して操作を実行するエンティティによる試行を特定します。
• システムまたはシステムの一部が外部または内部からの攻撃を受けているかどうかを判断します。 (たとえば、悪意のある認証済みユーザーがシステムを停止しようとしている可能性があります)。

これらの要件をサポートするには、次の場合にオペレーターに通知する必要があります。

• 1 つのアカウントで、指定した期間内にサインイン試行が繰り返し失敗します。
• 1 つの認証済みアカウントは、指定された期間中に禁止されているリソースへのアクセスを繰り返し試行します。
• 指定された期間中に多数の認証されていない要求または未承認の要求が発生します。

オペレーターに提供される情報には、各要求のソースのホスト アドレスを含める必要があります。 特定の範囲のアドレスからセキュリティ違反が定期的に発生した場合、これらのホストがブロックされる可能性があります。

システムのセキュリティを維持する上で重要な部分は、通常のパターンから逸脱したアクションをすばやく検出できることです。 失敗したサインイン要求や成功したサインイン要求の数などの情報を視覚的に表示して、異常なタイミングでアクティビティが急増しているかどうかを検出するのに役立ちます。 (このアクティビティの例として、ユーザーは午前 3 時にサインインし、稼働日が午前 9 時に開始されたときに多数の操作を実行します)。 この情報は、時間ベースの自動スケールの構成にも使用できます。 たとえば、オペレーターが特定の時間帯に多数のユーザーが定期的にサインインすることを確認した場合、オペレーターは、作業量を処理するために追加の認証サービスを開始するように手配し、ピークが過ぎたときにこれらの追加サービスをシャットダウンすることができます。

データ ソース、インストルメンテーション、およびデータ収集の要件

セキュリティは、ほとんどの分散システムの包括的な側面です。 関連するデータは、システム全体の複数のポイントで生成される可能性があります。 アプリケーション、ネットワーク機器、サーバー、ファイアウォール、ウイルス対策ソフトウェア、およびその他の侵入防止要素によって発生したイベントの結果として発生するセキュリティ関連の情報を収集するには、セキュリティ情報イベント管理 (SIEM) アプローチを採用することを検討する必要があります。

セキュリティ監視には、アプリケーションの一部ではないツールからのデータを組み込むことができます。 これらのツールには、外部機関によるポート スキャン アクティビティを識別するユーティリティや、アプリケーションとデータへの認証されていないアクセスの試行を検出するネットワーク フィルターが含まれます。

いずれの場合も、収集されたデータを使用して、管理者が攻撃の性質を判断し、適切な対策を講じる必要があります。

セキュリティ データの分析

セキュリティ監視の機能は、データが発生するさまざまなソースです。 さまざまな形式と詳細レベルでは、多くの場合、キャプチャされたデータを複雑に分析して、一貫性のある情報スレッドに結び付ける必要があります。 最も単純なケース (多数の失敗したサインインの検出、重要なリソースへの不正アクセスの繰り返しの試行など) とは別に、セキュリティ データの複雑な自動処理を実行できない場合があります。 代わりに、このデータをタイムスタンプ付きで書き込むのではなく、元の形式で安全なリポジトリに書き込んで、専門家による手動分析を可能にすることをお勧めします。

SLA の監視

有料顧客をサポートする多くの商用システムでは、SLA の形式でシステムのパフォーマンスが保証されます。 基本的に、SLA は、合意された時間内に、重要な情報を失うことなく、定義された作業量をシステムが処理できることを示しています。 SLA の監視は、システムが測定可能な SLA を満たすことができることを保証することに関係しています。

注

SLA の監視は、パフォーマンスの監視と密接に関連しています。 ただし、パフォーマンスの監視はシステムが 最適に機能することを保証することに関係していますが、SLA 監視は、 実際に何が最適 かを定義する契約上の義務によって管理されます。

SLA は、多くの場合、次の点で定義されます。

• システムの全体的な可用性。 たとえば、組織では、システムが 99.9% の時間使用可能であることが保証される場合があります。 これは、1 年あたり 9 時間以下、または週に約 10 分のダウンタイムに相当します。
• 運用スループット。 この側面は、多くの場合、システムが最大 100,000 件の同時ユーザー要求をサポートできることや、10,000 件の同時ビジネス トランザクションを処理できることを保証するなど、1 つ以上の高ウォーター マークとして表されます。
• 運用応答時間。 システムでは、要求が処理される速度が保証される場合もあります。 たとえば、すべてのビジネス トランザクションの 99% が 2 秒以内に完了し、1 回のトランザクションに 10 秒を超える時間はかからなくなります。

注

商用システムの一部の契約には、カスタマー サポート用の SLA も含まれる場合があります。 たとえば、すべてのヘルプ デスク要求が 5 分以内に応答を引き出し、すべての問題の 99% が 1 営業日以内に完全に対処されるということです。 効果的な 問題の追跡 (このセクションで後述) は、このような SLA を満たす上で重要です。

SLA 監視の要件

最高レベルでは、オペレーターは、システムが合意された SLA を満たしているかどうかを一目で判断できる必要があります。 そうでない場合は、オペレーターがドリルダウンし、基になる要因を調べて、標準以下のパフォーマンスの理由を判断できる必要があります。

視覚的に示すことができる一般的な高レベルインジケーターは次のとおりです。

• サービスのアップタイムの割合。
• アプリケーションのスループット (1 秒あたりの成功したトランザクションまたは操作の観点から測定)。
• 成功/失敗したアプリケーション要求の数。
• アプリケーションとシステムの障害、例外、警告の数。

これらのインジケーターはすべて、指定された期間でフィルター処理できる必要があります。

クラウド アプリケーションは、多くのサブシステムとコンポーネントで構成される可能性があります。 演算子は、高レベルのインジケーターを選択し、基になる要素の正常性からどのように構成されているかを確認できる必要があります。 たとえば、システム全体のアップタイムが許容される値を下回った場合、オペレーターは拡大し、この障害の原因となっている要素を特定できる必要があります。

注

システムのアップタイムは慎重に定義する必要があります。 冗長性を使用して最大限の可用性を確保するシステムでは、要素の個々のインスタンスが失敗する可能性がありますが、システムは機能したままにすることができます。 正常性の監視によって示されるシステムのアップタイムは、各要素の全体的なアップタイムを示す必要があり、システムが実際に停止したかどうかは必ずしもありません。 さらに、エラーが分離される可能性があります。 そのため、特定のシステムが使用できない場合でも、機能が低下しても、システムの残りの部分は使用可能なままになる可能性があります。 (eコマース システムでは、システムの障害により顧客が注文できない場合がありますが、顧客は製品カタログを参照できる可能性があります)。

アラートの目的で、高レベルインジケーターのいずれかが指定されたしきい値を超えた場合、システムはイベントを発生させる必要があります。 高レベルインジケーターを構成するさまざまな要因の下位レベルの詳細は、アラート システムのコンテキスト データとして使用できる必要があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

SLA 監視をサポートするために必要な生データは、正常性と可用性の監視の一部の側面と共に、パフォーマンスの監視に必要な生データに似ています。 (詳細については、これらのセクションを参照してください)。このデータは、次の方法でキャプチャできます。

• エンドポイント監視の実行。
• 例外、エラー、警告のログ記録。
• ユーザー要求の実行をトレースします。
• システムが使用するサードパーティサービスの可用性の監視。
• パフォーマンス メトリックとカウンターの使用。

すべてのデータに時間とタイムスタンプを設定する必要があります。

SLA データの分析

インストルメンテーション データを集計して、システムの全体的なパフォーマンスの図を生成する必要があります。 集計データでは、基になるサブシステムのパフォーマンスを調べるためにドリルダウンもサポートする必要があります。 たとえば、次のことが可能になります。

• 指定した期間中のユーザー要求の合計数を計算し、これらの要求の成功率と失敗率を決定します。
• ユーザー要求の応答時間を組み合わせて、システム応答時間の全体的なビューを生成します。
• ユーザー要求の進行状況を分析して、要求の全体的な応答時間を、その要求内の個々の作業項目の応答時間に分割します。
• 特定の期間のアップタイムの割合として、システムの全体的な可用性を決定します。
• システム内の個々のコンポーネントとサービスの利用可能時間の割合を分析します。 これには、サードパーティのサービスによって生成されたログの解析が含まれる場合があります。

多くの商用システムでは、一定の期間 (通常は 1 か月) の合意された SLA に対して実際のパフォーマンス数値を報告する必要があります。 この情報は、その期間中に SLA が満たされない場合に、顧客に対するクレジットやその他の形式の返済を計算するために使用できます。 可用性データの分析セクションで説明されている手法を使用して、サービスの 可用性を計算できます。

内部的な目的で、組織は、サービスの失敗の原因となったインシデントの数と性質を追跡する場合もあります。 これらの問題を迅速に解決する方法、または完全に解消する方法を学習すると、ダウンタイムを短縮し、SLA を満たすのに役立ちます。

監査

アプリケーションの性質によっては、ユーザーの操作を監査し、すべてのデータ アクセスを記録するための要件を指定する法的または他の法的規制が存在する場合があります。 監査は、顧客を特定の要求にリンクする証拠を提供できます。 否認は、アプリケーションまたはサービスを担当する顧客と組織との間の信頼を維持するために役立つ多くの電子ビジネス システムにおいて重要な要素です。

監査の要件

アナリストは、ユーザーのアクションを再構築できるように、ユーザーが実行している一連のビジネス操作を追跡できる必要があります。 これは、単に記録の問題として、またはフォレンジック調査の一環として必要な場合があります。

監査情報は機密性が高い。 システムのユーザーを識別するデータと、実行しているタスクが含まれる可能性があります。 このため、ほとんどの場合、監査情報は、グラフィカル操作のドリルダウンをサポートする対話型システムとしてではなく、信頼できるアナリストのみが使用できるレポートの形式になります。 アナリストは、さまざまなレポートを生成できる必要があります。 たとえば、レポートには、指定した期間内に発生したすべてのユーザーのアクティビティが一覧表示されたり、1 人のユーザーのアクティビティの時系列が詳細に表示されたり、1 つ以上のリソースに対して実行された一連の操作が一覧表示されたりすることがあります。

データ ソース、インストルメンテーション、およびデータ収集の要件

監査の主な情報ソースは次のとおりです。

• ユーザー認証を管理するセキュリティ システム。
• ユーザー アクティビティを記録するトレース ログ。
• 識別可能で識別できないすべてのネットワーク要求を追跡するセキュリティ ログ。

監査データの形式と格納方法は、規制要件によって推進される場合があります。 たとえば、どのような方法でもデータをクリーンアップできない場合があります。 (元の形式で記録する必要があります。改ざんを防ぐために、リポジトリが保持されているリポジトリへのアクセスを保護する必要があります。

監査データの分析

アナリストは、元の形式で生データ全体にアクセスできる必要があります。 一般的な監査レポートを生成する要件とは別に、このデータを分析するためのツールは特殊化され、システムの外部に保持される可能性があります。

使用状況の監視

使用状況の監視では、アプリケーションの機能とコンポーネントの使用方法を追跡します。 オペレーターは、収集されたデータを使用して次のことができます。

• どの機能が頻繁に使用されているかを判断し、システム内の潜在的なホットスポットを決定します。 トラフィックの多い要素は、負荷をより均等に分散させるために、機能パーティション分割やレプリケーションの恩恵を受ける可能性があります。 また、オペレーターは、この情報を使用して、使用頻度の低い機能を確認し、将来のバージョンのシステムで提供終了または置換の候補となる可能性を確認することもできます。

• 通常の使用中のシステムの運用イベントに関する情報を取得します。 たとえば、eコマース サイトでは、トランザクションの数と顧客の量に関する統計情報を記録できます。 この情報は、顧客の数が増えるにつれて容量計画に使用できます。

• システムのパフォーマンスまたは機能に対するユーザーの満足度を (場合によっては間接的に) 検出します。 たとえば、eコマース システムの多数の顧客が定期的にショッピング カートを放棄する場合、これはチェックアウト機能の問題が原因である可能性があります。

• 課金情報を生成します。 商用アプリケーションまたはマルチテナント サービスでは、使用するリソースに対して顧客に課金される場合があります。

• クォータを適用します。 マルチテナント システムのユーザーが、指定した期間中に処理時間またはリソース使用量の支払いクォータを超えた場合、アクセスを制限したり、処理を調整したりできます。

使用状況の監視の要件

システムの使用状況を調べるには、オペレーターは通常、次を含む情報を表示する必要があります。

• 各サブシステムによって処理され、各リソースに送信される要求の数。
• 各ユーザーが実行している作業。
• 各ユーザーが占有するデータ ストレージのボリューム。
• 各ユーザーがアクセスしているリソース。

演算子はグラフも生成できる必要があります。 たとえば、グラフには、リソースが最も多いユーザー、または最も頻繁にアクセスされるリソースまたはシステム機能が表示される場合があります。

データ ソース、インストルメンテーション、およびデータ収集の要件

使用状況の追跡は、比較的高いレベルで実行できます。 各要求の開始時刻と終了時刻、および要求の性質 (対象のリソースに応じて読み取り、書き込みなど) をメモできます。 この情報は、次の方法で取得できます。

• ユーザー アクティビティのトレース。
• 各リソースの使用率を測定するパフォーマンス カウンターのキャプチャ。
• 各ユーザーによるリソース消費量の監視。

測定の目的で、どのユーザーがどの操作を実行する責任があり、これらの操作で使用されるリソースを識別できる必要もあります。 収集された情報は、正確な課金を可能にするために十分に詳細である必要があります。

問題の追跡

システムで予期しないイベントや動作が発生した場合、お客様やその他のユーザーが問題を報告する場合があります。 問題の追跡は、これらの問題の管理、システム内の根本的な問題の解決への取り組みと関連付け、考えられる解決策をお客様に通知することに関係しています。

問題の追跡の要件

オペレーターは、ユーザーが報告する問題の詳細を記録して報告できる別のシステムを使用して、多くの場合、問題の追跡を実行します。 これらの詳細には、ユーザーが実行しようとしたタスク、問題の症状、イベントのシーケンス、および発行されたエラーまたは警告メッセージが含まれます。

データ ソース、インストルメンテーション、およびデータ収集の要件

問題追跡データの初期データ ソースは、最初に問題を報告したユーザーです。 ユーザーは、次のような追加データを提供できる場合があります。

• クラッシュ ダンプ (アプリケーションにユーザーのデスクトップで実行されるコンポーネントが含まれている場合)。
• 画面スナップショット。
• エラーが発生した日時と、ユーザーの場所などのその他の環境情報。

この情報は、デバッグ作業を支援し、ソフトウェアの将来のリリース用のバックログを構築するのに役立ちます。

問題追跡データの分析

異なるユーザーが同じ問題を報告する場合があります。 問題追跡システムでは、一般的なレポートを関連付ける必要があります。

デバッグ作業の進行状況は、各問題レポートに対して記録する必要があります。 問題が解決されると、顧客にソリューションを通知できます。

問題追跡システムで既知の解決策を持つ問題をユーザーが報告した場合、オペレーターはソリューションをすぐにユーザーに通知できる必要があります。

操作のトレースとソフトウェア リリースのデバッグ

ユーザーが問題を報告すると、多くの場合、ユーザーは自分の操作に対する即時の影響のみを認識します。 ユーザーは、独自のエクスペリエンスの結果のみを、システムの保守を担当するオペレーターに報告できます。 通常、これらのエクスペリエンスは、1 つ以上の基本的な問題の目に見える症状にすぎません。 多くの場合、アナリストは、問題の根本原因を確立するために、基になる操作の時系列を調べる必要があります。 このプロセスは 根本原因分析と呼ばれます。

注

根本原因分析は、アプリケーションの設計の非効率性を明らかにする可能性があります。 このような状況では、影響を受ける要素を再作業し、後続のリリースの一部として展開できる場合があります。 このプロセスには慎重な制御が必要であり、更新されたコンポーネントは注意深く監視する必要があります。

トレースとデバッグの要件

予期しないイベントやその他の問題をトレースするには、監視データが十分な情報を提供して、アナリストがこれらの問題の発生元までトレースし、発生した一連のイベントを再構築できるようにすることが重要です。 この情報は、アナリストが問題の根本原因を診断できるようにするために十分である必要があります。 その後、開発者は必要な変更を加えて、定期的な作業を防ぐことができます。

データ ソース、インストルメンテーション、およびデータ収集の要件

トラブルシューティングでは、操作の一部として呼び出されるすべてのメソッド (およびそのパラメーター) をトレースして、顧客が特定の要求を行ったときにシステムを介した論理フローを示すツリーを構築する必要があります。 このフローの結果としてシステムによって生成される例外と警告をキャプチャしてログに記録する必要があります。

デバッグをサポートするために、システムは、オペレーターがシステム内の重要なポイントで状態情報をキャプチャできるようにするフックを提供できます。 または、選択した操作の進行状況に応じて、詳細なステップ バイ ステップ情報を提供できます。 この詳細レベルでデータをキャプチャすると、システムに追加の負荷が発生する可能性があり、一時的なプロセスである必要があります。 オペレーターは主に、非常に異常な一連のイベントが発生してレプリケートが困難な場合、または 1 つ以上の要素をシステムに新しくリリースするときに、要素が期待どおりに機能することを確認するために注意深く監視する必要がある場合に、このプロセスを使用します。

監視と診断のパイプライン

大規模な分散システムの監視は、大きな課題です。 前のセクションで説明した各シナリオは、必ずしも単独で考慮する必要はありません。 状況ごとに必要な監視データと診断データに大きな重複がある可能性がありますが、このデータはさまざまな方法で処理および提示する必要があります。 これらの理由から、監視と診断の全体像を把握する必要があります。

図 1 に示すステージを構成するパイプラインとして、監視と診断のプロセス全体を想定できます。

図 1 - 監視と診断パイプラインのステージ。

図 1 は、監視と診断のためのデータがさまざまなデータ ソースから取得される方法を示しています。 インストルメンテーションと収集の段階では、データをキャプチャする必要があるソースの特定、キャプチャするデータの決定、キャプチャ方法、およびデータを簡単に調べることができるように書式設定する方法が関係します。 分析/診断ステージは生データを取得し、それを使用して、オペレーターがシステムの状態を判断するために使用できる意味のある情報を生成します。 オペレーターは、この情報を使用して、実行できるアクションに関する決定を行い、結果をインストルメンテーションとコレクションのステージに戻すことができます。 視覚化/アラート ステージ フェーズでは、システム状態の消耗品ビューが表示されます。 一連のダッシュボードを使用して、ほぼリアルタイムで情報を表示できます。 また、レポート、グラフ、グラフを生成して、長期的な傾向を特定するのに役立つデータの履歴ビューを提供できます。 KPI が許容範囲を超える可能性が高いと情報が示されている場合、このステージではオペレーターにアラートをトリガーすることもできます。 場合によっては、アラートを使用して、自動スケールなどの是正措置を実行しようとする自動化されたプロセスをトリガーすることもできます。

これらの手順は、ステージが並行して発生する連続フロー プロセスを構成します。 理想的には、すべてのフェーズを動的に構成する必要があります。 特にシステムが新しくデプロイされた場合や問題が発生している場合は、より頻繁に拡張データを収集することが必要になる場合があります。 それ以外の場合は、基本レベルの重要な情報のキャプチャに戻して、システムが正常に機能していることを確認できます。

さらに、監視プロセス全体は、フィードバックの結果として微調整と改善の対象となる、ライブで継続的なソリューションと見なす必要があります。 たとえば、多くの要因を測定してシステムの正常性を判断し始める場合があります。 時間の経過に伴う分析は、関連性のないメジャーを破棄すると絞り込みにつながる可能性があります。これにより、バックグラウンド ノイズを最小限に抑えながら、必要なデータをより正確に絞り込める可能性があります。

監視と診断データのソース

図 1 に示すように、監視プロセスで使用される情報は、いくつかのソースから取得できます。 アプリケーション レベルでは、情報はシステムのコードに組み込まれたトレース ログから取得されます。 開発者は、コードを通じて制御のフローを追跡するための標準的なアプローチに従う必要があります。 たとえば、メソッドへのエントリは、メソッドの名前、現在の時刻、各パラメーターの値、およびその他の関連情報を指定するトレース メッセージを出力できます。 入退室時間の記録も役立ちます。

すべての例外と警告をログに記録し、入れ子になった例外と警告の完全なトレースを保持する必要があります。 理想的には、コードを実行しているユーザーを識別する情報とアクティビティの関連付け情報 (システムを通過する要求を追跡するため) もキャプチャする必要があります。 また、メッセージ キュー、データベース、ファイル、その他の依存サービスなど、すべてのリソースへのアクセス試行をログに記録する必要があります。 この情報は、測定と監査の目的で使用できます。

多くのアプリケーションでは、ライブラリとフレームワークを使用して、データ ストアへのアクセスやネットワーク経由の通信などの一般的なタスクを実行します。 これらのフレームワークは、独自のトレース メッセージと未加工の診断情報 (トランザクションレート、データ転送の成功や失敗など) を提供するように構成できます。

注

多くの最新のフレームワークでは、パフォーマンス イベントとトレース イベントが自動的に発行されます。 この情報をキャプチャすることは、処理および分析できる場所で取得して格納する手段を提供するだけの問題です。

アプリケーションが実行されているオペレーティング システムは、I/O レート、メモリ使用率、CPU 使用率を示すパフォーマンス カウンターなど、システム全体の低レベルの情報のソースになる可能性があります。 オペレーティング システム エラー (ファイルを正しく開けませんでした) も報告される場合があります。

また、システムが実行される基になるインフラストラクチャとコンポーネントも考慮する必要があります。 仮想マシン、仮想ネットワーク、ストレージ サービスはすべて、重要なインフラストラクチャ レベルのパフォーマンス カウンターやその他の診断データのソースになります。

アプリケーションで Web サーバーやデータベース管理システムなどの他の外部サービスを使用している場合、これらのサービスは独自のトレース情報、ログ、パフォーマンス カウンターを発行する可能性があります。 たとえば、SQL Server データベースに対して実行された操作を追跡するための SQL Server 動的管理ビューや、Web サーバーに対して行われた要求を記録するための IIS トレース ログなどがあります。

システムのコンポーネントが変更され、新しいバージョンがデプロイされるため、問題、イベント、メトリックを各バージョンに属性付けできることが重要です。 この情報は、特定のバージョンのコンポーネントに関する問題をすばやく追跡して修正できるように、リリース パイプラインに関連付ける必要があります。

セキュリティの問題は、システム内の任意の時点で発生する可能性があります。 たとえば、ユーザーが無効なユーザー ID またはパスワードを使用してサインインを試みる場合があります。 認証されたユーザーは、リソースへの承認されていないアクセスを取得しようとする可能性があります。 または、ユーザーが、暗号化された情報にアクセスするために無効なキーまたは古いキーを提供する場合があります。 成功した要求と失敗した要求のセキュリティ関連の情報は、常にログに記録する必要があります。

アプリケーションのインストルメント化のセクションには、キャプチャする必要がある情報に関するガイダンスが含まれています。 ただし、さまざまな戦略を使用して、この情報を収集できます。

• アプリケーション/システムの監視。 この戦略では、アプリケーション、アプリケーション フレームワーク、オペレーティング システム、インフラストラクチャ内の内部ソースを使用します。 アプリケーション コードは、クライアント要求のライフサイクル中に注目すべきポイントで独自の監視データを生成できます。 アプリケーションには、状況に応じて選択的に有効または無効になる可能性があるトレース ステートメントを含めることができます。 診断フレームワークを使用して、診断を動的に挿入することもできます。 通常、これらのフレームワークには、コード内のさまざまなインストルメンテーション ポイントにアタッチし、これらのポイントでトレース データをキャプチャできるプラグインが用意されています。

  さらに、コードまたは基になるインフラストラクチャによって、重要なポイントでイベントが発生する可能性があります。 これらのイベントをリッスンするように構成されている監視エージェントは、イベント情報を記録できます。

• 実際のユーザー監視。 この方法では、ユーザーとアプリケーションの間の相互作用を記録し、各要求と応答のフローを観察します。 この情報は、2 つの目的を持つことができます。これは、各ユーザーによる使用状況の測定に使用できます。また、ユーザーが適切なサービス品質を受け取っているかどうかを判断するために使用できます (たとえば、応答時間の短縮、待機時間の短縮、最小限のエラーなど)。 キャプチャされたデータを使用して、障害が最も頻繁に発生する問題の領域を特定できます。 また、データを使用して、アプリケーションのホットスポットやその他の形式のボトルネックが原因でシステムの速度が低下する要素を特定することもできます。 この方法を慎重に実装すると、デバッグとテストの目的でアプリケーションを通じてユーザーのフローを再構築できる可能性があります。

  重要

  機密資料が含まれる可能性があるため、実際のユーザーを監視することによってキャプチャされるデータは機密性が高いと考える必要があります。 キャプチャしたデータを保存する場合は、安全に保存します。 パフォーマンスの監視またはデバッグの目的でデータを使用する場合は、まずすべての個人データを取り除きます。

• 代理ユーザーの監視。 この方法では、ユーザーをシミュレートし、構成可能だが一般的な一連の操作を実行する独自のテスト クライアントを作成します。 テスト クライアントのパフォーマンスを追跡して、システムの状態を判断できます。 また、ロード テスト操作の一環として、テスト クライアントの複数のインスタンスを使用して、システムがストレス下でどのように応答するか、およびこれらの条件下で生成される監視出力の種類を確立することもできます。

  注

  メソッド呼び出しやその他のアプリケーションの重要な部分の実行をトレースして時間を記録するコードを含めることで、実際のユーザー監視と合成ユーザー監視を実装できます。

• プロファイリング。 このアプローチは、主にアプリケーションのパフォーマンスの監視と向上を目的とします。 実際のユーザー監視と合成ユーザー監視の機能レベルで動作するのではなく、アプリケーションの実行時に下位レベルの情報をキャプチャします。 プロファイリングを実装するには、アプリケーションの実行状態の定期的なサンプリングを使用します (特定の時点でアプリケーションが実行されているコードの部分を決定します)。 また、重要なタイミング (メソッド呼び出しの開始と終了など) にプローブをコードに挿入し、呼び出されたメソッド、呼び出しの時間、各呼び出しにかかった時間を記録するインストルメンテーションを使用することもできます。 その後、このデータを分析して、アプリケーションのどの部分がパフォーマンスの問題を引き起こす可能性があるかを判断できます。

• エンドポイントの監視。 この手法では、監視を有効にするためにアプリケーションが公開する 1 つ以上の診断エンドポイントを使用します。 エンドポイントは、アプリケーション コードへの経路を提供し、システムの正常性に関する情報を返すことができます。 異なるエンドポイントは、機能のさまざまな側面に集中できます。 これらのエンドポイントに定期的な要求を送信し、応答を同化する独自の診断クライアントを作成できます。 詳細については、「 正常性エンドポイントの監視パターン」を参照してください。

カバレッジを最大限に高める場合は、これらの手法を組み合わせて使用する必要があります。

アプリケーションのインストルメント化

インストルメンテーションは、監視プロセスの重要な部分です。 システムのパフォーマンスと正常性に関して意味のある決定を行うことができるのは、これらの決定を行うことができるデータを最初にキャプチャする場合のみです。 インストルメンテーションを使用して収集する情報は、リモート運用サーバーにサインインしてトレース (およびデバッグ) を手動で実行しなくても、パフォーマンスの評価、問題の診断、意思決定を行うために十分である必要があります。 インストルメンテーション データは、通常、トレース ログに書き込まれるメトリックと情報で構成されます。

トレース ログの内容は、アプリケーションによって書き込まれたテキスト データの結果、またはアプリケーションが Windows イベント トレーシング (ETW) を使用している場合、トレース イベントの結果として作成されるバイナリ データです。 また、Web サーバーなどのインフラストラクチャの一部から発生したイベントを記録するシステム ログから生成することもできます。 多くの場合、テキスト ログ メッセージは人間が判読できるように設計されていますが、自動システムで簡単に解析できる形式で記述する必要もあります。

ログも分類する必要があります。 すべてのトレース データを 1 つのログに書き込むのではなく、個別のログを使用して、システムのさまざまな運用面からのトレース出力を記録します。 その後、1 つの長いファイルを処理する必要なく、適切なログから読み取ることで、ログ メッセージをすばやくフィルター処理できます。 異なるセキュリティ要件 (監査情報やデバッグ データなど) を持つ情報を同じログに書き込むことはありません。

注

ログはファイル システム上のファイルとして実装されるか、BLOB ストレージ内の BLOB などの他の形式で保持される場合があります。 ログ情報は、テーブル内の行など、より構造化されたストレージにも保持される場合があります。

メトリックは通常、特定の時点におけるシステム内の一部の側面またはリソースのメジャーまたはカウントで、1 つ以上のタグまたはディメンション ( サンプルと呼ばれることもあります) が関連付けられます。 メトリックの 1 つのインスタンスは、通常、単独では役に立ちません。 代わりに、時間の経過と同時にメトリックをキャプチャする必要があります。 考慮すべき重要な問題は、記録するメトリックと頻度です。 メトリックのデータを生成する頻度が高すぎると、システムに大きな負荷がかかる可能性があります。一方、メトリックをキャプチャする頻度が低いと、重大なイベントにつながる状況を見逃す可能性があります。 考慮事項は、メトリックによって異なります。 たとえば、サーバー上の CPU 使用率は 2 番目から 2 番目に大きく異なる場合がありますが、使用率が高い場合は、数分にわたって有効期間が長い場合にのみ問題になります。

データの関連付けに関する情報

個々のシステム レベルのパフォーマンス カウンターを簡単に監視し、リソースのメトリックをキャプチャし、さまざまなログ ファイルからアプリケーション トレース情報を取得できます。 ただし、一部の形式の監視では、複数のソースから取得されたデータを関連付けるために、監視パイプラインの分析と診断の段階が必要です。 このデータは生データに複数の形式を取る場合があり、分析プロセスには、これらの異なる形式をマップできる十分なインストルメンテーション データを提供する必要があります。 たとえば、アプリケーション フレームワーク レベルでは、タスクはスレッド ID によって識別される場合があります。 アプリケーション内では、同じ作業が、そのタスクを実行しているユーザーのユーザー ID に関連付けられている可能性があります。

また、非同期操作では同じスレッドを再利用して複数のユーザーに代わって操作を実行する可能性があるため、スレッドとユーザー要求の間に 1 対 1 のマッピングを行う可能性はほとんどありません。 さらに複雑にするために、実行がシステムを通過するにつれて、1 つの要求が複数のスレッドによって処理される場合があります。 可能であれば、各要求を、要求コンテキストの一部としてシステム経由で伝達される一意のアクティビティ ID に関連付けます。 (トレース情報にアクティビティ ID を生成して含める手法は、トレース データのキャプチャに使用されるテクノロジによって異なります)。

すべての監視データは、同じ方法でタイムスタンプを付ける必要があります。 一貫性を保つには、協定世界時を使用して、すべての日付と時刻を記録します。 これは、イベントのシーケンスをより簡単にトレースするのに役立ちます。

注

異なるタイム ゾーンとネットワークで動作しているコンピューターが同期されない場合があります。 複数のマシンにまたがるインストルメンテーション データを関連付けするためにタイムスタンプのみを使用することに依存しないでください。

インストルメンテーション データに含める情報

収集する必要があるインストルメンテーション データを決定するときは、次の点を考慮してください。

• トレース イベントによってキャプチャされた情報がマシンであり、人間が判読できることを確認します。 この情報に対して明確に定義されたスキーマを採用して、システム間でのログ データの自動処理を容易にし、ログを読む運用およびエンジニアリング スタッフに一貫性を提供します。 デプロイ環境、プロセスが実行されているマシン、プロセスの詳細、呼び出し履歴などの環境情報を含めます。

• プロファイリングは、システムに大きなオーバーヘッドが発生する可能性があるため、必要な場合にのみ有効にします。 インストルメンテーションを使用したプロファイリングでは、発生するたびにイベント (メソッド呼び出しなど) が記録されますが、サンプリングでは選択したイベントのみが記録されます。 選択できるのは、時間ベース ( n 秒ごとに 1 回) または頻度ベース ( n 個の要求ごとに 1 回) です。 イベントが非常に頻繁に発生する場合、インストルメンテーションによるプロファイリングによって負担が大きくなりすぎて、それ自体が全体的なパフォーマンスに影響を与える可能性があります。 この場合、サンプリングアプローチが望ましい場合があります。 ただし、イベントの頻度が低い場合は、サンプリングによって見落とされる可能性があります。 この場合、インストルメンテーションの方が適している可能性があります。

• 開発者または管理者が各要求のソースを特定できるようにするための十分なコンテキストを提供します。 これには、要求の特定のインスタンスを識別する何らかの形式のアクティビティ ID が含まれる場合があります。 また、このアクティビティを実行された計算作業と使用されるリソースと関連付けるために使用できる情報も含まれる場合があります。 この作業は、プロセスとマシンの境界を越える可能性があることに注意してください。 測定の場合、コンテキストには、要求を行う原因となった顧客への参照 (直接または他の相関情報を介して間接的に) も含める必要があります。 このコンテキストは、監視データがキャプチャされたときのアプリケーションの状態に関する重要な情報を提供します。

• すべての要求と、これらの要求の作成元となる場所またはリージョンを記録します。 この情報は、場所固有のホットスポットがあるかどうかを判断する際に役立つ場合があります。 この情報は、アプリケーションを再パーティション分割するか、使用するデータを再パーティション分割するかを決定する際にも役立ちます。

• 例外の詳細を注意深く記録してキャプチャします。 多くの場合、重要なデバッグ情報は、例外処理が不十分な結果として失われます。 内部例外やその他のコンテキスト情報など、アプリケーションがスローする例外の完全な詳細をキャプチャします。 可能であれば、呼び出し履歴を含めます。

• これは、イベントの分析やユーザー要求との関連付けに役立つ可能性があるため、アプリケーションのさまざまな要素がキャプチャするデータの一貫性を保つ必要があります。 開発者がシステムのさまざまな部分を実装するのと同じアプローチを採用するかどうかに応じてではなく、包括的で構成可能なログ パッケージを使用して情報を収集することを検討してください。 実行されている I/O のボリューム、ネットワーク使用率、要求の数、メモリ使用量、CPU 使用率など、主要なパフォーマンス カウンターからデータを収集します。 一部のインフラストラクチャ サービスでは、データベースへの接続数、トランザクションの実行速度、成功または失敗したトランザクションの数など、独自のパフォーマンス カウンターが提供される場合があります。 アプリケーションでは、独自のパフォーマンス カウンターを定義することもできます。

• データベース システム、Web サービス、インフラストラクチャの一部である他のシステム レベルのサービスなど、外部サービスに対して行われたすべての呼び出しをログに記録します。 各呼び出しの実行にかかった時間と、呼び出しの成功または失敗に関する情報を記録します。 可能であれば、発生した一時的なエラーに対するすべての再試行と失敗に関する情報をキャプチャします。

テレメトリ システムとの互換性の確保

多くの場合、インストルメンテーションによって生成される情報は一連のイベントとして生成され、処理と分析のために別のテレメトリ システムに渡されます。 テレメトリ システムは通常、特定のアプリケーションやテクノロジに依存しませんが、情報は通常スキーマによって定義される特定の形式に従うことを想定しています。 このスキーマは、テレメトリ システムが取り込むことができるデータ フィールドと型を定義するコントラクトを効果的に指定します。 スキーマは、さまざまなプラットフォームやデバイスからデータを受信できるように一般化する必要があります。

共通スキーマには、イベント名、イベント時刻、送信者の IP アドレス、他のイベント (ユーザー ID、デバイス ID、アプリケーション ID など) との関連付けに必要な詳細など、すべてのインストルメンテーション イベントに共通するフィールドを含める必要があります。 任意の数のデバイスでイベントが発生する可能性があるため、スキーマはデバイスの種類に依存しないように注意してください。 さらに、さまざまなデバイスが同じアプリケーションのイベントを発生させる可能性があります。アプリケーションは、ローミングまたはその他の形式のクロスデバイス分散をサポートしている可能性があります。

スキーマには、異なるアプリケーション間で一般的な特定のシナリオに関連するドメイン フィールドも含まれる場合があります。 これは、例外、アプリケーションの開始イベントと終了イベント、および Web サービス API 呼び出しの成功または失敗に関する情報である可能性があります。 同じドメイン フィールドのセットを使用するすべてのアプリケーションは、同じ一連のイベントを出力し、一連の一般的なレポートと分析を構築できるようにする必要があります。

最後に、スキーマには、アプリケーション固有のイベントの詳細をキャプチャするためのカスタム フィールドが含まれている場合があります。

アプリケーションのインストルメント化のベスト プラクティス

次の一覧は、クラウドで実行されている分散アプリケーションをインストルメント化するためのベスト プラクティスをまとめたものです。

• ログを読みやすく、簡単に解析できるようにします。 可能な場合は、構造化ログを使用します。 ログ メッセージでは簡潔でわかりやすいものにします。

• すべてのログで、ソースを識別し、各ログ レコードが書き込まれるとき、コンテキストとタイミングの情報を提供します。

• すべてのタイムスタンプに同じタイム ゾーンと形式を使用します。 これは、異なる地理的リージョンで実行されているハードウェアとサービスにまたがる操作のイベントを関連付けるのに役立ちます。

• ログを分類し、適切なログ ファイルにメッセージを書き込みます。

• システムに関する機密情報やユーザーに関する個人情報を開示しないでください。 ログに記録される前にこの情報をスクラブしますが、関連する詳細が保持されていることを確認してください。 たとえば、データベース接続文字列から ID とパスワードを削除しますが、残りの情報をログに書き込んで、システムが正しいデータベースにアクセスしていることをアナリストが判断できるようにします。 すべての重大な例外をログに記録しますが、管理者はログ記録のオンとオフを切り替えて、より低いレベルの例外と警告を有効にします。 また、すべての再試行ロジック情報をキャプチャしてログに記録します。 このデータは、システムの一時的な正常性を監視する場合に役立ちます。

• 外部 Web サービスやデータベースへの要求など、プロセス外の呼び出しをトレースします。

• 同じログ ファイルに、異なるセキュリティ要件を持つログ メッセージを混在させる必要はありません。 たとえば、デバッグと監査の情報を同じログに書き込まないとします。

• 監査イベントを除き、すべてのログ記録呼び出しが、ビジネス操作の進行状況をブロックしないファイア アンド フォーゲット操作であることを確認します。 監査イベントは、ビジネスにとって重要であり、ビジネス運用の基本的な部分として分類できるため、例外的です。

• ログ記録が拡張可能であり、具体的なターゲットへの直接的な依存関係がないことを確認します。 たとえば、 System.Diagnostics.Trace を使用して情報を書き込むのではなく、ログ 記録メソッドを公開し、任意の適切な方法で実装できる抽象インターフェイス ( ILogger など) を定義します。

• すべてのログ記録がフェールセーフであり、連鎖エラーがトリガーされないようにしてください。 ログは例外をスローしてはなりません。

• インストルメンテーションを継続的な反復プロセスとして扱い、問題が発生した場合だけでなく、ログを定期的に確認します。

データの収集と格納

監視プロセスの収集ステージでは、インストルメンテーションによって生成される情報の取得、分析/診断ステージでの使用が容易になるようにこのデータを書式設定し、変換されたデータを信頼性の高いストレージに保存することが関係しています。 分散システムのさまざまな部分から収集するインストルメンテーション データは、さまざまな場所とさまざまな形式で保持できます。 たとえば、アプリケーション コードによってトレース ログ ファイルが生成され、アプリケーション イベント ログ データが生成されるのに対し、アプリケーションで使用されるインフラストラクチャの主要な側面を監視するパフォーマンス カウンターは、他のテクノロジを使用してキャプチャできます。 アプリケーションが使用するサードパーティ製のコンポーネントとサービスは、個別のトレース ファイル、BLOB ストレージ、またはカスタム データ ストアを使用して、さまざまな形式でインストルメンテーション情報を提供する場合があります。

多くの場合、データ収集は、インストルメンテーション データを生成するアプリケーションから自律的に実行できるコレクション サービスを介して実行されます。 図 2 は、インストルメンテーション データ収集サブシステムを強調するこのアーキテクチャの例を示しています。

図 2 - インストルメンテーション データの収集。

これは簡略化されたビューであることに注意してください。 コレクション サービスは必ずしも 1 つのプロセスではなく、次のセクションで説明するように、異なるマシンで実行される多くの構成要素で構成される場合があります。 さらに、一部のテレメトリ データの分析を迅速に実行する必要がある場合 (このドキュメントの後半の「 ホット、ウォーム、コールド分析のサポート 」セクションで説明されているように、ホット分析)、コレクション サービスの外部で動作するローカル コンポーネントは、すぐに分析タスクを実行する可能性があります。 図 2 は、選択したイベントに対するこの状況を示しています。 分析処理の後、結果を視覚化およびアラート サブシステムに直接送信できます。 ウォーム分析またはコールド分析の対象となるデータは、処理を待機している間、ストレージに保持されます。

Azure アプリケーションとサービスの場合、Azure Diagnostics には、データをキャプチャするための 1 つの可能なソリューションが用意されています。 Azure Diagnostics は、コンピューティング ノードごとに次のソースからデータを収集し、集計して Azure Storage にアップロードします。

• IIS ログ
• IIS の失敗した要求ログ
• Windows イベント ログ
• 性能カウンター
• クラッシュ ダンプ
• Azure Diagnostics インフラストラクチャ ログ
• カスタム エラー ログ
• .NET EventSource
• マニフェスト ベースの ETW

詳細については、 Azure: テレメトリの基本とトラブルシューティングに関する記事を参照してください。

インストルメンテーション データを収集するための戦略

クラウドのエラスティックな性質を考慮し、システム内のすべてのノードからテレメトリ データを手動で取得する必要を回避するには、データを中央の場所に転送して統合するように手配する必要があります。 複数のデータセンターにまたがるシステムでは、最初にリージョンごとにデータを収集、統合、格納してから、リージョン データを 1 つの中央システムに集約すると便利な場合があります。

帯域幅の使用を最適化するために、バッチとして、より緊急度の低いデータをチャンクで転送することを選択できます。 ただし、特に時間に依存する情報が含まれている場合は、データを無期限に遅延してはなりません。

インストルメンテーション データのプルとプッシュ

インストルメンテーション データ収集サブシステムは、アプリケーションの各インスタンス ( プル モデル) のさまざまなログやその他のソースからインストルメンテーション データをアクティブに取得できます。 または、アプリケーションの各インスタンス ( プッシュ モデル) を構成するコンポーネントからデータが送信されるのを待機するパッシブ レシーバーとして機能することもできます。

プル モデルを実装する方法の 1 つは、アプリケーションの各インスタンスでローカルに実行される監視エージェントを使用することです。 監視エージェントは、ローカル ノードで収集されたテレメトリ データを定期的に取得 (プル) し、アプリケーションのすべてのインスタンスが共有する集中型ストレージに直接この情報を書き込む別のプロセスです。 これは、Azure Diagnostics が実装するメカニズムです。 Azure Web ロールまたは worker ロールの各インスタンスは、ローカルに格納されている診断およびその他のトレース情報をキャプチャするように構成できます。 各インスタンスと共に実行される監視エージェントは、指定されたデータを Azure Storage にコピーします。 このプロセスの詳細については、 Azure Cloud Services と Virtual Machines での診断の有効化 に関する記事を参照してください。 IIS ログ、クラッシュ ダンプ、カスタム エラー ログなどの一部の要素は、BLOB ストレージに書き込まれます。 Windows イベント ログ、ETW イベント、およびパフォーマンス カウンターからのデータは、テーブル ストレージに記録されます。 図 3 は、このメカニズムを示しています。

図 3 - 監視エージェントを使用して情報をプルし、共有ストレージに書き込む。

注

監視エージェントの使用は、データ ソースから自然にプルされるインストルメンテーション データのキャプチャに最適です。 たとえば、SQL Server 動的管理ビューからの情報や、Azure Service Bus キューの長さなどです。

前述の方法を使用して、限られた数のノードで実行されている小規模なアプリケーションのテレメトリ データを 1 つの場所に格納できます。 ただし、複雑で拡張性の高いグローバル クラウド アプリケーションでは、何百もの Web ロールと worker ロール、データベース シャード、その他のサービスから大量のデータが生成される可能性があります。 この大量のデータは、1 つの中央の場所で利用できる I/O 帯域幅を簡単に上回る可能性があります。 そのため、テレメトリ ソリューションは、システムの拡張に合わせてボトルネックとして機能しないようにスケーラブルである必要があります。 システムの一部が失敗した場合に、重要な監視情報 (監査や課金データなど) を失うリスクを軽減するために、ソリューションに冗長性の程度を組み込むのが理想的です。

これらの問題に対処するために、図 4 に示すように、キューを実装できます。 このアーキテクチャでは、ローカル監視エージェント (適切に構成できる場合) またはカスタム データ収集サービス (そうでない場合) は、データをキューにポストします。 非同期的に実行されている別のプロセス (図 4 のストレージ書き込みサービス) は、このキュー内のデータを受け取り、共有ストレージに書き込みます。 メッセージ キューは、ポスト後にキューに格納されたデータが失われないようにするのに役立つ "少なくとも 1 回" のセマンティクスを提供するため、このシナリオに適しています。 ストレージ書き込みサービスは、別の worker ロールを使用して実装できます。

図 4 - キューを使用してインストルメンテーション データをバッファー処理する。

ローカル データ収集サービスは、受信した直後にキューにデータを追加できます。 キューはバッファーとして機能し、ストレージ書き込みサービスは独自のペースでデータを取得および書き込むことができます。 既定では、キューは先入れ先出しで動作します。 ただし、より迅速に処理する必要があるデータがメッセージに含まれている場合は、メッセージに優先順位を付けてキューを介してメッセージを高速化できます。 詳細については、「 優先順位キューパターン」を参照してください。 または、必要な分析処理の形式に応じて、異なるチャネル (Service Bus トピックなど) を使用してデータをさまざまな宛先に転送することもできます。

スケーラビリティのために、ストレージ書き込みサービスの複数のインスタンスを実行できます。 大量のイベントがある場合は、イベント ハブを使用して、処理とストレージのために異なるコンピューティング リソースにデータをディスパッチできます。

インストルメンテーション データの統合

データ収集サービスがアプリケーションの 1 つのインスタンスから取得するインストルメンテーション データにより、そのインスタンスの正常性とパフォーマンスがローカライズされたビューに表示されます。 システムの全体的な正常性を評価するには、ローカル ビューでデータのいくつかの側面を統合する必要があります。 これは、データが格納された後で実行できますが、場合によっては、データの収集時に実現することもできます。 インストルメンテーション データは、共有ストレージに直接書き込まれるのではなく、データを結合し、フィルターおよびクリーンアップ プロセスとして機能する個別のデータ統合サービスを通過できます。 たとえば、アクティビティ ID など、同じ相関関係情報を含むインストルメンテーション データを組み合わせることができます。 (ユーザーが 1 つのノードでビジネス操作の実行を開始した後、ノード障害が発生した場合、または負荷分散の構成方法に応じて別のノードに転送される可能性があります)。このプロセスでは、重複したデータを検出して削除することもできます (テレメトリ サービスがメッセージ キューを使用してインストルメンテーション データをストレージにプッシュする場合は常に発生する可能性があります)。 図 5 は、この構造の例を示しています。

図 5 - 別のサービスを使用してインストルメンテーション データを統合およびクリーンアップする。

インストルメンテーション データの格納

前の説明では、インストルメンテーション データを格納する方法のかなり単純なビューを示しました。 実際には、各型の使用方法に最も適したテクノロジを使用して、さまざまな種類の情報を格納することが理にかなっています。

たとえば、Azure BLOB とテーブル ストレージには、アクセス方法にいくつかの類似点があります。 ただし、それらの操作を使用して実行できる操作には制限があり、保持するデータの細分性はまったく異なります。 より多くの分析操作を実行する必要がある場合や、データに対してフルテキスト検索機能が必要な場合は、特定の種類のクエリとデータ アクセス用に最適化された機能を提供するデータ ストレージを使用する方が適切な場合があります。 例えば次が挙げられます。

• パフォーマンス カウンター データを SQL データベースに格納して、アドホック分析を有効にすることができます。
• トレース ログは、Azure Cosmos DB に格納することをお勧めします。
• セキュリティ情報は HDFS に書き込むことができます。
• フルテキスト検索を必要とする情報は、Elasticsearch を使用して格納できます (豊富なインデックス作成を使用して検索を高速化することもできます)。

図 6 に示すように、共有ストレージからデータを定期的に取得し、その目的に従ってデータをパーティション分割してフィルター処理し、適切なデータ ストアセットに書き込む追加のサービスを実装できます。 別の方法として、統合とクリーンアップのプロセスにこの機能を含め、中間共有記憶域に保存するのではなく、取得したデータをこれらのストアに直接書き込みます。 各アプローチには長所と短所があります。 個別のパーティション分割サービスを実装すると、統合およびクリーンアップ サービスの負荷が軽減され、必要に応じて (共有ストレージに保持されるデータの量に応じて) 少なくとも一部のパーティション分割データを再生成できます。 ただし、追加のリソースが消費されます。 また、各アプリケーション インスタンスからインストルメンテーション データを受信してから、このデータを実用的な情報に変換するまでに遅延が発生する可能性があります。

図 6 - 分析とストレージの要件に従ったデータのパーティション分割。

複数の目的で同じインストルメンテーション データが必要になる場合があります。 たとえば、パフォーマンス カウンターを使用して、時間の経過に伴うシステム パフォーマンスの履歴ビューを提供できます。 この情報を他の使用状況データと組み合わせて、顧客の課金情報を生成する場合があります。 このような状況では、同じデータが複数の宛先に送信される場合があります。たとえば、課金情報を保持するための長期的なストアとして機能するドキュメント データベースや、複雑なパフォーマンス分析を処理するための多次元ストアなどです。

また、データが必要な緊急性も考慮する必要があります。 アラートに関する情報を提供するデータにすばやくアクセスする必要があるため、アラート システムが実行するクエリを最適化するために、高速データ ストレージに保持し、インデックスを作成または構造化する必要があります。 場合によっては、各ノード上のデータを収集するテレメトリ サービスが、アラート システムのローカル インスタンスが問題を迅速に通知できるように、データの書式設定と保存をローカルで行う必要がある場合があります。 前の図に示したストレージ書き込みサービスに同じデータをディスパッチし、他の目的にも必要な場合は一元的に格納できます。

より考慮された分析、レポート、履歴の傾向を特定するために使用される情報は、緊急性が低く、データ マイニングとアドホック クエリをサポートする方法で格納できます。 詳細については、このドキュメントの後半の「 ホット、ウォーム、コールド解析のサポート 」セクションを参照してください。

ログローテーションとデータリテンション期間

インストルメンテーションでは、大量のデータを生成できます。 このデータは、生のログ ファイル、トレース ファイル、および各ノードでキャプチャされたその他の情報から、共有ストレージに保持されているこのデータの統合、クリーニング、パーティション分割されたビューまで、複数の場所に保持できます。 場合によっては、データが処理されて転送された後、元の生ソース データを各ノードから削除できます。 それ以外の場合は、生の情報を保存することが必要な場合や、単純に役立つ場合があります。 たとえば、デバッグ目的で生成されたデータは、生の形式で使用可能なままにするのが最適ですが、バグが修正された後すぐに破棄できます。

多くの場合、パフォーマンス データの寿命が長くなり、パフォーマンスの傾向を見つけ出したり、容量を計画したりするために使用できます。 このデータの統合ビューは、通常、高速アクセスを可能にするために、有限期間オンラインで保持されます。 その後、アーカイブまたは破棄できます。 測定と課金のために収集されたデータは、無期限に保存する必要がある場合があります。 さらに、監査とセキュリティの目的で収集された情報もアーカイブして保存する必要がある場合があります。 まが、このデータは機密性が高く、改ざんを防ぐために暗号化またはその他の方法で保護する必要がある場合もあります。 ユーザーのパスワードや、ID 詐欺を行うために使用される可能性のあるその他の情報を記録しないでください。 このような詳細は、格納する前にデータからスクラブする必要があります。

ダウン サンプリング

履歴データを格納すると、長期的な傾向を見つけることができます。 古いデータ全体を保存するのではなく、データをダウンサンプリングして解像度を下げ、ストレージ コストを節約できる場合があります。 たとえば、分単位の業績評価指標を保存するのではなく、1 か月以上前のデータを統合して時間単位のビューを形成できます。

ログ情報を収集して格納するためのベスト プラクティス

次の一覧は、ログ情報をキャプチャして格納するためのベスト プラクティスをまとめたものです。

• 監視エージェントまたはデータ収集サービスは、アウトプロセス サービスとして実行する必要があり、デプロイが簡単である必要があります。

• 監視エージェントまたはデータ収集サービスからの出力はすべて、コンピューター、オペレーティング システム、またはネットワーク プロトコルに依存しない形式にする必要があります。 たとえば、ETL/ETW ではなく、JSON、MessagePack、Protobuf などの自己記述形式で情報を出力します。 標準形式を使用すると、システムは処理パイプラインを構築できます。合意された形式でデータを読み取り、変換、および送信するコンポーネントを簡単に統合できます。

• 監視とデータ収集のプロセスは、フェールセーフである必要があり、連鎖エラー状態をトリガーしてはなりません。

• データ シンクに情報を送信するときに一時的な障害が発生した場合は、最新の情報が最初に送信されるように、テレメトリ データを並べ替えるために監視エージェントまたはデータ収集サービスを準備する必要があります。 (監視エージェント/データ収集サービスでは、独自の判断で、古いデータを削除するか、ローカルに保存して後で送信して追いつくことを選択する場合があります)。

データの分析と問題の診断

監視と診断プロセスの重要な部分は、収集されたデータを分析して、システムの全体的な幸福の画像を取得することです。 独自の KPI とパフォーマンス メトリックを定義する必要があり、分析要件を満たすために収集されたデータを構造化する方法を理解することが重要です。 また、さまざまなメトリックとログ ファイルにキャプチャされたデータがどのように関連付けられるかを理解することも重要です。これは、この情報が一連のイベントを追跡し、発生した問題の診断に役立つ鍵となる可能性があるためです。

インストルメンテーション データの統合に関するセクションで説明したように、通常、システムの各部分のデータはローカルにキャプチャされますが、通常はシステムに参加している他のサイトで生成されたデータと組み合わせる必要があります。 この情報を使用するには、データを正確に結合するために慎重な相関関係が必要です。 たとえば、操作の使用状況データは、ユーザーが接続する Web サイトをホストするノード、この操作の一部としてアクセスされる別のサービスを実行するノード、および別のノードに保持されているデータ ストレージにまたがる場合があります。 操作のリソースと処理の使用状況の全体像を提供するには、この情報を結び付ける必要があります。 データの一部の前処理とフィルター処理は、データがキャプチャされるノードで発生する可能性がありますが、集約と書式設定は中央ノードで発生する可能性が高くなります。

ホット、ウォーム、およびコールドの分析のサポート

視覚化、レポート、アラートの目的でデータを分析および再フォーマットすることは、独自のリソース セットを使用する複雑なプロセスになる可能性があります。 一部の形式の監視はタイム クリティカルであり、データの即時分析を有効にする必要があります。 これは ホット分析と呼ばれます。 たとえば、アラートに必要な分析や、セキュリティ監視の一部の側面 (システムへの攻撃の検出など) があります。 これらの目的に必要なデータは、効率的な処理のために迅速に利用でき、構造化されている必要があります。 場合によっては、データが保持されている個々のノードに分析処理を移動することが必要になる場合があります。

その他の形式の分析は、タイム クリティカルが少なく、生データを受信した後に何らかの計算と集計が必要になる場合があります。 これは ウォーム分析と呼ばれます。 パフォーマンス分析は、多くの場合、このカテゴリに分類されます。 この場合、分離された単一のパフォーマンス イベントが統計的に有意である可能性は低くなります。 (急激なスパイクやグリッチが原因である可能性があります)。一連のイベントからのデータは、システム パフォーマンスのより信頼性の高い画像を提供する必要があります。

ウォーム分析を使用して、正常性の問題を診断することもできます。 通常、正常性イベントはホット分析によって処理され、すぐにアラートを生成できます。 オペレーターは、ウォーム パスからのデータを調べることで、正常性イベントの理由を詳しく調べることができる必要があります。 このデータには、正常性イベントの原因となった問題に至るまでのイベントに関する情報が含まれている必要があります。

一部の種類の監視では、より長期的なデータが生成されます。 この分析は、事前に定義されたスケジュールに従って、後日実行できます。 場合によっては、分析で、一定期間にわたってキャプチャされた大量のデータの複雑なフィルター処理を実行することが必要になる場合があります。 これは コールド分析と呼ばれます。 重要な要件は、データがキャプチャされた後に安全に格納されるということです。 たとえば、使用状況の監視と監査では、通常の時点でのシステムの状態を正確に把握する必要がありますが、この状態情報を収集した直後に処理できる必要はありません。

オペレーターは、コールド分析を使用して、予測正常性分析用のデータを提供することもできます。 オペレーターは、指定した期間にわたって履歴情報を収集し、現在の正常性データ (ホット パスから取得) と組み合わせて使用して、間もなく正常性の問題を引き起こす可能性のある傾向を特定できます。 このような場合は、修正アクションを実行できるようにアラートを生成する必要があります。

データの関連付け

インストルメンテーションによってキャプチャされるデータは、システム状態のスナップショットを提供できますが、分析の目的は、このデータを実行可能にすることです。 例えば次が挙げられます。

• 特定の時刻にシステム レベルで I/O の読み込みが激しくなる原因は何ですか?
• 大量のデータベース操作の結果ですか?
• これは、データベースの応答時間、1 秒あたりのトランザクション数、およびアプリケーションの応答時間に同じタイミングで反映されますか?

その場合、負荷を軽減する修復アクションの 1 つは、より多くのサーバーにデータをシャード化することです。 さらに、システムの任意のレベルで障害が発生した結果、例外が発生する可能性があります。 1 つのレベルで例外が発生すると、多くの場合、上記のレベルで別のエラーがトリガーされます。

このような理由から、システムの状態とその上で実行されているアプリケーションの全体的なビューを生成するには、各レベルのさまざまな種類の監視データを関連付けることができる必要があります。 その後、この情報を使用して、システムが正常に機能しているかどうかに関する決定を行い、システムの品質を向上させるために何ができるかを決定できます。

「データを関連付ける情報」セクションで説明されているように、未加工のインストルメンテーション データに、イベントを関連付けるために必要な集計をサポートするための十分なコンテキストとアクティビティ ID 情報が含まれていることを確認する必要があります。 さらに、このデータは異なる形式で保持される場合があり、この情報を解析して、分析のために標準化された形式に変換することが必要になる場合があります。

問題のトラブルシューティングと診断

診断には、根本原因分析の実行など、障害の原因や予期しない動作を特定する機能が必要です。 通常、必要な情報には次のものが含まれます。

• イベント ログとトレースからの詳細情報(システム全体または指定された時間枠内の指定されたサブシステムに関する情報)。
• 指定した期間内にシステム内または指定されたサブシステム内で発生した、指定されたレベルの例外と障害に起因するスタック トレースを完了します。
• システム内の任意の場所、または指定した時間枠内の指定したサブシステムの失敗したプロセスのクラッシュ ダンプ。
• アクティビティ ログには、指定した期間中にすべてのユーザーまたは選択したユーザーが実行した操作が記録されます。

トラブルシューティングのためにデータを分析するには、多くの場合、システム アーキテクチャとソリューションを構成するさまざまなコンポーネントに関する深い技術的な理解が必要です。 その結果、多くの場合、データを解釈し、問題の原因を特定し、それらを修正するための適切な戦略を推奨するために、大量の手動介入が必要になります。 この情報のコピーを元の形式で保存し、専門家によるコールド分析に使用できるようにするのが適切な場合があります。

データの視覚化とアラートの生成

監視システムの重要な側面は、オペレーターが傾向や問題をすばやく特定できるような方法でデータを提示できることです。 また、重要なのは、注意が必要な重要なイベントが発生した場合にオペレーターに迅速に通知できることです。

データの表示には、ダッシュボード、アラート、レポートを使用した視覚化など、いくつかのフォームを使用できます。

ダッシュボードを使用した視覚化

データを視覚化する最も一般的な方法は、一連のグラフ、グラフ、またはその他の図として情報を表示できるダッシュボードを使用することです。 これらの項目はパラメーター化でき、アナリストは特定の状況で重要なパラメーター (期間など) を選択できる必要があります。

ダッシュボードは階層的に整理できます。 最上位レベルのダッシュボードでは、システムの各側面の全体像を確認できますが、オペレーターは詳細にドリルダウンできます。 たとえば、システムのディスク I/O 全体を示すダッシュボードでは、アナリストが個々のディスクの I/O レートを表示して、1 つまたは複数の特定のデバイスがトラフィックの不均衡なボリュームを占めるかどうかを確認できるようにする必要があります。 理想的には、ダッシュボードには、この I/O を生成している各要求のソース (ユーザーまたはアクティビティ) などの関連情報も表示する必要があります。 この情報を使用して、デバイス間でより均等に負荷を分散させるかどうか (および方法) と、デバイスが追加された場合にシステムのパフォーマンスが向上するかどうかを判断できます。

ダッシュボードでは、色分けやその他の視覚的な手掛かりを使用して、異常に見える値や予期される範囲外の値を示すこともできます。 前の例を使用します。

• 長期間にわたって最大容量に近づいている I/O レートのディスク (ホット ディスク) は赤で強調表示できます。
• 短い期間にわたって定期的に最大制限で実行される I/O レートのディスク (ウォーム ディスク) は、黄色で強調表示できます。
• 通常の使用量を示すディスクは、緑色で表示できます。

ダッシュボード システムを効果的に機能させるには、使用する生データが必要です。 独自のダッシュボード システムを構築する場合、または別の組織によって開発されたダッシュボードを使用している場合は、収集する必要があるインストルメンテーション データを、どのレベルの細分性で、ダッシュボードが使用できるように書式設定する必要があるかを理解する必要があります。

優れたダッシュボードは情報を表示するだけでなく、アナリストがその情報に関するアドホックな質問を行うこともできます。 一部のシステムには、オペレーターがこれらのタスクを実行し、基になるデータを探索するために使用できる管理ツールが用意されています。 または、この情報を保持するために使用されるリポジトリによっては、このデータを直接クエリしたり、Microsoft Excel などのツールにインポートして詳細な分析やレポートを行ったりすることもできます。

注

この情報は商業的に機密性の高い可能性があるため、承認された担当者にダッシュボードへのアクセスを制限する必要があります。 また、ダッシュボードの基になるデータを保護して、ユーザーが変更できないようにする必要もあります。

アラートの発生

アラートは、監視データとインストルメンテーション データを分析し、重要なイベントが検出された場合に通知を生成するプロセスです。

アラートは、システムが正常で応答性が高く、セキュリティで保護された状態を維持するのに役立ちます。 これは、データをすぐに操作する必要があるユーザーに対してパフォーマンス、可用性、プライバシーの保証を行うシステムの重要な部分です。 オペレーターには、アラートをトリガーしたイベントの通知が必要な場合があります。 アラートは、自動スケールなどのシステム関数を呼び出すためにも使用できます。

アラートは通常、次のインストルメンテーション データによって異なります。

• セキュリティ イベント。 イベント ログに、認証または承認の失敗が繰り返し発生していることが示されている場合は、システムが攻撃を受けている可能性があり、オペレーターに通知する必要があります。
• パフォーマンス メトリック。 特定のパフォーマンス メトリックが指定されたしきい値を超えた場合、システムはすぐに応答する必要があります。
• 可用性情報。 障害が検出された場合は、1 つ以上のサブシステムをすばやく再起動するか、バックアップ リソースにフェールオーバーすることが必要な場合があります。 サブシステムで障害が繰り返し発生すると、より深刻な問題が発生する可能性があります。

オペレーターは、電子メール、ポケットベル デバイス、SMS テキスト メッセージなど、多くの配信チャネルを使用してアラート情報を受信する場合があります。 アラートには、状況がどれほど重要であるかを示す情報も含まれる場合があります。 多くのアラート システムではサブスクライバー グループがサポートされており、同じグループのメンバーであるすべてのオペレーターが同じアラート のセットを受け取ることができます。

アラート システムはカスタマイズ可能で、基になるインストルメンテーション データの適切な値をパラメーターとして指定できます。 この方法を使用すると、オペレーターはデータをフィルター処理し、関心のある値のしきい値または組み合わせに焦点を当てます。 場合によっては、生のインストルメンテーション データをアラート システムに提供できます。 その他の状況では、集計データを提供する方が適切な場合があります。 (たとえば、ノードの CPU 使用率が過去 10 分間に 90% を超えた場合にアラートをトリガーできます)。 アラート システムに提供される詳細には、適切な概要とコンテキスト情報も含まれている必要があります。 このデータは、誤検知イベントがアラートをトリップする可能性を減らすのに役立ちます。

レポーティング

レポートは、システムの全体的なビューを生成するために使用されます。 現在の情報に加えて履歴データが組み込まれる場合があります。 レポート要件自体は、運用レポートとセキュリティ レポートという 2 つの大きなカテゴリに分類されます。

運用レポートには、通常、次の側面が含まれます。

• 指定された時間枠内のシステム全体または指定されたサブシステムのリソース使用状況を把握するために使用できる統計を集計します。
• 指定された期間におけるシステム全体または指定されたサブシステムのリソース使用状況の傾向を特定します。
• 指定した期間中にシステム全体または指定されたサブシステムで発生した例外を監視する。
• デプロイされたリソースの観点からアプリケーションの効率を判断し、リソースの量 (およびそれに関連するコスト) を不必要にパフォーマンスに影響を与えることなく削減できるかどうかを理解します。

セキュリティ レポートは、お客様によるシステムの使用の追跡に関係します。 次のものが含まれます。

• ユーザー操作の監査。 これには、各ユーザーが実行する個々の要求を日付と時刻と共に記録する必要があります。 データは、管理者が指定した期間にユーザーが実行する一連の操作をすばやく再構築できるように構造化する必要があります。
• ユーザーによるリソースの使用の追跡。 これには、ユーザーの各要求がシステムを構成するさまざまなリソースにアクセスする方法と、その期間を記録する必要があります。 管理者は、このデータを使用して、指定した期間にわたってユーザーによる使用状況レポートを生成できる必要があります(場合によっては課金目的)。

多くの場合、バッチ プロセスでは、定義されたスケジュールに従ってレポートを生成できます。 (通常、待機時間は問題ではありません)。ただし、必要に応じて、アドホックベースで生成することもできます。 たとえば、Azure SQL Database などのリレーショナル データベースにデータを格納する場合は、SQL Server Reporting Services などのツールを使用して、データを抽出して書式設定し、一連のレポートとして表示できます。

次のステップ

• Azure Monitor の概要
• Microsoft Azure Storage の監視、診断、およびトラブルシューティング
• Microsoft Azure のアラートの概要
• Azure Portal を使用したサービス正常性通知の表示
• Application Insights とは
• Azure 仮想マシンのパフォーマンス診断
• Visual Studio 用 SQL Server Data Tools (SSDT) をダウンロードしてインストールする

関連リソース

• 自動スケール ガイダンス では、オペレーターがシステムのパフォーマンスを継続的に監視し、リソースの追加または削除に関する決定を行う必要性を減らすことで、管理オーバーヘッドを削減する方法について説明します。
• 正常性エンドポイント監視パターン では、外部ツールが一定の間隔で公開されたエンドポイントを介してアクセスできる機能チェックをアプリケーション内に実装する方法について説明します。
• 優先順位キュー パターン は、緊急の要求を受信し、緊急性の低いメッセージの前に処理できるように、キューに登録されたメッセージに優先順位を付ける方法を示します。