監視と診断のベスト プラクティス

クラウドで実行される分散アプリケーションとサービスは、多くの可動部分を構成する複雑なソフトウェアです。 運用環境では、顧客がシステムをどのように使用しているかを追跡し、リソース使用率をトレースし、システムの正常性とパフォーマンスを監視することが重要です。 この情報を使用して、問題を検出して修正し、発生する前に潜在的な問題をキャッチすることができます。

監視と診断のシナリオ

監視を使用して、システムがどれだけ適切に機能するかについての分析情報を得ることができます。 監視は、サービス品質 (QoS) ターゲットを維持する上で重要な部分です。 次の一般的なシナリオの監視データを収集します。

• システムが正常なままであることを確認します。

• システムとそのコンポーネントの可用性を追跡します。

• 作業量が増えるにつれてシステムのスループットが予期せず低下しないように、パフォーマンスを維持します。

• システムがサービス レベル アグリーメント (SLA) を満たしていることを保証します。

• システム、ユーザー、およびデータのプライバシーとセキュリティを保護します。

• 監査または規制の運用を追跡します。

• システムの日常的な使用状況を監視し、問題につながる可能性のある傾向に対処します。

• 最初のレポートから考えられる原因の分析、修正、ソフトウェア更新プログラム、展開まで、発生した問題を追跡します。

• オペレーションをトレースし、ソフトウェア リリースをデバッグします。

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

健康状態の監視

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

アラートを設定する

異常な部分がある場合、システムは数秒以内にアラートを生成する必要があります。 アラートでは、信号信号を介してシステムの正常性を強調表示できます。

• 異常の場合は赤 (システムが停止しました)
• 一部正常の場合は黄色（システムは一部機能が制限された状態で動作します）
• 健康のための緑

包括的な正常性監視システムでは、各サブシステムとコンポーネントの正常性状態が表示されるため、どの部分が正常に機能し、どの部分で問題が発生しているかを判断できます。

健康データを収集する

次のソースでは、正常性監視に必要な生データを生成できます。

• ユーザー要求の実行をトレースします。 この情報を使用して、成功または失敗した要求を特定し、各要求にかかる時間を測定できます。

• シミュレートされたユーザーを監視します。 このプロセスは、ユーザーが実行するアクションをシミュレートし、定義済みの一連の手順に従います。 各ステップの結果をキャプチャします。

• 例外、エラー、警告をログに記録します。 この情報は、アプリケーション コードに埋め込まれたトレース ステートメントと、システムが参照するサービスのイベント ログからキャプチャできます。

• システムが使用する非Microsoft サービスの正常性を監視します。 これらのサービスが提供する正常性データを取得して解析することが必要になる場合があります。

• エンドポイントを監視します。

• バックグラウンド CPU 使用率や入出力 (I/O) 操作 (ネットワーク アクティビティを含む) などのアンビエント パフォーマンス情報を収集します。

ヘルス データを分析する

ヘルスモニタリングの主な焦点は、システムが稼働しているかどうかを迅速に示すことです。 重要なコンポーネントが異常な場合、即時データのホット分析によってアラートがトリガーされる可能性があります。

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

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

メトリックの値が定義されたしきい値を超えた場合、システムはアラートを生成してスケールアップできます。 また、システムの正常性を維持するために、リソースの追加、失敗したサービスの再起動、優先順位の低い要求の調整を行うこともできます。

可用性の監視

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

多くのシステムでは、データベースなどの一部のコンポーネントは、重大な障害や接続の損失が発生した場合に迅速なフェールオーバーを可能にするために、組み込みの冗長性で構成されています。 これらの障害に関するできるだけ多くの情報を収集して原因を特定し、再発を防ぐための是正措置を講じます。

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

可用性監視ソリューションは、各サブシステムの可用性状態の現在および履歴のビューを提供します。 1 つ以上のサービスが失敗したとき、またはユーザーがサービスに接続できない場合に、すばやくアラートが表示されます。 この情報を使用して、サブシステムの障害を引き起こす可能性のある傾向を特定します。 たとえば、可用性データを使用して、ピーク処理時間中に失敗したサービスを検出できます。

可用性データの収集

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

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

可用性データの分析

次の種類の分析をサポートするために、データを集計して関連付けます。

• システムとサブシステムの即時可用性。

• システムとサブシステムの可用性エラー率。 障害を特定のアクティビティと関連付けて、システム障害の原因を理解します。

• 障害が発生した場合の、指定した期間の障害率とシステムの負荷 (ユーザー要求の数など) の履歴ビュー。

