Jira クラスタの監視
Jira Data Center がクラスタ化されている場合は、Jira ツールを使用してノードの状況を簡単に把握できます。
Jira システム管理者が利用できる新しいクラスター監視ページでは、ノードのリアルタイムデータが収集されます。このページで確認できる情報を使用して、クラスターに追加したばかりのノードが適切に構成されているかどうかを確認することもできます。このページには、次のようなデータが表示されます。
- ノード ID:
<Jira home>/cluster.properties jira.node.idに設定された名前 - クラスター アドレス: ノードとの通信に使用されるネットワーク アドレス
- 負荷: 直近 1 分間のシステム負荷平均にノード内のプロセッサ数を掛けたもの
- メモリ: 使用済みヒープのパーセンテージ
- 前回の再起動以降の稼働時間
- ノードとアプリのステータス
次のページに直接スキップ
クラスタ ノードを確認する
クラスタ ノードの情報を確認するには、 [Jira 管理] > [システム] > [クラスタリング] に移動します。Jira のクラスタリングの詳細については「Jira クラスタの設定」を参照してください。
![使用可能なノードの一覧が記載された [クラスタリング] ページ。](https://confluence.atlassian.com/adminjiraserver0915/files/1402410927/1402410936/1/1631559598609/Node+statuses+1+%281%29.png "使用可能なノードの一覧が記載された [クラスタリング] ページ。")
緑色のドットが表示されているノードは、自分が現在いるノードです。
ノードのステータスとヘルスを監視する
- アクティブ: ノードは現在アクティブで、ハートビートがあります。
jira.cluster.node.self.shutdown.if.offline.disabled=true プロパティを使用して無効にすることができます。
- ハートビートなし: ノードは一時的にダウンしているか、終了されたか、アクティブだが失敗しています。この状態は自動デプロイメントによって発生する場合があります。また、サーバーが起動中で一時的に "ハートビートなし" ステータスになっている場合もあります。通常、ノードは "ハートビートなし" が報告されてから 5 分後にこの状態に移行します。ノードが実際にダウンしているかを確認して、再起動するか、REST API 経由で直ちに削除するかを判断できます。
ノードが突然終了された場合、ステータスが "ハートビートなし" に変更されるまでに約 5 分間アクティブとして表示される可能性があります。
既定では、"ハートビートなし" 状態が報告されたあと 2 日経つと、そのノードは自動的にオフラインに移行します。ただし、jira.not.alive.active.nodes.retention.period.in.hours システム プロパティを変更することで、既定値を変更できます。または、Jira の起動時に JVM フラグを追加することができます。たとえば、3 時間後にノードをオフラインにしたい場合は、次のフラグを入力します。
Djira.not.alive.active.nodes.retention.period.in.hours=3jira.not.alive.active.nodes.retention.period.in.hours の値は、Jira インスタンスの起動時間よりも大きくする必要があります。これを行わない場合、クラスタ内の他のノードにより、ノードが オフライン 状態に移行される可能性があります。
- オフライン: ノードが手動で修正または停止され、オフラインに移行されました。このノードを使用してクラスタ ジョブを実行することはできません。オフラインに移動されたノードは 2 日後に自動的にクラスタから削除されます。
jira.cluster.state.checker.job.disabled=true プロパティを使用して、この機能を無効にすることができます。また、独自のスクリプトを使用したい場合は、こちらで説明する API を使用できます。
アプリケーションのステータス
応答は、サーバー側で毎分更新されます。最新のデータを取得するには、ページを更新します。ノードが "オフライン"または "ハートビートなし" になっている場合、アプリケーション ステータス列にデータは含まれません。
メンテナンス: ノード上の Jira は再インデックス中で、現在ユーザーにサービスを提供することはできません。
エラー: 起動時に何らかの問題が発生し、Jira はこのノードで実行されていません。エラーの原因には、データベースへの到達不可、ロック ファイルの存在などの複数の理由が考えられます。詳細はログ ファイルをご覧ください。
実行中: ノードが稼動していて、Jira がそのノードで実行されています。
開始中: Jira が起動中のノードです。
監査ログのクラスタ情報
クラスタの管理に役立てるため、監査ログで、クラスタに参加または離脱するノードの情報を探すこともできます。
これらのイベントを収集するには、グローバル設定および管理カバレッジ エリアを [フル] に設定します。
[Jira 管理] > [システム] > [監査ログ] に移動します。
- [高度な監査ログ] 管理ページで、
> [設定] をクリックします。 - [カバレッジ] で、[グローバル設定および管理] カバレッジ エリアを [フル] に設定し、[保存] をクリックします。
ログに記録されたクラスタ関連イベントを確認するには、[Jira 管理] > [システム] > [監査ログ] に移動し、"クラスタリング" というキーワードを検索します。
次のイベントを記録します。
- - NodeJoined - 新しいノードがクラスタにジョインした
- - NodeReJoined - 既存のノードがクラスタが再起動され、クラスタに再度ジョインした
- - NodeLeft - "オフライン" ステータスを受信したノード
- - NodeRemoved - ノードがクラスタから削除されました
- - NodeUpdated - 既存のノードが更新されたときのその他すべての場合
ランタイムおよびシステム情報を確認する
さらに詳細にランタイムとシステム情報を確認するには、特定のノードで [アクション] をクリックします。
インデックス作成に最も時間がかかるカスタム フィールドを表示する
インデックス作成のパフォーマンスが突然低下した場合、カスタム フィールドのインデックス作成に時間がかかっている可能性があります。通常、再インデックスにかかる時間は均等に分散されず、インデックス作成時間のほとんどを占めるフィールドがいくつか存在します。
インデックス作成に最も時間がかかっている可能性があるカスタム フィールドを判別するには、ログでメトリックを確認する (Jira 8.10 以上で利用可能) か、特定のノードで [アクション] > [カスタム フィールドのインデックス化] の順にクリックして、UI でこのデータを表示します。ページには、最も時間のかかるカスタム フィールドの上位 20 件が表示されます ("合計" 10 件、"スナップショット" 期間 10 件)。
インデックス作成時間の大部分をカスタム フィールドが占めている事実を踏まえて、パフォーマンスの改善策を講じることができます。カスタム フィールドの設定の変更を試したり、カスタム フィールド インデクサー自体を向上させたりすることができます。業務に重要でないカスタム フィールドがあり、それがシステム カスタム フィールドでない場合は、それをテスト環境から削除してインデックス作成時間の削減量を確認できます。
メトリック分析のベスト プラクティス
構成に変更を加えたり、テスト環境のシステムに変更を加えたりするたびに、これらの指標を参照することをおすすめします。レポートを分析する予定がある場合は、次のベスト プラクティスを検討してください。
信頼できるデータを取得するには、バックグラウンドでの完全な再インデックスが完了した後にレポートを確認することをおすすめします。
もっとも質の高いデータを使用するため、インスタンスの課題数よりもインデクサーへの呼び出しが多いレポートを分析することをお勧めします。
変更を適用する前には必ず、"スナップショット" セクションの [最大インデックス化時間] 列の値を確認してください。ここでの数値が高いカスタム フィールド (たとえば、5000 ミリ秒 - 5 秒 - 以上に達するもの) が、最もインデックス作成に時間がかかる傾向があるものとなります。
パフォーマンス データを分析する
表には、インデックス作成または再インデックス作成にもっとも時間がかかるカスタム フィールド (合計 10 個、およびスナップショット 10 個) が表示されます。データはノードごとに表示されます。そのため、クラスタリング ページで選択したノードに応じて異なる可能性があります。データは 5 分毎にバックグラウンドで更新されます。タイムスタンプを確認することで、システムによって最後のインデックス作成データ更新が送信された時刻を確認できます。
データは、"合計" および "スナップショット" セクションで最も時間のかかるカスタム フィールドを先頭に、インデックス作成コストを基準に並べられます。
表には、次のデータが含まれています。
期間: データ表示の時間枠を設定します。"合計" は、最後のインデックスの完全な再作成または Jira の起動時 (起動してからインデックスの完全な再作成が行われていない場合) からの時間です。"スナップショット" は 5 分間の時間枠 (最後のスナップショットからの時間) を表します。
カスタム フィールド名: JQL で使用されるカスタム フィールドの名前です。
カスタム フィールド タイプ: カスタム フィールドのタイプです。
- "システム" はシステムで使用されるカスタム フィールドです。この設定やインデックス作成時間を変更することはできません。
- サードパーティ アプリは、ご利用のサードパーティ アプリで作成されたカスタム フィールドです。インデックス作成に時間がかかる場合、この構成の変更を試すか、カスタム フィールドのインデクサーの改善についてベンダーにお問い合わせください。
- "カスタム" は、ご利用のインスタンスで作成されたカスタム フィールドです。インデックス作成に時間がかかる場合は、この設定の変更を試すか、カスタム フィールドのインデクサーを改善してください。
インデックス化時間のパーセンテージ: 対象のカスタム フィールドのインデックス作成または再作成にかかった時間のパーセンテージです。カスタム フィールドがインデックス作成時間に与えた影響を示します。
最大インデックス化時間 (ミリ秒): 対象のカスタム フィールドのインデックス作成または再作成にかかった最大時間です。
平均インデックス化時間 (ミリ秒): 対象のカスタム フィールドのインデックス作成または再作成にかかった平均時間です。インデクサーへのすべての呼び出し (ミリ秒) の合計を、呼び出し回数で割ったものです。
インデクサーへのコール: ある期間に、対象のカスタム フィールドのインデックスを再作成するために、カスタム フィールド インデクサーが呼び出された回数です。
詳細分析
より多くのインサイトを得るため、ログを分析することもできます (Jira 8.1 以降で利用可能)。
atlassian/application-data/jira/log/atlassian-jira.log に移動します。
grep indexing-stats を使用してデータを探します。これは、次のように表示される場合があります。
通常のログ エントリは、次のようなものです。
{field: epic, addIndex: {sum/allSum:38.5%, sum:1285825ms, avg:30.1ms, max:3822ms, count:42717}},インデックス再作成のログ エントリは、次のようなものです。
ここで:
order - インデックスの作成/再作成が行われるフィールドが、それらのインデックス作成/再作成にかかる時間に応じて表示されます。
sum/allSum - すべてのカスタム フィールドに対する、1 つのカスタム フィールドのインデックス作成にかかる時間の割合です。
addIndex sum / avg / max / count - カスタム フィールドのインデックス作成に費やした時間の合計/カスタム フィールドのインデックス作成に費やした時間の平均/カスタム フィールドのインデックス作成に費やした最大時間/インデクサーへの呼び出し
totalIndexTime - インデックス作成/再作成にかかる合計時間です。
addIndexSum/totalIndexTime - このフィールドのインデックスを作成/再作成するコスト (時間) と、インデックス作成/再作成の合計時間です。
numberOfIndexingThreads - インデックス作成スレッドの数です。
ログの統計の詳細については、「インデックス作成の統計」を参照してください。