監視システムの設計と作成に関する推奨事項
この Power Platform Well-Architected オペレーショナル エクセレンス チェックリストの推奨事項に適用されます:
| OE:06 | 監視システムを設計および実装して、設計の選択を検証し、将来の設計およびビジネス上の決定を通知します。 このシステムは、ワークロードから出力される運用テレメトリ、メトリック、ログをキャプチャして公開します。 |
|---|
このガイドでは、監視システムの設計と作成に関する推奨事項について説明します。 セキュリティ、パフォーマンス、信頼性に関してワークロードを効果的に監視するには、すべての監視、検出、アラート機能の基盤となる独自のスタックを備えた包括的なシステムが必要です。
定義
| 用語 | 定義 |
|---|---|
| ログ | 記録されたシステム イベント。 ログには、構造化テキスト形式または自由形式のテキスト形式でさまざまな種類のデータを含めることができます。 タイムスタンプが含まれています。 |
| メトリック | 一定の間隔で収集される数値。 メトリックは、特定の時点におけるシステムのいくつかの側面を説明します。 |
主要な設計戦略
ワークロードに合わせた包括的な監視システム設計を実装するには、次の基本原則に従います。
可能な限り、プラットフォームが提供する監視ツールを活用してください。通常、これらのツールは構成をほとんど必要としないため、通常では取得が難しいワークロードの詳細な分析情報を提供することができます。
ワークロード スタック全体からログとメトリックを収集します。 すべてのロー コードおよびコード ファーストのコンポーネントとリソースは、標準化された意味のあるデータを生成するように構成する必要があり、そのデータを収集する必要があります。
収集したデータを、標準化された信頼性の高い安全なストレージ ソリューションに保存します。
保存されたデータを分析およビジュアル化ソリューションで処理できるように処理します。
処理されたデータを分析して、ワークロードの状態を正確に判断します。
ワークロード チームやその他の関係者にとって意味のあるダッシュボードまたはレポートでワークロードの状態を視覚化します。
問題が発生したときにワークロード チームに通知するために、インテリジェントに定義されたしきい値に対する実用的なアラートやその他の自動応答を構成します。
全体的なワークロード テスト プラクティスに監視およびアラート システムを含めます。
監視および警告システムが継続的な改善の範囲内であることを確認します。 運用環境でのアプリケーションと構成の動作は、継続学習の機会を提供します。 これらの教訓を監視および警告の設計に取り入れます。
収集した監視データをシステムとユーザー フローに結びつけ、分析します。これにより、フローの健全性とデータ、およびワークロード全体の正常性を相関させることができます。 そのデータをフローの観点で分析することで、可視化戦略を正常性モデルと整合させることができます。
法律や規制を確実に遵守するために、個人を特定できる情報の保存は最小限に抑えます。 識別可能な情報を保存する必要がある場合は、ソリューションを設計するときに、個人が情報の削除を要求できる要件を考慮に入れてください。
なりすましに使用される可能性のあるユーザーのパスワードやその他の情報は決して記録しないでください。 これらの詳細情報は、データが保存される前に削除します。 規制要件に、監査とセキュリティのために収集された情報をアーカイブして保存する必要があることが定められている場合があります。 まが、このデータは機密性が高く、改ざんを防ぐために暗号化またはその他の方法で保護する必要がある場合もあります。
監視システムのすべての機能を可能な限り自動化し、毎日終日継続的に実行する必要があります。
このワークフロー パイプラインは監視システムを示しています。
コレクション
ローコード、コードファーストのコンポーネント、環境やポリシーなどのプラットフォーム設定のいずれであっても、すべてのワークロード コンポーネントを構成して、ログやメトリックなどのテレメトリとイベントをキャプチャする必要があります。
ログは主に、異常の検出と調査に役立ちます。 通常、ログはワークロード コンポーネントによって生成され、監視プラットフォームに送信されるか、監視プラットフォームによって自動化されて取得されます。
メトリックは主に正常性モデルの構築と、ワークロードのパフォーマンスと信頼性の傾向を特定するのに役立ちます。 メトリックは、ユーザーの使用行動の傾向を特定するのにも役立ちます。 これらの傾向は、顧客の観点から改善に関する意思決定を行うのに役立ちます。 通常、メトリックは監視プラットフォームで定義され、監視プラットフォームとその他のツールはワークロードをポーリングしてメトリックを取得します。
ワークロード データ
データを収集するには、既成のApplication Insights との統合を使用します。 Application Insights を有効にすると、重要なイベントをリアルタイムと履歴の両方で明確に把握できます。
アプリケーション ログは、エンド ツー エンドのアプリケーション ライフ サイクルをサポートします。 ログは、アプリケーションがさまざまな環境でどのように動作するか、どのイベントが発生するか、どのような条件で発生するかを理解するために不可欠です。
すべての主要な環境にわたってアプリケーション ログとイベントを収集することをお勧めします。 実用的であれば、環境ごとに異なるデータ ストアを使用して、可能な限り環境間でデータを分離します。 フィルターを使用して、重要でない環境によって運用ログの解釈が複雑にならないようにします。 最後に、アプリケーション全体の対応するログ エントリは、それぞれのトランザクションの関連付け ID をキャプチャする必要があります。
インフラストラクチャ データと構成データ
ワークロード内のインフラストラクチャ リソースで、ログとメトリックの両方を必ず収集してください。 Power Platform はサービスとしてのプラットフォーム (PaaS) の機能であるため、基になるインフラストラクチャに関連するログをキャプチャする機能が制限される場合があります。 ただし、ワークロードの正常性とインシデントに関連する構成とポリシーの変更に関するログと分析をキャプチャすることはできます。
可能な限り、クラウド プラットフォームからログを収集します。 サブスクリプションのアクティビティ ログと管理プレーンの診断ログを収集できる可能性があります。
パフォーマンスに関する考慮事項
複雑で高スケーラブルなアプリケーションは、大量のデータを生成できます。 アプリケーション レベルでのトレースの詳細度に応じて、データの量によりパフォーマンスの問題が発生する場合があります。 テレメトリ ソリューションはボトルネックとして機能してはならず、システムの拡張に合わせてスケーラブルである必要があります。
分析
さまざまなソースからデータを収集したら、それを分析してシステム全体の正常性を評価します。 この分析を行うために、次のことを明確に理解しておきます。
- 定義した主要業績評価指標 (KPI) およびその他の業績評価指標に基づいてデータを構造化する方法。
- さまざまなメトリックとログ ファイルでキャプチャされたデータを関連付ける方法。 この関連付けは、一連のイベントを追跡する場合に重要であり、問題の診断に役立ちます。
ほとんどの場合、ワークロードにはさまざまなコンポーネンやログトが含まれ、イベントはさまざまな形式またはテーブルでキャプチャされます。 ワークロードの全体的な正常性を理解するには、データを正確に組み合わせる必要があります。
たとえば、Power Platform ソリューションが次のコンポーネントで構成されているとします。
- ユーザーがデータを操作できるキャンバス アプリ
- 管理者がアプリケーションの設定を構成できるモデル駆動型アプリ
- データ操作を実行するクラウド フロー
- 操作に関連付けられたデータを保存する Dataverse インスタンス
- Azure テーブル ストレージからデータを取得し、アプリケーションから呼び出される Azure 関数
単一のビジネス操作の使用状況データは、ワークロードのすべてのコンポーネントに及ぶ可能性があります。 操作のリソースと処理の使用状況の全体像を把握するには、この情報を関連付ける必要があります。
データの分析に関する推奨事項
アプリケーション レベルとリソース レベルのログを関連付けます。 両方のレベルでデータを評価して、問題の検出とトラブルシューティングを最適化します。
コールド分析のためのストレージの保持時間を明確に定義します。 特定の期間の履歴分析を可能にするには、このプラクティスをお勧めします。 また、ストレージ コストの管理にも役立ちます。 データを確実に安価なストレージにアーカイブし、長期的な傾向分析のためにデータを集約するプロセスを実装します。
長期的な傾向を分析して運用上の問題を予測します。 長期データを評価して運用戦略を策定し、どのような運用上の問題がいつ発生するかを予測します。 たとえば、平均応答時間が時間の経過とともに徐々に増加し、最大ターゲットに近づいていることに注意することができます。
ビジュアル化
稼働状況の監視のビジュアル化は、ワークロードの状態を理解するために重要です。 視覚化は、問題と傾向をすばやく特定するのに役立ち、ワークロードに加えた変更の影響を理解する際にも役立ちます。
ダッシュボード
データを視覚化する最も一般的な方法は、チャートやグラフの形式で情報を表示できるダッシュボードを使用することです。 これらの項目はパラメーター化でき、アナリストは特定の状況に対して期間などの重要なパラメーターを選択できます。
ダッシュボードを正常性モデルに合わせて調整し、ワークロードまたはワークロードのコンポーネントが正常、劣化、または異常な状態であるかどうかを示します。
ダッシュボード システムが効果的に機能するには、ワークロード チームにとって意味のあるものでなければなりません。 ワークロードの正常性に関連し、実用的な情報を視覚化します。 ワークロードまたはコンポーネントがデグレードまたは異常な状態になった場合、ワークロード チームのメンバーは、ワークロード内のどこで問題が発生しているかを簡単に特定し、修正アクションまたは調査を開始できる必要があります。 逆に、実行可能な情報ではないものや、作業負荷の正常性に関係のない情報を含めると、ダッシュボードが不必要に複雑になり、実行可能なデータからバックグラウンドノイズを識別しようとしているチームメンバーにとって、フラストレーションのたまるものとなる可能性があります。
関係者や開発者向けに、関係があると思われるワークロードに関するデータのみを表示するようにカスタマイズされたダッシュボードを用意することができます。 ワークロード チームが、他のチームが確認したいデータ ポイントの種類を理解していることを確認し、共有する前にダッシュボードをプレビューして明確であることを確認するようにします。 関係者に対して作業負荷に関するダッシュボードを提供することは、作業負荷の正常性を把握してもらうには良い方法ですが、関係者がデータを明確に理解していない場合、逆効果になるリスクがあります。
ダッシュボードへのアクセスを許可された担当者に制限します。 ダッシュボード上の情報は機密情報である可能性があります。 また、基礎となるデータを保護して、ユーザーがデータを変更できないようにする必要があります。
レポート
レポートは、システムの全体的なビューを生成するために使用されます。 履歴データと現在の情報が含まれます。 レポート要件は、運用レポートとセキュリティ レポートという 2 つの大きなカテゴリに分類されます。
運用レポートには通常、次のものが含まれます。
- 指定された時間枠内のシステム全体または指定されたサブシステムのリソース使用状況を把握するために使用できる統計を集計します。
- 指定された期間におけるシステム全体または指定されたサブシステムのリソース使用状況の傾向を特定します。
- 指定された期間中にシステム全体または指定されたサブシステムで発生した例外を監視します。
- 展開されたリソースに対するアプリケーションの効率を判断し、パフォーマンスに不必要に影響を与えることなくリソースの量とそれに関連するコストを削減できるかどうかを理解します。
セキュリティ レポートは、顧客のシステム使用状況を追跡します。 次のものが含まれます。
- ユーザー操作の監査。 このタスクでは、各ユーザーが完了した個々のリクエストを日時とともに記録する必要があります。 データは、管理者 が指定された期間中にユーザーが完了する操作のシーケンスを迅速に再構築できるように構造化する必要があります。
- ユーザーのリソース使用状況の追跡。 このタスクでは、ユーザーからの各要求がシステム内のさまざまなリソースにどのようにアクセスし、どのくらいの期間アクセスするかを記録する必要があります。 管理者はこのデータを使用して、指定された期間のユーザー別の使用状況レポートを生成し、請求に使用することができます。
アラート
システムの正常性、応答性、安全性を維持するために、オペレーターがタイムリーに対応できるようにアラートを設定します。 アラートには、診断活動をすぐに開始するのに役立つ十分なコンテキスト情報を含めることができます。
アラートに関する推奨事項
- 責任のある所有者とアクションを特定するアラート対応のプロセスを定義します。
- 明確に定義された範囲に対してアラートを設定し、詳細度を調整してノイズを最小限に抑えます。
- ユーザーが問題を積極的に探すのではなく、Splunk や Azure Monitor などの自動アラート ソリューションを使用します。
- アラートを使用して修復プロセスを運用可能にします。 たとえば、問題と解決策を追跡するためのチケットを自動的に作成します。
しきい値
しきい値を超えて、監視システムによって検出されると、アラートが生成されます。 設定したしきい値によって、パフォーマンスの低下や停止を回避するためにワークロードに必要な変更を実装するのに十分な時間を確保します。 また、アラートの数を減らすために、必要なエラー処理を実装し、ワークロード内の既知のエラーを見つける必要があります。 たとえば、クラウド フローでのアクションの再試行ポリシーを構成して、フロー実行の一部として再試行が試行され、再試行が繰り返されても失敗した場合にのみ、フローの失敗が記録されてアラートが送信されます。 詳細については、信頼性の高いモニタリングとアラート戦略の設計に関する推奨事項をご参照ください。
Power Platform の促進
Power Platform は、Azure Monitor エコシステムの一部である Application Insights と統合します。 この統合は以下に使用します。
Application Insights の Dataverse プラットホーム で取得された診断とパフォーマンスに関するテレメトリを受信します。 アプリケーションが Dataverse データベースおよびモデル駆動型アプリ内で実行する操作に関するテレメトリを受信するようにサブスクライブできます。 このテレメトリは、エラーとパフォーマンスに関連する問題の診断とトラブルシューティングに使用できる情報を提供します。
キャンバス アプリから Application Insights に接続します。 これらの分析を使用して問題を診断し、ユーザーがアプリで何を行っているかを把握できます。 より適切なビジネス上の意思決定に役立つ情報を収集し、およびアプリの品質を向上することができます。
Power Automate テレメトリを構成して Application Insights へとフローするようにします。 たとえば、クラウド フローの実行を監視し、クラウド フローの実行の失敗に関するアラートを作成できます。
Microsoft Copilot Studio エージェントから Azure Application Insightsで使用するためのテレメトリ データをキャプチャします。 このテレメトリを使用して、エージェントとの間で送受信されるログに記録されたメッセージとイベント、ユーザーの会話中にトリガーされるトピック、およびトピックから送信できるカスタムテレメトリイベントを監視できます。
Power Platform は、Microsoft Purview コンプライアンス ポータル でログの活動をリソースします。 ほとんどのイベントはアクティビティの 24 時間以内に利用可能になります。 この情報をリアルタイム監視に使用しないでください。 Power Platform でのログ活動についての情報は、次を参照してください。
- Power Apps
- Power Automate
- Copilot Studio
- Power Pages
- Power Platform コネクタ
- データ損失防止
- Power Platform 管理ログ
- Dataverse 監査
Power Platform のワークロードには、Azure のリソースが含まれる場合があります。 詳細については、監視システムの設計と構築に関する推奨事項をご参照ください。
Power PlatformCoE スターター キットは、Power Platform の採用とサポートのための戦略開発に役立つように設計されたコンポーネントおよびツールのコレクションを含む参照実装です。 CoE スタート キットには、豊富なダッシュボードのセットが含まれています。 詳細情報については、CoE Power BI ダッシュボードで、Microsoft Power Platform 導入に関する深い分析情報を入手するを参照してください。
Power Platform オートメーション キット は、自動化プロジェクトにおけるデスクトップ用 Power Automate の使用とサポートを加速させる一連のツールです。 このキットは、自動化プロジェクトを管理し、それらをモニタリングして節約された費用と投資収益率 (ROI) を見積もるのに役立つツールを提供します。 オートメーション キットの一部である コントロール センターは、デスクトップ フロー実行の監視機能を補完します。 コントロール センターの主な焦点は、サポート アナリストと組織が監視し、アクションを実行し、必要に応じて警告するためのオーケストレーター ビューです。