監視システムの設計と作成に関する推奨事項
この Power Platform Well-Architected Operational Excellenceチェックリストの推奨事項に適用されます:
| 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に流入するように構成します。 たとえば、クラウド フロー の実行を監視し、クラウドフローの実行失敗に関するアラートを作成できます。
Azureで使用するために、 Microsoft Copilot Studio copilot からテレメトリ データをキャプチャします Application Insights。 このテレメトリを使用すると、コパイロットとの間で送受信されるログに記録されたメッセージとイベント、ユーザーの会話中にトリガーされるトピック、トピックから送信できるカスタム テレメトリ イベントを監視できます。
Power Platform リソースは、 Microsoft Purviewコンプライアンス ポータルにアクティビティを記録します。 ほとんどのイベントはアクティビティの 24 時間以内に利用可能になります。 この情報をリアルタイム監視に使用しないでください。 Power Platform でのログ活動についての情報は、次を参照してください。
- Power Apps
- Power Automate
- Copilot Studio
- Power Pages
- Power Platform コネクタ
- データ損失防止
- Power Platform 管理ログ
- Dataverse 監査
ワークロードにはAzureリソースが含まれる場合があります。 Power Platform 詳細については、 監視システムの設計と作成に関する推奨事項をご覧ください。
Power PlatformCoE スターター キットは、Power Platform の採用とサポートのための戦略開発に役立つように設計されたコンポーネントおよびツールのコレクションを含む参照実装です。 CoEスターター キットには、豊富なダッシュボード セットが含まれています。 詳細については、「CoEダッシュボードを使用して、導入に関する詳細な情報を取得する」をご覧ください。 Microsoft Power Platform Power BI
Power Platform オートメーション キット は、自動化プロジェクトにおけるデスクトップ用 Power Automate の使用とサポートを加速させる一連のツールです。 このキットは、自動化プロジェクトを管理し、それらをモニタリングして節約された費用と投資収益率 (ROI) を見積もるのに役立つツールを提供します。 自動化キットの一部である コントロール センターは、モニター デスクトップ フロー 実行機能を補完します。 コントロール センターの主な焦点は、サポート アナリストと組織が監視し、アクションを実行し、必要に応じて警告するためのオーケストレーター ビューです。