Jira/Service Management Server/Data Center で低速な通知/通知のスタックの問題のトラブルシューティングを行う

お困りですか?

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

コミュニティに質問

プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く


On this page:

問題

Jira 8.x で先日導入された Jira のバッチ通知や、Service Desk に独自の通知システムが組み込まれていることにより、一部の通知が非常に遅れて届いたり一切送信されなかったりする場合の調査がさらに困難なものになっています。

このような問題を効率的にトラブルシューティングするには、Jira と Service Desk の両方に存在するあらゆる種類の通知やそれらの仕組み、そしてそれらの通知の生成や送信に関与するすべてのサービスを最初に理解しておくことが重要です。このナレッジによって調査を適切な方向に導き、可能性の高い根本原因に焦点を当てることができます。

Jira と Service Desk に存在する通知の種類とそれらの仕組み

Jira と Service Desk の両方を同時に実行されていると、Jira の設定内容や対象のプロジェクトによって 3 種類の通知が登場する可能性があります。この 3 種類の通知は次のとおりです。

  • Jira の非バッチ通知
  • Jira のバッチ通知
  • Service Desk のカスタマー通知

Jira 通知

  • 送信先
    • Jira Core と Jira Software のチケットで作業している任意のユーザー
    • Service Desk チケットでエージェントとして振る舞っているユーザー
  • ページ [プロジェクト設定] > [通知]通知スキーム経由で設定
  • 次のいずれか
    • ⚙ > [システム] > [メール通知のバッチ] が有効化されている場合はバッチ
    • ⚙ > [システム] > [メール通知のバッチ] が無効化されている場合は非バッチ

Service Desk のカスタマー通知

  • Service Desk チケットでカスタマーとして振る舞うユーザーに送信
  • ページ [プロジェクト設定] > [カスタマー通知]カスタマー通知設定経由で設定
  • Jira のバッチ通知で利用されているものとは異なる独自のバッチ メカニズムを持つ。これらは 1 分単位でバッチ化される。この値はハードコードされていて設定不可

トリガーされた通知の種類にかかわらず、各通知は同じメール キューにたどり着きます。

  • このキューはページ ⚙ > [システム] > [メール キュー] で監視可能
  • このキューはデフォルトでは 1 分ごとに Mail Queue Service によってフラッシュされる
  • Mail Queue Service は、⚙ > [システム] > [送信メール] で設定された SMTP メール サーバー経由で通知を受信者に送信する

以下の図は 3 種類の通知の仕組みに加えて次の内容を説明しています。

  • 関与しているサービス/ジョブ (緑色) 
  • 関与しているデータベース (青色)

最初のトラブルシューティング ステップ

上の図でわかるように、イベントで通知がトリガーされる瞬間から通知メールの送信までのプロセスを通して、Jira サービス、データベース テーブル、メール サーバーを含むさまざまな要素が関与しています。

問題が発生する可能性があるのは主に 4 つの領域です。

  • Jira と SMTP サーバーの間の接続
  • Mail Queue Service
  • Jira のバッチ通知ジョブ
  • Service Desk のカスタマー通知ジョブ

ログの深堀り、スレッド ダンプの分析、データベース クエリの実行などの複雑な調査を行う前に、開始ポイントとしていくつかの質問に答えることが重要です。これらの質問は通知ワークフロー全体のなかで特定の領域に着目するのに役立ち、次の図にまとめられています。


この図の確認が終わったら、図での確認内容に従ってこの KB 記事の適切なセクションに移動します。

SMTP メール サーバーの問題のトラブルシューティング


問題が Jira アプリケーションと SMTP メール サーバーの間にある場合、ページ ⚙ > [システム] > [メール キュー] に移動すると、メールがエラー キューに表示されているか、次のようにメール キューにピンクの背景色で表示されています。

Mail Queue Service で SMTP サーバー経由で通知メールを送信できなかった理由にはさまざまなものが考えられます。このような理由には次のものが考えられますが、ほかの理由も考えられます。

  • Jira サーバーと SMTP メール サーバーの間のネットワーク接続性の問題
  • SMTP メール サーバーの側のメール スロットル設定
  • Jira 側の SSL 設定の問題
  • Jira サーバーと SMTP メール サーバーの間のアンチウイルスまたはファイアウォールでトラフィックがブロックされている

<Jira ホーム>/log/atlassian-jira-outgoing-mail.log ファイルでエラーを探し、次のいずれかに一致するエラーがあるかどうかを確認します。(warning) これらのエラーはほとんどののメールで返されるもので、ログで頻繁に発生している場合にのみ関連する点にご注意ください。これらのエラーが稀に発生している場合、それらは偽陽性である可能性があります。