• システムまたはサブシステムが使用できない理由。 これらの理由には、サービスが実行されていない、接続が失われた、タイムアウト、またはエラー コードの応答が含まれます。

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

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

SLA の監視には、この数式を使用します。 ダウンタイムの定義は、サービスによって異なります。 たとえば、Azure DevOps ビルド サービスでは、ダウンタイムを合計累積時間 (分単位) として定義し、その間はビルド サービスを使用できません。 その分のすべての継続的な HTTP 要求でエラー コードが発生した場合、または応答が返されない場合、サービスは 1 分間使用できないと見なされます。

パフォーマンスの監視

ユーザーの量が増えるにつれて、ユーザーがアクセスするデータセットのサイズが大きくなり、1 つ以上のコンポーネントで障害が発生する可能性が高くなります。 パフォーマンスの低下は、多くの場合、コンポーネントの障害前に発生します。 低下を検出できる場合は、事前に手順を実行して障害を防ぐことができます。

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

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

システムのパフォーマンスを評価するには、通常、次の情報が必要です。

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

次の相関関係を特定するのに役立つツールを使用します。

• 同時ユーザーの数と要求の待機時間、またはユーザーが要求を送信した後に要求の処理を開始するのにかかる時間

• 同時ユーザーの数と平均応答時間の比較、または要求の処理開始後に要求が完了するまでにかかる時間

• 要求の量と処理エラーの数

この高度な機能情報と共に、システム内の各コンポーネントのパフォーマンスの詳細なビューを取得します。 低レベルのパフォーマンス カウンターは、通常、このデータを提供します。 次の情報を追跡します。

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

すべての視覚化では、期間を指定できます。 表示されるデータは、現在の状況のスナップショットまたはパフォーマンスの履歴ビューである可能性があります。 システムは、指定した時間間隔中に、指定した値に対するパフォーマンス測定に基づいてアラートを生成する必要があります。

パフォーマンス データの収集

ユーザーの要求の進行状況を監視することで、スループット、同時実行ユーザーの数、ビジネス トランザクションの数、エラー率などの高レベルのパフォーマンス データを収集します。 トレース ステートメントとタイミング情報をアプリケーション コードの重要なポイントに組み込みます。 すべての障害、例外、警告を十分なデータでキャプチャし、それらを原因となった要求と関連付けます。

可能であれば、アプリケーションが使用する外部システムのパフォーマンス データをキャプチャします。 これらの外部システムは、パフォーマンス データを要求するための独自のパフォーマンス カウンターまたはその他の機能を提供する場合があります。 このメソッドが不可能な場合は、外部システムへの各要求の開始時刻と終了時刻、操作の成功、失敗、警告の状態などの情報を記録します。

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

パフォーマンス データを分析する

ほとんどの分析では、ユーザー要求の種類、または各要求が送信されるサブシステムまたはサービスによって、パフォーマンス データが集計されます。 ユーザー要求の例として、ショッピング カートまたは e コマース システムのチェックアウト プロセスに項目を追加する方法があります。

もう 1 つの一般的な要件は、パフォーマンス データをパーセンタイル単位で集計することです。 たとえば、99% の要求、95% の要求、70% の要求の応答時間を決定できます。 各パーセンタイルに対して SLA ターゲットまたはその他の目標を設定できます。 問題をすぐに検出できるように、ほぼリアルタイムで継続的な結果を報告します。 統計目的で時間の経過に伴う結果の集計。

待機時間の問題は、パフォーマンスにも影響する可能性があります。 ボトルネックの原因をすばやく特定するには、各要求が実行する各ステップの待機時間を評価します。 パフォーマンス データは、各ステップのパフォーマンス メトリックを関連付けて特定の要求に関連付ける方法を提供する必要があります。

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

セキュリティの監視

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

• すべてのサインイン試行と、それぞれが失敗したか成功したか

• 認証されたユーザーによって実行されるすべての操作と、ユーザーがアクセスするすべてのリソースの詳細

• ユーザーがセッションを終了してサインアウトしたとき

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

セキュリティ監視の要件

セキュリティ監視によってキャプチャされるデータは、次の場合に役立ちます。

• 認証されていないエンティティによる侵入の試行を検出します。

• エンティティがアクセス権を持たないデータに対して操作を実行しようとする試行を特定します。

• 認証されていないユーザーまたは悪意のある認証されたユーザーがシステムを攻撃しようとしているかどうかを判断します。

