Jira クラスタの監視

システム管理

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Jira Data Center がクラスタ化されている場合は、Jira ツールを使用してノードの状況を簡単に把握できます。 

Jira システム管理者向けの新しいクラスタ監視ページは、ノード ID、アドレス、アップタイム (前回の再起動以降)、負荷 (直前の 1 分のシステム負荷平均) およびメモリなどのリアルタイム データを収集します。このページで確認できる情報を使用して、クラスタに追加したばかりのノードが適切に構成されているかどうかを確認することもできます。 

この機能は Jira Data Center でのみ利用できます。

Skip directly to:


クラスタ ノードを確認する

クラスタ ノードの情報を確認するには、 [Jira 管理] > [システム] > [クラスタリング] に移動します。Jira のクラスタリングの詳細については「Jira クラスタの設定」を参照してください。

Clustering page, with a list of available nodes.

緑色のドットが表示されているノードは、自分が現在いるノードです。

ノードのステータスとヘルスを監視する

  • ACTIVE: the node is active and has heartbeat.
If an ACTIVE node gets flagged as OFFLINE Jira automatically shuts down to prevent any possible damage to cluster. This is not an official and recommended way to shut down the Jira cluster. You can disable this feature by using the jira.cluster.node.self.shutdown.if.offline.disabled=true property. 

  • NO HEARTBEAT
    : the node is temporarily down, has been killed, or is active but failing. This state might be caused by automatic deployment. It might also happen that the server is starting and the No heartbeat status is temporary. Normally, a node is moved to this state after 5 minutes of reporting no heartbeat. You can check if a node is really down and decide if you want to restart it, or remove it right away through REST API. After two days of reporting the No heartbeat state, the node is automatically moved offline.
If a node is killed abruptly, it might still show as active for about 5 minutes before changing the status to No heartbeat.
  • OFFLINE: the node has been manually fixed or stopped, and moved offline. The node should not be used to run cluster jobs. Once moved offline, the node is automatically removed from cluster after two days. 
If you don't want the nodes to be automatically moved offline and removed from cluster, you can disable the feature by using the jira.cluster.state.checker.job.disabled=true property. Additionally, if you want to use your own scripts, you can use the API described here.


アプリケーションのステータス

応答は、サーバー側で毎分更新されます。最新のデータを取得するには、ページを更新します。ノードが "オフライン"または "ハートビートなし" になっている場合、アプリケーション ステータス列にデータは含まれません。

メンテナンス: ノード上の Jira は再インデックス中で、現在ユーザーにサービスを提供することはできません。

エラー: 起動時に何らかの問題が発生し、Jira はこのノードで実行されていません。エラーの原因には、データベースへの到達不可、ロック ファイルの存在などの複数の理由が考えられます。詳細はログ ファイルをご覧ください。

実行中: ノードが稼動していて、Jira がそのノードで実行されています。

開始中: Jira が起動中のノードです。 

Cluster information in the audit log

To help you manage your cluster, you can also find the information on nodes leaving or joining the cluster  in your Audit log. The events are logged when you select the Full level of  the Global configuration and administration coverage area.  

  1. Go to Jira administration > System > Advanced audit log

  2. Search by the "Clustering" keyword for the logged cluster-related events. 

We log the following events:

  •  - NodeJoined - a new node has joined the cluster
  •  - NodeReJoined - an existing node was restarted and re-joined the cluster
  •  - NodeLeft - a node received the OFFLINE status
  •  - NodeRemoved - a node was removed from the cluster
  •  - NodeUpdated - all other cases when existing node was updated

ランタイムおよびシステム情報を確認する

さらに詳細にランタイムとシステム情報を確認するには、特定のノードで [アクション] をクリックします。 

System information in the Jira administration console.

View the custom fields that take longest to index

When you experience a sudden degradation in indexing performance, it might be because a custom field takes long to index. Normally, re-indexing time is not evenly distributed and there are several fields which take up most of the indexing time.

