Share via

アプリケーションのインストルメント化に関する推奨事項

  • [アーティクル]

この Azure Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:07 設計の選択を検証し、将来の設計とビジネス上の決定を通知するための監視システムを設計して実装します。 このシステムは、ワークロードのインフラストラクチャとコードから出力される運用テレメトリ、メトリック、ログをキャプチャして公開します。

関連ガイド: 監視システムの設計と作成に関する推奨事項

このガイドでは、インストルメンテーションを使用してアプリケーションの監視を有効にするための推奨事項について説明します。 監視システムに取り込んで統合できる意味のあるテレメトリを生成します。 インストルメンテーションを使用すると、リモート運用サーバーにサインインせずに情報を収集し、トレースまたはデバッグを手動で実行できます。 インストルメンテーション データには、パフォーマンスの評価、問題の診断、ワークロードの決定に使用できるメトリックとログが含まれます。

主要な設計戦略

ワークロードのテレメトリを最適化するには、アプリケーションをインストルメント化して次のデータを生成します。

  • ログ は、個別のイベントのタイムスタンプ付きレコードです。 ログには、プレーン テキスト、構造化、バイナリの 3 つの形式があります。

  • 分散トレース ログ を使用すると、さまざまなサービスとコンポーネントを通過する要求のパスを確認できます。

  • メトリック は、特定の時点におけるシステムの側面を表す数値です。

注意

Application Insights、Dynatrace、Elastic Application Performance Monitoring などのツールを使用して、アプリケーションを自動的にインストルメント化できます。 これらのツールを使用すると、インストルメンテーションが簡単になりますが、制限される可能性もあります。 自動インストルメンテーション ツールを使用する場合は、必要に応じて手動インストルメンテーションを使用してさらに機能を追加できます。

ログと分散トレース ログ

構造化ログを使用して、ログを監視および分析プラットフォームに簡単に統合します。 詳細度のレベルを変更できるように、アプリケーションをインストルメント化します。 一定の詳細ログはストレージ リソースを無駄にする可能性があるため、トラブルシューティングのために必要に応じてオンとオフを切り替える必要があります。

トレース ログには、アプリケーションで Event Tracing for Windows (ETW) が使用されている場合に、トレース イベントから作成されたテキスト データまたはバイナリ データが含まれます。 システム ログは、Web サーバーなどのインフラストラクチャ内のイベントからトレース ログ コンテンツを生成します。 テキスト ログ コンテンツは人間が読み取れるように設計されていますが、自動システムでも解析できる形式で記述されていることを確認する必要があります。

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

注意

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

メトリック

メトリック ( サンプル) は、特定の時点におけるシステム内の一部の側面またはリソースの数であり、1 つ以上のタグまたはディメンションが関連付けられています。 メトリックの 1 つのインスタンスは分離に役立ちません。メトリックは時間の経過と同時にキャプチャする必要があります。 記録するメトリックと頻度を検討します。 生成頻度が高すぎるデータは、システムに大きな負荷を与える可能性がありますが、データ キャプチャの頻度が低いと、重大なイベントにつながる状況を見逃す可能性があります。 データをキャプチャするための適切な頻度は、メトリックによって異なる場合があります。 たとえば、サーバーの CPU 使用率は 2 番目から 2 番目に大きく異なる場合がありますが、使用率が高い場合は、数分で一貫性がある場合にのみ問題になります。

データを相互に関連付けるための情報

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

非同期操作では複数のユーザーに対して同じスレッドが再利用される可能性があるため、スレッドとユーザー要求の間の 1 対 1 のマップになることはほとんどありません。 さらに複雑にするために、1 つの要求がシステムを通過する際に複数のスレッドに関連付けることができます。 可能であれば、各要求を、要求コンテキストの一部としてシステム全体に伝播される一意のアクティビティ ID に関連付けます アクティビティ ID を生成してトレース情報に含めるテクニックは、トレース データをキャプチャするために使用されるテクノロジによって異なります。

