Javaプロセス死活監視構成と試験方法について

Anonymous
2026-01-20T14:52:13.6133333+00:00

お世話になっております。

Azure上でのTomcat(Java)プロセスの死活監視について、VM監視およびAKS監視の2パターンで構成・試験シナリオを作成しております。

以下①-④の内容について、ご確認をお願いいたします。

①Azure上でのTomcat(Java)プロセスの死活監視シナリオ(後述の「■VMプロセス死活監視(Java)シナリオ」、「■AKSプロセス死活監視(Java)シナリオ」)について、の構成・試験方法で実現可能かご教示ください。

②AKSでJavaプロセス停止を直接識別できるか

「■AKSプロセス死活監視(Java)シナリオ」について、CrashLoopBackOffはKubernetesのイベントであり、「Java プロセスが停止した」ことを直接示すものではないと理解しています。この理解が正しいか確認したいです。

③Application Insights(OpenTelemetry)で「AKS の Java プロセス死活監視」は可能か

Application InsightsではJVMメトリクスやアプリ内部トレースは取得可能と認識しておりますが、

OSプロセス(javaプロセスが停止状態かなど)を監視する仕組みではないと理解しています。

そのため、「AKS内のJavaプロセスが停止したことをApplication Insights単体で監視することはできない」という認識で問題ないでしょうか。

④AKS上のTomcat(Java)プロセス死活を行うための推奨構成について

「■AKSプロセス死活監視(Java)シナリオ」について、AKSでTomcat(Java)プロセスの死活監視を実現するために、Microsoft が推奨する構成・試験方法があれば教えてください。

(例:livenessProbe / readinessProbe、JMX Exporter、OpenTelemetry、追加のログ監視など)

ご確認のほどよろしくお願いいたします。


■VMプロセス死活監視(Java)シナリオ

【導入サービス】

Azure Monitor Agent(AMA)

Azure Monitor Log Analytics

Azure Monitor Alerts

Azure Monitor Action Group

【試験方法】

Azure Monitor Agent(AMA)を VM に導入し、DCR を作成

