アプリケーション開発の最良事例 > ThingWorx アプリケーションの監視 > 監視ツール
監視ツール
ThingWorx プラットフォームは Java テクノロジに基づいて開発されています。このセクションで説明する診断ツールと監視ツールは、Java 仮想マシン (JVM) から性能判定基準およびその他のデータを収集するように設計されています。これらのツールを使用して、JVM レイヤーから ThingWorx アプリケーションを監視します。これらのツールは JVM から次のデータを取得します。
• メモリオペレーション - サーバーに十分なメモリリソースが割り当てられているかどうかと、JVM ガベージコレクション (GC) オペレーションにかかった時間をチェックします。
• スレッドパフォーマンス - ThingWorx アプリケーションにおけるパフォーマンスの問題の原因となりうる、長いトランザクションやスレッドの問題がないかチェックします。
PTC System Monitor (PSM)
PTC System Monitor (PSM) は、Dynatrace を使用したアプリケーションパフォーマンス監視システムです。PTC は ThingWorx アプリケーションの監視要件に合わせて Dynatrace をカスタマイズしています。PSM に備わっているツールを使用して、システム管理者はアプリケーションの動作の正常性に影響を与える問題を検出、診断、および修復できます。これはテストシステムと生産システムの両方を監視します。これは ThingWorx アプリケーションのパフォーマンスには影響しません。このモジュールはメンテナンス契約の一部として提供されており、コアプラットフォーム監視のために追加のライセンスを購入する必要はありません。
PSM は JVM レベルで発生したスレッドレベルのアクティビティを監視し、このアクティビティを PurePath と呼ばれる特許技術に抽出します。PSM PurePath には、サーバー上の ThingWorx サービスの実行パスおよび実行時間の詳細が含まれています。さらに、実行された SQL 文などのコンテキスト情報も含まれています。
PSM の機能
PSM では以下を行えます。
• アプリケーションが失敗する前にアップタイムを増やす。
◦ 高い CPU 使用率など、しきい値違反があった場合に通知を送信します。これにより、管理者はシステム全体の問題に拡大する前に、問題に対処するための是正措置を講じることができます。
◦ システムリソースの使用率の履歴ビューが表示されます。これに基づいて、システムリソースの容量に対する将来の要件を見積もることができます。
• 監視機能を向上させる。
◦ 簡素化されたカスタマイズ可能なダッシュボードに、システムとコンポーネントの正常性が集約されています。
◦ 個々のトランザクション、ユーザー、サーバーコンポーネントの詳細を得るためのドリルダウン機能が備わっています。
◦ システムの正常性に影響を与える問題が集約されたインシデントリストが含まれています。
• リアルタイムのデータによって診断能力を高める。
◦ PurePath テクノロジを使用して、診断データをリアルタイムで収集し、性能判定基準の履歴データを記録します。
◦ 追加の詳細設定を使用して問題を再現して PTC テクニカルサポートとともに問題をトラブルシューティングする時間を削減します。
PSM は ThingWorx アプリケーションから継続的にリアルタイムデータを収集して記録し、このデータを長期にわたって保管します。PSM によって収集されたデータに基づいて、カスタムアプリケーションに影響を与える次のような性能判定基準を常に監視できます。これによって開発チームや PTC サポートサービスはパフォーマンスの問題の原因となるイベントを容易に再現できます。
• JVM メモリのパフォーマンス
• PurePath 時間データを使用したサービス実行時間
• オペレーティングシステムのメモリ、CPU、およびデータベースクエリーの判定基準
• ThingWorx ログエラーおよびその他のインシデント
JVM の直接監視
JVM を直接監視するツールは Oracle または ThingWorx Support Tool 拡張機能によって提供されます。これらのツールを PSM とともに使用することで詳細なパフォーマンスデータを取得できます。PSM を使用しない場合、JVM からデータを直接収集することで、パフォーマンスの問題を特定して修正できます。ThingWorx アプリケーションに関する次のような JVM 診断を監視することをお勧めします。
• JVM の組み込み機能であるガベージコレクションログを使用して、メモリのパフォーマンスを経時的に監視します。
• ThingWorx Support Tool 拡張機能を使用したスレッドレベルの収集および分析。
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 の末尾に以下のテキストを二重引用符で囲んで追加します。
-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”
次のことに注意してください。
▪ -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.out ファイルを gc.out.restart に自動的にバックアップします。
# Backup the gc.out file to gc.out.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.out" ]; then
cp -f "$CATALINA_HOME/logs/gc.out" "$CATALINA_HOME/logs/gc.out.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」フィールドで、次の行を追加します。
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGC オプションと -XX:+PrintGCDetails オプションについては、「Linux でのガベージコレクションのログの設定方法 (setenv.sh)」のセクションを参照してください。
5. 「Apply」をクリックしてサービスコンフィギュレーションに対する変更を保存します。
6. 「General」タブで、「Stop」をクリックします。
7. 「Start」をクリックして Apache Tomcat サービスを再起動します。
新規のガベージコレクションログが %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out ファイルに書き込まれます。
Support Tool 拡張機能を使用した診断データの収集
ThingWorx Support Tool 拡張機能を使用して、ThingWorx テクニカルサポートの情報を収集します。ThingWorx アプリケーションでの問題をトラブルシューティングする際にこの情報を使用します。この拡張機能は次の診断データを収集します。
• Java スレッドダンプ - 特定の時間に Java 仮想マシンで実行しているすべてのスレッドに関する詳細が含まれています。これには指定した時間のスレッドアクティビティを記録できます。
• Java ヒープダンプ - 特定の時間の Java 仮想マシンのヒープ領域内のすべてのオブジェクトに関する詳細が含まれています。
PTC は ThingWorx インスタンスにこの拡張機能をインストールすることをお勧めします。この拡張機能は support.ptc.com の「PTC ソフトウェアのダウンロード」ページにあります。
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 のパフォーマンスが低下することがあります。プラットフォームで使用可能なリソースが不十分である場合、アプリケーションが予期しない動作を起こすことがあります。
ログはサーバー上の /ThingworxStorage/logs フォルダ内に別個のファイルとして保存されます。ログは logs フォルダ内の archives フォルダ内にアーカイブされます。ログのローテーション規則は、ログサブシステムの「ログ保持期間の設定」で設定されているファイルサイズと時間のコンフィギュレーションに基づきます。これらの設定はランタイムで変更および適用できます。
「システム」 > 「サブシステム」 > 「LoggingSubsystem」 > 「コンフィギュレーション」で次のロールオーバーコンフィギュレーションを指定できます。
• ファイルサイズ - ログファイルのサイズが「最大ファイルサイズ (KB)」フィールドで定義されているサイズに達するか超えると、ログファイルはアーカイブされます。ログのデフォルトのファイルサイズは 100000 KB に設定されています。設定可能な最大ファイルサイズは 1000000 KB です。
• 時間 - 毎日深夜にログイベントがトリガーされたときにファイルがロールオーバーされます。ログは archives フォルダに移動します。デフォルトでは、ログが archives フォルダに入ってから 7 日以上経過すると、削除されます。「アーカイブの最大日数」フィールドでこのデフォルトを変更できます。1 から 90 日の範囲で指定できます。
ログサイズを監視することが重要です。先にファイルをバックアップするか、ファイルに古い情報が含まれている場合にはファイルを破棄することで、定期的にログファイルをパージします。