To find out which custom fields might take longest to index, you can look up the metrics in the logs (available in Jira 8.1 and later) or click Actions > Custom field indexing  for a specific node to view this data in the UI. The page displays the 20 most time-consuming custom fields (10 in the Total and 10 in the Snapshot time period).

The information which custom fields take up the majority of the indexing time allows you to take action to improve the performance. You might try changing the custom field’s configuration or, if possible, improve the custom field indexer itself. If it’s a custom field that’s not crucial to your business and it’s not a system custom field, you might try removing it in the test environment and see what indexing time gain you can achieve.

Custom field indexing page, with a list of most indexing-heavy custom fields.

Best practices for analyzing metrics

It’s a good idea to refer to these metrics every time you introduce a configuration change or you make changes to the system in your test environment. If you’re about to analyze the report, consider the following best practices:

To get reliable data, we recommend looking at the report after a full background re-index finished.

It’s a good idea to analyze reports where there are more calls to indexer than the number of issues on an instance as this is the best quality data.

Before introducing any changes, look at the values in the Max indexing time column in the Snapshot section. The custom fields that score high there (for example reach 5000 miliseconds - 5 secs - or more) are the ones that tend to be most expensive index-wise.


Analyze performance data

The table displays the custom fields that take longest to index or re-index (10 for Total and 10 for Snapshot). The data is displayed per node so it might be different depending on the node you select on the Clustering page. The data is refreshed in the background every 5 minutes. You can refer to the timestamp to see when the last indexing data update was sent by the system.

The data is sorted by indexing cost starting with the most time-consuming custom field in Total and in the Snapshot sections.

The table contains the following data:

Time period: sets the timeframe for the presentation of the data. Total is the time from the last full re-index or the start of Jira (if there was no full re-index since that time). Snapshot presents a 5-minute-timeframe (time from the last snapshot). 

Custom field name: is the name of the custom field as used in JQL.

Custom field type: is the type of the custom field:

  • System is a custom field used by the system. You cannot change its configuration or its indexing time.
  • 3rd party app is a custom field coming from a 3-rd party app you use. If it takes long to index, you might try changing its configuration or contact the vendor to improve the custom field indexer.
  • Custom is a custom field that has been created on your instance. If it takes long to index, you might try changing its configuration or improve the custom field indexer.

% of the indexing time: is the % of time spent indexing or re-indexing a given custom field. It shows how a custom field affects indexing time.

Max indexing time (ms): is the maximum time spent indexing or re-indexing a given custom field.

Average indexing time (ms): is the average time spent indexing or re-indexing a given custom field. It's the sum in milliseconds of all the calls to indexer divided by the number of these calls.

Calls to indexer: is how many times the custom field indexer was called in a time period to re-index a given custom field. 

Further analysis

To get more insights, you might also analyse the logs (available in Jira 8.1 and later):

Go to atlassian/application-data/jira/log/atlassian-jira.log

Use grep indexing-stats to find the data. It might look in the following way:

Regular log entry:

{field: epic, addIndex: {sum/allSum:38.5%, sum:1285825ms, avg:30.1ms, max:3822ms, count:42717}},


Re-indexing log entry:

ここで:

order - fields that are indexed/re-indexed are displayed according to how long it took to index/re-index them

sum/allSum - is the % of time spent indexing a custom field vs all custom fields

addIndex sum / avg / max / count - is the the total time spent indexing a custom field / the average time spent indexing a custom field / maximum time spent indexing a custom field / calls to indexer

totalIndexTime - is the total indexing/re-indexing time

addIndexSum/totalIndexTime - is the cost (in time) of indexing/reindexing this field vs the total indexing/re-indexing time

numberOfIndexingThreads - number of indexing threads

For further explanation of the log stats, see Indexing stats.


最終更新日 2020 年 6 月 23 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.