Azure Container Apps のログとメトリック
Note
Basic、Standard、Enterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。
Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。
この記事の適用対象:✅ Basic/Standard ✅ Enterprise
Azure Spring Apps から Azure Container Apps に移行すると、監視のための類似の機能が複数ありますが、それらにはいくつかの重要な違いがあります。 この記事では、これらの違いについて説明し、Azure Container Apps でアプリケーションを監視する方法について説明します。
前提条件
- 既存の Azure Container Apps。 詳細については、クイックスタート: Azure portal を使用して最初のコンテナー アプリをデプロイする を参照してください。
- Azure CLI。
ログ
ログのオプションを構成する
Azure Container Apps を使用すると、Azure Container Apps 環境でログ記録を管理できます。
ログは、Azure Log Analytics と Azure Monitor の両方に格納できます。 Azure Monitor を選択すると、Azure Spring Apps の場合と同様に、環境設定に診断設定メニューが表示されます。
次の例に示すように、Azure CLI を使用して環境を作成すると、自動生成された Log Analytics ワークスペースがプロビジョニングされます。
az containerapp env create \
--resource-group MyResourceGroup \
--name MyContainerappEnvironment \
--location eastus2
次のコマンドを使用して、既存の Log Analytics ワークスペースを持つ環境を作成することもできます。
az containerapp env create \
--resource-group MyResourceGroup \
--name MyContainerappEnvironment \
--logs-workspace-id myLogsWorkspaceID \
--logs-workspace-key myLogsWorkspaceKey \
--location eastus2
ログの分析
Azure Container Apps を使用すると、コンテナー コンソールからログをストリーミングできます。 次の一覧に、ログ記録の主な相違点を示します。
コンソール ログ: コンソール ログの場合は、テーブルに対するクエリは、Azure Spring Apps で使用される
ApplicationConsoleテーブルでなく、Azure Container Apps のContainerAppConsoleLogs_CLテーブルに対して実行します。システム ログ: Azure Spring Apps は、Config Server、Service Registry、API ポータル、Application Configuration Service、Spring Cloud Gateway に対して
SystemLogsを提供します。 Azure Container Apps では、これらのコンポーネントを個別のアプリケーションとしてプロビジョニングし、それらのログに対するクエリはContainerAppConsoleLogs_CLテーブル内で実行し、そのときに、クエリ内に各アプリの名前を指定する必要があります。ビルド ログ: Paketo Buildpacks を使用したローカル ビルドからのビルド ログは、Azure Container Apps では使用できません。この点は Azure Spring Apps と異なります。
ログを表示する
既定では、Azure Container Apps はログを Azure Log Analytics に直接送信します。 ただし、Azure Monitor にログを格納する場合は、テーブル名と列名が異なる場合があります。 Azure Monitor では、テーブル名と列名にサフィックスは含まれません。 たとえば、Azure Monitor に格納されているログのクエリを作成するときは、ContainerAppConsoleLogs_CL の代わりに ContainerAppConsoleLogs を使用し、Log_s の代わりに Log を使用します。
Azure Container Apps でコンソール ログを表示するには、たとえば次のクエリを使用します。
ContainerAppConsoleLogs_CL
| limit 50
Azure Log Analytics は Kusto エンジンを使用して実行されているので、分析のためにログに対してクエリを実行できます。 Kusto を使用したログのクエリの概要については、「Log Analytics のチュートリアル」を参照してください。
アプリケーション ログを表示する
アプリケーション ログの一覧を、最新のログが最初に表示されるように時間順に並べ替えて確認するには、次のクエリを使用します。
ContainerAppConsoleLogs_CL
| project TimeGenerated, EnvironmentName_s, ContainerAppName_s, RevisionName_s, Log_s
| sort by TimeGenerated desc
エラーまたは例外を含むログ エントリを表示する
エラーまたは例外を示す並べ替えられていないログ エントリを確認するには、次のクエリを使用します。
ContainerAppConsoleLogs_CL
| project TimeGenerated, EnvironmentName_s, ContainerAppName_s, RevisionName_s, Log_s
| where Log_s contains "error" or Log_s contains "exception"
このクエリを使用してエラーを検出するか、クエリ用語を変更して特定のエラー コードまたは例外を検索します。
過去 1 時間にアプリケーションから報告されたエラーと例外の数を表示する
過去 1 時間にアプリケーションによってログに記録されたエラーと例外の数を表示する円グラフを作成するには、次のクエリを使用します。
ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(1h)
| where Log_s contains "error" or Log_s contains "exception"
| summarize count_per_app = count() by ContainerAppName_s
| sort by count_per_app desc
| render piechart
Spring Cloud Gateway のログを表示する
Spring Cloud Gateway ログのログ エントリを確認するには、次のクエリを使用します。
ContainerAppSystemLogs_CL
| where ComponentType_s == "SpringCloudGateway"
| project TimeGenerated, ComponentType_s, EnvironmentName_s, ComponentName_s, Log_s
| limit 100
Eureka サーバーのログを表示する
Eureka サーバー ログのログ エントリを確認するには、次のクエリを使用します。
ContainerAppSystemLogs_CL
| where ComponentType_s == "SpringCloudEureka"
| project TimeGenerated, ComponentType_s, EnvironmentName_s, ComponentName_s, Log_s
| limit 100
メトリック
次の表は、Azure Spring Apps と Azure Container Apps の間のメトリックのマッピングを示します。
共通
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
| アプリの CPU 使用率 | 該当なし |
| アプリのメモリ使用量 | 該当なし |
| App Network In (受信累積バイト数) | 該当なし |
| App Network Out (送信累積バイト数) | 該当なし |
エラー指標
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
tomcat.global.error |
該当なし |
パフォーマンス メトリック
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
system.cpu.usage |
CPU 使用率 (プレビュー) |
process.cpu.usage |
該当なし |
| アプリのメモリ使用量 | 該当なし |
jvm.memory.committed |
jvm.memory.committed |
jvm.memory.used |
jvm.memory.used |
jvm.memory.max |
該当なし |
| その他の JVM メトリック | 該当なし |
.NET パフォーマンス メトリック
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
| CPU 使用率 | CPU 使用率 (プレビュー) |
| Working set | メモリ ワーキング セット (バイト単位) |
| GC ヒープ サイズ | 該当なし |
| Gen 0 GC count | 該当なし |
| その他の GC メトリック | 該当なし |
要求のメトリック
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
tomcat.global.sent |
該当なし |
tomcat.global.request.total.count |
Requests |
.NET 要求メトリック
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
| 1 秒あたりの要求数 | 該当なし |
| 要求の合計 | Requests |
セッション メトリック
| Azure Spring Apps のメトリック名 | Azure Container Apps のメトリック名 |
|---|---|
tomcat.sessions.active.max |
該当なし |
tomcat.sessions.alive.max |
該当なし |
Azure Container Apps の Java アプリ用 Java メトリック
Azure Container Apps の開発スタックとして Java を選択した場合、アプリケーションの正常性とパフォーマンスを確保するためには、Java 仮想マシン (JVM) メトリックの監視が不可欠です。 詳細については、「Azure Container Apps の Java アプリ用 Java メトリック」を参照してください。
マネージド コンポーネント
マネージド コンポーネントの監視データについては、次の記事を参照してください。
統合
Azure Container Apps には、アプリケーションの状態の監視と診断に役立つ、いくつかの組み込みの監視機能が用意されています。 ただし、Azure Monitor Application Insights またはその他のアプリケーション パフォーマンス監視 (APM) エージェントを使用する場合は、アプリケーション コードにインストルメンテーションを追加する必要があります。
アプリケーション パフォーマンス監視と統合する
Azure Monitor Application Insights またはその他の APM との統合については、「アプリケーション パフォーマンス監視をコンテナー イメージに統合する」を参照してください。
OpenTelemetry エージェント (プレビュー)
監視データは、Azure Container Apps 環境で OpenTelemetry データ エージェントを使用して、Azure Monitor Application Insights、Datadog、または OTLP と互換性のあるエンドポイントなどの宛先に OpenTelemetry 形式で送信できます。 マネージド エージェントを使用すると、エージェントを手動で実行または再構成することなく、宛先エンドポイントを変更できるため、構成が簡略化されます。 これを設定するには、ARM テンプレート、Bicep、または Azure CLI を使用してコンテナー環境でエージェントを構成し、OpenTelemetry SDK をインストールし、メトリック、ログ、またはトレースのコードをインストルメント化して、アプリケーションを準備します。 Application Insights など、宛先サービスを事前に設定してください。 各宛先には特定の要件があり、エージェントは適切に構成されインストルメント化された場合にのみデータを送信します。 詳細については、「Azure Container Apps で OpenTelemetry データを収集して読み取る」を参照してください。
カスタム ダッシュボードとアラート
Azure Container Apps にアプリケーションをデプロイする場合、カスタム ダッシュボードは次の 2 つの異なるデータ ソーシング方法に依存できます。
アプリ統合 APM エージェント: ビルド プロセス中にサードパーティの APM エージェントをアプリケーションに統合した場合、これらのエージェントはメトリックとログを APM プラットフォームに直接送信します。 この場合、アプリケーション コードが変更されない限り、ダッシュボードを変更する必要はありません。
Azure Monitor ベースのダッシュボード: ダッシュボードで Azure Monitor のメトリックとログ (Application Insights API、Azure Event Hubs、Azure Storage など) を使用する場合は、Azure Container Apps 固有のメトリック名、名前空間、またはログ構造を反映するように、ダッシュボードを更新する必要が生じる場合があります。 Azure Container Apps 固有のメトリック マッピングとデータ構造に基づいて、ダッシュボードを見直して更新するようにします。
ダッシュボードの構成を慎重に検証して、Azure Container Apps への移行後も、それらの構成が正確であることを保ちます。
トラブルシューティング
Azure Container Apps には、Java アプリケーション用のヒープ ダンプまたはスレッド ダンプを生成する API は用意されていません。 これらのダンプを作成するには、コンソールを介してコンテナー アプリに接続する必要があります。 次に、jmap コマンドまたは jstack コマンドを使用して、コンテナー内のダンプ ファイルを生成します。 その後、生成されたファイルをローカル コンピューターにコピーして詳細な分析を行います。
jcmd コマンドを使用して同じ操作を実行し、実行中のアプリケーションで Java Flight Recorder (JFR) を開始することもできます。 コンソールを使用してコンテナー アプリにアクセスする方法の詳細については、「Azure Container Apps でコンテナー コンソールに接続する」を参照してください。
既知の制限事項
- 構造化ログ: Azure Container Apps では、構造化されたアプリケーション ログはサポートされていません。 アプリケーション ログが Azure Spring Apps スキーマに従う場合、完全な JSON 文字列が
ContainerAppConsoleLogs_CLのLog_s列に表示されます。 - イングレス ログ: Azure Spring Apps には組み込みのイングレス アクセス ログがありますが、Azure Container Apps にはありません。 このデータをキャプチャするには、アプリケーション コードにアクセス ログを実装する必要があります。
- Azure Container Apps では、アプリのライフサイクル イベントは提供されません。
- Azure Container Apps には、イングレス メトリックのサポートは組み込まれていません。 アプリケーションでカスタムのトラッキングを実装する必要があります。