Zabbixによる継続的なJVM監視

大規模なJavaアプリケーションがあるとします。 これは、コンテナまたはスタンドアロンサービスでホストされるWebサーブレットにすることができます。 開発プロセス中（および操​​作中）、JVMで発生するプロセスを監視する必要があります。ガベージコレクター操作、メモリ使用量、スレッドライフサイクル、MBeanを介したプロジェクト固有のその他のインジケーター。 最も簡単なオプションは、プロファイラーを使用することです。 しかし、残念ながら、スケジュールどおりに問題が発生することはありません。プロファイラーをいつ接続するかを事前に知ることは不可能です。また、プロファイラーを常時オンにすることもオプションではありません。 そのような場合、理想的なソリューションは継続的な監視です。 それについて説明します。 しかし、最初に、古典的なプロファイリングについてのいくつかの言葉。

プロファイラーを使用する

おそらく、アプリケーションを監視する最も簡単で手頃な方法です。 プロファイラーを使用すると、JVMの状態をリアルタイムで監視し、個々のフローのアクティビティの分析まで、その動作の統計を詳細に分析できます。 市場には無料と有料の両方のソリューションがあります。

• jconsoleは、コーヒーコレクターのキャンプセット「 JDK Tools and Utils 」に含まれるユーティリティです。 MBeanとの直接作業を含む、すべての基本的なJVM統計へのアクセスを提供します。
• VisualVMはjconsoleの高度なアナログです。 しばらくの間（ 誰かが誰かを買ったとき ）、jdkも付属しています。 この記事では、VisualVMとプロファイリングの基本について読むことができます。 プロファイラーをリモートサーバー上のJVMに接続する必要があるが、気にしたくない場合は、その上でvisualvmバイナリを見つけてから、Xセッション変換でssh経由で呼び出すだけです。
  
  ssh -X login@domain /usr/bin/jvisualvm
  
  
  
  
  
  
• JProfilerは、商用プロファイラーのリーダーです（これを使用した経験が豊富な人がいれば、喜んで採用します）。

継続的な監視

プロファイラーには1つの大きな欠点があります。1日24時間、週7日、開いたままにしておくことはできません。 これは単にこれを目的としていません。 なぜこのような監視が必要なのですか？ 次に、アプリケーションに問題が発生する時期がわからないこと。 継続的な監視により、1日、1日、1か月の統計の要約分析を実行し、メモリ使用量、スレッド、およびその他のメトリックのグラフに基づいて、サービス/アプリケーションの不正な動作の原因に関する初期仮定を構築できます。 たとえば、夜にQAテストを実行し、朝に継続的な監視に基づいてサービスの動作を分析します。



許容できる価格と品質の組み合わせで既製のシステムが見つからなかったため、 Zabbixで豊富な経験を積んでいたので、 Zabbixを自分のニーズに合わせることにしました（Zapcatに精通している人のために、この記事の最後にいくつかの言葉があります）。 すぐに尋ねることができます：「なぜNagiosではなくZabbixなのか？」。 箱から出してすぐに機能し、モジュールの手動デバッグとドッキングを必要としない完成品が大好きです。



それでは、サーバー側の料理に取りかかりましょう;-)！ 「Zabbix Meansによる継続的なJMXモニタリング」ディッシュを準備するには、次のものが必要です。

• Ubuntu Server 10.04（代わりにDebianとRedHatを使用できます）
• 味わうPostgreSQLまたはMySQL
• Zabbixサーバー
• Zabbixクライアント
• Oracle Java（この記事のスクリプトはJVM HotSpotに焦点を当てています）
• Jolokia （JMX-HTTPブリッジ）-JMX RMI接続のセットアップに関する問題の回避に役立ちます

すべてのアクションは、新しくインストールされたOSで実行されることを思い出させてください。

Zabbixクイックセットアップ

監視のためにクライアントマシンが接続されたZabbixサーバーがすでに構成されている場合は、次のステップに直接進むことができます。



Zabbixサーバーとエージェントは、リポジトリからインストールすることも、ソースから組み立てることもできます。 通常、リポジトリにはzabbixの非常に古いバージョンがありますが、それらはテストのために行われますが、日常的な使用には新しいものをお勧めします。 したがって、リポジトリから配置します。



sudo apt-get install zabbix-agent zabbix-server-pgsql zabbix-frontend-php php5-pgsql tomcat6







インストール後、 localhost / zabbixに移動し、zabbixパスワードを使用してadminユーザーとしてログインします。 「構成->ホスト」タブに移動し、「Zabbixサーバー」をクリックします。 ステータスを「監視対象外」から「監視対象」に変更します。 次に、エディターでファイル/etc/zabbix/zabbix_agentd.confを開き、その内容を提案されたものに置き換えます。



