監視ツール
ThingWorx Platform は Java テクノロジに基づいて開発されています。このセクションで説明する診断ツールと監視ツールは、Java 仮想マシン (JVM) から性能判定基準およびその他のデータを収集するように設計されています。これらのツールを使用して、JVM レイヤーから ThingWorx ソリューションを監視します。これらのツールは JVM から次のデータを取得します。
• メモリオペレーション - サーバーに十分なメモリリソースが割り当てられているかどうかと、JVM ガベージコレクション (GC) オペレーションにかかった時間をチェックします。
• スレッドパフォーマンス - ThingWorx ソリューションにおけるパフォーマンスの問題の原因となりうる、長いトランザクションやスレッドの問題がないかチェックします。
JVM の直接監視
Oracle およびサポートサブシステムによって、JVM を直接監視するツールが提供されています。JVM からデータを直接収集することで、パフォーマンスの問題を特定して修正できます。ThingWorx ソリューションに関する次のような JVM 診断を監視することをお勧めします。
• JVM の組み込み機能であるガベージコレクションログを使用して、メモリのパフォーマンスを経時的に監視します。
• サポートサブシステムを使用したスレッドレベルの収集および分析。
ThingWorx サーバーのメモリ使用量の監視
Java 仮想マシン (JVM) はガベージコレクター (GC) を使用して独自のメモリ (ヒープ) をネイティブに管理します。GC は Java ヒープ内の使用されていないオブジェクトを特定して除去します。GC によって収集された詳細をログに記録することで、ThingWorx サーバーのメモリ使用量を監視できます。
GC ログファイルを使用してメモリ消費の傾向を把握できます。傾向に応じて、パフォーマンスを向上させるために Apache Tomcat サーバーの最大ヒープパラメータを変更すべきかどうかをチェックできます。このため、Apache Tomcat サーバーで GC のログを設定することをお勧めします。
JVM にはランタイムで呼び出されるフラグがあります。これらのフラグを使用して、GC イベントのタイプ、イベント開始時に消費されていたメモリ量、GC イベントによって解放されたメモリ量、GC イベントの所要時間など、GC イベントに関する統計が書き込まれます。
JVM が起動するたびに GC ログファイルが上書きされます。サーバーの再起動時にはログファイルをバックアップすることをお勧めします。メモリ使用量がサーバー再起動の原因であるかどうかを分析する際にこれが役立ちます。
GCEasy.io や Chewiebug GC Viewer などの分析ツールを使用してガベージコレクションからのログを分析できます。
Linux でのガベージコレクションのログの設定方法 (setenv.sh)
Linux でガベージコレクターのログを設定するには、次の手順を実行します。
1. テキストエディタで $CATALINA_HOME/bin/setenv.sh スクリプトを開きます。
一部のインストールでは setenv.sh スクリプトファイルが存在しないことがあります。このファイルが存在しない場合、この場所に新規の setenv.sh ファイルを作成します。
2. 変数 JAVA_OPTS の末尾に以下のテキストを二重引用符で囲んで追加します。
Java 8:
-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
JAVA_OPTS が setenv.sh ファイルで指定されていないか、setenv.sh ファイルが新規の場合、ファイルに以下の行を追加します。
JAVA_OPTS=”-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails”
Java 9 以降:
-Xlog:gc:file=/logs/gc.log:time,level,tags
JAVA_OPTS が setenv.sh ファイルで指定されていないか、setenv.sh ファイルが新規の場合、ファイルに以下の行を追加します。
JAVA_OPTS="-Xlog:gc:file=/logs/gc.log:time,level,tags"
次のことに注意してください。
▪ -XX:+PrintGC オプションはあまり詳細ではない出力ログを返します。たとえば、出力ログには次のような情報が含まれています。
2017-10-10T13:22:49.363-0400: 3.096: [GC (Allocation Failure) 116859K->56193K(515776K), 0.0728488 secs]
▪ -XX:+PrintGCDetails オプションは詳細な出力ログを返します。たとえば、出力ログには次のような情報が含まれています。
2017-10-10T13:18:36.663-0400: 35.578: [GC (Allocation Failure) 2017-10-10T13:18:36.663-0400: 35.578: [ParNew: 76148K->6560K(76672K), 0.0105080 secs] 262740K->193791K(515776K), 0.0105759 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
3. setenv.sh スクリプトの末尾に次の行を追加します。このコードは、Apache Tomcat サーバーを起動する前に、既存の gc.log ファイルを gc.log.restart に自動的にバックアップします。
# Backup the gc.log file to gc.log.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.log" ]; then
cp -f "$CATALINA_HOME/logs/gc.log" "$CATALINA_HOME/logs/gc.log.restart"
fi
if [ -e "$CATALINA_HOME/logs/gc.log" ]; then
cp -f "$CATALINA_HOME/logs/gc.log" "$CATALINA_HOME/logs/gc.log.restart"
fi
4. 変更内容をファイルに保存します。
5. お使いのオペレーティングシステムに適したサービスコントローラを使用して、Apache Tomcat サービスを再起動します。
Windows でのガベージコレクションのログの設定方法 (Apache Service Manager)
Windows でガベージコレクターのログを設定するには、次の手順を実行します。
1. Windows エクスプローラで、<Tomcat_home>\bin にブラウズします。
2. 名前に w が含まれている実行ファイルを開始します。例: Tomcat<version number>w.exe
3. 「Java」タブをクリックします。
4. 「Java Options」フィールドで、次の行を追加します。
Java 8:
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
Java 9 以降:
-Xlog:gc:file=/logs/gc.log:time,level,tags
-XX:+PrintGC オプションと -XX:+PrintGCDetails オプションについては、「Linux でのガベージコレクションのログの設定方法 (setenv.sh)」のセクションを参照してください。
5. 「Apply」をクリックしてサービスコンフィギュレーションに対する変更を保存します。
6. 「General」タブで、「Stop」をクリックします。
7. 「Start」をクリックして Apache Tomcat サービスを再起動します。
新規のガベージコレクションログが %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out ファイルに書き込まれます。
サポートサブシステムを使用した診断データの収集
詳細については、サポートサブシステムを参照してください。
VisualVM およびその他の JMX 監視ツール
VisualVM は Java ソリューションのデータを収集する監視ツールです。VisualVM を使用して ThingWorx ソリューションを監視できます。これはメモリ使用量と CPU 使用率に関する情報を収集します。これはヒープダンプを生成および分析してメモリリークを追跡します。ローカルに実行しているソリューションおよびリモートマシン上で実行しているソリューションのデータを収集できます。
VisualVM には、Java ソリューションに関する情報をグラフィカルに表示可能なインタフェースが備わっています。
VisualVM は Java JDK とともに提供されています。VisualVM の接続設定の詳細については、ThingWorx ヘルプセンターのApache Tomcat Java オプションの設定を参照してください。
Java Management Extensions (JMX) を使用して JVM に統合されているその他のツールにも同様の監視機能が備わっています。
VisualVM はソリューションのパフォーマンスに影響を与える次のような主な判定基準を取り込みます。
• JVM メモリのパフォーマンス
• スレッドに実行に必要な時間
• オペレーティングシステムのメモリおよび CPU 判定基準
• データベース接続プールの監視
VisualVM は約 20 分間リアルタイムデータを追跡します。
ThingWorx アプリケーションログの監視
ThingWorx ソリューションログを定期的に監視してエラーやその他の異常な処理がないか確認する必要があります。エラーは、プラットフォームレイヤー、または ThingWorx で使用されているカスタムスクリプトで発生する可能性があります。エラーログ内のメッセージを毎日確認することをお勧めします。
エラーのスタックトレースを書き込むための LoggingSubsystem オプションの設定
「LoggingSubsystem」の「スタックトレースを有効化」オプションは、エラーメッセージおよび関連するスタックトレースをログファイルに書き込みます。デフォルトでは、LoggingSubsytem はスタックトレース (コールスタック) をディスクに書き込むように設定されていません。「スタックトレースを有効化」オプションを設定することで、例外のコースタックとエラーメッセージを ThingworxStorage/logs フォルダ内の ErrorLog.log ファイルに書き込みます。エラーのデバッグ中にスタックトレース内の関数呼び出しの詳細を取得するには、このオプションを設定することをお勧めします。
アプリケーションログの維持
ログレベルによって、ログに表示される詳細度が決まります。問題を積極的にトラブルシューティングしている場合を除き、ソリューションのログレベルを「情報」や「警告」などの最小限の詳細度に維持することをお勧めします。ログ詳細度を「デバッグ」、「トレース」、または「すべて」に上げる際には注意してください。これによって ThingWorx のパフォーマンスが低下することがあります。ThingWorx Platform で使用可能なリソースが不十分である場合、ソリューションが予期しない動作を起こすことがあります。
ログはサーバー上の /ThingworxStorage/logs フォルダ内に別個のファイルとして保存されます。ログは logs フォルダ内の archives フォルダ内にアーカイブされます。ログのローテーション規則は、ログサブシステムの「ログ保持期間の設定」で設定されているファイルサイズと時間のコンフィギュレーションに基づきます。これらの設定はランタイムで変更および適用できます。
> > > で次のロールオーバーコンフィギュレーションを指定できます。
• ファイルサイズ - ログファイルのサイズが「最大ファイルサイズ (KB)」フィールドで定義されているサイズに達するか超えると、ログファイルはアーカイブされます。ログのデフォルトのファイルサイズは 100000 KB に設定されています。設定可能な最大ファイルサイズは 1000000 KB です。
• 時間 - 毎日深夜にログイベントがトリガーされたときにファイルがロールオーバーされます。ログは archives フォルダに移動します。デフォルトでは、ログが archives フォルダに入ってから 7 日以上経過すると、削除されます。「アーカイブの最大日数」フィールドでこのデフォルトを変更できます。1 から 90 日の範囲で指定できます。
ログサイズを監視することが重要です。先にファイルをバックアップするか、ファイルに古い情報が含まれている場合にはファイルを破棄することで、定期的にログファイルをパージします。