JMX MBeanを設計する際のベストプラクティスにはどのようなものがありますか？特に役立つと思う例はありますか？
4 に答える
6
率ではなく絶対数を返します。たとえば、レートを導出するのではなく、db コミットの総数を返します。
これを行うことにより、クライアントは、必要な期間にわたって料金を自分で監視および導出できます。おそらくもっと重要なことは、これにより、クライアントがあまり頻繁に接続しない場合に、レートの急上昇を見逃すことからクライアントを保護できることです。
主に HTML インターフェース経由で JMX Bean を使用している場合、私が従ういくつかのプラクティスがあります。以下は、多くの場合、JMX Bean が既存の Bean をラップする必要があることを意味します (既存のメソッドを JMX に公開するだけではなく)。
- 返されたオブジェクトを表す適切にフォーマットされた文字列を出力します。デフォルトの
toString()出力を取得することはほとんど役に立たない可能性があります - 例外をキャプチャして表示します。そうしないと、空白のページが表示される可能性が高く、ログ ファイルにアクセスして何が問題なのかを判断する必要があります。
- 異なる文字セットを表示している場合は、表示の問題を防ぐために出力を適切にエスケープする必要がある場合があります (中国語のデータを表示する JMX コントロールでこれに遭遇しました)。
trim()公開されたメソッドへの入力は適切にサニタイズする必要があります (たとえば、操作の一部として ID を入力する場合、空白などを削除したい場合があります)。
上記は、JMX を介して単純に公開された Bean から、使用可能な管理コンソールに近づくものへと強調を変更します。
于 2009-03-31T14:11:52.460 に答える
4
最初の JMX Bean を手に入れた最初のことは、戻り値の型でした。メソッドが文字列を返すと、はるかに簡単になります。そうすれば、クライアントは簡単に応答を表示できます (私は主に JConsole を使用していました)。 、応答として com.mycompany.Response@xxxx のようなものを取得しますが、これはあまり意味がありません:)
于 2009-03-31T13:51:13.493 に答える
3
属性に副作用がなく、操作が予測可能であることを確認してください。
時間のかかる (またはリソースを消費する) 操作を実行する無害に見える属性ほど悪いものはありません。私は私の時代にいくつかのハムディンガーを見てきました..
于 2009-03-31T21:57:00.313 に答える
1
ロギングに JMX を使用しないでください。たとえば、起動以降のすべての接続の詳細を返す MBean 関数を使用しないでください。
JMX は監視用であることを覚えておく必要があります。意味 - 現時点に関連するデータのみを表示します。
于 2009-11-30T12:24:58.607 に答える