Server=127.0.0.1

Hostname=redcraft

StartAgents=16

DisableActive=1

EnableRemoteCommands=1

DebugLevel=4

Timeout=30

PidFile=/var/run/zabbix-agent/zabbix_agentd.pid

LogFile=/var/log/zabbix-agent/zabbix_agentd.log







Zabbix UIで、「監視->最後のデータ」に進み、ローカルマシンからデータの収集が開始されたことを確認します。 これでZabbixの基本セットアップが完了しました。JMXの準備に進みます。

Jolokia JVMエージェントの接続

実験的なJVMとして、tomcatを使用します。 RMIプロトコル経由で接続するのではなく、HTTPを使用するために、JMokia JMX-HTTPブリッジを使用します。 Tomcatの場合、 戦争アセンブリは公式Webサイトで入手できます。 ダウンロードしたwarファイルの名前をjolokia.warに変更し、/ var / lib / tomcat6 / webappsに配置します。 Tomcatを再起動します。 localhostアドレス：8080 / jolokiaを開き、すべてが正しく行われると、次の情報が表示されます。



{"timestamp":1328444565,"status":200,"request":{"type":"version"},"value":{"protocol":"6.1","agent":"1.0.2","info":{"product":"tomcat","vendor":"Apache","version":"6.0.24"}}}







スタンドアロンアプリケーションがある場合、jolokiaにアプリケーションを接続するには、次のパラメーターを起動ラインに追加します。



-javaagent:$LIBDIR/jolokia-agent.jar=port=9090,host=localhost







$ LIBDIR / jolokia-agent.jarはJolokia JVM-Agentへのパスです

Jolokiaでデータ収集をセットアップする

これで、JMX-HTTPブリッジが接続されたZabbixとJVMができました。 データ収集を整理する必要があります。 データ収集スキームは次のようになります。







メトリックを直接収集せず、中間バッファーを使用する理由を説明します。 スキームを設定せずに構成すると、リクエストごとにJMX統計を収集するスクリプトが起動されます。これは、バッファから読み取るよりもリソースを集中的に使用する操作です。 したがって、N秒ごとにすべてのメトリックが収集され、ファイルごとに配置され、必要に応じてファイルから読み取られるモデルを選択しました。



データを収集するには、既製のライブラリを使用してJMX-HTTPブリッジを操作します。 ライブラリはPerlで記述され、CPANを使用してインストールされます。



sudo cpan -i JMX::Jmx4Perl







インストールが成功したら、jmx4perlを使用してTomcatで最初のメトリックを取得しようとします。



jmx4perl localhost:8080/jolokia read java.lang:type=Memory HeapMemoryUsage







コマンドの結果は次のようになります。



{

committed => 65470464,

init => 0,

max => 132579328,

used => 10264072

}







ご想像のとおり、Tomcat JVMヒープメモリの使用に関する情報を取得しました。



ここで、メトリックを収集するスクリプトを作成し、指定したディレクトリのファイルに配置する必要があります。 あなたはあなた自身を書くか、私の例を使用することができます：

 #!/usr/bin/perl use strict; use warnings; use Error qw( :try ); use JMX::Jmx4Perl; use JMX::Jmx4Perl::Alias; use File::Path qw(make_path remove_tree); use Data::Dumper; my %source = ( GC_COPY_COLLECTION_COUNT => ["java.lang:name=Copy,type=GarbageCollector", "CollectionCount"], GC_MARK_SWEEP_COLLECTION_COUNT => ["java.lang:name=ConcurrentMarkSweep,type=GarbageCollector", "CollectionCount"], GC_COPY_COLLECTION_TIME => ["java.lang:name=Copy,type=GarbageCollector", "CollectionTime"], GC_MARK_SWEEP_COLLECTION_TIME => ["java.lang:name=ConcurrentMarkSweep,type=GarbageCollector", "CollectionTime"], THREAD_COUNT => ["THREAD_COUNT"], MEMORY_HEAP_COMITTED => ["MEMORY_HEAP_COMITTED"], THREAD_COUNT_DAEMON => ["THREAD_COUNT_DAEMON"], THREAD_COUNT_STARTED => ["THREAD_COUNT_STARTED"], MEMORY_HEAP_INIT => ["MEMORY_HEAP_INIT"], RUNTIME_VM_VENDOR => ["RUNTIME_VM_VENDOR"], MEMORY_HEAP_MAX => ["MEMORY_HEAP_MAX"], RUNTIME_VM_NAME => ["RUNTIME_VM_NAME"], CL_TOTAL => ["CL_TOTAL"], CL_LOADED => ["CL_LOADED"], CL_UNLOADED => ["CL_UNLOADED"], THREAD_COUNT_PEAK => ["THREAD_COUNT_PEAK"], RUNTIME_UPTIME => ["RUNTIME_UPTIME"], MEMORY_HEAP_USED => ["MEMORY_HEAP_USED"], RUNTIME_VM_VERSION => ["RUNTIME_VM_VERSION"], ); my $log_dir = "/var/jmx"; my $result = 0; my $port = $ARGV[0]; my $cmd = $ARGV[1]; if(defined $cmd && defined $port) { try { my $jmx = JMX::Jmx4Perl->new(url => "http://localhost:$port/jolokia/"); if($cmd eq "DUMP") { make_path("$log_dir/$port"); while(my($key, $value) = each %source) { open FILE, ">$log_dir/$port/$key" or throw Error::Simple("Could not open file"); print FILE $jmx->get_attribute(@$value) . "\n"; close FILE; } $result = 1; } else { my $param = $source{$cmd}; $result = $jmx->get_attribute(@$param); } } catch Error with { $result = 0; # --- Uncomment for debug --- #my $ex = shift; #print $ex->{-text}."\n"; #print $ex->{-line}."\n"; # --- Debug block ended --- }; } else { $result = 0; } print $result . "\n";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトを/ usr / local / sbinに配置し、jmx_grabberを呼び出します。 スクリプトが機能しない可能性があります。 これは、GC_COPY_COLLECTION_COUNT、GC_MARK_SWEEP_COLLECTION_COUNT、GC_COPY_COLLECTION_TIME、GC_MARK_SWEEP_COLLECTION_TIMEの最初の4つのメトリックが原因です。 メトリックは、「ガベージコレクター」（GC）の統計情報のみを表示します。 特定のJVM実装で使用されるガベージコレクターの名前は異なる場合があります。 JVM HotSpotについては、PS Scavenge + PS MarkSweepとConcurrentMarkSweep + Copyの2つのペアに出会いました。 GCの名前を判断するのが難しい場合は、コマンドを実行します