これらのタスクをサポートするために、システムは次の場合にアラートを送信する必要があります。

• 1 つのアカウントで、指定した期間内にサインイン試行が繰り返し失敗します。

• 1 つの認証済みアカウントは、指定された期間中に禁止されているリソースへのアクセスを繰り返し試行します。

• 指定された期間中に多数の認証されていない要求または未承認の要求が発生します。

各要求のソースのホスト アドレスを含むようにアラートを設定します。 特定の範囲のアドレスからセキュリティ違反が定期的に発生する場合は、これらのホストをブロックできます。

システムのセキュリティを維持する重要な部分は、通常のパターンから逸脱したアクションをすばやく検出できることです。 失敗したサインイン要求や成功したサインイン要求の数などの情報を視覚的に表示して、異常な時期にアクティビティの急増を検出できます。 この情報を使用して、時間ベースの自動スケールを設定することもできます。 たとえば、多くのユーザーが特定の時刻に定期的にサインインしている場合は、追加の認証サービスを開始して作業量を処理できます。 ピークが経過した後、これらのサービスをシャットダウンします。

セキュリティ データの収集

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

セキュリティ監視には、アプリケーションの外部にあるツールからのデータを組み込むことができます。 これらのツールには、外部機関によるポート スキャン アクティビティを識別するユーティリティや、アプリケーションとデータへの認証されていないアクセスの試行を検出するネットワーク フィルターが含まれます。 場合によっては、継続的インテグレーションと継続的デリバリー (CI/CD) デプロイ ツールがアプリケーション ライフ サイクルの重要な部分を占めます。 これらのツールは、異常な動作にもフラグを設定する必要があります。

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

セキュリティ監視の主な機能は、多くのソースからデータを収集することです。 多くの場合、さまざまな形式と詳細レベルでは、データを一貫した情報スレッドにコンパイルするために複雑な分析が必要になります。 サインインの失敗や、リソースへの不正アクセスの試行の繰り返しを検出できますが、セキュリティ データの複雑な自動処理は実現できない可能性があります。 このシナリオでは、エキスパートによる手動分析のために、データのタイムスタンプを設定し、元の形式でセキュリティで保護されたリポジトリに書き込む必要があります。

SLA の監視

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

次のメトリックは SLA を定義します。

• システムの全体的な可用性。 たとえば、組織は、その時点の 99.9% 利用可能なシステムにコミットする場合があります。 この割合は、1 年あたり 9 時間以下、つまり 1 週間に約 10 分のダウンタイムに相当します。

• 運用スループット。 この側面は、多くの場合、システムが最大 100,000 件の同時ユーザー要求をサポートしたり、10,000 件の同時ビジネス トランザクションを処理したりできるコミットメントなど、1 つ以上の高い基準として表されます。

• 運用応答時間。 システムでは、定義されたレートで要求を処理する必要がある場合もあります。 たとえば、すべてのビジネス トランザクションの 99% は 2 秒以内に完了する必要があり、1 回のトランザクションの所要時間は 10 秒を超える必要はありません。

SLA 監視の要件

システムが SLA を満たしているかどうかを迅速に判断できる必要があります。 SLA を満たしていない場合は、基になる要因を評価して、標準以下のパフォーマンスの原因を見つける必要があります。

次の大まかなインジケーターを視覚的に示すことができます。

• サービスのアップタイムの割合

• 1 秒あたりの成功したトランザクションまたは操作の観点から測定されるアプリケーションのスループット

• 成功または失敗したアプリケーション要求の数

• アプリケーションとシステムの障害、例外、警告の数

これらのインジケーターをすべて、指定した期間でフィルター処理できることを確認します。

クラウド アプリケーションは、複数のサブシステムとコンポーネントで構成されている可能性があります。 システムの全体的なアップタイムなど、高レベルのインジケーターを選択し、その正常性状態に影響を与える基になる要素を判断できる必要があります。

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

SLA データの収集

SLA 監視に必要な生データをキャプチャするには、次のアクションを実行します。

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

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

SLA データの分析

SLA データを集計して、システムの全体的なパフォーマンスの図を生成します。 集計データをドリルダウンして、基になるサブシステムを評価することもできます。 たとえば、次のタスクを実行できる必要があります。

• 指定した期間中のユーザー要求の合計数を計算し、これらの要求の成功率と失敗率を決定します。

• ユーザー要求の応答時間を組み合わせて、システム応答時間の全体的なビューを生成します。

• ユーザー要求の進行状況を分析して、全体的な応答時間を要求内の個々の作業項目の応答時間に分割します。