com.atlassian.mail.MailException: com.sun.mail.smtp.SMTPSendFailedException: 421 4.4.2 Message submission rate for this client has exceeded the configured limit
java.net.SocketTimeoutException: Read timed out
Too many login attempts, please try again later
com.atlassian.mail.MailException: com.sun.mail.util.MailConnectException: Couldn't connect to host, port: smtp.office365.com, 587; timeout -1;
      nested exception is:
        java.net.ConnectException: Connection timed out (Connection timed out)
        at com.atlassian.mail.server.impl.SMTPMailServerImpl.sendWithMessageId(SMTPMailServerImpl.java:222) [atlassian-mail-5.0.0.jar:?]
com.atlassian.mail.MailException: com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.0 Must issue a STARTTLS command first. 7sm25921297qkx.49 - gsmtp
	at com.atlassian.mail.server.impl.SMTPMailServerImpl.sendWithMessageId(SMTPMailServerImpl.java:225) [atlassian-mail-2.7.18.jar:?]
com.atlassian.mail.MailException: javax.mail.MessagingException: Could not convert socket to TLS;
      nested exception is:
    	java.io.IOException: Can't verify identity of server: <SERVER_NAME>
com.atlassian.mail.MailException: javax.mail.MessagingException: Could not convert socket to TLS;
      nested exception is:
    	javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: smtp.gmail.com, port: 587;
nested exception is:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:2056) [javax.mail-1.5.4.jar:1.5.4]
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:697) [javax.mail-1.5.4.jar:1.5.4]
at javax.mail.Service.connect(Service.java:386) [javax.mail-1.5.4.jar:1.5.4]
at javax.mail.Service.connect(Service.java:245) [javax.mail-1.5.4.jar:1.5.4]
at javax.mail.Service.connect(Service.java:194) [javax.mail-1.5.4.jar:1.5.4]
at com.atlassian.mail.server.impl.SMTPMailServerImpl.sendWithMessageId(SMTPMailServerImpl.java:174) [atlassian-mail-2.5.16.jar:?]
... 25 more


このようなエラーがログで頻繁に確認される場合、次の KB 記事のいずれかが該当する可能性があります。

Mail Queue Service の問題のトラブルシューティング

問題が Mail Queue Service にある場合、次のいずれかの症状があります。これらは Mail Queue Service がスタックしているか、実行が非常に低速になっているか、時間どおりにスケジュールされていないことを意味します。

  • A high number of emails are piling up in the mail queue in ⚙ > System > Mail Queue as shown in the image below:
  • メール キューのサイズが自動的に減らないか、非常にゆっくり減っている
  • メール キューが手動でフラッシュしたときに空になる

There can be various reasons why the mail queue service is not running as expected. The most common root causes are described below.

tip/resting Created with Sketch.

To track the state of email sending in Jira applications, you can also use the health check for mail error queues. The health check is available with the ATST plugin 1.53.2 and later.

根本原因 1 - Mail Queue Service の設定

Mail Queue Service は既定で 1 分に 1 回実行されます。これがユーザー設定によって異なる間隔に変更されるときがあり、そのような場合は各エンド ユーザーへの到達時間に直接影響します。

これは、⚙ > [システム] > [高度] > [サービス] に移動して [スケジュール] 値を確認することで検証できます。

  • デフォルト値は 0 * * * * ? で、毎分を意味します。
  • デフォルト値と異なるクーロン式が確認できた場合、毎分よりも少ない頻度で実行するよう変更されている可能性があります。この場合は式をデフォルトに変更し、問題が解決するかどうかを確認します。

Root cause 2 - The Jira mail handlers are using most of the Caesium threads

Jira に接続されたメールボックスに大量のメッセージがある場合に、受信メール ハンドラによるメールボックスの読み取りに時間がかかる問題も確認されています。これによって Caesium スレッドが期待された頻度で解放されず、Mail Queue Service が実行するまでに時間がかかるようになります。

メール ハンドラの実行時間のために Mail Queue Service が実行されていないことを確認するには、次の KB 記事をご確認ください。

Jira notifications piling up in the mail queue due to mail handlers using too many Caesium threads

Root cause 3 - Outgoing Mail Server configured with and infinite timeout value

