JMX インターフェイスを使用したライブ モニタリング
この記事は、JMX クライアントでの監視用に Jira 内で JMX MBeans を表示する方法、および製品内診断用に JMX MBeans を使用する方法について説明します。
このガイドは、JMX インターフェースの基本的な概要を紹介します。内容は現状のまま提供されるものとします。弊社のサポート チームは、特定の Jira の問題のトラブルシューティングをサポートできますが、監視システムのセットアップや、結果の解釈についてはサポート対象外となります。
JMX とは何か
JMX (Java Management Extensions) は、Java アプリケーションを監視及び管理するための技術です。JMX は、MBeans (Managed Beans) と呼ばれるオブジェクトを使用して、アプリケーションからデータやリソースを表示します。Jira Server または Jira Data Center の大規模なインスタンスでは、JMX を有効化することで、アプリケーション リソースの消費量をより簡単に監視したり、インデックス関連のパフォーマンスの問題をより簡単に診断したりできるようになります。これにより、マシン リソースの保持 / 最適化方法について、より優れた判断を行えます。
Jira によって収集されるメトリック
次のテーブルは、Jira が収集するメトリック (MBeans) を示します。これらはすべて、com.atlassian.jira プロパティにグループ化されます。
| メトリック | 説明 | Jira 起動後にリセット |
|---|---|---|
| dashboard.view.count | すべてのダッシュボードがユーザーによって閲覧された回数 | はい |
| entity.attachments.total | 添付ファイルの数 | N/A |
| entity.components.total | コンポーネントの数 | N/A |
| entity.customfields.total | カスタム フィールドの数 | N/A |
| entity.filters.total | フィルターの数 | N/A |
| entity.groups.total | ユーザー グループの数 | N/A |
| entity.issues.total | 課題の数 | N/A |
| entity.users.total | ユーザー数 | N/A |
| entity.versions.total | 作成されたバージョンの数 | N/A |
| issue.assigned.count | 課題がユーザーに割り当てられた/再割り当てされた回数 (各アクションをカウント) | はい |
| issue.created.count | Jira インスタンス起動後に作成した課題の数 | はい |
| issue.link.count | Jira インスタンス起動後に作成した課題リンクの数 | はい |
| issue.search.count | 課題の検索回数 | はい |
| issue.updated.count | 課題の更新回数 (情報の追加または変更後の各更新) | はい |
| issue.worklogged.count | 課題に対する作業の記録回数 | はい |
| jira.license | 所有しているライセンスのタイプ、アクティブ ユーザーの数、および各ライセンス タイプで利用可能なユーザーの最大数 | N/A |
| quicksearch.concurrent.search | リアルタイムで実行されているクイック検索の同時検索数です。これを使用すると、同時検索に設定した制限が十分かどうかを判断できます。 | はい |
| web.requests | リクエストの数 (invocation.count)および合計応答時間 (total.elapsed.time) | はい |
次のメトリックは 8.1 以降の Jira に追加されており、com.atlassian.jira/metrics で公開されています。次のメトリックは、Jira を再起動するとすべてリセットされます。
メトリック パス | 説明 |
|---|---|
comment | コメント操作に関するメトリック |
comment/Create | 作成されているコメント |
comment/Delete | 削除されているコメント |
comment/Update | 更新されているコメント |
indexing | Metrics related to issue, comment, worklog, and change indexing |
indexing/CreateChangeHistoryDocument | 変更履歴のエンティティ用に作成されているインデックス ドキュメント。各課題に対して複数の変更履歴ドキュメントが作成される可能性があることにご注意ください。 |
indexing/CreateCommentDocument | コメント エンティティ用に作成されているインデックス ドキュメント |
indexing/CreateIssueDocument | 課題エンティティ用に作成されているインデックス ドキュメント。 |
indexing/IssueAddFieldIndexers | FieldIndexer modules enrich Issue documents as part of Index document creation. Plugins can register custom FieldIndexer modules. These metrics provide insight into how much time is spent in FieldIndexer and can be used to track down indexing performance issues caused by them. The metrics describe how much time was spent in all FieldIndexers combined per Issue document created. |
indexing/LuceneAddDocument | Lucene インデックスへのドキュメントの追加に費やされた時間 |
indexing/LuceneDeleteDocument | Lucene インデックスから語句が一致する 1 つ以上のドキュメントを削除するのに費やされた時間 |
indexing/LuceneOptimize | Lucene インデックスの最適化に関するメトリック (Jira から手動でトリガーされます) |
indeding/LuceneUpdateDocument | Lucene インデックスへの作成済みドキュメントの追加に費やされた時間 |
indexing/ReplicationLatency | レプリケーション遅延は、変更が行われたノードで課題、コメント、または作業ログのインデックス作成が行われてから現在のノードでインデックス作成操作が再生されるまでの時間です。 |
indexing/WaitForLucene | ドキュメントは Lucene インデックスに非同期で書き込まれます。このメトリックでは、Lucene が書き込みを完了するまで Jira のインデックス作成スレッドが待機した時間をキャプチャします。 |
indexing/issueAddSearchExtractors | EntitySearchExtractor は、インデックス ドキュメント作成の一環として課題ドキュメントを強化するものです。プラグインを使用してカスタム EntitySearchExtractor モジュールを登録できます。これらのメトリックを利用すると、EntitySearchExtractor で費やされた時間に関するインサイトを得て、それらによって生じたインデックス パフォーマンスの低下を追跡できます。これらのメトリックは、作成された課題ドキュメントごとに組み合わされたすべての EntitySearchExtractor で費やされた時間について示しています。 |
課題 | 課題操作に関するメトリック |
issue/Create | 作成されている課題 |
issue/Delete | 削除されている課題 |
issue/Index | Lucene インデックスに追加されている課題。これは、課題ドキュメントの作成およびインデックスへのドキュメントの追加を対象としています。 |
issue/DeIndex | Lucene インデックスから削除されている課題 |
issue/ReIndex | 課題更新の結果としてインデックスが再作成されている課題。これは、課題ドキュメントの作成、インデックスからの古いドキュメントの削除、およびインデックスへの新しいドキュメントの追加を対象としています。 |
issue/Update | 更新されている課題 |
Metrics collected by Assets in Jira Service Management
The following table lists metrics (MBeans) that are collected by Assets in Jira Service Management.
メトリック | 説明 |
|---|---|
assets.objectindeximpl.objects_load_on_add_ms | How long to load objects when a message is received. This metric tells you how long it took to populate the index from the database. |
assets.objectindeximpl.missing_objects_reload_retry_count_on_add | The number of attempts to reload an object when adding the object to the database. The metric gives an indication on how many attempts it took to load the object from the database due to the delays in writing to the database. |
assets.objectindeximpl.missing_objects_count_on_add | The number of missing objects on the first attempt at adding them to the database. This metric indicates the number of missing objects. |
assets.objectindeximpl.missing_objects_reload_on_add_ms | The time in milliseconds that was spent trying to reload from the database when an object wasn’t available. This metric shows how much time was spent looping and waiting for the object to be available in the database. |
assets.objectindeximpl.objects_load_on_update_ms | The time in milliseconds to load updates for on the first attempt.
|
assets.objectindeximpl.missing_objects_reload_on_update_ms | The time in milliseconds that is spent waiting for updates to appear in the database.
|
assets.objectindeximpl.missing_objects_reload_retry_count_on_update | The number of attempts to reload an object on update until the right version was found. |
assets.objectindeximpl.missing_objects_reload_retry_count_on_update | The number of missing object updates that were not ready in the database when an update started. |
assets.objectindeximpl.objects_removal_ms | The time in milliseconds that indicates how long it took to remove objects from Assets.
|
assets.assetsbatchreplicationmessageworkqueuepoller.process_ms | The number of milliseconds that indicates how long to process a replication message. |
assets.assetsbatchreplicationmessageworkqueuepoller.number_of_create_failures | The number of failures in a message batch when an object is created. |
assets.assetsbatchreplicationmessageworkqueuepoller.number_of_update_failures | The number of failures in a message batch when an object is updated. |
assets.cachemessageworkqueuepoller.process_batch_size | The number of object changes that were batched together to be sent across the cluster. |
assets.cachemessageworkqueuepoller.wait_for_clearance_ms | The time in milliseconds that is spent waiting for database updates to be drained from the application or submitted to the database. |
assets.cachemessageworkqueuepoller.process_ms | The time in milliseconds that is the total duration of the process of batching and sending a replication message. |
assets.assetsbatchreplicationmessagereceiver.work_queue_size | The size of the work queue in the replication message receiver. |
assets.assetsbatchreplicationmessagereceiver.work_queue_gauge | The current size of the work queue in the replication message receiver |
assets.assetsobjectreplicationbatchmanager.work_queue_size | The work queue size in the batch manager collecting individual changes to batch and send across the cluster. |
assets.assetsobjectreplicationbatchmanager.work_queue_gauge | The current work queue size in the batch manager collecting individual changes to batch and send across the cluster |
assets.defaultassetsbatchmessagesender.send_message | The amount of time to dispatch the message and continue processing the next message. |
assets.insightcachereplicatorimpl.legacy_object_receiver_queue_size | The queue size on the legacy replication mechanism using cluster messages. |
assets.insightcachereplicatorimpl.object_replication_dispatch | The amount of time it takes to |
assets.insightcachereplicatorimpl.legacy_object_send_queue_size | The queue size after offering a message for legacy index replication using the cluster message cache.
|
assets.assetsreplicationretryqueuepoller.retry_queue_size | The size of the retry/failure queue. |
assets.assetsreplicationretryqueuepoller.create_retry_attempts | The number of attempts to get successful processing for creating a message. |
assets.assetsreplicationretryqueuepoller.update_retry_attempts | The number of attempts to get successful processing for updating a message. |
assets.assetsreplicationretryqueuepoller.replay_wait_time | The amount of waiting time that was added before retrying the update. This metric helps to see if processing is keeping up with the queue, or if updates are backlogged and being processed immediately. If there is no waiting time applied, the queue is not processed quickly enough. |
assets.assetsreplicationretryqueuepoller.dead_letter_queue_size | The number of items in the dead letter queue. |
assets.assetsreplicationretryqueuepoller.process_retry_excluding_wait_ms | The time in milliseconds that it takes to process the failures, excluding any wait time prior to processing. This metric is an indication of how long the batches of failures are taking to be processed. It will also help to see if more delays are being added in the |
assets.assetsreplicationretryqueuepoller.dead_letter_queue_gauge | The current number of messages in the dead letter queue. |
assets.assetsreplicationretryqueuepoller.retry_queue_gauge | The current number of messages in the retry queue. |
Jira の監視
Jira を監視する前に、JMX の監視を有効にしてから、JMX クライアントを使用してメトリックを表示する必要があります。
考慮事項
メトリックの閲覧は常に、Jira にパフォーマンス上の影響を与えます。更新は 1 秒に 1 回未満にすることをお勧めします。
Jira で JMX 監視を有効化する
All of the metrics are collected by default, but you should enable JMX monitoring to expose them. You can do it in Jira but you must be a Jira admin.
- 上部のナビゲーション バーから [管理者
] > [システム] を選択します。 - Go to JMX monitoring.
- JMX 監視の有効化を切り替えます。
JConsole を使って監視する
JMX 監視を有効にした後、任意の JMX クライアントを使用してメトリックを表示できます。これをすばやく簡単に行うために、ここでは、JConsole を使用して表示する方法について説明しています。Jira インスタンスはローカルでもリモートでも監視できます。
特定の課題のトラブルシューティングを行う場合、または Jira を短期間のみ監視する必要がある場合は、Jira のローカル監視が便利です。ローカル監視はサーバーのパフォーマンスに影響を与える可能性があるため、本番システムの長期的な監視にはお勧めしません。
Jira のリモート監視は、Jira Server のリソースを消費しないため、本番環境システムにお勧めです。
手順についてリモートで監視するには:
Add the following properties to your
setenv.sh/setenv.batfile. The port can be any port that is not in use.
CATALINA_OPTSWindowsSET CATALINA_OPTS="-Dcom.sun.management.jmxremote.authenticate=true ${CATALINA_OPTS}" SET CATALINA_OPTS="-Dcom.sun.management.jmxremote.password.file=/atlassian-jira-software-x.y.z-standalone/jmxremote.password ${CATALINA_OPTS}" SET CATALINA_OPTS="-Dcom.sun.management.jmxremote.access.file=/atlassian-jira-software-x.y.z-standalone/jmxremote.access ${CATALINA_OPTS}"
x.y.zLinuxCATALINA_OPTS="-Dcom.sun.management.jmxremote.authenticate=true ${CATALINA_OPTS}" CATALINA_OPTS="-Dcom.sun.management.jmxremote.password.file=/atlassian-jira-software-x.y.z-standalone/jmxremote.password ${CATALINA_OPTS}" CATALINA_OPTS="-Dcom.sun.management.jmxremote.access.file=/atlassian-jira-software-x.y.z-standalone/jmxremote.access ${CATALINA_OPTS}"
For more details, see the Using Password Authentication section in Monitoring and Management Using JMX Technology.
Additionally, to access the JMX properties, you might need to configure SSL. For more details, see the SSL sections in Monitoring and Management Using JMX Technology.
JAVA_OPTSUsing JAVA_OPTS works to expose the JMX MBeans for remote access but causes errors to be thrown during Jira shutdown.
WindowsJAVA_OPTS=-Dcom.sun.management.jmxremote %JAVA_OPTS% JAVA_OPTS=-Dcom.sun.management.jmxremote.port=8099 %JAVA_OPTS% JAVA_OPTS=-Dcom.sun.management.jmxremote.authenticate=false %JAVA_OPTS%LinuxJAVA_OPTS="-Dcom.sun.management.jmxremote ${JAVA_OPTS}" JAVA_OPTS="-Dcom.sun.management.jmxremote.port=8099 ${JAVA_OPTS}" JAVA_OPTS="-Dcom.sun.management.jmxremote.authenticate=false ${JAVA_OPTS}" export JAVA_OPTS- リモート接続の保護方法を決定します。詳細については、リモート監視と管理を参照してください。
認証を無効にすることは可能ですが、本番環境システムではお勧めしません。 - JConsole を起動します。これは、JDK インストール ディレクトリの
binディレクトリにあります。 - リモート プロセス を選択します。
- ホスト名とポートを入力します。これは、Jira ポートではなく、前に指定したポートです。
- [Connect] を選択します。
- 接続後、すべてのメトリックをグループ化する
com.atlassian.jiraプロパティを展開します。
リモート監視の詳細については、JConsole の使用を参照してください。
Known security issues
We’re providing a robust fix for a potential security vulnerability that may be caused by an RCE (remote code execution) JMX attack. During this attack, a remote user with valid credentials for JMX monitoring can execute arbitrary code on Jira Data Center via Java Deserialization, even if this user’s account is readOnly (montiorRole).
To prevent fabricated data from getting into the system through requests, we're using a blocklist deserialization filter based on ObjectInputFilter from JVM.
If you use a custom JDK and miss appropriate classes in your classpath based on the Java version, your Jira node won’t be started.
atlassian.jira.log will contain the following error: BlocklistDeserializationFilter has not been set up. It means that your Java environment has some security issues.
To eliminate the error and boost the security of your Jira instance, make sure your JDK contains the following classes:
For JDK 8: the class
sun.misc.ObjectInputFiltermust be enabled in the classpath.For JDK 11 and later: the class
java.io.ObjectInputFiltermust be enabled in the classpath.
In-product diagnostics available through JMX
Since Jira 9.3, we've introduced a set of database connectivity metrics for in-product diagnostics available through JMX.
製品内診断 (IPD) では、実行中のインスタンスの動作についてより深いインサイトが得られます。
IPD uses additional metrics handling Jira’s interactions with its database. Using database connectivity metrics, you’ll efficiently identify what in your environment or infrastructure might cause the performance issues.
In Jira 9.5, in-product diagnostics has been complemented with more new metrics: HTTP connection metrics and mail queue metrics. In Jira 9.8, we've added a few new mail queue metrics allowing you to get a more detailed picture of mail queue contents and to collect more data for better performance monitoring.
The feature is disabled by default. Live metrics are available in the following formats:
- 新しい JMX MBeans として
- 新しい IPD ログ ファイル (
atlassian-jira-ipd-monitoring.log) 内の JMX 値のスナップショットの履歴として
このログ ファイルは、すべての既存のログ ファイルが格納されている {jira_home}\log フォルダにあります。このログ ファイルは、ATST プラグインで作成されるサポート ZIP ファイルにも含まれています。必要に応じて、Atlassian troubleshooting & support tools プラグインでサポート ZIP ファイルを生成し、ファイルをアトラシアン サポートに送信できます (アトラシアン社内にはファイル解釈用のツールがあります)。プラグインの詳細をご確認ください。
コミュニケーション
この機能では通信に次の方法が使用されます。
- JMX: JMX MBean は内部スケジュールに基づいて定期的に更新されます。
- The log file
atlassian-jira-ipd-monitoring.log: JMX values are snapshotted and recorded to the log file on a configurable schedule. By default, the JMX values are polled and written to the log file every 60 seconds. (This parameter is up to date since Jira 9.3 EAP 02.)
In-product diagnostics metrics
Expand the following sections to learn more about the metrics available for in-product diagnostics.
メトリックを使用するには、必ず JMX を有効にしてください。
Enabling In-product diagnostics monitoring
IPD monitoring is enabled by default. To manage it:
- 上部のナビゲーション バーから [管理者 ] > [システム] を選択します。
In the left-side panel, go to System Support and select Monitoring.
Use the In-product diagnostics monitoring toggle to enable or disable IPD monitoring.
The toggle is also available in version 9.4.3. Check Jira Software release notes for updates.
REST API
In Jira 9.5, we've introduced a new REST API endpoint for managing the IPD monitoring, specifically the In-product diagnostics monitoring toggle in the user interface: /rest/api/2/monitoring/ipd.
ログ形式
atlassian-jira-ipd-monitoring.log への書き込みは log4j を使用して行われます。その設定は log4j.properties で管理します。
#####################################################
# In-product diagnostics monitoring logging
#####################################################
log4j.appender.ipd=com.atlassian.jira.logging.JiraHomeAppender
log4j.appender.ipd.File=atlassian-jira-ipd-monitoring.log
log4j.appender.ipd.MaxFileSize=20480KB
log4j.appender.ipd.MaxBackupIndex=5
log4j.appender.ipd.layout=com.atlassian.logging.log4j.NewLineIndentingFilteringPatternLayout
log4j.appender.ipd.layout.ConversionPattern=%d %m%n
log4j.logger.ipd-monitoring = INFO, filelog
log4j.additivity.ipd-monitoring = false
log4j.logger.ipd-monitoring-data-logger = INFO, ipd
log4j.additivity.ipd-monitoring-data-logger = falseログの内容
既定では、各ログ エントリには簡潔データ セットが含まれています。拡張データ セットをログに記録するには、com.atlassian.jira.in.product.diagnostics.extended.logging 機能フラグを有効にします。
拡張データを有効にするには、次の手順に従います。
<JIRA_URL>/secure/admin/SiteDarkFeatures!default.jspaに移動します。ここで、<JIRA_URL>は Jira インスタンスのベース URL です。- [有効にする開発中機能] テキスト領域で
com.atlassian.jira.in.product.diagnostics.extended.logging.enabledと入力します。[追加] を選択します。ダーク機能を管理する方法をご確認ください。- 拡張データを無効にするには、[開発中機能 (サイト経由)] パネルで
com.atlassian.jira.in.product.diagnostics.extended.logging.enabledを探して [無効化] を選択します。
- 拡張データを無効にするには、[開発中機能 (サイト経由)] パネルで
次の各表で、簡潔ログ形式と拡張ログ形式の構造の違いを参照してください。
The metrics in JMX always go in the extended format.
簡潔データ
MBean タイプ | Properties | 属性 |
|---|---|---|
カウンター | timestamp ラベル 属性 | _count |
値 | _value | |
統計 | _99thPercentile _max _min _mean |
拡張データ
The metrics in JMX always go in the extended format.
MBean タイプ | Properties | 属性 |
|---|---|---|
カウンター | timestamp ラベル 属性 オブジェクト名 | _count _fifteenMinuteRate _fiveMinuteRate _meanRate _oneMinuteRate _rateUnit |
値 | _value _number | |
統計 | _50thPercentile _75thPercentile _95thPercentile _98thPercentile _99thPercentile _999thPercentile _count _min _max _mean _stdDev _durationUnit _fifteenMinuteRate _fiveMinuteRate _meanRate _oneMinuteRate _rateUnit |
プロパティを処理する
JMX ログ記録のポーリング間隔は 60 秒に設定されており、変更できません。
ログ ファイルのポーリング間隔は 60 秒に設定されており、システム プロパティ
jira.diagnostics.ipdlog.poll.secondsを使用して変更できます。既定では、JMX 値はポーリングされて
atlassian-jira-ipd-monitoring.logに書き込まれます。