• 特定の期間のアップタイムの割合として、システムの全体的な可用性を決定します。

• システム内の個々のコンポーネントとサービスの利用可能時間の割合を分析します。 Microsoft サービス以外で生成されるログを解析する必要がある場合があります。

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

内部的な目的で、組織は、サービスの失敗の原因となるインシデントの数と性質を追跡することもできます。 ダウンタイムを短縮し、SLA を満たすことができるように、これらの問題を迅速に解決する方法またはそれらを排除する方法について説明します。

監査

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

監査の要件

ユーザーのアクションを再構築できるように、ユーザーが実行する一連の業務を追跡できる必要があります。 このレコードは、ドキュメントの目的で、またはフォレンジック調査の一環として必要になる場合があります。

監査情報は機密性が高い。 システム ユーザーと実行するタスクを識別するデータが含まれている可能性があります。 このため、監査情報は、対話型システムの一部としてではなく、信頼できるアナリストのみが使用できる可能性が高くなります。 アナリストは、次の例のようなさまざまなレポートを生成します。

• 指定した期間内のすべてのユーザーのアクティビティを一覧表示するレポート

• 1 人のユーザーのアクティビティの時系列を詳しく説明するレポート

• 1 つ以上のリソースに対して実行された一連の操作を一覧表示するレポート

監査データの収集

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

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

規制要件によって、監査データの形式と保存方法が決まります。 規制でデータを元の形式で記録する必要がある場合は、データをクリーンアップできない可能性があります。 その結果、改ざんを防ぐために、リポジトリを格納するリポジトリへのアクセスを厳密に保護する必要があります。

監査データの分析

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

使用状況の監視

使用状況の監視では、お客様がアプリケーションの機能とコンポーネントを使用する方法を追跡します。 データを使用すると、次のことができます。

• システムで一般的な機能と潜在的なホットスポットを特定します。 トラフィックの多い要素では、負荷をより均等に分散させるために、機能パーティション分割またはレプリケーションの利点が得られる場合があります。 また、この情報を使用して、使用頻度が低く、将来のバージョンのシステムで提供終了または置換の候補となる可能性のある機能を決定することもできます。

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

• システムのパフォーマンスと機能に関するユーザーの満足度を検出します。 たとえば、eコマース システムの多くの顧客が定期的にショッピング カートを放棄する場合、チェックアウト機能に問題がある可能性があります。

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

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

• ノイズの多い近隣の問題を検出します。 エラーの調査や製品の決定を促進するために、トラフィックが均等に分散されているかどうか、または少数のユーザーがトラフィックの大部分を生成するかどうかを判断します。 1 人のユーザーが大量のトラフィックを生成した場合、この機能でパフォーマンスのチューニングが必要になる場合があります。 または、トラフィックを減らすために追加のクォータを適用することもできます。

使用状況の監視の要件

システムの使用状況を評価するには、通常、次の情報が必要です。

• 各サブシステムが処理し、各リソースに送信する要求の数

• 各ユーザーが実行する作業

• 各ユーザーが占有するデータ ストレージのボリューム

• 各ユーザーがアクセスするリソース

グラフを生成することもできます。 一般的な例としては、最も多くのリソースを消費するユーザーのグラフや、最も頻繁にアクセスされるリソースまたはシステム機能が挙げられます。

使用状況データの収集

各要求の開始時刻と終了時刻、および各要求の性質 (読み取りまたは書き込みなど) を記録することで、高レベルの使用状況の追跡を実行できます。 この情報をキャプチャするには、次のタスクを実行します。

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

測定の目的で、どのユーザーがどの操作を実行し、これらの操作が使用するリソースを識別する必要もあります。 収集する情報が、正確な課金をサポートするのに十分な詳細であることを確認します。

問題の追跡

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

問題の追跡の要件

問題を追跡するには、ユーザーが報告する問題の詳細を記録して報告できる別のシステムを使用します。 これらの詳細には、試行されたタスク、問題の症状、イベントのシーケンス、エラーまたは警告メッセージが含まれます。

問題追跡データを収集する

問題追跡データの初期データ ソースは、問題を報告するユーザーです。 このユーザーは、次の詳細を指定できる場合があります。

• クラッシュ ダンプ (ユーザーのデスクトップで実行されるコンポーネントがアプリケーションに含まれている場合)

• 画面スナップショット

• エラーが発生した日時とその他の環境情報 (ユーザーの場所など)