送信メール サーバー (SMTP メール サーバー) のコネクション タイムアウトが 0 に設定されているか、コネクション タイムアウトが設定されていないと、Mail Queue Service は SMTP サーバーからのコネクションを永続的に待機します。なんらかの理由でコネクションが不安定で、メール キューが通知の送信中である場合、通知がその永続状態でスタックする可能性があります。メール キューが毎分に設定されていないと、メール キューが無限に蓄積されることになります。

SMTP サーバーのタイムアウト値のために Mail Queue Service の実行が妨げられていることを確認するには、次の KB 記事をご参照ください。

Jira notifications piling up in the mail queue due to the SMTP server infinite timeout setting

根本原因 4 - Jira サーバーのホスト名の DNS 解決の問題

Every time  the Mail Queue Service attempts to send an email, it will perform a reverse DNS lookup for the Jira application server hostname. If the hostname isn't reachable, Jira application will have to wait for for a timeout which can be a long period of time (20-40 seconds).

If you make the observations listed below, then this root cause might be relevant:

  • メール キューの自動クリアが非常にゆっくり実行される
  • キューを手動でフラッシュしたときに、メール キューが引き続きゆっくりクリアされる
  • 送信メールのログとデバッグの有効化後に <Jira ホーム>/log/atlassian-jira-outgoing-mail.log ファイルを確認すると、各メールの送信に長い時間がかかっている (例: 20-40 秒)

    grep 'was sent with Message-Id' atlassian-jira-outgoing-mail.log:
    
    2020-07-27 04:53:41,256+0200 DEBUG [] Sending mailitem To='email1@test.com' Subject='Updated: (ABC-123)' From='null' FromName='Test User (Jira)' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/html' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@24d56930' MessageId='null' ExcludeSubjectPrefix=false' anonymous    Mail Queue Service Message was sent with Message-Id <JIRA.428775.1594212067000.32599.1595818401102@Atlassian.JIRA>
    2020-07-27 04:54:01,456+0200 DEBUG [] Sending mailitem To='email2@test.com' Subject='Updated: (ABC-123)' From='null' FromName='Test User (Jira)' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/html' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@3b62f1d5' MessageId='null' ExcludeSubjectPrefix=false' anonymous    Mail Queue Service Message was sent with Message-Id <JIRA.428775.1594212067000.32600.1595818441274@Atlassian.JIRA>
    2020-07-27 04:54:21,639+0200 DEBUG [] Sending mailitem To='email3@test.com' Subject='Updated: (ABC-123)' From='null' FromName='Test User (Jira)' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/html' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@19310596' MessageId='null' ExcludeSubjectPrefix=false' anonymous    Mail Queue Service Message was sent with Message-Id <JIRA.428775.1594212067000.32601.1595818481472@Atlassian.JIRA>

この場合、次の 2 つのナレッジベース記事のいずれかが該当する可能性があります。

JVM の IPv6 の問題により、メール キューに Jira 通知が蓄積される
サーバーのホスト名解決の問題により、メール キューに Jira 通知が蓄積される

根本原因 5 - グループ フィルター購読が大量のユーザーに送信されているか、非公開フィルターの購読が非常に多い

Mail Queue Service のキューが混み合い、大量のフィルター購読メールを送信しているために、頻繁にスタックする場合があります。

この状況の影響を受けているかどうかを確認するには次のナレッジベース記事を確認します。

グループ フィルター購読や大量の非公開フィルター購読によって Jira 通知が非常に遅れて届く

Root Cause 6 - Some 3rd party add-ons are using most of the Caesium threads

Mail Queue Service は 1 分ごと (デフォルト値) のスケジュール実行を行う際、Caesium スレッドに依存しています。次のいずれかのアドオンが Jira インスタンスにインストールされている場合、そのアドオンがすべての Caesium スレッドを定常的に利用し、Mail Queue Service (およびその他の任意の Jira サービス) のスケジュール実行を妨げている可能性があります。

このシナリオの影響を受けているかどうかを確認するには次のナレッジベース記事を確認します。

Jira incoming mail and outgoing mail functionalities are not running due to an add-on taking all the Caesium threads

Root Cause 7 - Network slowness between Jira and the SMTP Mail server, or slowness on the SMTP Mail server side

If there is any network slowness or slowness on the SMTP mail server side, the size of the Mail Queue might increase quickly, as emails we will be sent very slowly.

