単純な HTTP サーブレットで JMX を使用する理由
私の観点からは、JMX は次の 3 つの理由で優れています。
- 監視ポイントを有効にするために必要なコードが少なくて済みます。
- Java のシリアル化されたオブジェクトをエンドツーエンドで処理するため、データの一貫性が向上します。
- (前述のように)サーブレットベースではないプログラムで動作します。
JMX は、特定のデータ項目へのはるかに簡単なインターフェイスを提供します。多くのサーブレットで同じ機能を作成することは確かにできますが、JMX を使用してそれらを公開する方が簡単です。
たとえば、Spring を使用している場合は、org.springframework.jmx.export
注釈 ( @ManagedResource
、@ManagedAttribute
など) を使用してクラスをマークアップできます。また、 SimpleJmx フレームワークも公開したので、Spring とは関係なく、2 つのアノテーションだけで属性と操作を簡単に公開できます。例えば:
@JmxResource(domainName = "j256", objectName = "lookupCache")
public class LookupCache {
// this can also be done as @JmxAttributeMethod on the getter/setters
@JmxAttributeField(description = "Number of hits in the cache")
private int hitCount;
...
@JmxOperation(description = "Flush the cache")
public void flushCache() {
...
}
}
それがどのように機能するかを確認するために、完全に機能するサンプルプログラムがあります。したがって、値または操作を公開するために必要なことは、クラスと各属性および/またはメソッドに注釈を追加することだけです。SimpleJmx を使用して公開するコードは次のようになります。豆とはいえ、春は似ています:
// create a new server listening on port 8000
JmxServer jmxServer = new JmxServer(8000);
jmxServer.start();
// register our lookupCache object defined above
jmxServer.register(lookupCache);
サーブレットで同様の機能を実現するには、単なる注釈よりも多くのコードが必要になります。とはいえ、私が知らないサーブレットランドで同様の機能を提供するフレームワークが存在する可能性があります。
その他の注意事項:
- HTTP/HTML を理解するためのより優れた監視ツールが存在する可能性がありますが、分散型 JMX 監視アプリケーションも数多くあります。たぶん投げです。
- プログラムで JMX サーバーからオブジェクトを取得できることは、サーブレット ページからの単なる文字列とは対照的にプラスです。 SimpleJmxは単純な JMX クライアントもサポートしていますが、より優れたものがあります。
- もちろん、VM 設定、スレッドの詳細、メモリ情報など、他の多くの価値のあるデータがデフォルトで JVM によって公開されています。