次の方法で共有

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

  • [アーティクル]

Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

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

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

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

主要な設計戦略

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

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

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

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

Note

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

構造化ログとトレースを使用する

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

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

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

Note

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

アプリケーション メトリックを取り込む

メトリック (または "サンプル") は、特定の時点におけるシステム内の何らかの側面またはリソースの数であり、1 つ以上のタグまたはディメンションが関連付けられています。 1 インスタンスのメトリックは、単独では役に立ちません。時間をかけてメトリックを取り込む必要があります。 どのメトリックをどのくらいの頻度で記録する必要があるかを検討してください。 データが頻繁に生成されるとシステムに大きな負荷がかかる可能性がありますが、データ キャプチャの頻度が低いと、重大なイベントにつながる状況を見逃す可能性があります。 データを取り込む適切な頻度は、メトリックごとに異なる場合があります。 たとえば、サーバーの CPU 使用率は秒単位で大幅に変化する可能性がありますが、高い使用率が問題になるのは、それが数分間にわたって継続する場合のみです。

コンポーネント間の相関関係を容易にする

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

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

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

Note

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

関連データを取り込む

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

人が判読できるデータ

トレース イベントによって取り込まれた情報は、コンピューターと人間の両方が判読できるものにする必要があります。 この情報に対して適切に定義されたスキーマを採用すると、システム全体でログ データの自動処理を実装し、ログを読み取る運用とエンジニアリングのスタッフに一貫性を提供できます。

データには次のような環境情報を含めてください。

  • デプロイ環境
  • 処理マシン
  • プロセスの詳細
  • 呼び出し履歴

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

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

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

測定の場合、要求を引き起こした顧客への言及をコンテキストに直接的または間接的に含めるようにします。 このコンテキストは、監視データがキャプチャされた時点のアプリケーションの状態に関する重要な情報を提供します。

関連するすべてのデータを取り込む

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

例外の詳細を慎重に記録してキャプチャします。 不適切な例外処理の結果として重要なデバッグ情報が失われることがしばしばあります。 可能であれば、内部例外やその他のコンテキスト情報 (呼び出し履歴など) を含め、アプリケーションからスローされるすべての例外の詳細を取り込みます。

データの一貫性を追求する

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

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

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

アプリケーションでも、独自のパフォーマンス カウンターを定義していることがあります。

外部依存関係を検討する

すべての外部サービス呼び出しをログします。 外部呼び出しは、以下に対して行われる可能性があります。

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

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

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

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

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

  • イベント名。
  • イベント時間。
  • 送信者の IP アドレス。
  • 次のように、他のイベントと相関させるために必要な詳細。
    • User ID
    • Device ID
    • アプリケーション ID

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

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

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

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

インストルメンテーション コードを最適化する

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

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

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

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

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

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

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

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

  • すべての重大な例外をログしても、必要に応じて、管理者がログのオンとオフを切り替えて例外と警告を減らせるようにします。

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

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

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

  • すべてのログ呼び出しは、業務処理の進行を妨げない "ファイア アンド フォーゲット" 操作にする必要があります。 監査イベントは業務に不可欠であるため、この規則から除外します。

  • ログには拡張性を確保し、具体的なターゲットに直接依存しないようにする必要があります。

  • すべてのログをフェイルセーフにして、連鎖エラーをトリガーしないようにします。

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

アプリケーション プロファイルを使用する

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

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

Azure ファシリテーション

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

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

レコメンデーションの完全なセットを参照してください。

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