To know if this root cause is relevant, check if you can observe both symptoms below:

  • Collect Thread Dumps, and check if you can see a long running thread showing that the Mail Queue is taking time to sent an email

    "Sending mailitem PostprocessingMailQueueItem{delegate=To='someuser@test.com' Subject='ABC-123 Some Issue' From='null' FromName='Chalupa, Petr (Jira)' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/html' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@5baf200d' MessageId='null' ExcludeSubjectPrefix=false'}" daemon prio=5 tid=0x0000000000000465 nid=0 runnable 
       java.lang.Thread.State: RUNNABLE
    	at java.net.SocketInputStream.socketRead0(Native Method)
    	at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    	at java.net.SocketInputStream.read(SocketInputStream.java:171)
    	at java.net.SocketInputStream.read(SocketInputStream.java:141)
    	at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:102)
    	at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    	at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    	- locked <0x00000000465e0014> (a java.io.BufferedInputStream)
    	at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:100)
    	at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:2456)
    
    ...
    
    	at com.atlassian.jira.mail.JiraMailQueue$1.apply(JiraMailQueue.java:51)
    	at com.atlassian.jira.mail.JiraMailQueue$1.apply(JiraMailQueue.java:48)
  • Enable DEBUG for Outgoing Mail in ⚙ > System > Logging and profiling, and check how long emails take to be sent. For example, in the example below, we can see that it takes more than 1 min for an email to be sent (there is a gap of >1min after the line mentioning "Sending message"):

    2023-02-06 15:27:43,416+0200 DEBUG [] Sending mailitem To='someuser@test.com' Subject='ABC-123 Some Issue' From='null' FromName='Some User' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/plain' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@2c754c73' MessageId='null' ExcludeSubjectPrefix=true' anonymous    Mail Queue Service [c.atlassian.mail.outgoing] Getting transport for protocol [smtp]
    2023-02-06 15:27:43,416+0200 DEBUG [] Sending mailitem To='someuser@test.com' Subject='ABC-123 Some Issue' From='null' FromName='Some User' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/plain' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@2c754c73' MessageId='null' ExcludeSubjectPrefix=true' anonymous    Mail Queue Service [c.atlassian.mail.outgoing] Got transport: [smtp://jira@test.com]. Connecting
    2023-02-06 15:27:43,429+0200 DEBUG [] Sending mailitem To='someuser@test.com' Subject='ABC-123 Some Issue' From='null' FromName='Some User' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/plain' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@2c754c73' MessageId='null' ExcludeSubjectPrefix=true' anonymous    Mail Queue Service [c.atlassian.mail.outgoing] Sending message
    2023-02-06 15:28:51,463+0200 DEBUG [] Sending mailitem To='someuser@test.com' Subject='ABC-123 Some Issue' From='null' FromName='Some User' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/plain' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@2c754c73' MessageId='null' ExcludeSubjectPrefix=true' anonymous    Mail Queue Service [c.atlassian.mail.outgoing] Message was sent with Message-Id <JIRA.2999030.1675684169000.182.1675690063415@Atlassian.JIRA>

If both symptoms listed above are observed, then this root cause is probably relevant.

Root Cause 8 - High Jira activity triggering huge amount of emails that the SMTP server or the network cannot handle

Ideally, in a very healthy network environment, the Mail Queue should be able to send each email within 200 msec, which is 5 emails per second and 300 emails per minute. If the Jira application has a strong ticket activity from thousands of users, it is possible that more than 300 emails will be triggered per minute. If the network speed is not ideal (mails take more than 200 msec to be delivered to the SMTP server), and if the number of emails is too high, it is expected that emails will pile up in the Mail Queue.

The resolution is unfortunately not simple, as it consists in:

  • either improving the network stability/speed
  • or reducing the amount of issue activity in Jira
  • or enabling the Jira Notification Batching, as it will reduce the amount of emails triggered from any issue (only available in Jira 8.0.0 and higher versions)

根本原因 9 - Jira チケットで非常に長いテキスト フィールドが更新された

非常に大きなサイズ (数百~数千文字) のテキスト フィールドが Jira 課題で編集された場合、Mail Queue Service でフィールドの変更内容を示す Jira 通知の構築中にスタックする、既知の Jira バグが発生する可能性があります。このバグの影響を受けたかどうかや潜在的な回避策を確認するには、次の公開バグ チケットをご確認ください。

JRASERVER-65963 - 課題詳細を取得中... ステータス

根本原因 10 - Mail Queue Service がデータベースの接続性の問題から復旧しない

Jira でデータベースの接続性の一時的な問題 (DB サーバーのメンテナンスや再起動など) が発生した場合、Mail Queue Service などの一部のスケジュール ジョブが復旧せず、スケジューラーでの再実行も試行されない可能性があります。

この場合は次の公開バグの影響を受けている可能性があります。