jmx4perl localhost:8080/jolokia attributes | less







次に、キーワード「GarbageCollector」を検索します。 次のようなものがあります。



java.lang:name=ConcurrentMarkSweep,type=GarbageCollector -- CollectionCount = 12

java.lang:name=ConcurrentMarkSweep,type=GarbageCollector -- LastGcInfo =

java.lang:name=ConcurrentMarkSweep,type=GarbageCollector -- CollectionTime = 0

java.lang:name=ConcurrentMarkSweep,type=GarbageCollector -- Name = ConcurrentMarkSweep

java.lang:name=ConcurrentMarkSweep,type=GarbageCollector -- Valid = [true]







値は「java.lang：name」であり、「ガベージコレクター」のいずれかの名前です。



ファイルからデータを取得するbashスクリプトを作成しましょう。

 #!/bin/bash JMX_DIR="/var/jmx" if [ -r "$JMX_DIR/$1/$2" ]; then cat "$JMX_DIR/$1/$2" else echo 0; fi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

記述されたスクリプトを機能させるには、ファイル::パス、モジュール::検索、JSON、エラーのPerlライブラリが必要です。 それらをインストールします。



sudo cpan -i File::Path

sudo cpan -i Module::Find

sudo cpan -i JSON

sudo cpan -i Error







すべてが正しく行われたかどうかを確認します。 次のパラメーターを使用してスクリプトを呼び出します。



/usr/local/sbin/jmx-grabber 8080 RUNTIME_VM_NAME







「Java HotSpot（TM）Client VM」という行を返す必要があります。 フォルダー/ var / jmxを作成し、他のパラメーターを使用してスクリプトを呼び出します。



/usr/local/sbin/jmx-grabber 8080 DUMP







/ var / jmxフォルダーの内容を確認します。 サブディレクトリ8080が表示されます。サブディレクトリには、JVMメトリックを含むファイルが含まれ、メトリックごとに1つのファイルがあります。 8080がjolokiaエージェント（スタンドアロンインストール）またはjolokiaコンテナーを備えたTomcatをリッスンするローカルポートであると推測するのは難しくありません。



メトリックの収集と読み取りを設定したら、Zabbixにアップロードするプロセスに進みます。

JVMメトリックをZabbixにアップロードする

/etc/zabbix/zabbix_agentd.confファイルに2行追加します。



UserParameter=jmx_grabber[*],/usr/local/sbin/jmx-grabber $1 $2

UserParameter=jmx_reader[*],/usr/local/sbin/jmx-stats-reader $1 $2







その後、zabbixエージェントを再起動することを忘れないでください。 追加された行により、通常のZabbixメトリックのようなファイルシステムスクリプトにアクセスできます。 別の方法があります：zabbixトラッパーを使用できますが、アクティブモードで統計を送信するためにzabbixエージェントを使用しません。 大きな違いはありません。 Zabbix-agentを使用する場合、UIを介してZabbixでデータ収集期間が設定されます。 トラッパーを使用する場合は、パペット（またはその類似物）を介してメトリックを送信するためのcronスクリプトを分散させる必要があります。