すべての監視データには、同じ方法でタイムスタンプを付ける必要があります。 一貫性を保つために、すべての日付と時刻は、世界協定時刻を使用して記録します。

注意

異なるタイム ゾーンとネットワークで動作するコンピューターが同期されない場合があります。 複数のマシンにまたがるインストルメンテーション データを相互に関連付けるときは、タイムスタンプのみに頼るべきではありません。

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

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

人間が判読できるデータ

トレース イベントによってキャプチャされた情報が、コンピューターと人間の読み取り可能な両方であることを確認します。 この情報に対して明確に定義されたスキーマを採用して、システム間でログ データの自動処理を実装し、ログを読み取る運用スタッフとエンジニアリング スタッフに一貫性を提供します。

データに次の環境情報を含めます。

  • デプロイ環境
  • 加工機械
  • プロセスの詳細
  • [呼び出し履歴]

トレーサビリティと相関関係に投資する

開発者または管理者が各要求のソースを特定できるように、要求の特定のインスタンスに関連付けられているアクティビティ ID などの十分なコンテキストを指定します。

データ コンテキストには、アクティビティと実行された計算作業と使用されるリソースを関連付けるために使用される情報も含まれる場合があります。 この作業は、プロセスとマシンの境界を越える場合があります。

測定の場合、コンテキストには、要求の原因となった顧客への参照を直接または間接的に含める必要があります。 このコンテキストは、監視データがキャプチャされた時点のアプリケーションの状態に関する重要な情報を提供します。

関連するすべてのデータをキャプチャする

すべての要求と、それらが行われた場所またはリージョンを記録します。 この情報を使用して、場所固有のホットスポットを特定できます。 アプリケーションまたはそれが使用するデータを再パーティション化するかどうかの判断にも役立ちます。

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

データの一貫性を確保する

一貫性のあるデータは、イベントを分析し、ユーザー要求と関連付けるのに役立ちます。 包括的で構成可能なログ パッケージを使用して情報を収集することを検討してください。 ログ パッケージは、システムのさまざまな部分を実装する際に、開発者がアプローチを採用する依存を回避するのに役立ちます。

主要なパフォーマンス カウンターから、入出力ボリューム、要求数、メモリ、ネットワーク、CPU 使用率などのデータを収集します。 一部のインフラストラクチャ サービスには、次のような独自のパフォーマンス カウンターが用意されています。

  • データベースへの接続数。
  • トランザクションレート。
  • 成功または失敗したトランザクションの数。

アプリケーションでは、独自のパフォーマンス カウンターを定義することもできます。

外部依存関係を検討する

すべての外部サービス呼び出しをログに記録します。 外部からの呼び出しは、次の場合に行われる場合があります。

  • データベース システム。
  • Web サービス
  • インフラストラクチャの一部であるその他のシステム レベルのサービス。

各呼び出しの期間と、呼び出しの成功または失敗に関する情報を記録します。 可能であれば、すべての再試行と、発生した一時的なエラーに関する情報をキャプチャします。

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

多くの場合、インストルメンテーション情報は一連のイベントとして生成され、処理と分析のために個別の製品利用統計情報システムに渡されます。 テレメトリ システムは、通常、特定のアプリケーションやテクノロジに依存しません。

テレメトリ システムでは、定義されたスキーマを使用して情報を解析します。 スキーマは、テレメトリ システムが取り込むことができるデータ フィールドと型を定義するコントラクトを指定します。 スキーマを一般化して、さまざまなプラットフォームやデバイスからデータを受信できるようにします。 共通スキーマには、次のようなすべてのインストルメンテーション イベントに関連するフィールドを含める必要があります。

  • イベント名。
  • イベント時間。
  • 送信者の IP アドレス。
  • イベントの関連付けに必要な詳細(次を含む):
    • User ID
    • デバイス ID
    • アプリケーション ID

