私たちは監視が好きです。 私たちはJavaが好きです。 他の言語を軽視することはありません。Ruby、perl、php、.NET、その他のプラットフォームも好きで、それらを監視することも好きです。
ただし、他のほとんどの言語とは異なり、Javaは、アプリケーションとシステムオブジェクトを監視するための明示的なテクノロジを提供します。 JMXは、JVMを実行するすべてのプラットフォームでサポートされていますが、他のほとんどの監視プロトコルと同様に、興味深いニュアンスと使用方法がたくさんあります。 これは、それを検出して監視する方法に多くのニュアンスがあることを意味します。
標準アプリケーションとカスタムアプリケーションの両方で、JMX監視にLogicMonitorを使用しているお客様が静かにいるため、かなりの数の小さな問題が発生し、それらを解決しました。
XNUMXつの例は、JMXオブジェクトの命名規則が大まかに定義されていることです。 当初、LogicMonitorのJMXコレクターは、で指定されているように、すべてのオブジェクトに「タイプ」キープロパティがあると想定していました。 ベストプラクティス。 もちろん、これは「遵守よりも違反の方が尊重される」というルールです。WowzaMediaServerやTomcatなどの広範なアプリケーションはこれに準拠していないためです。
もうXNUMXつの例は、JMXが複雑なデータ型をサポートしていることです。 すべてのクラスのデータに異なるMbeanを登録するのではなく、マップのマップを返すMbeanを公開するお客様がいます。 コレクターとActiveDiscoveryは、これらのデータ型の使用を予期していなかったため、最初はこれらのデータ型を処理しませんでした。 しかし、さまざまなケースでそれらを使用する正当な理由があるため、LogicMonitorはユーザーの希望をサポートする必要があります。これは、LogicMonitorによって、ユーザーが先入観に縛られるのではなく、ユーザーが望む方法で作業できるようにするという私たちの信条のXNUMXつです。 。 そこで、ActiveDiscoveryを拡張して、マップ、マップのマップ、および複合データ型を反復処理しました。
これにより、お客様は、管理とアラートの構成を自動化しながら、最も適切と思われる方法でアプリケーションをインストルメント化できます。 JMXのすべての順列がカバーされていると思いますが、サポートされていない完全に論理的なユースケースを追加する新しいバリアントが新しい顧客に提供されないことは間違いありません。 もちろん、その場合はXNUMXか月程度でサポートし、現在および将来のすべてのお客様がすぐにメリットを享受できるようになります。 これは、ホスト型SaaSモデルの優れた点のXNUMXつにすぎません。