Jira 9.1 への準備

This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira 9.1

変更の概要

In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your apps. Once they're ready, we'll indicate when a change has been implemented, and in which milestone.

Sprint caching improvements

ステータス : 進行中

We're introducing two new caches to improve Jira’s performance during the concurrent usage of Agile sprints. This change will also help to mitigate the sprints scale and growth factor in performance matters.

The following caches will be added:

• a fine-grained cache that holds a single entry for each sprint and lets you instantly retrieve sprints by IDs. 
• a cache that holds Sprints per board, which are accessible by rapid view ID.

The new configuration will ensure a faster cache population, allowing Jira to perform such actions as opening an Agile board much quicker. This will enable teams to work simultaneously without being blocked by slow board loading time or facing timeout requests.

You can find more information about the problem we’re fixing in this ticket: JSWSERVER-20618 - Getting issue details... STATUS

Excluded events for advanced audit log

ステータス: 実装済み

We've added new functionality that allows excluding some audit events from being recorded in the log. The new feature is available for admins on the Audit log settings page under the System support section (in the left-side panel). 

1. Audit log: Here you can view all events recorded in the log.
2. Settings: A tab where all the audit log settings are configured.

You can view and add excluded events by scrolling down to the bottom of the page:

1. Excluded events: this is where admins can block events from being recorded.

Apps performance monitoring via JMX

Status: IMPLEMENTED

We've instrumented metrics available via JMX that allow measuring and monitoring the performance of your apps that can be paired with the APM tool of your choice such as Grafana, NewRelic, or App Dynamics.

With this update in place, you can quickly check if an app is contributing to poor system performance as well as identify potential problems. Some of the things you can now monitor include how long it's taking to render web resources, perform operations, do garbage collection, and more.

ご確認いただきたい内容

• We’ve provided example Grafana dashboards that are ready to use or to serve as inspiration for your existing dashboards. The source code for Grafana dashboards is available on Github.
• You need a Prometheus-compatible server to use real data in Grafana. The setup instructions are available in the Getting started guide. 
• There are no changes to the installation or upgrade process as part of this feature.
• There are no database schema changes added as part of this change. 
• This feature introduces a new UpgradeTask_Build901000, which enables JMX monitoring by default. This is required for app monitoring to function. 

How do you turn off the feature?

This feature is enabled by default. You can disable it in several ways.

1. Disable app monitoring cluster-wide from the Administration menu:
   1. Open the monitoring page by going to Administration > System > Monitoring
      or navigate to /secure/admin/JmxMonitoringAction.jspa.

   2. Turn off the App Monitoring toggle.
      
      

      If you want to turn the feature on, make sure that the JMX Monitoring toggle is enabled as well. Otherwise, the app monitoring won’t work.

2. Disable app monitoring cluster-wide via API. See Changes to the API section for details.
3. Disable app monitoring per-node via the com.atlassian.profiling.ita.metrics.deny system property. 

Changes to the API

• Added POST @ /rest/api/2/monitoring/app that accepts content type application/json {isEnabled:"true/false"} to enable or disable the feature cluster-wide.
• Introduced a new com.atlassian.diagnostics.internal.platform.plugin.ClassNameToPluginKeyStore class that debug logging can be enabled for. The class has two debug lines that could explain why it’s not possible to attribute a plugin for using the database on the db.core.executionTime metric:
  • Came across a null bundle while rebuilding the map of classnames to plugin keys after the plugin event: {}
  • The plugin event {} triggered rebuilding the map of classnames to plugin keys, but wasn't able to get the wiring for bundle: {}

監査ログのメール チャンネル

ステータス: 実装済み

App: JIRA SERVICE MANAGEMENT

新しい監査ログでメール チャンネルを常に把握しましょう。メール チャンネルとの接続がアクティブかどうかを簡単にチェックして、すべての受信メールが正しく処理されていることを確認できるようになりました。監査ログは、次の 2 つの異なるタブで構成されています。

• 接続済みのメール アカウントから受信したすべてのメッセージを示す処理ログ。これによって、特定のメールを検索して絞り込めます。
• 接続ログ。Jira Service Management は、60 秒ごとにメール チャンネルに接続して新しいメッセージをプルします。接続ログには、試行ごとの結果の履歴が表示されます。

Insight のアクセシビリティとアップリフト

ステータス: 実装済み

App: JIRA SERVICE MANAGEMENT

Insight のアクセシビリティと改善を引き続き行っています。このリリースでは次のような問題を修正しました。

• カラー コントラストの問題
• オブジェクト スキーマ ビューの問題
• さまざまなビュー全体におけるグラフ コンポーネントの問題

PSMQ 情報のログ記録を改善

Status: IMPLEMENTED

App: JIRA SERVICE MANAGEMENT

サポート チームが PSMQ 関連の問題をトラブルシューティングできるように、情報のログ処理を改善しました。次は改善点の一部です。

• メッセージの処理時間と、キュー内のメッセージの合計待機時間に関して不足している情報をログに追加しました。
• デバッグ トレースが有効になっている場合は、PSMQ キューのメッセージ カウントがログに出力されます (毎分)。
• 現在のキュー設定は設定ページから利用できます。

ユーザー側で知っておくべきこと

• トレース レベルでは、デバッグ レベルよりも多くの情報が表示されます。
• ログに表示される PSMQ キューのメッセージ カウント情報は、キュー テーブルの MESSAGE_COUNT 列からフェッチされます。これは、MESSAGES テーブルの実際のメッセージとは異なる可能性があります。この変更は、データベース過負荷を避けるために加えました。