この情報は、システムをデバッグし、将来のソフトウェア リリース用のバックログを作成するのに役立ちます。

問題追跡データを分析する

異なるユーザーが同じ問題を報告する可能性があり、問題追跡システムは共通のレポートを関連付ける必要があります。

各レポートに対するデバッグ作業の進行状況を記録します。 問題を解決したら、ソリューションを顧客に通知します。

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

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

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

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

予期しないイベントやその他の問題をトレースするには、監視データは、アナリストが問題の原因を見つけてイベントのシーケンスを再構築できるように十分な情報を提供する必要があります。 その後、開発者は問題が再発するのを防ぐために変更を加えることができます。

トレースとデバッグ データの収集

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

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

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

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

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

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

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

監視プロセス全体を、フィードバックに基づいて微調整と改善を必要とする、ライブで継続的なソリューションとして扱います。 たとえば、まず多くの要因を測定してシステムの健全性を判断し、時間をかけて分析を洗練させながら、関連性のない指標を除外していきます。

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

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

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

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

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

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

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

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

監視と診断データを収集するには、次の戦略を使用します。

• アプリケーションとシステムの監視 では、アプリケーション、アプリケーション フレームワーク、オペレーティング システム、インフラストラクチャ内の内部ソースが使用されます。 アプリケーション コードは、クライアント要求のライフ サイクル中に注目すべきポイントで独自の監視データを生成できます。 アプリケーションには、必要に応じてオンとオフを切り替えることができるトレース ステートメントを含めることができます。 診断フレームワークを使用して、診断を動的に挿入することもできます。 これらのフレームワークは、通常、コード内のさまざまなインストルメンテーション ポイントにアタッチし、これらのポイントでトレース データをキャプチャするプラグインを提供します。

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

• 実際のユーザー監視 では、ユーザーとアプリケーションの間の相互作用が記録され、各要求と応答のフローが観察されます。 この情報を使用して、各ユーザーの使用状況を測定し、ユーザーが適切な QoS を受信するかどうかを判断します。これには、応答時間の短縮、待機時間の短縮、最小限のエラーが含まれます。 データを使用して、障害が最も頻繁に発生する領域を特定できます。 また、データを使用して、アプリケーション内のホットスポットやその他のボトルネックのためにシステムの速度が低下する領域を特定することもできます。 この方法を慎重に実装すると、デバッグとテストの目的でアプリケーションを通じてユーザーのフローを再構築できる場合があります。

  Important

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

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

  Note

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

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

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

• ユーザー エラー ダンプは、 回復できない場合にアプリケーションの状態のスナップショットを収集する方法をアプリケーションに依存します。 また、ユーザーはそのスナップショットを自発的に共有する必要があります。 エラー ダンプが実行されることを保証することはできませんが、提供される低レベルのデータを使用して、エラーの根本原因を特定できます。 このシナリオは、エラーが頻繁に発生する頻度が低い場合、または使用頻度の低いアプリケーション機能でのみエラーが発生する場合に一般的です。

情報の取得範囲を最大限にするために、これらのテクニックを組み合わせて使用する必要があります。

アプリケーションをインストルメント化する

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

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

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

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

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

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

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

すべての監視データに同じ方法でタイムスタンプを付ける。 一貫性を保つには、UTC を使用してすべての日付と時刻を記録します。 このメソッドは、イベントのシーケンスをより簡単にトレースするのに役立ちます。

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

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

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

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

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

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

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

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

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

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

多くの場合、インストルメンテーションによって生成される情報は一連のイベントとして生成され、処理と分析のために別のテレメトリ システムに渡されます。 テレメトリ システムは通常、特定のアプリケーションやテクノロジに依存しませんが、情報はスキーマによって定義された特定の形式に従うことを想定しています。 スキーマは、テレメトリ システムが取り込めるデータ フィールドと型を定義する契約を規定します。 さまざまなプラットフォームやデバイスからのデータを許可するようにスキーマを一般化します。 広く使用されているフレームワークとスキーマの 1 つの例として 、OpenTelemetry があります。

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

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

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

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

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

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

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

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

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

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

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

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

• 自律的に動作し続けるログ記録呼び出しを開始します。 これらの種類の操作は、ビジネス操作の進行状況をブロックしません。 監査イベントはビジネスにとって重要であるため、例外です。 ビジネス運用の基本的な部分として分類します。

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

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

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

データの収集と格納

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

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