(参考:

https://learn.microsoft.com/ja-jp/azure/azure-monitor/vm/data-collection-syslog

https://zenn.dev/mochi_1206/articles/09067fe871c1ca)

Tomcat を起動し、systemctl status tomcat にてサービスが active であることを確認

Tomcat の Java プロセスを意図的に停止

例:sudo kill -9 $(pgrep -f 'java.*tomcat')

Syslog に tomcat.service: Main process exited などの停止ログが記録されることを確認

Log Analytics で停止イベントが収集されていることを確認

Azure Monitor Alerts によるアラート発報を確認

Azure Monitor Action Group によるメール通知を確認

【期待する結果】

Tomcat(Java)プロセス停止が Syslog 経由で検知されること

停止イベントに基づくアラートが発報されること

メール通知が届くこと

■AKSプロセス死活監視(Java)シナリオ

【導入サービス】

Azure Monitor for Containers

Azure Monitor Log Analytics

Azure Monitor Alerts

Azure Monitor Action Group

【試験方法】

Microsoft 公式ドキュメントに沿って AKS クラスタ監視(Container Insights)を有効化

参考:

https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=portal

コンテナ内部でアプリケーションプロセスを異常終了させ CrashLoopBackOff を再現

例:kill -9 1

Log Analytics に CrashLoopBackOff イベントが記録されていることを確認

Azure Monitor Alerts によるアラート発報を確認

Azure Monitor Action Group によるメール通知を確認

【期待する結果】

コンテナの main プロセス(Java)が異常終了すると CrashLoopBackOff 状態になること

CrashLoopBackOff を利用したアラートが発報されること

メール通知が届くこと

Azure Monitor
Azure Monitor

Azure およびオンプレミス環境からのテレメトリ データを収集、分析、処理するために使用する Azure サービス。


1 件の回答

並べ替え方法: 最も役に立つ
  1. Siva shunmugam Nadessin 10,900 評価のポイント Microsoft 外部スタッフ モデレーター
    2026-01-20T18:29:49.6966667+00:00

    こんにちは 89302197,

    Microsoft Q&A フォーラムにご連絡いただき、ありがとうございます

    Azure VM 上の Tomcat/Java では、Log Analytics エージェントを使用した Azure Monitor により、JVM のメトリクス、プロセスの可用性、カスタムヘルスチェックを追跡できます。AKS では、Prometheus スクレイピング、コンテナ用 Azure Monitor、Application Insights の自動計測を組み合わせることで、アプリケーションレベルでの可視性を確保します。はい、Application Insights(自動計測を通じて)を使用して AKS 上の Java プロセスの状態を監視し、CrashLoopBackOff イベントを通じてコンテナの障害を検出することは可能ですが、これらは目的が異なります

    Tomcat(Java)モニタリングの推奨設定

    Azure VM 上で

    Azure Monitor エージェント (AMA) または Log Analytics エージェント

    • JVMのメトリクス(ヒープ使用量、GCの活動、スレッド数)を収集する
    • カスタムスクリプトやハートビートチェックを使用して、Tomcatプロセスの可用性を監視します

    カスタムヘルスプローブ

    • TomcatでHTTPエンドポイント(例:/healthや/status)を設定します
    • Azure Monitor または Application Gateway のヘルスプローブを使用して、可用性をテストします

    アラートルール

    • JavaプロセスのCPU/メモリしきい
    • Tomcatサービスの再起動やクラッシュイベントに関するアラート

    AKSノード上で

    コンテナ向け Azure モニタ

    • ポッドレベルのメトリクス、コンテナのログ、ノードのリソース使用状況を収集します。
    • JVM/Tomcatのメトリクスに対してPrometheusのメトリクスクレイピングを有効にする。

    ライブネス/レディネスプローブ

    • Tomcatのエンドポイント用にKubernetesプローブを定義します
    • 不健康なポッドを検出して、自動的に再起動をトリガーします

    クラッシュループバックオフイベント

    • ポッドのライフサイクルイベントを監視して、繰り返し発生する障害を検出します。
    • 早期検出のために、CrashLoopBackOff 状態に対して Azure Monitor アラートを使用します

    AKSでのJavaプロセスのヘルスモニタリング ユーザーの画像

    Application Insights: AKSでのJava自動計測に対応しています。コンテナイメージにAIエージェント(jar)を追加するか、コードを変更せずにテレメトリを収集するプレビューフィーチャーを有効にします

    CrashLoopBackOff: コンテナのクラッシュ検出には有用ですが、JVMレベルのヘルスチェックには不十分です。プローブやAIと組み合わせて使用するのが最適です

    リスクと留意点

    ·         __VMとAKSの違い:__VMではOSとプロセスを直接制御できますが、AKSでは監視はコンテナ化されており、Kubernetesネイティブのプローブが必要です。

    ·         オーバーヘッド: Application Insights はテレメトリのオーバーヘッドを追加します。コストの急増を避けるためにサンプリング率のバランスを取ってください

    ·         誤検知: CrashLoopBackOff は JVM の状態ではなく、設定ミスが原因で発生することがあります。常にログやメトリクスと照らし合わせて確認してください

    おすすめ:

    JVM/Tomcatの健全性およびリクエストレベルの監視には、Application Insightsの自動計測を使用し、コンテナのライフサイクルの健全性にはCrashLoopBackOffアラート付きでKubernetesのプローブを構成します。これらを組み合わせることで、AKS上のJavaプロセスの健全性を包括的に把握できます

    他に質問があれば教えてください

    もしこの回答が役に立った場合は、回答を承認し、上向き投票をお願いします。これにより、同じような問題に直面している他のコミュニティメンバーにも役立つ可能性があります。Microsoft Q&A コミュニティへのご協力に心より感謝いたします。

     

     

     

    この回答は役に立ちましたか?


お客様の回答

質問作成者は回答に "承認済み"、モデレーターは "おすすめ" とマークできます。これにより、ユーザーは作成者の問題が回答によって解決したことを把握できます。