JRASERVER-62072 - 課題詳細を取得中... ステータス

Mail Queue Service が実行されない理由がこのバグであるかどうかを確認するには、次の KB 記事をご確認ください。

バグ JRASERVER-62072 のために Jira/Service Management の通知がメール キューに蓄積される

根本原因 11 - Bamboo サービスのインスタンスが多すぎる

Jira の 8.2.2 未満のバージョンを実行している場合、次のバグの影響を受けている可能性があります。
JRASERVER-66593 - Getting issue details... STATUS

Due to this bug, after every Jira re-start, a new duplicate entry for the job com.atlassian.jira.plugin.ext.bamboo.service.PlanStatusUpdateJob will be added to the clusteredjob table. Since all scheduled jobs share the same resources (4 Caesium threads), if this job clogs the clusteredjob table, then other jobs such as the Mail Queue Service may never have a chance to run.

次の SQL クエリを実行すると、この根本原因の確認に役立ちます。

select count (*) from clusteredjob
WHERE job_runner_key = 'com.atlassian.jira.plugin.ext.bamboo.service.PlanStatusUpdateJob';

If this query returns a high number of duplicate rows, then this root cause might be relevant.

Jira の通知の問題のトラブルシューティング (バッチおよび非バッチ)


バッチ通知設定 (ページ ⚙ > [システム] > [バッチ通知]) の有効化有無にかかわらず Jira 通知が設定されていないことを確認した場合、Jira の通知モジュール全体が機能していないことになります。

現時点で 1 つの根本原因のみが特定されています。

根本原因 - 不適切なアップグレード パスにより Insight アドオンが無効化されている

Jira を 8.16.0 以降 (あるいは Jira Service Management 4.16.0 以降) にアップグレードしたあとに Jira 通知 (バッチまたは非バッチ) が動作を停止した場合、次のナレッジベース記事で説明されている問題の影響を受けている可能性があります。

不適切なアップグレード パスによって Insight プラグインが無効化されたことで Jira のメール通知に失敗する

Jira のバッチ通知メールの問題のトラブルシューティング

ページ ⚙ > [システム] > [バッチ通知] でバッチ通知を無効化すると Jira 通知が適切に送信される場合、Jira のバッチ通知を処理するジョブが実行に失敗しているか、低速になっている可能性があります。

Jira のバッチ通知のジョブが期待どおりに動作しない原因にはさまざまなものが考えられます。もっともよくある根本原因は次のとおりです。

根本原因 1 - 期待された挙動

Jira 通知で一定の遅延 (例: 30 分、10 分など) が確認されていて、ページ ⚙ > [システム] > [メール通知のバッチ] でバッチ通知が有効化されている場合、この遅延は期待されるものです。バッチ通知はこのページにあるさまざまな頻度で送信でき、もっとも頻繁なものは 2 分ごとの送信です。

通知の受け取りで確認される遅延は、設定頻度よりも少し長いものになる可能性がある点にご注意ください。たとえば頻度が 10 分に設定されている場合、通知はイベントの 12-15 分後に送信されます。これは Jira コードでのバッチ通知の実装方法によるもので、期待された挙動です。

根本原因 2 - Jira の MSSQL データベース設定の問題

Jira のバッチ通知が一切送信されず、MSSQL データベースを利用している場合、次のナレッジベース記事で説明された問題の影響を受けている可能性があります。

MS SQL データベースの利用時にバッチ通知が動作しない

根本原因 3 - Oracle データベース ドライバと Jira の間の互換性の問題

Jira のバッチ通知が一切送信されず、Oracle データベースを利用している場合、次のナレッジベース記事で説明された問題の影響を受けている可能性があります。

Oracle データベースの利用時にバッチ通知が動作しない

根本原因 4 - Jira が MSSQL または Oracle データベースに接続されているときにパフォーマンスの問題がバッチ通知ジョブに影響している

バッチ通知が断続的に大きな遅延 (例: 40 分、数時間) で送信される場合、次のパフォーマンスのバグを受けている可能性があります。

JRASERVER-71350 - 課題詳細を取得中... ステータス

Root Cause 5 - Batched notification job does does not recover from a database connectivity issue (Jira Server and Data Center - Applies to both single node and multi-node environments)

Jira Server または Data Center をシングル ノードで利用している場合

  • Jira でデータベースの接続性の一時的な問題 (DB サーバーのメンテナンスや再起動など) が発生した場合、バッチ通知ジョブなどの一部のスケジュール ジョブが復旧せず、スケジューラーでの再実行も試行されない可能性があります。
  • この場合は次のバグの影響を受けている可能性があります。