この図は、データ収集の簡略化されたビューを示しています。 コレクション サービスは、通常、さまざまなマシンで実行される多くの部分で構成されます。 テレメトリ データをすばやく分析する必要がある場合は、収集サービスの外部で動作するローカル コンポーネントを使用します。 分析処理の後、コンポーネントは結果を視覚化およびアラート サブシステムに直接送信します。 ウォーム分析またはコールド分析の対象となるデータは、処理を待機している間、ストレージに保持されます。 詳細については、「 ホット、ウォーム、およびコールド分析のサポート」を参照してください。

仮想マシン上で実行されるAzureアプリケーションとサービスの場合、Azure Monitor エージェントはデータをキャプチャするためのソリューションを提供します。 各コンピューティング ノードから収集するデータと、それを送信するAzure MonitorのLog Analytics ワークスペースを指定するデータ収集規則 (DCR) を定義します。 エージェントは、次のソースからデータを収集できます。

• インターネット インフォメーション サービス (IIS) ログ
• Windowsイベントログ
• 性能カウンター
• Linux ノードからの Syslog
• アプリケーションが書き込むテキストログと JSON ログ

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

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

帯域幅の使用を最適化するために、緊急度の低いデータをバッチとして転送できます。 特に、データに時間の機密情報が含まれている場合は、転送を無期限に遅らせないでください。

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

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

プル モデルの 1 つのアプローチは、アプリケーションの各インスタンスでローカルに実行される監視エージェントを使用することです。 監視エージェントは、ローカル ノードで収集されたテレメトリ データを定期的に取得し、アプリケーションのすべてのインスタンスが共有する集中型ストレージにこの情報を書き込む別のプロセスです。 Azure Monitor エージェントは、このメカニズムを実装します。 データ収集規則を使用して、各コンピューティング インスタンスから収集するデータを構成します。 各インスタンスと共に実行される監視エージェントは、IIS ログ、Windows イベント ログ、パフォーマンス カウンターなどの指定されたデータを収集し、Azure MonitorのLog Analytics ワークスペースに送信して、クエリと分析を行うことができます。 次の図は、このアーキテクチャの例を示しています。

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

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

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

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

インストルメンテーション データを統合する

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

インストルメンテーション データを格納する

前のセクションでは、インストルメンテーション データを格納する方法の簡略化されたビューを示します。 実際には、使用する方法に合ったテクノロジを使用して、さまざまな種類の情報を格納する必要があります。

たとえば、Azure Blob StorageとAzure Table Storageのアクセス パターンは似ていますが、実行できる操作は限られており、格納するデータの粒度は異なります。 分析操作を実行する必要がある場合、またはフルテキスト検索機能が必要な場合は、次のクエリとデータ アクセス機能を提供するデータ ストレージを使用する必要があります。

• SQL データベースにパフォーマンス カウンター データを格納して、計画外の分析を有効にします。
• トレース ログをAzure Cosmos DBに格納します。
• Hadoop 分散ファイル システム (HDFS) にセキュリティ情報を書き込みます。
• リッチ インデックスを使用して検索を高速化する Elasticsearch を使用して、フルテキスト検索を必要とする情報を格納します。

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

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

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

より複雑な分析、レポート作成、履歴傾向の特定に使用する情報は、緊急性が低くなります。 データ マイニングと計画外のクエリをサポートする方法で格納します。 詳細については、「 ホット、ウォーム、およびコールド分析のサポート」を参照してください。

ログローテーションとデータ保持

インストルメンテーションでは大量のデータが生成されます。 場合によっては、データの処理と転送後に、各ノードから元の生ソース データを削除できます。 または、生の情報を保存する必要がある場合があります。

パフォーマンス データは、通常、パフォーマンスの傾向を特定し、容量を計画するために使用できるように、有効期間が長くなります。 このデータにすばやくアクセスできるように、このデータの統合ビューを有限期間オンラインに保ちます。 測定と課金のために収集されたデータを無期限に保存する必要がある場合があります。 また、規制要件では、監査とセキュリティの目的で収集された情報をアーカイブして保存することが必要になる場合があります。 改ざんを防ぐために、この機密データを暗号化または保護します。 ユーザーのパスワードやその他の個人情報を記録しないでください。 保存する前に、データからこれらの詳細情報を削除してください。

データダウンサンプリング

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

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

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

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

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

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

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

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

監視と診断の重要な部分は、収集されたデータを分析して、システムの全体的な正常性を把握することです。 独自の KPI とパフォーマンス メトリックを定義し、分析要件を満たすようにデータを構造化する方法について説明します。 この情報は一連のイベントの追跡と問題の診断に重要であるため、さまざまなメトリックとログ ファイルでキャプチャされたデータがどのように関連付けられるかを理解します。

