Uncategorized

【プロセス監視】プロセスダウン(Java/Tomcat)のアラート対応

記事内に商品プロモーションを含む場合があります

はじめに

こんにちは、インフラエンジニアのやすです。

この記事では、APサーバでTomcatやJavaのプロセスが停止した際のアラート対応を紹介します。

Tomcatは、JavaをベースとしたWebアプリケーションを動かすために必要なソフトです。なので、TomcatやJavaが停止しているということは「Webアプリが動かせない(Webサイト全体が機能していないも同然)」ということになります。

迅速な復旧が必要です。

障害対応フロー

基本は、下記の図の流れで落ち着いて対応していきましょう。

状況確認

プロセスは動いているか?

まず、プロセスが今動いているか」と「止まった形跡があるか」をログインして確認しましょう。

確認のやり方

・Linuxなら、サーバにログインして「ps aux | grep -e tomcat -e java」で確認します。起動時間もでるので、直近で止まっているかも確認します。

・Windowsならタスクマネージャーからサービス管理ツールを開き、tomcatとjavaが動いているか確認しましょう。

計画停止?(作業影響?)

もしプロセスが止まっていたら、だれか今何かやっていないかを確認しましょう。

作業影響の場合、単純にアラートの抑止漏れということになります。
「次回はアラートの抑止忘れないでくださいね!」と伝えて対応終了です。

作業影響でない場合、本当の障害の線が濃厚です。
ダンプファイルを取得してから、プロセスを起動させましょう。

暫定対応

ヒープダンプ/スレッドダンプの取得

javaやtomcat周りで障害が起きた際の定番な初期対応として、ヒープダンプやスレッドダンプの取得があります。

ヒープダンプやスレッドダンプは、問題が起きている今のJavaの状態をダンプしたファイルです。

javaやtomcatを起動させると状態がリセットされるので、起動後だと取得の効果が薄れます。復旧を優先させるのも良いのですが、後々の原因調査を考えると、ぜひとも取得しておきたいファイルです。

ヒープダンプとは?

ヒープダンプは、Javaアプリケーションの「メモリの中身(オブジェクトの状態)」を丸ごと記録したファイルのことです。メモリ関連のエラー(OutOfMemoryError)の際に取得します。

取得方法

・プロセスIDを確認する(ps aux | grep tomcat)

・スレッドダンプを取得する。
 jmap -dump:live,format=b,file=/tmp/heapdump.hprof
※PIDはTomcatプロセスなどのJavaプロセスIDを指定する。

スレッドダンプとは?

スレッドダンプは、Javaアプリケーション内で動作しているすべてのスレッドの状態を記録したスナップショットです。

よくメールやチャットで最初の会話にどんどん返信してやり取りがたまるのをスレッドって言いますよね。そのjava版(javaのやり取りの履歴=スレッド)のイメージです。javaのスレッドをダンプしたものです。

取得方法

・プロセスIDを確認する(ps aux | grep tomcat)

・スレッドダンプを取得する。
 jstack <プロセスID> > /tmp/thread_dump_$(date +%Y%m%d_%H%M%S).txt
※PIDはTomcatプロセスなどのJavaプロセスIDを指定する。

スレッドダンプやヒープダンプは、取得の際にCPU使用率など負荷が上がったり、取得に時間がかかる可能性があります。

同じ構成の検証環境で、実際に取得してみて試してみたり、本番環境で影響が出ない時間帯に取得してみるなどをしておくと良いと思います。

Java/Tomcat起動

ダンプを取得したら、Java/Tomcatを起動させましょう。

systemctl start java

systemctl start tomcat

起動できない場合

単純に再起動して起動できれば問題ないのですが、起動ができない場合はさらに対応が必要です。

ログにエラーは出ているか?

まず、ログに起動が失敗した理由がでているかを確認しましょう。

確認するログはtomcatのメインログであるcatalina.outと、シスログ(/var/log/messages)です。

エラーが出ていれば、その内容に沿って対応を進めます。

エラーっぽいのは出ているんだが内容がよくわからん、エラーが出ていないという場合は、他の観点で探しましょう。

直近、なにか設定変更した?

直近で、誰かなにか設定を変えたかを確認しましょう。

tomcatは、起動時に設定ファイルを読み込むので、設定ファイルを修正しただけだと動的に設定は反映されません。

なので、設定の修正と設定の反映のタイミングがズレて、今になって設定の不備が発覚した可能性もあります。

リソース不足?(サーバが高負荷?)

これまで問題なく動いていて、設定を誰も変えていないとなると、次に怪しいのはリソース不足です。

CPU、メモリ、ディスクの使用率を確認し、高騰していれば対応しましょう。

ディスク使用率が100%でtomcatが起動できないという場面は見たことがありますね。

起動するとログに書き込んだり一時ファイルを作ったりが発生するのですが、それができない状態ということであれば、起動に失敗します。

キャッシュや一時ファイル、ゴミプロセス残っている?

「リソースを確保したが起動できない」もしくは「リソースに問題がなかった」場合は、キャッシュや一時ファイル、tomcatの以前のプロセス(ゴミプロセス)が残っていないかを確認しましょう。

以前のプロセスが変な風に残ってしまっていて、起動に失敗している可能性があります。

ps aux | grep tomcat
rm -rf $CATALINA_BASE/work/*
rm -rf $CATALINA_BASE/temp/*

起動できない場合の最終手段

OS再起動

色々試してみたが起動できない、もしくはOS再起動しても良いという調整が取れたのであれば、最終手段のOS再起動を実行しましょう。

OSを再起動すれば、さすがに起動できるはずです。

まとめ

ここでは、tomcatやjavaが停止してさらに単純に起動ができなかった場合の対処方法を見ていきました。

普段から定期的に緊急時の対応をシミュレーションしておくと、いざというときにスムーズに対応ができますね。

ではまた、バイバーイ♪