JRASERVER-62072 - Getting issue details... STATUS

根本原因 6 - バッチ通知ジョブがデータベースの接続性の問題から復旧しない (Jira Data Center のマルチノードのみ - Jira Server や Data Center のシングルノードは対象外)

Jira Data Center をマルチノードで利用している場合

  • クラスタの任意のノードがジョブ (例: バッチ通知ジョブ) を開始すると、他のノードが同じジョブを実行するのを防ぐため、データベース内でテーブル clusterlockstatus にロックが設定されます。

  • ノードはジョブの完了時に、他のノードが将来的にジョブを実行できるよう、clusterlockstatus テーブルからロックを解放することが期待されます。

  • ノードがロックの解放に失敗した場合 (データベース接続の問題など)、ノードでロック解除の再試行が行われないため、すべての Jira ノードを次に再起動するまでジョブはロックされたままになります。

Jira Data Center をバージョン 8.3.0 未満で利用している場合は次のバグの影響を受けている可能性があります。

JRASERVER-66597 - 課題詳細を取得中... ステータス

根本原因 7 - 1 つの Jira 課題に大量のウォッチャーが意図せず追加されたときにバッチ通知ジョブがスタックする

1 つのチケットのウォッチャー一覧に意図せず大量のユーザー (数百、数千単位) が追加されたあとに、ユーザーへの Jira のバッチ通知の送信が停止することがあります (あるいは数時間単位の遅延で送信)。

このシナリオの影響を受けているかどうかを確認するには次のナレッジベース記事を確認します。

1 つのチケットに対象のウォッチャーを追加したあとに任意のプロジェクトで Jira のバッチ通知が送信されなくなった

根本原因 8 - 1 つのチケットで非常に大きなテキスト量のコメントが編集されたあとにバッチ通知ジョブがスタックする

特定の条件で、非常にテキスト量の多いコメント (例: <300k 文字) がチケットで編集されたときに、Jira のバッチ通知の送信が停止することがあります (あるいは数時間単位の遅延で送信)。

このシナリオの影響を受けているかどうかを確認するには次のナレッジベース記事を確認します。

1 つのチケットで非常に大きなテキスト量のコメントが編集されたあとに任意のプロジェクトで Jira のバッチ通知が送信されなくなった

Root Cause 9 - The Batched notification job keeps being executed on the same node (Jira Data Center multi-nodes only - Does not apply to Jira Server nor Data Center single node)

Due to the bug https://jira.atlassian.com/browse/JRASERVER-75733, under some unknown conditions, the Batched Notification job might be constantly executed by the same Jira node, instead of being evenly/randomly executed by all the nodes in the cluster (and regardless if the user activity is evenly distributed across nodes by the Load Balancer).

この場合、次のことが起こります。

  • all the Batched Notification emails will end up on the Mail Queue of the same node
  • in case of a busy Jira instance, the emails will be sent with a long delay, since all emails are being sent by 1 single node, instead of being sent by by multiple nodes

To check if this root cause might be relevant:

  • Log into each node's Mail Queue page ⚙ > System > Mail Queue by using each node's IP address and bypassing the Load Balancer
    • if the Mail Queue is piling up on only 1 node, then it's an indication that this root cause might be relevant
  • Check the Jira Outgoing Mail Logs from the home folder of each node
    • If you see logs like the ones shown below recorded on only 1 node, then it's another indication that this root cause might be relevant:

      Log snippet
      2023-11-10 09:34:44,626-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.
      2023-11-10 09:34:44,718-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:34:44,725-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:35:44,627-0500 INFO [] Caesium-1-4 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.
      2023-11-10 09:35:44,647-0500 INFO [] Caesium-1-4 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:36:44,625-0500 INFO [] Caesium-1-4 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.
      2023-11-10 09:37:44,648-0500 INFO [] Caesium-1-2 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.
      2023-11-10 09:38:44,627-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.
      2023-11-10 09:38:44,650-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:38:44,697-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:38:44,701-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:39:44,628-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.
      2023-11-10 09:39:44,643-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:39:44,649-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:39:44,654-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for flushed/mention events to notify and using queryTimeout of null seconds.
      2023-11-10 09:40:44,631-0500 INFO [] Caesium-1-3 ServiceRunner     [c.a.m.o.c.a.j.p.i.batching.cron.MemorySafeEventRetriever] Searching for scheduled events to notify and using queryTimeout of null seconds.


