-
Suggestion
-
Resolution: Unresolved
-
None
-
1
-
Problem
Jira does not surface any data in the UI about what notification emails have been sent. Therefore it is difficult for a Jira Administrator to determine what email the instance is sending.
With the increase of adoption of automation, it is possible for Jira to send out a high volume of mail. It can be inside an admin's responsibility to identify and stop any problematic email spikes or floods as a result of scripted or automated notifications.
Suggested Solution
Surface the data already stored in the database for batching notifications. This data currently stores (at least)
- User who generated the event
- User who received the event
- Jira Issue
- Mention or non mention
- Notification creation DateTime
- Notification released to mail queue DateTime
If this data was surfaced in a table, exposed via a REST API, or plotted on a graph, it would solve the visibility problem.
As a Jira admin it's helpful to group the data around around a Jira issue, user generating the event or user receiving the notification.
This data is held in the database until the com.atlassian.jira.plugins.inform.events.cleanup.CleanupJobScheduler Scheduled Job runs. By default, this is at the end of each month.
Potential Workarounds
- Aggressively collect data from atlassian-jira-outgoing-mail.log using an external solution
- Available if Batching Email Notifications is turn off
- Available if Batching Email Notifications is turned on if on a Jira version with
JRASERVER-70759fixed - Only surfaces: Time email was sent, sender, recipient, and implied issue key through subject:
2020-08-31 13:20:00,332+1000 DEBUG [] Sending mailitem PostprocessingMailQueueItem{delegate=To='juser@localhost' Subject='Updates for SCRU-1: Testset' From='null' FromName='admin (Jira)' Cc='null' Bcc='null' ReplyTo='null' InReplyTo='null' MimeType='text/html' Encoding='UTF-8' Multipart='javax.mail.internet.MimeMultipart@4d9367a0' MessageId='null' ExcludeSubjectPrefix=false'} anonymous Mail Queue Service [c.atlassian.mail.outgoing] Getting transport for protocol [smtp]
- Since
JRASERVER-70759moves all batching logs under "Outbound Email Debug: ON", the log can get extremely noisy and therefore can be rotated very quickly. Potential solution:- After turning on Outgoing Mail Debug, Set logging for package -> com.atlassian.mail.outgoing.com.atlassian.jira.plugins.inform (SIC - this is all a single string) -> INFO
- This will result in the batching debug logging being surpresed and minimse the log to just the email debug log style messages
- Periodically poll mail queue API and store history in external service / monitoring solution
- This only gives queueSize and errorQueueSize
- Must be run against each node if using Jira Data Center
- If Batching Email Notifications is enabled, you can take the data from the database. The following query worked under Postgres 9.6, Jira 8.5.5. It may need to be adjusted for other database type or Jira version.
SELECT er."CONSUMER_NAME" as type, er."EVENT_ID" AS event_id, er."ID" as event_recipient_id, er."STATUS" AS status, er."CREATED" AS event_created_time, er."SEND_DATE" AS scheduled_send_time, er."UPDATED" AS attemped_send_time, er."USER_KEY" as recipient_user_key, ep."NAME", ep."VALUE" as issue_key_of_notification, au.lower_user_name as username_of_who_generated_event FROM "AO_733371_EVENT_RECIPIENT" er JOIN "AO_733371_EVENT" e on e."ID" = er."EVENT_ID" JOIN "AO_733371_EVENT_PARAMETER" ep ON ep."EVENT_ID" = e."ID" JOIN app_user au on au.user_key = e."USER_KEY" WHERE (er."CONSUMER_NAME" = 'mailEventConsumer' OR er."CONSUMER_NAME" = 'mailMentionEventConsumer') AND ep."NAME" = 'object#issue#key#0'
- is related to
-
JRASERVER-67539 Add incoming and outgoing mail health monitoring
- Gathering Interest
- relates to
-
JRASERVER-61548 Show status of Outgoing Mail
- Gathering Interest
- mentioned in
-
Page Loading...