原文はこちら。
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server
WebLogic Serverは実行時にたくさんの一連のメトリックとランタイムのステート情報を生成します。呼び出し件数、セッション・アクティビティ、ワークマネージャー・スレッドなど、数千ものメトリックを使用してパフォーマンス・データを取得できます。これらのメトリックは、アクティビティの追跡、問題の診断、十分なリソースが利用可能であることを保証する上で非常に役立ちます。メトリックはJMXとWebサービスの両方で公開され、Enterprise ManagerやWebLogic Server Administration ConsoleなどのOracle管理ツールやサードパーティのクライアントでサポートされています。
そんなサードパーティ・クライアントの1つにPrometheusがあります。
![]()
このツリーでは、ServerRuntimeはMBeanツリーの最上位で、複数のApplicationRuntime MBeanを持ちます。各々のApplicationRuntime MBeanは複数のComponentRuntime MBeanを有しています。 それらの中には、複数のServlet MBeanを持つWebAppComponentRuntime型のものがあります。次のようにJMX Exporterを構成することができます。
JMX Exporterもややプロセッサに負荷を掛けます。ツリー内の各Beanを取得するためにJMXを別々に起動する必要があるため、サーバーで処理を行う必要があります。Exporterの設定は、MBean名と正規表現に依存しているため、難しい場合があります。論理的には、特定のMBeanの属性のサブセットを選択することは可能ですが、実際には正規表現にさらに複雑さが加わり、実現困難になるでしょう。その結果、すべての情報を収集してデータ伝送およびストレージのコストを負担しつつ、データを最終的に表示するときにのみフィルタリングすることが一般的です。
Oracleは、このインタフェースを利用するWebLogic Monitoring Exporterを作成しました（もうすぐ公開する予定です）。このExporterは、監視対象のWebLogic ServerインスタンスにデプロイされるWebアプリケーションとして実装されています。その設定は、ServerRuntime MBeanの下から始まるMBeanツリーに明示的に従います。
先ほどの例と同じ結果を得るには、以下のように呼び出します。
Exporterは常にデプロイ先のサーバに接続しているため、URLを指定する必要がないことにご注意ください。ユーザー名やパスワードを指定するのではなく、クライアントがメトリックを読み取ろうとする場合にメトリックを指定する必要があります。
![]()
ランディングページにはメトリックのリンクが含まれているだけでなく、常に現在の構成も表示しています。最初にアプリケーションがロードされた時は、WARファイルに埋め込まれている構成を使います。しかしながら、ランディングページには新たなyamlファイルを選択することで構成を変更できるようなフォームがあります。
新たなファイルからのクエリのみを使用し、送信前にAppendボタンを選択してクエリを組み合わせることができます。
例えば、いくつかのJVMメトリックを追加してみましょう。
![]()
次回クライアントがメトリックのURLにアクセスすると、新しいメトリックをレポートします。上記の新たな要素は以下のようなメトリックを生成します。
これを使用するには、クエリ同期を記述する新しい最上位の要素を初期構成に追加する必要があります。
coordinatorを使用するように構成されたExporterで構成を更新すると、新しいクエリはcoordinatorに送信され、他のExporterがクエリをロードできるようになります。このように、管理対象サーバのクラスタ全体で、そのメトリック構成を同期しながら保持することができます。
テストでは、CPU使用率が低く、より迅速に応答しており、JMX Exporterと比べてパフォーマンスが大幅に向上しています。以下のグラフで緑色の線がJMX Exporter、黄色の線がWebLogic Monitoring Exporterを表します。
![]()
WebLogic Serverのパフォーマンスを監視したいお客様にとって、このWebLogic Monitoring Exporterがお役に立つことを願っています。今後のエントリで、PrometheusとGrafanaを使って取得したデータを監視する方法について詳しく説明する予定です。
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server
WebLogic Serverは実行時にたくさんの一連のメトリックとランタイムのステート情報を生成します。呼び出し件数、セッション・アクティビティ、ワークマネージャー・スレッドなど、数千ものメトリックを使用してパフォーマンス・データを取得できます。これらのメトリックは、アクティビティの追跡、問題の診断、十分なリソースが利用可能であることを保証する上で非常に役立ちます。メトリックはJMXとWebサービスの両方で公開され、Enterprise ManagerやWebLogic Server Administration ConsoleなどのOracle管理ツールやサードパーティのクライアントでサポートされています。
そんなサードパーティ・クライアントの1つにPrometheusがあります。
Prometheus - Monitoring system & time series databasePrometheusは、クラウド環境で時系列データの収集、保存、クエリのフレームワークとしてよく使われるオープンソースの監視ツールキットです。さまざまなサービスからの情報を収集し、その情報をPrometheusサーバーに供給するための数多くのExporterが作られています。
https://prometheus.io/
Exporters and IntegrationsデータがPrometheusに入ると、Prometheus自体、またはPrometheusのデータを処理できるGrafanaなどのツールを使用して取得できます。
https://prometheus.io/docs/instrumenting/exporters/
Grafana - The open platform for analytics and monitoringOracleのお客様は、汎用的なPrometheus JMX Exporterを使用してWebLogic Serverインスタンスから情報を取得していますが、このソリューションは、より大きなサイトでのユーザビリティの問題とスケーラビリティがネックになっています。
https://grafana.com/
prometheus/jmx_exporterMBeanツリーの次の部分を考えてみましょう。
https://github.com/prometheus/jmx_exporter
このツリーでは、ServerRuntimeはMBeanツリーの最上位で、複数のApplicationRuntime MBeanを持ちます。各々のApplicationRuntime MBeanは複数のComponentRuntime MBeanを有しています。 それらの中には、複数のServlet MBeanを持つWebAppComponentRuntime型のものがあります。次のようにJMX Exporterを構成することができます。
これにより適切なMBeansが選択され、Exporterが以下のようなメトリックを生成することができます。jmxUrl: service:jmx:t3://@HOST@:@PORT@/jndi/weblogic.management.mbeanservers.runtime
username: system
password: gumby1234
lowercaseOutputName: false
lowercaseOutputLabelNames: false
whitelistObjectNames:
- "com.bea:ServerRuntime=*,Type=ApplicationRuntime,*"
- "com.bea:Type=WebAppComponentRuntime,*"
- "com.bea:Type=ServletRuntime,*"
rules:
- pattern: "^com.bea<ServerRuntime=.+, Name=(.+), ApplicationRuntime=(.+), Type=ServletRuntime, WebAppComponentRuntime=(.+)><>(.+): (.+)"
attrNameSnakeCase: true
name: weblogic_servlet_$4
value: $5
labels:
name: $3
app: $2
servletName: $1
- pattern: "^com.bea<ServerRuntime=(.+), Name=(.+), ApplicationRuntime=(.+), Type=WebAppComponentRuntime><>(.+): (.+)$"
attrNameSnakeCase: true
name: webapp_config_$4
value: $5
labels:
app: $3
name: $2
webapp_config_open_sessions_current_count{app="receivables",name="accounting"} 3
webapp_config_open_sessions_current_count{app="receivables",name="inventory"} 7
weblogic_servlet_invocations_total_count{app="receivables",name="accounting",servletName="Balance"} 0
weblogic_servlet_invocations_total_count{app="receivables",name="accounting",servletName="Login"} 0
weblogic_servlet_invocations_total_count{app="receivables",name="inventory",servletName="Count"} 0
weblogic_servlet_invocations_total_count{app="receivables",name="inventory",servletName="Reorder"} 0JMX Exporterもややプロセッサに負荷を掛けます。ツリー内の各Beanを取得するためにJMXを別々に起動する必要があるため、サーバーで処理を行う必要があります。Exporterの設定は、MBean名と正規表現に依存しているため、難しい場合があります。論理的には、特定のMBeanの属性のサブセットを選択することは可能ですが、実際には正規表現にさらに複雑さが加わり、実現困難になるでしょう。その結果、すべての情報を収集してデータ伝送およびストレージのコストを負担しつつ、データを最終的に表示するときにのみフィルタリングすることが一般的です。
The WebLogic Monitoring Exporter
JMXとともに、Oracle WebLogic Server 12.2.1以降で、ランタイムの状態およびメトリックにアクセスするためのRESTfulな管理インタフェースを提供しています。Oracle® Fusion Middleware RESTful管理サービスによるOracle WebLogic Serverの管理 12c (12.2.1.2.0)このインターフェースには強力なバルクアクセス機能が含まれているため、クライアントは、必要な情報を正確に記述し、当該情報のみを含む単一の応答を取得するクエリをPOSTすることができます。
WLS RESTful管理インタフェースについて
https://docs.oracle.com/cd/E84527_01/wls/WLRUR/overview.htm#GUID-B193E8EF-1912-48D1-8FB9-99C5ADACCC3B
Oracle® Fusion Middleware Administering Oracle WebLogic Server with RESTful Management Services 12c (12.2.1)
About the WLS RESTful Management Interface
https://docs.oracle.com/middleware/1221/wls/WLRUR/overview.htm#WLRUR111
Oracleは、このインタフェースを利用するWebLogic Monitoring Exporterを作成しました（もうすぐ公開する予定です）。このExporterは、監視対象のWebLogic ServerインスタンスにデプロイされるWebアプリケーションとして実装されています。その設定は、ServerRuntime MBeanの下から始まるMBeanツリーに明示的に従います。
先ほどの例と同じ結果を得るには、以下のように呼び出します。
このExporterで、所望のメトリックを単一のHTTPクエリを使って取得できます。複数回のJMXクエリや、特殊な設定は不要で、MBeanのために生成されたメトリックを簡単に選択することができます。metricsNameSnakeCase: true
queries:
- applicationRuntimes:
key: name
keyName: app
componentRuntimes:
type: WebAppComponentRuntime
prefix: webapp_config_
key: name
values: [openSessionsCurrentCount, openSessionsHighCount]
servlets:
prefix: weblogic_servlet_
key: servletName
Exporterは常にデプロイ先のサーバに接続しているため、URLを指定する必要がないことにご注意ください。ユーザー名やパスワードを指定するのではなく、クライアントがメトリックを読み取ろうとする場合にメトリックを指定する必要があります。
Managing the Application
ExporterはWebアプリケーションなので、ランディングページがあります。
ランディングページにはメトリックのリンクが含まれているだけでなく、常に現在の構成も表示しています。最初にアプリケーションがロードされた時は、WARファイルに埋め込まれている構成を使います。しかしながら、ランディングページには新たなyamlファイルを選択することで構成を変更できるようなフォームがあります。
新たなファイルからのクエリのみを使用し、送信前にAppendボタンを選択してクエリを組み合わせることができます。
例えば、いくつかのJVMメトリックを追加してみましょう。
次回クライアントがメトリックのURLにアクセスすると、新しいメトリックをレポートします。上記の新たな要素は以下のようなメトリックを生成します。
jvm_heap_free_current{name="myserver"} 285027752
jvm_heap_free_percent{name="myserver"} 71
jvm_heap_size_current{name="myserver"} 422051840Metrics in a WebLogic Server Cluster
もちろん、WebLogic Serverクラスタでは、単一のサーバインスタンスで収集したメトリックを変更してもほとんど意味がありません。すべてのクラスタメンバーが同じアプリケーションをホストしているため、同じメトリックを報告させるようにします。このためには、いずれかのサーバに加えられた変更に対してすべてのサーバーが応答するように設定する必要があります。Exporterでは、別のconfig_coordinatorプロセスを使用して変更を追跡することでこの課題に対応します。これを使用するには、クエリ同期を記述する新しい最上位の要素を初期構成に追加する必要があります。
ここでは、個別のDockerコンテナで実行されるconfig_coordinatorプロセスのURLを指定します。Exporterがはじめて起動した際、構成にこの要素が含まれている場合は、coordinatorに連絡して、新しい構成があるかどうかを確認します。 その後、ランディングページまたはメトリックページのいずれかがクエリされるたびに実行されます。 オプションのrefreshInterval要素は、Exporterが構成の更新を探す頻度を制限します。refreshIntervalがあれば、サーバーを再起動するのではなく、すぐにロードします。query_sync:
url: http://coordinator:8099
refreshInterval: 10
coordinatorを使用するように構成されたExporterで構成を更新すると、新しいクエリはcoordinatorに送信され、他のExporterがクエリをロードできるようになります。このように、管理対象サーバのクラスタ全体で、そのメトリック構成を同期しながら保持することができます。
Summary
WebLogic Monitoring Exporterは、Docker/Kubernetes環境でのWebLogic Serverインスタンスのクラスタから、メトリックをエクスポートするプロセスを大幅に簡素化します。MBean名を調べ、正規表現でごにょごにょする必要はありません。また、フィールド名からメトリックラベルを明示的に定義することができ、一貫性を確保するために、従属MBeanのメトリックにそれらの定義を自動的に使用します。テストでは、CPU使用率が低く、より迅速に応答しており、JMX Exporterと比べてパフォーマンスが大幅に向上しています。以下のグラフで緑色の線がJMX Exporter、黄色の線がWebLogic Monitoring Exporterを表します。
WebLogic Serverのパフォーマンスを監視したいお客様にとって、このWebLogic Monitoring Exporterがお役に立つことを願っています。今後のエントリで、PrometheusとGrafanaを使って取得したデータを監視する方法について詳しく説明する予定です。