Service Desk のカスタマー通知のメールの問題のトラブルシューティング

Jira 通知が期待どおりに送信されているが Service Desk のカスタマー通知が送信されていない (あるいは長い遅延で送信されている) 場合、カスタマー通知を処理するジョブが実行に失敗しているか、低速になっている可能性があります。

カスタマー通知のジョブが期待どおりに動作しない原因にはさまざまなものが考えられます。もっともよくある根本原因は次のとおりです。

根本原因 1 - 複雑な SLA 設定によってカスタマー通知が遅延している

Service Management の SLA、カスタマー通知、自動化はすべて同じスレッド (SdOffThreadEventJobRunner:thread) を共有しています。このため、ある Service Desk プロジェクトに、複数の JQL クエリを使う大量のゴールを持つ複数の SLA が含まれていると、次の症状が発生する可能性があります。

  • チケットに表示される SLA の遅延や不一致
  • 自動化のトリガーの遅延
  • カスタマー通知の遅延

この根本原因の詳細については次のナレッジベース記事をご確認ください。

複雑な SLA 設定のために Service Management のカスタマー通知の送信に大きな遅延が発生する

Root Cause 2 - Customer notification job does does not recover from a database connectivity issue (Jira Server and Data Center - Applies to both single node and multi-node environment)

Jira Server または Data Center をシングル ノードで利用している場合

  • Jira でデータベースの接続性の一時的な問題 (DB サーバーのメンテナンスや再起動など) が発生した場合、カスタマー通知ジョブなどの一部のスケジュール ジョブが復旧せず、スケジューラーでの再実行も試行されない可能性があります。
  • この場合は次のバグの影響を受けている可能性があります。

JRASERVER-62072 - Getting issue details... STATUS

根本原因 3 - カスタマー通知ジョブがデータベースの接続性の問題から復旧しない (Jira Data Center のマルチノードのみ - Jira Server や Data Center のシングルノードは対象外)

Jira Data Center をマルチノードで利用している場合

  • クラスタの任意のノードがジョブ (例: バッチ通知ジョブ) を開始すると、他のノードが同じジョブを実行するのを防ぐため、データベース内でテーブル clusterlockstatus にロックが設定されます。

  • ノードはジョブの完了時に、他のノードが将来的にジョブを実行できるよう、clusterlockstatus テーブルからロックを解放することが期待されます。

  • ノードがロックの解放に失敗した場合 (データベース接続の問題など)、ノードでロック解除の再試行が行われないため、すべての Jira ノードを次に再起動するまでジョブはロックされたままになります。

Jira Data Center をバージョン 8.3.0 未満で利用している場合は次のバグの影響を受けている可能性があります。

JRASERVER-66597 - 課題詳細を取得中... ステータス

1 つのコメントに大量の (100k) リンクが含まれていると、カスタマー通知のジョブが完全にスタックする可能性があります。このような場合は次のようになります。

  • Jira アプリケーションを再起動しても問題が解消されない
  • スレッド ダンプの収集時に次の長期実行スレッドが見つかる場合があります。

    "Caesium-2-1" #20668 daemon prio=5 tid=0x0000000004770000 nid=0x5b42 runnable [0x00007f740d93f000]
       java.lang.Thread.State: RUNNABLE
    	at java.lang.String.indexOf(String.java:1769)
    	at java.lang.String.indexOf(String.java:1718)
    	at org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4075)
    	at org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:3868)
    	at com.atlassian.servicedesk.internal.feature.customer.request.IssueUrlConverterImpl.replaceIssueUrlsWithPortalRequestUrls(IssueUrlConverterImpl.java:69)
    	at com.atlassian.servicedesk.internal.feature.customer.request.CustomerTextRendererImpl.updateCustomerTextIntertal(CustomerTextRendererImpl.java:159)
    	at com.atlassian.servicedesk.internal.feature.customer.request.CustomerTextRendererImpl.updateEmailTextForCustomer(CustomerTextRendererImpl.java:154)
    	at com.atlassian.servicedesk.internal.notifications.render.StylingBodyFinaliserImpl.buildMultiPartHtmlEmailBody(StylingBodyFinaliserImpl.java:79)
    	at com.atlassian.servicedesk.internal.notifications.render.StylingBodyFinaliserImpl.buildMessageBodyForRecipient(StylingBodyFinaliserImpl.java:72)
    	at com.atlassian.servicedesk.internal.notifications.render.StylingBodyFinaliserImpl.lambda$buildHtmlBody$0(StylingBodyFinaliserImpl.java:55)
    	at com.atlassian.servicedesk.internal.notifications.render.StylingBodyFinaliserImpl$$Lambda$2582/1308621309.apply(Unknown Source)
    	at io.atlassian.fugue.Either$RightProjection.map(Either.java:872)
    	at io.atlassian.fugue.Either.map(Either.java:217)
    	at com.atlassian.servicedesk.internal.notifications.render.StylingBodyFinaliserImpl.buildHtmlBody(StylingBodyFinaliserImpl.java:55)