通常、システムの各部分のデータはローカルにキャプチャされますが、システムに参加している他のサイトで生成されたデータと組み合わせる必要があります。 この情報を慎重に関連付けて、データが正確に結合されるようにします。 たとえば、操作の使用状況データは、次のノードにまたがる場合があります。

• ユーザーが接続する Web サイトをホストするノード
• この操作の一部としてアクセスされる別のサービスを実行するノード
• データ ストレージを格納するノード

操作のリソースと処理の使用状況の全体的なビューを提供するには、この情報を結び付ける必要があります。 データをキャプチャするノードは、データの前処理とフィルター処理を行う場合がありますが、通常、中央ノードはデータを集計して書式設定します。 詳細については、「 インストルメンテーション データの統合」を参照してください。

ホット、ウォーム、コールドの分析をサポートする

視覚化、レポート、アラートの目的でデータを分析および再フォーマットすることは、独自のリソース セットを使用する複雑なプロセスになる可能性があります。 一部の形式の監視では、即時データ分析を有効にする必要があります ( ホット分析とも呼ばれます)。 たとえば、アラートとセキュリティ監視の分析が挙げられます。 ホット分析の場合は、効率的な処理のためにデータを使用可能にし、構造化します。 場合によっては、データを保持する個々のノードに分析処理を移動することが必要になる場合があります。

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

ウォーム分析を使用して、健全性に関する問題の診断に役立てることもできます。 ホット分析を使用して正常性イベントを処理し、すぐにアラートを生成します。 次に、Warm analysis でデータを分析し、ヘルス イベントの原因を特定します。

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

コールド分析を使用して、予測的な正常性分析用のデータを提供することもできます。 指定した期間の履歴情報を収集し、それを現在の正常性データと組み合わせて、正常性の問題を引き起こす可能性のある傾向を確認します。 このような場合は、傾向を修正するためにアラートを発生させる必要があります。

データの関連付け

インストルメンテーションによってキャプチャされるデータは、システム状態のスナップショットを提供できますが、分析の目的は、このデータを実行可能にすることです。 たとえば、特定の時刻にシステム レベルで大量の I/O 読み込みの原因を特定し、データベースの応答時間、1 秒あたりのトランザクション数、アプリケーションの応答時間を同じタイミングで確認できます。

負荷を軽減する 1 つの方法は、より多くのサーバーでデータをシャード化することです。 例外は、システムの任意のレベルで障害が発生したために発生する可能性があります。 あるレベルの例外は、多くの場合、その上のレベルで別の障害をトリガーします。

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

生のインストルメンテーション データに、イベントを関連付けるために必要な集計をサポートするための十分なコンテキストとアクティビティ ID 情報が含まれていることを確認します。 このデータは異なる形式で保持される可能性があるため、解析して標準化された形式に変換して分析する必要がある場合があります。 詳細については、 データの関連付けの情報を参照してください。

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

問題を診断するには、RCA を実行して、障害または予期しない動作の原因を特定する必要があります。 通常、指定された時間枠内のシステム全体または特定のサブシステムに対して、次の情報が必要です。

• イベント ログとトレースからの詳細情報
• 指定されたレベルの例外とエラーからのスタック トレースを完了する
• 異常終了したすべてのプロセスのクラッシュダンプ
• すべてのユーザーまたは選択ユーザーが実行する操作を記録するアクティビティ ログ

トラブルシューティングのためにデータを分析するには、システム アーキテクチャとそのコンポーネントに関する深い技術的な理解が必要です。 データを解釈し、問題の原因を特定し、それらを修正するための戦略を推奨する必要があります。 もう 1 つの戦略は、この情報のコピーを元の形式で保存し、専門家によるコールド分析に使用できるようにすることです。

データを視覚化してアラートを生成する

傾向や問題をすばやく特定できるように、監視システムはデータを提示する必要があります。 また、注意が必要なイベントが発生したときにすぐに通知する必要もあります。

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

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

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

ダッシュボードは階層的に整理できます。 最上位レベルのダッシュボードでは、システムの各側面の全体的なビューが表示され、詳細にドリルダウンできます。 たとえば、システムのディスク I/O 全体を示すダッシュボードでは、個々のディスクの I/O レートを表示して、1 つまたは複数の特定のデバイスがトラフィックの不均衡なボリュームを占めるかどうかを判断できます。 ダッシュボードには、この I/O を生成するユーザーやアクティビティなどの関連情報も表示されます。 この情報は、デバイス間でより均等に負荷を分散するのに役立ちます。

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

