レプリカの再起動が起きているのですが、起きている理由がシステムログから特定できません。

ご回答いただき誠にありがとうございます。それぞれ調査を実施しました。

結論として、リスタートの原因が断定できる要素は確認できませんでした。

下記が調査結果になります。

アプリケーションクラッシュ（未処理例外／プロセス終了） → アプリケーションログ（stdout/stderr）を確認し、エラーやスタックトレースを確認してください

今回確認した ContainerAppConsoleLogs_CL からは、コンテナリスタートの直接原因と判断できるアプリケーションクラッシュの証拠は確認できませんでした。

Traceback や UnicodeDecodeError などの例外は出ていましたが、restart 直前ではなく、またプロセス終了やコンテナ停止につながったことを示すログも確認できないため、1つ目の「アプリケーションクラッシュ（未処理例外／プロセス終了）」が直接原因である可能性は低いと判断しました。

Liveness プローブの失敗 → ヘルスチェックが繰り返し失敗すると、プラットフォームがコンテナを再起動します。 → ログ内のプローブ失敗メッセージを確認し、プローブ設定を見直してください。

2つ目の「Liveness プローブの失敗」については、liveness probe failed 自体は確認できなかったため、Liveness probe failure が直接原因であるとは判断しませんでした。

一方で、各コンテナ作成・開始直後に startup probe failed: connection refused が連続しており、その直後にアプリケーション起動完了ログが出ていることは確認できました。

このため、コンテナ起動直後にアプリケーションがまだ応答可能状態になっておらず、startup probe が失敗していたことは確認できました。

ただし、startup probe failed の後に KillingContainer、ContainerTerminated、ContainerBackOff が続く流れは確認できず、いずれも起動完了ログまで到達しています。

そのため、probe failure が restart の直接原因だったとまでは断定せず、restart 前後に発生していた関連イベントとして扱い、直接原因とは判断しませんでした。

スケーリングイベント（Consumption プランの挙動） → スケールイン時にインスタンスが終了したり、スケールアウト時に置き換えられる場合があります。 → リビジョンやレプリカ数の変更、タイムスタンプを確認してください。

スケーリングは発生していましたが、これはリスタートとは直接関係しないと思います。認識は合っていますでしょうか？

プラットフォームイベント（メンテナンス／インフラ更新） → これらはコンテナログに表示されない場合があります。 → Activity Log や「Diagnose and Solve Problems」のタイムラインを確認してください。

今回確認できた範囲では、Azure 側のメンテナンス、基盤更新、Resource Health の異常、platform initiated event が restart と同時刻に発生していたことを示す情報は確認できませんでした。

Availability and Performance で確認できた内容は、CPU / メモリ / コンテナ作成失敗に関する診断であり、特にメモリ使用率が高めだったことはすでに確認した通りです。

したがって、4つ目の「プラットフォームイベント（メンテナンス／インフラ更新）」が今回の restart の直接原因である可能性は低いと判断しました。

構成変更やデプロイ → 小さな変更でも再起動が発生します。 → Activity Log で「Update Container App」などの操作を確認してください。

Activity Log では、対象時間帯に構成変更・デプロイ・revision 切り替えに該当する操作は確認できませんでした。

CPU 負荷やアプリケーションのハング → CPU 使用率の上昇やデッドロックにより応答不能となり、プローブ失敗→再起動につながることがあります。 → CPU メトリクスと再起動タイミングを相関させて確認してください。

CPU については、2 core 中 1 core 程度の使用で推移しており、CPU 全体の枯渇が restart の直接原因だったとは判断しませんでした。

ただし、単一スレッドまたは特定処理が 1 core を使い切り、アプリケーションの応答性に影響していた可能性は残りますが、CPU 使用率と restart を直接結びつけるログは確認できていません。

たとえば、cpu resource above target のような system log や、CPU 高騰直後にコンテナが kill / restart されたことを示すイベントは確認できていません。

加えて、liveness probe failed も確認できていません。

メモリメトリクスと再起動タイミングの相関を確認 毎回再起動直前にメモリ使用量が増加し高水準に達している場合、有力な指標となります。

こちらはすでに確認済みで、リスタート前にメモリが80%付近まで上昇しているため相関はありますが、OOMKilledなどが観測できないため断定はできない状態です。

アプリケーションレベルでのメモリログを追加 ヒープ使用量、RSS、GC 活動などを定期的にログ出力することで、メモリリークやスパイクの検出に役立ちます。

RSSやGC活動のログはすでにあり、メモリリークしていたことは見つけて改善済みです。

メモリ上限を一時的に引き上げる（検証テスト） メモリ割り当てを増やすことで再起動が減少または解消される場合、メモリ圧迫が原因である可能性が高いです

現在は原因を確定できるかできないかを調査している段階のため、確定していない段階での対応は避けたいです。

もし原因が確定できないと判断したら、複合的な要素から判断し、対応を考える方針です。

ログの欠落（ギャップ）を確認 アプリケーションエラーがなく突然終了している場合（再起動直前のログがない場合）、外部要因（例：Eviction）の可能性があります

こちらはどのように確認ができますか？

他環境との比較（例：テスト vs 本番） トラフィックや負荷の違いにより、メモリ関連の問題が顕在化することがあります。

こちらはどのように比較をすると、どのようなメモリ関連の問題が顕在化する可能性がありますでしょうか？

これ以外に、何かリスタートの原因を断定するための調査をすることができますでしょうか？

もしくは、これ以上調査をしても断定はできず複合的な要素から判断するしかないでしょうか？

現時点では、リスタート前には70~80%とメモリが高負荷になっているためメモリが原因と推測しています。