次に、テンプレートを作成します。 このプロセスに深く入り込むことはせず、Zabbixにインポートする必要があるテンプレートの完成したxmlファイルを添付します。 これを行うには、「構成->エクスポート/インポート」タブを開き（Zabbixの最新バージョンでは、インポートは「構成->テンプレート」にあり、「テンプレートのインポート」ボタン）、リストから「インポート」を選択します。







次に、追加したテンプレートをサーバーに割り当てる必要があります。 「構成->ホスト」タブに移動し、「Zabbixサーバー」をクリックします。 「リンクされたテンプレート」パネルで、テンプレート「Template_Multitenant_Tomcat_JMX_Toolkit」を追加します。 「保存」をクリックして、「監視->最後のデータ」に進みます。 20秒後、Tomcat JVMで最初の統計を取得します。 データが届かない場合は、zabbix-agentが実行されているかどうか、および正しく構成されているかどうかを確認してください（上記を参照）。 30分後、グラフを見ることができ（「監視->グラフ」）、「Tomcat JVM Memory」について次のようなものが表示されます。







ほとんどの場合、質問がありますが、同じ物理/仮想マシン上に複数のJVMがある場合はどうなりますか？ はい、これは不快な機能ですが、監視のために1台のマシンの複数のJVMを追加するには、データが収集される各jolokiaポートに対して個別のテンプレートを作成する必要があります。

テスト実行

さて、Tomcat JVMを使用したメトリック収集システムがあります。 実際に試してみるといいでしょう。 これらの目的のために、スレッドを作成する小さなサービスを作成しました。スレッドは、JVMでオブジェクトが停止するまで継続的に生成します。 外部からアクセス可能な管理インターフェイスは次のようになります。







[増加]ボタンと[減少]ボタンは、スレッドの数を増減します。[乗数]を使用すると、次のオブジェクトを生成する前に、ストリームの遅延時間間隔の乗数を制御できます。 サービスはこちらからダウンロードできます 。



Tomcatにサービスを配置し、次の操作を実行します。

• スレッド数を20に上げて5分間待ちます
• スレッドの数を50に増やし、5分間再び待ちます
• フロー遅延係数を50に減らして5分間待ちます
• スレッドの数をゼロにリセットします

その結果、次のグラフが得られます。

ザップキャット

受け入れ可能な既成のソリューションが見つからなかったと言ったとき、私は少しずるいです。 1つの解決策があります-これはZapcatです。 ところで、TomcatとZabbixを横断するためにそれを使用するのに5分以上かかりません。 なぜ自転車を発明したのですか？ これには2つの理由があります。

• zapcatは2008年以降更新されていません。 それが完全に悪いというわけではない-彼はまだかなりうまくいった。 しかし、誰もサポートしていないシステムを使いたくはありません。
• エージェントは、アプリケーションコードでスタンドアロンのzapcatサービスに直接接続します。 私にとっては、出生時に眼圧計やその他のセンサーが縫い付けられたように見えますが、これは後で手術でしか取り外せません。 私は本当にzapcat（もはやサポートされていない）をアプリケーションの一部にしたくありませんでした。 それは安全ではなく、建築の観点からは文盲です。 理論的には、zapcatはjavaagentとして設計できますが、同じ名前のディレクティブを使用して接続できる既製の実装は見つかりませんでした。

私が説明した監視方法が必要かどうか、またはzapcatで十分かどうかを判断するために、展開が簡単な代替手段として、次の質問をしてください。

• 監視ツールをアプリケーションに統合しますか？ （スタンドアロンサービスにのみ関連）
• ファイルシステム（またはキャッシュ）に既に収集されている中間データの追加処理を実行しますか。 すべてのサービスコピー全体の平均合計を計算できます。
• zabbix以外のツールを使用してjmxブリッジ経由でサービス/アプリケーションにアクセスしますか？

最後に

私が提案したオプションは、特定のタスクとニーズに基づいて耐用年数監視システムを構築するためのフレームワークとしての既成の監視システムではありません。 エージェントを検出し、監視にネットワークノードを自動的に追加するZabbixの機能と併せて、Javaサービスの動作を制御するタスクが数回簡素化されます。

設定に問題がある場合-個人的なメッセージやコメントを書いてください。可能な限りお伝えします。 テストベンチを手動で構成したくない場合は、VirtualBoxに既製のイメージ （ログインレッド、パスワードパスワード）を使用することをお勧めします。

素晴らしい実験と安定したJVMをお楽しみください！ ;-)



PS：ランチタイムと夕方にのみメッセージとコメントに返信できます