グローバル Jira 設定の構成
アセットのグローバル Jira 設定には、オブジェクト スキーム、オブジェクト タイプ、あるいはオブジェクトではなく、アセット アプリ自体の設定が含まれます。ここでは、ログ設定、日時、アセットのインデックス再作成などを設定できます。利用できる設定の詳細については、次をご覧ください。
このページの内容
グローバル Jira 設定にアクセス
アセットのグローバル Jira 設定にアクセスするには、次の手順に従います。
- [管理] > [アプリを管理] の順に移動します。
- [アセット] セクションでページを探します。
一般設定
一般設定を開くには [アセット設定] を選択します。
| 設定 | 説明 |
|---|---|
| ユーザー相互作用 | |
属性の既定ラベル | すべてのオブジェクト タイプの既定のラベルとして使用されるテキスト タイプの属性。これは、特定のオブジェクト タイプ設定でも変更できます。 この設定はこの設定の変更後に作成されるオブジェクト タイプにのみ影響することにご注意ください。 |
属性の既定の説明 | 既定のラベル属性の説明。これは、特定のオブジェクト タイプ設定でも変更できます。 |
[オブジェクトを開く] ダイアログ イベント | ユーザーがオブジェクト リンクを選択、またはユーザーがオブジェクト リンクにカーソルを移動した際に、オブジェクト ダイアログを開くかどうかを決定します。 これは、Jira 課題を表示している際にアセット オブジェクト フィールドを表示する場合にも適用されます。 |
カスタム フィールドで取得されるオブジェクトの既定数 | これは、アセットがリクエストごとにカスタム フィールドで取得するオブジェクトの数を示します。既定値は 25 に設定されています。 ユーザーがカスタム フィールドのオブジェクトの検索を開始すると、検索条件に一致するオブジェクトがサーバーから非同期でフェッチされます。したがって、既定の制限である 25 で十分なはずであり、この値が推奨されます。 この数を増やすとリクエストごとにより多くのオブジェクトをフェッチする必要があるため、パフォーマンスに影響します。 |
| 一般設定 | |
アセット監査ログが有効 | このチェックボックスをオンにすると、すべてのアセット オブジェクト イベントが監査ログファイルに記録されます。 |
属性値を監査ログに含める | このチェックボックスは、上記の [アセット監査ログが有効] がオンになっている場合にのみ有効になります。 オンにすると、監査ログにあるオブジェクトのすべての属性値が含まれます。 |
アセット インデックスをファイルから復元 | これによって、起動時にアセット インデックスがファイルから確実に復元されるため、起動時間の短縮に繋がります。 アセットは起動時にファイルの整合性チェックをデータベースに対して実行して、一致しない場合はインデックスを再作成します。 これをオフにすると起動時間が遅くなる場合がありますが、壊れたインデックス ファイルがデータの不整合を引き起こす可能性があるリスクを排除できます。 初期設定ではオンになっています。ファイルは {$JIRA_HOME/caches/assets_indexes} にあります。 たとえば、MacOS ではファイルのパスは {/var/atlassian/application-data/jira/caches/assets_indexes} になります。 |
キャッシュをシャットダウン時に保存 | これは、アセットのインデックスをアセットのシャットダウン時にファイルに保持する必要があることを示します (例: プラグインのアップグレード、Jira の再起動、アセットの無効化など)。 [アセット インデックスをファイルから復元] がオンになっている場合は、このプロパティもオンにすることをお勧めします。 |
アセット キャッシュを制限 | これによって、アセットに保存できるオブジェクトの量を制限できます。キャッシュに存在するオブジェクトの数が限られるため、メモリ フットプリントが制限されます。 既定では、アセットを使用する際にキャッシュ内のオブジェクトは制限されず、この方法が推奨されます。制限すると、パフォーマンスに悪影響が及ぼされます。 |
キャッシュに許されるオブジェクトの数 | [アセット キャッシュを制限] がオンになっている場合にのみ有効になります。 このプロパティは、キャッシュに保存されるアセット オブジェクトの数を示します。 推奨される方法は、キャッシュのオブジェクトを制限しないことです。 |
ファイル アップロードの最大サイズ | ファイル、画像、添付ファイルをアセットにアップロードする際の最大サイズ (バイト単位)。 |
アセットの並列処理 | アセットが並列タスク (データのインポート、インデックスの再作成など) を実行するために生成するスレッドの数です。 この数値が低い値に設定されている場合はアセットが Jira にかける負担が軽減します。ただし、パフォーマンス速度は低下します。 |
インポート中にデータ ソースを一時ファイル経由で処理 | インポート中のメモリ フットプリントを減らす目的でインポート モジュールを使用する際に、データをディスク上で一時的に保存します。 |
| カスタム ロケールをアセットに使用 | アセットに保存されているデータを Jira の既定のロケール以外のロケールで並べ替える必要があることを示すために使用されます。 オンにするとオブジェクトのフェッチが遅くなる可能性があるため、パフォーマンスに問題が起こらないように初期設定では無効になっています。 |
| アセットのロケール | [カスタム ロケールをアセットに使用] がオンになっている場合にのみ有効になります。 この設定で、アセットがデータを並べ替える際に使用する言語が決まります。 |
インポートする一時ファイルのバッファ サイズ | 一時ファイルを介してデータ ソースを処理する際に、メモリに保存される項目の最大数 |
インポートする一時ファイルの代替ディレクトリ | 有効な場合、インポート中に一時ファイルをディスクに保存するための代替ディレクトリ。この設定の変更を有効化するには、インスタンスを再起動してください。 |
並行インポートの最大数 | クラスター全体で実行できる並行インポートの数。並行インポートの設定方法についてはこちらをご確認ください。 |
Jira Service Management | |
Jira Service Management ポータルの検索テキスト (単一) | Jira Service Desk ポータル上にあるアセット フィールドのプレースホルダー (単一フィールド) |
Jira Service Management ポータルの検索テキスト (複数) | Jira Service Desk ポータル上にあるアセット フィールドのプレースホルダー (複数フィールド) |
| クラスター化された Data Center | |
| スケジュールとインポートの専用ノード | この設定は、マルチノードの Data Center を構成している場合にのみ使用できます。 このノードはアセットのスケジュール タスク (Importers や Automation など) を実行するための専用ノードになります。 ノードがスケジュールの専用ノードとして選択されてスケジュールされたタスクの実行時に利用できなくなった場合、そのタスクは実行されないことにご注意ください。 |
| 進行中アクションのステータス更新頻度 | |
| オブジェクト インデックスのレプリケーション | |
| オブジェクト読み込みの再試行回数 | データベースからオブジェクトを読み込む試行回数。 |
| オブジェクト読み込みの再試行間隔 (ミリ秒) | オブジェクトの読み込みを試行する間隔。 |
| 送信者キューのサイズ | レプリケーション メッセージの作業キューのサイズ。この設定の変更を有効化するには、インスタンスを再起動する必要があります。 |
| 送信者スレッドの数 | レプリケーション メッセージをバッチ処理および送信するためのスレッドの数。この設定の変更を有効化するには、インスタンスを再起動する必要があります。 |
| 最大バッチ サイズ | まとめて 1 つのメッセージにバッチ処理される変更の最大数。 |
| バッチ処理遅延 (ミリ秒) | 変更の完了後、作業キューからバッチ処理して送信するまで待機するための遅延。 |
| 受信者キューのサイズ | レプリケーション メッセージを受信するためのキューのサイズ。この設定の変更を有効化するには、インスタンスを再起動する必要があります。 |
| 受信者スレッドの数 | 受信者のキューから読み取るスレッドの数。この設定の変更を有効化するには、インスタンスを再起動する必要があります。 |
| 再試行キュー スレッドの数 | 再試行キューをポーリングするスレッドの数。この設定の変更を有効化するには、インスタンスを再起動する必要があります。 |
| 再試行回数 | 最初に通知が届いたときにデータベースからオブジェクトを読み取る準備ができていない場合に、再試行キューから再試行する回数。 |
| 再試行キューの間隔 (ミリ秒) | 再試行キューからメッセージを再試行するまで待機する間隔。 |
| デッドレター キューの記録間隔 (ミリ秒) | デッドレター キューの内容を確認してから、キューに問題がある場合にエラーを記録するまでの間隔。 |
セキュリティ | |
| Jira 許可リストを使用してインポート設定 URL をブロックする | Jira 許可リストで設定されていない外部ソースからのアセットインポートをブロックする場合に有効にします。Jira 許可リストの構成方法 Jira 許可リストを使用してブロックできるのは、オブジェクト スキーマ インポート、 LDAP インポート、JSON インポート、CSV インポート、Bitbucket環境インポート、Device42インポート、Jamf インポート、ServiceNow インポート、Snow インポートのみです。 |
日付の設定
アセットのすべての日付は Jira 管理者設定を使用しています。次の URL で変更できます。
https://host:port/secure/admin/AdvancedApplicationProperties.jspaログ ファイル
ログは次のディレクトリにあります。
<Jira-shared-home>/log添付ファイル
アセットの添付ファイルは、次のディレクトリの avatars、files、icons、objects という名前のサブフォルダーにそれぞれ保存されます。
<Jira_home>/data/attachments/assetsインデックス作成
インデックス設定を開くには [アセットのインデックス化] を選択します。
インデックス作成では次のオプションから選択できます。
- 再インデックスを消去
すべてのノードですべてのオブジェクトがインデックスから削除されて、その後再びインデックス化されます。これは、新しいインデックスが必要な場合に推奨されます。インデックス化の進行中は、その処理を取り消したり、オブジェクトを検索またはフィルタリングしたりすることはできません。 - 再インデックス化
この処理ではすべてのオブジェクトをインデックスに残した上で、アセットが再度インデックスを作成します。処理中もオブジェクトを検索できます。 - アセット インデックスをファイルに永続化
ディスク上のインデックスを手動で保持 (コピー) できます。多数のオブジェクトを含む大規模なアセット環境があり、アプリの再インストールを計画している場合に役立ちます。インデックスをディスク上に置いておけば、アセットでゼロから作り直す必要はありません。
Groovy スクリプト
アセットの自動化や事後操作で使用する Groovy スクリプトを表示して実行できます。
レポートの同期
レポートの同期設定を開くには [アセット レポート] を選択します。ここでは、レポートのデータを同期する cron スケジュールを設定できます。
Analytics
アナリティクスの設定を開くには [Mindville アナリティクス] を選択します。
Data Center に関するその他の設定
clustermessage テーブルのデータ保持期間を設定する
データ保持期間を設定すると、clustermessage テーブルの過負荷に起因するパフォーマンスの問題を回避できます。大量のデータセットを短時間でアセットにインポートすると、clustermessage テーブルに情報が入力されてパフォーマンスの問題が発生する可能性があります。
データ保持期間を設定するには、次の手順に従います。
- [管理] > [システム] の順に移動します。
- [詳細] セクションまで下にスクロールして [サービス] を選択します。
- [サービスを追加] の [クラス] で [Build-in services (組み込みサービス)] を選択します。
- [クラスター メッセージ フラッシュ サービス] を選択します。
- 以下の情報を入力します：
- 名前 - クラスター メッセージ フラッシュ サービス
- クラス - com.atlassian.jira.service.services.cluster.ClusterMessageCleaningService
- スケジュール - 0 0 4/12 * * ?
- [サービスを追加] を選択します。
- [保存期間] に「2880m」と入力します。
- 更新を選択します。
[プロセスの結果] タブの更新頻度を設定する
この設定は、マルチノードの Data Center を構成している場合にのみ使用できます。
インポートの進捗は、[アセット設定] で設定できる実行作業単位の数に応じて、データベース全体で共有されます。作業単位は、進行中の操作におけるデータベース更新頻度を定量化するものです。ユーザー エクスペリエンスのパフォーマンスに問題があることに気づいた場合にのみ、この値を変更することをお勧めします。
たとえば、CSV インポートの場合、作業単位は CSV ファイルの 1 つの行 (アセット オブジェクト) を表します。間隔を 100 作業単位とした場合、新しいオブジェクトが 100 個インポートされるたびに、インポート操作のステータスがデータベースで更新されます。
既定の作業単位数は 100 です。この値を変更するには、次の手順に従います。
- [管理] > [アプリを管理] の順に移動します。
- 左側のパネルで、[アセット設定] を選択します。
- [Edit settings] を選択します。
- [データ センター] セクションで、[進行中アクションのステータス更新頻度] の値を編集します。
- [保存] を選択します。
アセット インデックスの検証プロパティ
アセットのインデックス作成プロセスの制御には次のプロパティを使用します。
既定値 | 実行時のリロード | 説明 | これを変更する理由 |
|---|---|---|---|
送信者キューのサイズ: | |||
10000 | いいえ |
| この値を十分に大きく設定することで、保存するオブジェクトがブロックされないようにし、スレッドによってキューがドレインされ続けるようにします。キューが最大容量に近づいている場合は、サイズを大きくすることで、キューにデータを送信するシステム部分の負担を軽減できます。 キューのサイズを増やすと、現在利用できる容量によっては、追加の JVM メモリが必要になる場合があります。 |
送信者スレッド: | |||
5 | いいえ |
このプロパティは送信者キューのサイズ ( | インスタンスが大規模なインポートや一括変更を処理している場合、この値を増やすことで、メッセージの処理速度が向上します。これにより、作業キューのサイズをより迅速に減らすことができます。 ただし、値を高く設定しすぎると、バッチが小さくなり、アップデートを遅らせて 1 つのメッセージにまとめる効果が無効になります。詳細については、最大バッチ サイズ プロパティとバッチ処理の遅延プロパティを確認してください。 |
最大バッチ サイズ: | |||
1000 | はい |
バッチ サイズはログと Java Management Extensions (JMX) で確認できます。たとえば、
さらに、
| すべてのメッセージが常に現在の最大バッチ サイズに達している場合は、レプリケーションがなかなか追いついていないということです。ただし、Oracle などの一部のデータベースにはアップデート制限があるため、この値を 1000 より大きく設定することはお勧めしません。 |
バッチ処理の遅延: | |||
400ms | はい | アイテムが作業キューに入ってから、キューが処理されるまでの遅延を指定します。この遅延によりキューにデータが追加され、作成、アップデート、削除の一括処理用にバッチが最適化されます。 遅延を長くすると、バッチが大きくなる可能性がありますが、クラスター内の他のノードにアップデートが表示されるまでにかかる時間も長くなります。 | バッチが小さいことに気付いた場合は、遅延を長くして、より大きなバッチが生成されるまでの時間を増やすことができます。 バッチが |
オブジェクト読み込みの再試行回数: | |||
200 | はい | データベース トランザクションが完了する前にメッセージが処理された場合、作成中にデータベースでオブジェクトをチェックする回数を指定します。これは、オブジェクトをレンダリングするときのオブジェクト インデックス内の追加とアップデートの両方に適用されます。 | メッセージがデータベースに存在する前にメッセージを受信し、メッセージがデッドレター キュー (DLQ) に入ってしまう場合は、 |
オブジェクト読み込みの再試行間隔: | |||
100ms | はい | オブジェクト インデックスの追加とアップデートのためにオブジェクトを読み込む試行間の遅延を決定します。 | このプロパティを c データベースのクエリの負荷が増えるため、この値を 100 ミリ秒未満に減らすことはお勧めしません。 |
受信者キューのサイズ: | |||
10000 | いいえ | 受信ノードで処理するメッセージを追加するための作業キューの最大サイズを指定します。変更は 1 つの | キューがいっぱいになる時間が長すぎると、Atlassian のキャッシュからの TCP 接続がブロックされ、インデックスのレプリケーションなどの他の操作が遅くなる可能性があります。一方、キューに制限がないと、メモリを過剰に消費する可能性があります。 |
受信者スレッド: | |||
5 | いいえ |
| 十分なコンピューティング リソースがある場合は、この値を増やして、受信メッセージを含むキューの処理を強化できます。これにより Jira TCP スレッドのブロックがより素早く解除されます。 |
再試行キュー スレッドの数: | |||
2 | いいえ |
| インスタンスが処理する障害の数が多い場合は、この値を増やすことを検討してください。障害は、データベースがレプリケーション プロセスほど迅速にアップデートされないために、再試行キューのドレインに時間がかかることで発生する場合があります。 |
再試行回数: | |||
10 | はい | 再試行キューからの再試行回数を指定します。これにより、デッドレター キュー (DLQ) に移動する前に、失敗したメッセージが再試行キューに戻される回数が決まります。 | データベースの遅延が予想される場合など、再試行回数が増えることでメッセージ処理が成功する可能性がある場合は、この値を増やしてください。 |
再試行キューの間隔: | |||
60000 ミリ秒 (1 分) | はい | 最後の再試行からメッセージを再試行するまでの間隔を指定します。遅延により、システムがデータベースのアップデートに追いつくのに十分な時間が確保されます。 再試行のたびに、オブジェクト インデックスは | このプロパティを |
デッドレター キューの記録間隔: | |||
300000 ミリ秒 (5 分) | はい | DLQ でアイテムをチェックして警告を記録する間隔を指定します。 | DLQ の変化をより早く確認する必要がある場合は、間隔を短くします。 |