多くのデバイスが同じアプリケーションのイベントを発生させる可能性があるため、スキーマはデバイスの種類に依存しないように注意してください。 アプリケーションでは、ローミングまたはデバイス間の配布をサポートする必要があります。 スキーマには、次のようなアプリケーション間で一般的な特定のシナリオに関連するドメイン フィールドを含めることもできます。

  • 例外に関する情報。
  • アプリケーションの開始イベントと終了イベント。
  • Web サービス API 呼び出しの成功または失敗。

アプリケーション間で共通のレポートと分析のセットを構築するために、同じイベント セットを生成するドメイン フィールドを確立します。 アプリケーション固有のイベントの詳細をキャプチャするためのカスタム フィールドを含むスキーマを構成する必要がある場合があります。

OpenTelemetry は、API、SDK、およびその他のツールのベンダーに依存しないコレクションです。 OpenTelemetry を使用してアプリケーションをインストルメント化し、言語間で一貫して意味のあるテレメトリを生成できます。 OpenTelemetry はツールに依存しないため、オープンソースや商用オファリングを含む多くの監視プラットフォームと互換性があります。 Microsoft では、インストルメンテーションの標準ツールとして OpenTelemetry を採用しています。

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

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

  • ログは、読みやすく、簡単に解析できるようにします。 可能であれば、構造化されたロギングを使用します。

  • ログ メッセージは、簡潔でわかりやすくします。

  • ログのソースを特定します。

  • 各ログ レコードが書き込まれるとき、タイムスタンプ情報を追加します。

  • すべてのタイム スタンプで、同じタイム ゾーンと形式を使用します。

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

  • システムに関する機密情報やユーザーに関する個人情報を明らかにしないでください。 ログに記録される前にこの情報をスクラブしますが、関連する詳細は保持してください。

  • すべての重大な例外をログに記録しますが、必要に応じて管理者がログ記録をオンまたはオフにして、例外と警告を減らします。

  • すべての再試行ロジック情報をキャプチャしてログします。 このデータは、システムの一時的な正常性を監視する場合に役立ちます。

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

  • セキュリティ要件が異なるログ メッセージを同じログ ファイルに混在させないでください。

  • すべてのログ記録呼び出しが、ビジネス操作の進行状況をブロックしない fire-and-forget 操作であることを確認します。 監査イベントはビジネスにとって重要であるため、このルールから除外します。

  • ログ記録が拡張可能であり、具象ターゲットへの直接の依存関係がないことを確認します。

  • すべてのログ記録がフェールセーフであり、カスケード エラーがトリガーされないようにします。

  • インストルメンテーションを継続的な反復プロセスとして扱い、ログを定期的に確認します。

考慮事項

  • プロファイリングは、システムに大きなオーバーヘッドを課す可能性があるため、必要な場合にのみ実装します。 インストルメンテーションを使用すると、プロファイリングによって、発生するたびにメソッド呼び出しなどのイベントが記録されます。 ただし、サンプリングでは、選択したイベントのみが記録されます。

  • プロファイリングの選択には、時間ベース ( n 秒ごとに 1 回など) や頻度ベース ( n 回の要求ごとに 1 回など) を指定できます。 イベントが頻繁に発生する場合、プロファイリングによってシステムに大きな負担がかかりすぎて、全体的なパフォーマンスに影響を与える可能性があります。 この場合、サンプリングアプローチが好ましい。 ただし、イベントの発生頻度が低い場合、サンプリングではイベントをキャプチャできないことがあります。 この場合、プロファイリングの方が適切な方法である可能性があります。

Azure ファシリテーション

Autoinstrumentation は、 Application Insights で監視されるさまざまな種類の Azure およびオンプレミス アプリケーションで使用できます。 autoinstrumentation 関数は、Application Insights に豊富なテレメトリを提供するようにアプリケーションを自動的に構成し、 アプリケーション ダッシュボード や アプリケーション マップなどのエクスペリエンスに簡単にアクセスできます。 サポートされているホスティング プラットフォームと開発言語については、「 サポートされている環境、言語、およびリソース プロバイダー」を参照してください。

オペレーショナル エクセレンス チェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンス チェックリスト