AIS サービス ランディング ゾーン アクセラレータの運用管理に関する考慮事項
この記事では、AIS オファリングを使用する際の運用管理と監視に関する考慮事項と推奨事項について説明します。
このセクションの推奨事項のほとんどは、Standard (シングルテナント) バージョンの Logic Apps に適用されます。これは、それ自体が Azure App Service オファリングの一部であり、同じ管理機能の多くを共有しています。
AIS を構成する多くのリソースは、Log Analytics/Application Insights、またはカスタム ストレージの場所 (ストレージ アカウント、Event Hubs など) にログ、テレメトリ、メトリック データを格納するように構成できます。
この情報を利用して、リソースの全体的な正常性を視覚化し、適切な管理アクションを実行できます。
定義
Azure Monitor ログでは、監視対象のリソースからログとパフォーマンス データを収集して編成します。 その後、Log Analytics などのツールで、このログ情報を照会または視覚化したり、特定の条件が満たされた場合にアラートを生成したりできます。
Azure メトリック ログでは、監視対象のリソースから時系列データベースに数値データを収集します。 その後、Application Insights などのツールで、このデータを視覚化し、パフォーマンスとランタイムの問題を特定できます。
Log Analytics は Azure Monitoring オファリングであり、ログとパフォーマンス データを格納する場所を提供し、それらのログのクエリを実行するためのメカニズムと言語を提供し (Kusto)、(いくつかある機能の中で特に) それらのログに基づいてアラートとダッシュボードを作成する機能を提供します。
Application Insights は Azure Monitoring オファリングであり、監視対象のリソースによって出力されるパフォーマンス データを視覚化してアラートを生成する機能を提供します。
Kusto 照会言語 (KQL) は、データのクエリと書式設定に最適化された強力なクエリ言語です。 たとえば、Log Analytics の主要なクエリ言語です。
デザインに関する考慮事項
監視ソリューション全体を考えます。
どのようなリソースを監視する必要がありますか?
リソース間を流れるメッセージをどのように追跡しますか?
どのような外部システムに接続しますか?
どのような種類のアラートが必要ですか?
実行する必要があるクエリについて考えます。 たとえば、特定の要求に予想以上の時間がかかるかどうかを知る必要がありますか? 単一のエラーとエラーのクラスターが発生したかどうかについてはどうですか?
どのレベルの追跡が必要ですか? たとえば、サード パーティからメッセージが到着した場合、関連付けられているすべてのリソースでそのメッセージを追跡する必要がありますか?
実行する必要がある管理タスクは何ですか? メッセージまたはファイルを再送信する必要がありますか?
ロジック アプリの実行履歴は既定で Azure Storage に格納されますが、メトリックとログ ファイルを他のソース (Log Analytics、外部ストレージ アカウントなど) にエクスポートすることもできます。 ログ情報の使用方法と、一元化されたログ ストアを使用する場合を考慮します。
Application Insights は、アプリケーション パフォーマンス監視を提供するために使用されます。 これは、ソリューションを構成するリソースからメトリックを収集することで行われます。
Log Analytics は、ログのクエリとアラートの設定に使用され、リソースの正常性を確認し、発生する可能性のある問題を把握できます。 ログ データにはカスタム プロパティを含めることができます (後述の ''追跡対象のプロパティ'' に関する説明を参照)。
App Services に固有の考慮事項と推奨事項について詳しくは、App Service ランディング ゾーン アクセラレータの管理に関する記事を参照してください
設計上の推奨事項
Log Analytics ワークスペースをデータ ソースとして使用するように Application Insights を設定します (ワークスペース ベースのリソースと呼ばれる)。 これにより、ログとパフォーマンス データを統合された場所に保持できます。
すべてのリソースのアラートを設定して、個々のリソースまたはワークロードに関連するイベントを適切なチームに通知します。
サポートされている場合は、ソリューション内のリソースを Application Insights にリンクします。 たとえば、ランタイム データとメトリックをクエリに使用できるように、ロジック アプリを Application Insights にリンクできます。 例については、こちらを参照してください。
Logic Apps の clientTrackingId 機能を使用してカスタム追跡 ID を指定し、ロジック アプリの実行間のイベントを関連付けることができます。 x-ms-client-tracking-id ヘッダーを使用すると、Request、HTTP、または HTTP+WebHook トリガーでこの結果が得られます。
Logic Apps の追跡対象プロパティ機能を使用して、アクションの他のデータ (入力または出力) をログ ファイルに記録します。 その後、これらのプロパティは、Log Analytics または別のソリューションで KQL を使用してログに対してクエリを実行するときに使用できます。
リソース タグの使用を検討してください。 リソース タグは、Azure でリソースを管理および整理するのに役立ちます。 これらを使用して、リソースにメタデータを割り当てることができます。 このメタデータは、アプリケーションや部署別のリソースの分類、リソースのコストの追跡、コンプライアンスのためのリソースの識別などの、さまざまな目的で使用できます。
サンプル Kusto クエリ
以下のクエリは、AIS ログ データに使用される 3 つの主なテーブルに対してクエリを実行する方法を示しています。 これらの各テーブルには、ロジック アプリの [監視] セクションの [ログ] オプションからアクセスできます。
主なクエリ テーブルは次のとおりです。
exceptions
このテーブルには、ロジック アプリ ランタイムによってスローされた例外など、リソースによってログに記録された例外が含まれています。 ポータルまたはコードの実行中に表示される問題の根本的な原因を探すために使用できます。requests
このテーブルでは、ロジック アプリ ランタイムによって別のリソースまたはワークフロー内の特定のアクションに対して行われたすべての要求を記録します。traces
このテーブルには、Logic Apps ランタイム ログの大部分、トリガーの実行、ワークフローの開始と停止、およびアクションの実行に関するログの詳細が含まれています。 アクションから追跡されたプロパティをログに記録した場合、このデータは customDimensions セクションにあります。 その後、クエリで extend 句を使用して、クエリ応答に列としてデータを追加できます。
エラーのあるワークフロー:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions.LogLevel == "Error"
すべてのワークフローにわたる過去 24 時間のワークフロー実行の数:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count
トリガーの成功率 (経時的にグラフ化)
> traces
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
> \| where customDimensions\["EventName"\] == "WorkflowTriggerEnd"
> \|summarize
>
> success = countif(customDimensions\["prop\_\_status"\] ==
> "Succeeded"),
>
> failures = countif(customDimensions\["prop\_\_status"\] == "Failed")
>
> by bin(timestamp, 1m)
> \| render timechart
次のステップ
重要な設計領域を確認し、アーキテクチャの完全な考慮事項と推奨事項を作成します。