JMX統合により、ユーザーは JMX でメトリクスを公開するあらゆるアプリケーションを監視できるようになります。統合には、JVM から主要なメトリクスを自動的に収集するデフォルトの収集ファイルが含まれています。
互換性と要件
統合をインストールする前に、次の要件を満たしていることを確認してください。
- NewRelicアカウント。持っていませんか?無料でお申し込み頂けます!クレジットカードは必要ありません。
- Java バージョン 8 以降。
PATH
で構成されたものとは異なる Java バージョンを使用する必要がある場合は、 GitHub にある New Relic の構成ドキュメントに従ってください。- 本製品はIIOPプロトコルに対応していません。
クイックスタート
Kubernetes または ECS 環境で JMX を実行していない場合は、ガイド付きインストールをお勧めします。ガイド付きインストールでは、インフラストラクチャ エージェントと CLI を使用して JMX 統合をセットアップし、環境内で実行されている他のアプリケーションとログ ソースを検出して、どのアプリケーションを計測する必要があるかを推奨します。
ガイド付きインストールは、ほとんどの設定と連動します。ただし、ご希望に添えない場合は、以下の他のインストールオプションがあります。
始める準備はできていますか?使用するデータセンターの地域に応じて、該当するボタンをクリックします。インストールが完了したら、本ドキュメントに戻って設定オプションを確認してください。
インストール
ガイド付きインストールを使用しない場合は、ご使用の環境に応じた手順に従ってください。
''
統合を更新する
このインテグレーションは、自動更新しません。最善の結果を得るため、インテグレーションパッケージの更新とInfrastructureエージェントの更新を定期的に実施してください。
インストール後のタスク
インストールが完了したら、設定オプションを設定できます。インテグレーションを機能させるには、設定がいくつか必要ですが、オプションの設定もあります。
統合を構成する
統合のYAML形式の構成では、必要なログイン資格情報を配置し、データの収集方法を構成できます。どのオプションを変更するかは、セットアップと設定によって異なります。
インストール方法に応じて、統合を構成する方法はいくつかあります。
- Kubernetes経由で有効になっている場合: Kubernetesで実行されているサービスの監視をご覧ください。
- Amazon ECSを介して有効になっている場合: ECSで実行されている監視サービスを参照してください。
- ホストにインストールされている場合:統合のYAML構成ファイル
jmx-config.yml
の構成を編集します。
統合設定ファイル
構成ファイルには、 interval
、 timeout
、 inventory_source
などのすべての統合に適用できる共通の設定があります。これらの一般的な設定についてすべて読むには、 構成フォーマットのドキュメントを参照してください。
JMXに関連する特定の設定は、構成ファイルのenv
セクションを使用して定義されます。これらの設定は、JMXインスタンスへの接続、およびその他のセキュリティ設定と機能を制御します。有効な設定のリストについては、このドキュメントの次のセクションで説明します。
設定オプションは以下の通りです。設定例については、 example config file を参照してください。
メトリクス収集ファイル
メトリクス・コレクション定義ファイルは構造化されたYAMLファイルで、どのようなメトリクスを収集するかをインテグレーションに伝えます。構成例については、 メトリクス・コレクション・ファイルの例 を参照してください。
デフォルトのJVMメトリック収集ファイル: /etc/newrelic-infra/integrations.d/jvm-metrics.yml
ヒント
整理やメンテナンスを容易にするために、異なるコレクションファイルを書くことができます。例として、 設定ファイル を参照してください。
Kubernetesのアノテーションを利用したコレクションの設定
Kubernetesアノテーションを使用して、コレクション構成を提供できます。これを実現するには、 nri-jmx
アプリケーションの構成ファイルを作成するKubernetesクラスターにconfigMap
をデプロイする必要があります。
この設定ファイルでは、 container auto-discovery のコマンドを指定する必要があります。これにより、Kubernetesのアノテーションを含む統合設定でプレースホルダーを使用することができます。
TomcatアプリケーションでJVMを監視するためのconfigMap
の例:
次に、アノテーションを使ってコレクションの構成を定義します。例えば、アノテーションを使用したTomcatのデプロイメントを示します。
apiVersion: apps/v1kind: Deploymentmetadata: name: tomcat-deployment labels: app: javaspec: replicas: 1 selector: matchLabels: app: java template: metadata: annotations: newrelic.config: >- { "collect": [ { "domain": "java.lang", "event_type": "JVMSample", "beans": [ { "query": "type=GarbageCollector,name=*", "attributes": [ "CollectionCount", "CollectionTime" ] }, { "query": "type=Memory", "attributes": [ "HeapMemoryUsage.Committed", "HeapMemoryUsage.Init", "HeapMemoryUsage.Max", "HeapMemoryUsage.Used", "NonHeapMemoryUsage.Committed", "NonHeapMemoryUsage.Init", "NonHeapMemoryUsage.Max", "NonHeapMemoryUsage.Used" ] }, { "query": "type=Threading", "attributes": [ "ThreadCount", "TotalStartedThreadCount" ] }, { "query": "type=ClassLoading", "attributes": [ "LoadedClassCount" ] }, { "query": "type=Compilation", "attributes": [ "TotalCompilationTime" ] } ] } ] } labels: app: java spec: containers: - name: tomcat image: tomcat:10.0.12 ports: - containerPort: 9999 env: - name: CATALINA_OPTS value: '-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false'
カスタム コネクタ
JMX では、アプリケーションとの通信にカスタム・コネクタを使用することができます。カスタムコネクターを使用するには、nrjmx クラスパスにカスタムコネクターを含める必要があります。
デフォルトでは、サブフォルダーconnectors
はクラスパスにあります。このフォルダが存在しない場合は、nrjmxがインストールされているフォルダの下に作成してください。
たとえば、JBossのサポートを追加するには、デフォルト(Linux)ライブラリパス/usr/lib/nrjmx/
( /usr/lib/nrjmx/connectors/
)の下にconnectors
という名前のフォルダーを作成し、カスタムコネクターjar( $JBOSS_HOME/bin/client/jboss-cli-client.jar
)をそのフォルダーにコピーします。これで、JBossに対してJMXクエリを実行できます。
構成例
オン・ホスト・インストールのためのファイル構成例。
オンホスト統合構成の一般的な構造の詳細については、「 構成」を参照してください。
データに名前を付ける
メトリックは、サンプルの形式で送信および保存されます。これは、メトリック データとメタデータを含むキーと値のペアのリストです。各サンプルは、データベースにイベントとして保存されます。
New Relic に報告する JMX データの作成と命名は、お客様の責任で行ってください。このため、New Relic では、イベントタイプの名前を付ける際に、これらの規約に従うことを強く推奨します。一貫した命名法を行うために。
- キャメルケースを使う。
- どのようなデータが含まれているのかが明確にわかるような名称を使用してください。
例: MyorgApplicationSample
推奨: 異なるアプリケーション間で類似したメトリクスに同じ命名法を使用する。
データを見つけて使用する
このサービスからのデータは、 統合ダッシュボードに報告されます。
JMXデータは、構成ファイルで指定されたユーザー定義のイベントタイプに添付されます。たとえば、JMX統合を使用してTomcatを監視することに関心がある場合は、 TomcatSample
}というevent_type
を定義し、そのイベントタイプをクエリします。
トラブルシューティングの目的で、またはカスタムチャートとダッシュボードを作成するために、このデータをクエリできます。
データを検索して使用する方法の詳細については、統合データについてを参照してください。
メトリックデータ
統合によって生成されたメトリクスには、収集元である MBean に関連するメタデータが含まれます。このメタデータを NRQL クエリ で使用して、クエリが目的のビーンのデータのみを返すように、データをフィルタリングおよびファセットすることができます。また、メトリクス名はすべてのビーン間で一意であるとは限らないため、メトリクスを一意に識別するために使用することもできます。
各イベントには、以下のメタデータが含まれています。
名前 | 説明 |
---|---|
| これらのメトリクスのJMXドメイン名です。 |
| これらのメトリクスのJMXドメイン名に、エンティティタイプの「domain:」を前置したもの。 |
| メトリクスを収集しているJMXホストです。 |
| これらのメトリクスを収集するために使用されるクエリ。 |
| これらのメトリクスが収集された属性を持つBean。 |
| Bean名のキーごとに、Beanのキーの値を使用して |
NRQLクエリの例
ここでは、収集されたすべてのJVMガベージコレクターをメタデータモニターで活用した、 NRQL クエリの例を示します。
SELECT latest(CollectionTime)FROM JVMSampleFACET `key:name`WHERE `key:type` = 'GarbageCollector'
メトリクスデータの属性
JMXインテグレーションでは、以下のメトリックデータ属性を収集します。
名前 | 説明 |
---|---|
| 使用されたJavaヒープメモリの合計。 |
| 使用するためにコミットされたJavaヒープメモリの合計。 |
| 最初に割り当てられたJavaヒープメモリ。 |
| 利用可能な最大のJavaヒープメモリです。 |
| 使用されたJavaの非ヒープメモリの合計。 |
| 使用するためにコミットされたJavaの非ヒープメモリの合計。 |
| 最初に割り当てられたJavaの非ヒープメモリ。 |
| 利用可能なJavaの非ヒープメモリの最大値です。 |
| ライブスレッドの数です。 |
| 発生したガベージコレクションの総数です。 |
| 経過したおおよその累積ガベージコレクション時間です。 |
在庫データ
JMX 統合の構成パラメータをキャプチャします。このデータは、 インベントリページ 、 config/jmx ソースの下にあります。インベントリデータの詳細については、 Understand integration data を参照してください。
トラブルシューティング
トラブルシューティングのヒント:
''
''
ソースコードを確認してください
この統合はオープン ソース ソフトウェアです。つまり、ソース コードを参照して改善を送信したり、独自のフォークを作成してビルドしたりできます。