• I/O レートが長期間にわたって最大容量に近づいているディスク、またはホット ディスクの場合は赤

• 短時間、I/O レートが定期的に最大上限に達するディスク、またはウォーム ディスクには黄色を使用します

• 通常の使用量を示すディスクの緑色

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

効果的なダッシュボードでは、情報について質問することもできます。 一部のシステムには、これらのタスクの実行と基になるデータの探索に使用できる管理ツールが用意されています。 情報を保持するリポジトリによっては、データを直接照会したり、Excelなどのツールにインポートして詳細な分析やレポートを行ったりできる場合があります。

アラートを発生させる

アラートは、監視データとインストルメンテーション データを分析し、重大なイベントを検出した場合に通知を生成します。

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

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

• セキュリティ イベント: イベント ログに、認証または承認の繰り返しの失敗が示されている場合。 このシナリオでは、システムが攻撃を受けている可能性があることを通知するアラートが表示されます。

• パフォーマンス メトリック: パフォーマンス メトリックが指定されたしきい値を超えた場合、システムはすぐに応答する必要があります。

• 可用性情報: 障害が検出された場合は、1 つ以上のサブシステムをすばやく再起動するか、バックアップ リソースにフェールオーバーすることが必要になる場合があります。 サブシステムで障害が繰り返し発生すると、より深刻な問題が発生する可能性があります。

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

アラート システムをカスタマイズ可能にし、基になるインストルメンテーション データの適切な値をパラメーターとして指定します。 この方法を使用すると、特定のしきい値または値の組み合わせについてデータをフィルター処理できます。 場合によっては、生のインストルメンテーション データをアラート システムに提供できます。 または、集計データを提供する方が適切な場合もあります。 たとえば、ノードの CPU 使用率が過去 10 分間に 90% を超えると、アラートがトリガーされます。 誤検知イベントによってアラートがトリガーされる可能性を減らすために、アラート システムに適切な概要とコンテキスト情報を提供します。

レポーティング

レポートを使用して、システムの全体的なビューを生成します。 履歴データと現在の情報を組み合わせることができます。 レポートの要件は、運用とセキュリティのカテゴリに分類されます。

通常、運用レポートには、指定された時間枠内のシステム全体または特定のサブシステムに関して、次の側面が含まれます。

• リソース使用率を把握するために使用できる集計統計

• リソース使用量の傾向

• 例外の監視

• デプロイされたリソースに関するアプリケーションの効率と、パフォーマンスに影響を与えずにリソースの量を減らすことができるかどうか

セキュリティ レポートでは、お客様によるシステムの使用方法が追跡されます。 通常、次の側面が含まれます。

• ユーザー操作を監査します。 各ユーザーが実行した個々の要求を日付と時刻と共に記録します。 指定した期間にユーザーが実行する一連の操作をすばやく再構築できるように、データを構造化します。

• 各ユーザーのリソース使用量を追跡します。 ユーザーの各要求がシステム リソースにアクセスする方法と、その期間を記録します。 このデータを使用して、指定した期間にわたってユーザーごとに使用状況レポートを生成します(請求目的の場合があります)。

多くの場合、バッチ プロセスでは、定義されたスケジュールに従ってレポートを生成できます。 通常、レポートの生成では待機時間が長くないため、必要に応じてオンデマンドでレポートを生成できます。 Azure SQL Databaseなどのリレーショナル データベースにデータを格納する場合は、SQL Server Reporting Servicesなどのツールを使用してデータを抽出および書式設定し、レポートのセットとして表示できます。

次のステップ

• Azure Monitor の概要
• Storage の監視、診断、トラブルシューティング
• Azure のアラートの概要
• Application Insights の概要
• Azure VM のパフォーマンス診断

関連するリソース

• 自動スケール ガイダンス では、システムのパフォーマンスを継続的に監視し、リソースを追加または削除する決定を下す必要性を減らすことで、管理オーバーヘッドを削減する方法について説明します。

• 正常性エンドポイント監視パターン では、外部ツールが一定の間隔で公開されたエンドポイントを介してアクセスできる機能チェックをアプリケーション内に実装する方法について説明します。

• 優先順位キュー パターン では、緊急性の低いメッセージの前にシステムが緊急の要求を受信して処理できるように、キューに登録されたメッセージに優先順位を付ける方法について説明します。