Important
非推奨の通知: この記事は非推奨であり、更新されなくなりました。 最適なガイダンスのみが表示されるように、この記事は 2026 年 5 月に削除されます。
別のガイダンスについては、Azure アーキテクチャ センターの integration アーキテクチャ ガイダンスを参照してください。
このガイダンスを保存する場合は、このページの左下にある PDF をダウンロードするか、GitHub からファイルをダウンロードします。
この記事では、AIS オファリングを使用する場合の運用管理と監視に関する考慮事項と推奨事項について説明します。
このセクションの推奨事項のほとんどは、Standard (シングルテナント) バージョンの Logic Apps に適用されます。これは、それ自体がAzure App Serviceオファリングの一部であり、同じ管理機能の多くを共有します。
AIS を構成する多くのリソースは、ログ、テレメトリ、メトリック データを Log Analytics/Application Insights またはカスタム ストレージの場所に格納するように構成できます (これらのリソースには、ストレージ アカウント、Event Hubs などが含まれます)。
この情報を利用して、リソースの全体的な正常性を視覚化し、適切な管理アクションを実行できます。
定義
Azure Monitor Logs は、監視対象のリソースからログとパフォーマンス のデータを収集して整理します。 Log Analyticsなどのツールを使用すると、このログ情報を照会または視覚化したり、特定の条件が満たされた場合にアラートを生成したりできます。
Azure メトリック ログは、監視対象のリソースから時系列データベースに数値データを収集します。 Application Insights などのツールは、このデータを視覚化して、パフォーマンスとランタイムの問題を特定するのに役立ちます。
Log Analytics はAzure監視オファリングであり、ログとパフォーマンス データを格納する場所を提供し、それらのログ (Kusto) を照会するためのメカニズムと言語を提供し、それらのログ (その他の機能の中で) に基づいてアラートとダッシュボードを作成する機能を提供します。
Application Insights はAzure監視オファリングであり、監視対象リソースによって生成されたパフォーマンス データを視覚化してアラートを生成できます。
Kusto クエリ言語 (KQL) は、データのクエリと書式設定に最適化された強力なクエリ言語です。 たとえば、Log Analyticsの主要なクエリ言語です。
設計に関する考慮事項
監視ソリューション全体を考えてみましょう。
監視する必要があるリソースは何ですか?
リソース間を流れるメッセージを追跡する方法
どの外部システムに接続しますか?
どのような種類のアラートが必要ですか?
実行する必要があるクエリについて考えてください。 たとえば、特定の要求に予想以上の時間がかかるかどうかを知る必要がありますか? 単一エラーが発生する場合と複数のエラーが発生する場合とではどうなりますか？
どのレベルの追跡が必要ですか? たとえば、サード パーティからメッセージが届く場合、関連するすべてのリソースでそのメッセージを追跡する必要がありますか。
実行する必要がある管理タスク メッセージまたはファイルを再送信する必要がありますか?
ロジック アプリの実行履歴は既定でAzure Storageに格納されますが、メトリックとログ ファイルを他のソース (Log Analytics、外部ストレージ アカウントなど) にエクスポートすることもできます。 ログ情報を使用する方法と、一元化されたログ ストアを使用する場合を検討してください。
Application Insights は、アプリケーションのパフォーマンス監視を提供するために使用されます。 これを行うには、ソリューションを構成するリソースからメトリックを収集します。
Log Analyticsは、ログのクエリとアラートの設定に使用され、リソースの正常性を確認し、発生する可能性のある問題を把握できます。 ログ データには、カスタム プロパティを含めることができます (以下 の追跡プロパティを 参照)。
App Services に固有の考慮事項と推奨事項については、App Service ランディング ゾーン アクセラレータ の管理に 関する記事を参照してください
設計に関する推奨事項
Log Analytics ワークスペースをデータ ソース (
workspace ベースのリソース) として使用するように、 を設定します。 これにより、ログ記録とパフォーマンス データを統合された場所に保持できます。Application Insights 個々のリソースまたはワークロードに関連するイベントを適切なチームに通知するために、すべてのリソースのアラートを設定します。
サポートされている場合は、ソリューション内のリソースを Application Insights にリンクします。 たとえば、ロジック アプリを Application Insights にリンクして、ランタイム データとメトリックをクエリに使用できるようにします。 例については、こちらを参照してください。
Logic Apps の clientTrackingId 機能を 使用してカスタム追跡 ID を指定し、ロジック アプリの実行間でイベントを関連付けることができます。 x-ms-client-tracking-id ヘッダーを使用して、要求、HTTP、または HTTP+WebHook トリガーを使用してこの結果を実現できます。
Logic Apps の 追跡プロパティ 機能を使用して、アクションの他のデータ (入力または出力) をログ ファイルに記録します。 これらのプロパティは、Log Analyticsまたは別のソリューションで KQL を使用してログにクエリを実行するときに使用できます。
リソース タグの使用を検討してください。 リソース タグは、Azureでリソースを管理および整理するのに役立ちます。 これらを使用して、メタデータをリソースに割り当てることができます。 このメタデータは、アプリケーションまたは部署別のリソースの分類、リソースのコストの追跡、コンプライアンスのためのリソースの識別など、さまざまな目的に使用できます。
Kusto クエリのサンプル
次のクエリは、AIS ログ データに使用される 3 つのメイン テーブルに対してクエリを実行する方法を示しています。 これらの各テーブルには、ロジック アプリの [監視] セクションの [ログ] オプションからアクセスできます。
メイン クエリ テーブルは次のとおりです。
例外
このテーブルには、ロジック アプリ ランタイムによってスローされた例外など、リソースによってログに記録された例外が含まれています。 ポータルまたはコードの実行中に表示される問題の根本的な原因を探すために使用できます。リクエスト
次の表は、ロジック アプリ ランタイムによって別のリソースまたはワークフロー内の特定のアクションに対して行われたすべての要求をログに記録します。痕跡
この表には、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
次のステップ
重要な設計領域を確認して、アーキテクチャに関する完全な考慮事項と推奨事項を作成します。