Service Management の 4.5.0 未満のバージョンを利用している場合、次のバグの影響を受けている可能性があります。

JSDSERVER-6516 - 課題情報を取得中... ステータス

根本原因 5 - 1 つのチケットが何千ものリクエスト参加者に共有されているときにカスタマー通知ジョブがスタックする

1 つの Service Management リクエストが大量の参加者と共有されていると、カスタマー通知ジョブがスタックし、カスタマー通知が一切送信されないことがあります。このような場合に Jira アプリケーションを再起動しても問題は解決しません。

この挙動は、次のリンクで追跡されている Service Management バグで発生しています。
JSDSERVER-7346 - Getting issue details... STATUS

根本原因 6 - カスタマー通知ジョブが cwd_user_attributes テーブルのトークンの処理でスタックする

Jira Service Management (JSM) のバージョン 5.3.0 でログイン不要のポータルが追加されました。このバージョンではこの機能の実装にあたり、トークンの検証プロセスが追加されています。このプロセスがカスタマー通知機能の機能に悪影響をおよぼし、数時間単位で通知を遅らせることがあります。

このシナリオは、次のリンクで追跡されている Service Management バグで発生しています。
JSDSERVER-12279 - Getting issue details... STATUS

JSM 5.3.0 あるいはそれ以降へのアップグレード後にカスタマー通知で大きな遅延 (数時間/数日) が発生している場合はこの根本原因が影響している可能性があります。

アトラシアン サポートにデータを提供する

通知がスタックまたは遅延する原因が特定できない場合はこちらのリンクからアトラシアン サポートにお問い合わせください。

アトラシアンのサポート チームが問題を迅速に調査できるよう、次の手順を利用し、収集した全データをアトラシアンのサポート チケットに添付してください。

  1. Enable some additional debugging packages by following the steps below:
    1. ページ ⚙ > [システム] > [ログとプロファイル] に移動
    2. [送信メールのログ] で [有効化] をクリック
    3. その下の [デバッグを有効化] をクリック
    4. 同じページで [別のパッケージのログ レベルを設定] をクリック
    5. パッケージ名として com.atlassian.jira.service を使い、"ログ レベル" として "DEBUG" を選択
    6. Repeat the same step above, but this time with the 2 packages com.atlassian.servicedesk.plugins.notifications and com.atlassian.jira.plugins.inform.batching.cron.BatchNotificationJob
  2. 十分なログを集められるよう、30 分程度待つ
  3. サポート zip を生成する。生成時に [スレッド ダンプ] オプションを選択するようにしてください。
    1. (warning) サポート zip の作成時にスレッド ダンプを含めるには、⚙ > [システム] > [トラブルシューティングおよびサポート ツール] > [サポート zip の作成] > [Zip のカスタマイズ] に移動し、[スレッド ダンプ] オプションを選択して [保存] ボタンをクリックします。
    2. (warning) Jira Data Center をご利用の場合は各 Jira ノードでサポート zip を生成してください。
  4. 次のスクリーンショットを取得
    1. ページ ⚙ > [システム] > [送信メール] で [編集] ボタンをクリック後
    2. ページ ⚙ > [システム] > [メール キュー]
    3. ページ ⚙ > [システム] > [メール通知のバッチ]
  5. Jira データベースに対して次の SQL クエリを実行

    select * from rundetails where job_id in (
    'com.atlassian.jira.service.JiraService:10000',
    'com.atlassian.jira.plugins.inform.batching.cron.BatchNotificationJobSchedulerImpl',
    'sd.custom.notification.batch.send');
  6. サポート チケットに次の内容を添付
    1. スクリーンショット
    2. サポート zip
    3. SQL クエリの結果




説明

このページでは、次のような問題を解決するために必要な手順を説明しています。すべてのイベントの通知メールのユーザーへの到達が遅れ、場合によっては意図した受信者に届くまでに数時間がかかる。メール キューに警告やエラーはなく、メールは正常に送信されているが遅延が発生している。

製品Jira



最終更新日: 2024 年 1 月 16 日

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

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