Notifications Azure DevOps服务器2019.1出现问题；“工作项目用户交付”；工作吊

我管理两台运行2019版的Azure DevOps服务器。更新1.1（17.153.29522.3）

这两台服务器中的一台定期停止发送“工作项”通知。发生此问题时，通知实际上存在，并由服务器保留，直到应用层重新启动。在该机器重新启动后，数百个积压的工作项通知会在一次大的“慌乱”（一次全部）中一次发送出去

我在8周的时间里一直在关注这个问题。在此期间，该问题已发生6次。所有6次都是在周四晚上开始的。我不知道是什么引发了这个问题。然而，如果它发生，它总是发生在周四晚上。（只是不是每周四晚上。）

问题发生在昨晚2020年7月23日

在今天早上的OI作业监控页面上，在重新启动后，我看到“WorkItem User Delivery”作业失败，结果是“Inactive”，运行时间为14小时9分钟

History Id  Priority    Result      Host Name                           Job Name                Queue Time          Time in Queue   Run Time
9227035     10          Inactive    [TEAM FOUNDATION]DefaultCollection  WorkItem User Delivery  7/23/2020 2:30 PM   0:00:00.28      14:09:26.557

详情如下:

Job History Details

[9227035] [TEAM FOUNDATION]DefaultCollection:WorkItem User Delivery
Result: Inactive
Priority:   10
Queued Reasons: Queued
Host:   [TEAM FOUNDATION]DefaultCollection
Job Name:   WorkItem User Delivery
Agent:  Process does not exist anymore
Queue Time: Thursday, July 23, 2020 2:30 PM
Queue Duration: 0:00:00.28
Start Time: Thursday, July 23, 2020 2:30 PM
Run Duration:   14:09:26.557
End Time:   Friday, July 24, 2020 4:39 AM
Result Message: 
Host Id:    33d3f91e-acc9-41b9-8744-fc2ed904235a
Job Id: 631f49b3-46e1-42ec-8fff-081bd176c18a
Agent Id:   3d718e2d-8c24-4297-9088-9e58c2ed9a6e

我想在诊断这个问题时寻求帮助，并就如何解决这个问题提出建议

注：我正在审查此处提到的类似问题的旧案例：

我还想问一下，在这种情况下，是否有任何建议仍然与Azure DevOps服务器2019相关。更新1.1。然而，他的决议信息似乎并不适用

EDIT as of 7/31/2020 Follows....

与此模式一样，WorkItem用户交付作业在太平洋时间2020年7月30日星期四4:27:32再次挂起

这一次，我在前几个小时通过procmon监视TfsJobAgent.exe，在“：587”上进行过滤

在4:27的交互之后，该进程没有进一步尝试初始化到电子邮件服务器的流量

此时生成的作业失败消息：

电子邮件作业摘要：1个错误，0个警告。此作业的详细日志 可从以下网址获得： https://.com/DefaultCollection/_apis/notification/DiagnosticLogs/a96d6177-beef-477a-a2ee-2c31433214d0/entries/52195e2c-6e55-4db6-aea7-e9d16279da80Previous 作业运行成功。当前作业运行成功-连续成功： 3843属性和统计信息：计时：NotificationSql=6预交付=0 过滤器=0标识=0通知传递时间平均值=30014 NotificationDeliveryTimeAttempts=1摘要：读取=1尝试=1 成功=0失败=1失败Alertable=0失败NoAlertable=0 failedRetryable=1 recipientCount=1 failedWithFailed=1 DeploymentCompletedEvent:读取=1尝试=1成功=0失败=1 failedAlertable=0 FailedNonaAlertable=0 failedRetryable=1 recipientCount=1 Smtp:UnassignedBatch 1 First 423866已启动 08:11:38.4594602完成08:12:08.6917156:423866的通知 DeploymentCompletedEvent结果失败！TF271000:发生错误 尝试向以下用户发送电子邮件通知时： 地址：编辑部。user@co.com. 验证电子邮件通知 团队基金会的设置是正确的 Console.SmtpException:发送失败 邮件.@ExceptionDispatchInfo.Throw:0@TaskAwaiter.HandleNonSuccessAndDebuggerNotification:0@d__2.MoveNext:0@ExceptionDispatchInfo.Throw:0@TaskAwaiter.HandleNonSuccessAndDebuggerNotification:0@d__6.MoveNext：0+内部：WebException:异常 操作已超时。08:12:08.6917156:ID:423866- 下一个进程时间=2020年7月31日上午9:12:08 尝试次数=1008:12:08.9573417:上一次作业运行 成功。08:12:08.9573417:当前作业运行成功-连续 成功：3843

上面URL处的诊断日志返回：

内部日志文本：

{“count”：1，“value”：[{“batches”：[{“startTime”：“08:11:38.4594602”，“endTime”：“08:12:08.6917156”，“NotificationId”：“423866”，“notificationCount”：1，“problematicNotifications”：[{“id”：423866，“result”：“Failed”，“eventId”：1293755，“eventType”：“DeploymentCompletedEvent”，“subscriptionId”：“477”，“stats”：{}，“recipients”：{“7833f10d-690D-45f4-8ed8-40E012A868”：{“收件人：{“id”：“7833f10d-690f-45f4-8ed8-40e012a86868”，“显示名称”：“}”，状态：null}，“消息”：[{“级别”：1，“时间”：“08:12:08.6917156”，“消息”：“TF271000: 尝试向发送电子邮件通知时出错 以下地址：redact.co.com。请验证电子邮件 通知设置在团队基础中是正确的 管理控制台。\r\nSmtpException:发送失败 邮件。\r\n\n@ExceptionDispatchInfo.Throw：0\r\n\n@TaskAwaiter.HandleNonSuccessAndDebuggerNotification：0\r\n\n@d__2.MoveNext：0\r\n\n@ExceptionDispatchInfo.Throw：0\r\n\n@TaskAwaiter.HandleNonSuccessAndDebuggerNotification：0\r\n\n@d__6.MoveNext：0\r\n+内部：\r\n异常：内部 操作已计时 out.\r\n\r\n“}]}]，“结果”：“部分成功”，“统计”：{“计时”：{“NotificationSql”：6，“预交付”：0，“筛选器”：0，“标识”：0，“NotificationDeliveryTimeAverage”：30014，“NotificationDeliveryTimeAttempts”：1}，“全部”：{“读取”：1，“尝试”：1，“成功”：0，“失败”：1，“failedAlertable”：0，“failedNonAlertable”：0，“failedRetryable”：1，“recipientCount”：1，“Failed“：1}，“DeploymentCompletedEvent”：{“读取”：1，“尝试”：1，“成功”：0，“失败”：1，“failedAlertable”：0，“FailedNoAlertable”：0，“failedRetryable”：1，“recipientCount”：1，“失败”：1}，“EmailCounters”：{“emailProcessed”：1，“emailAttemptedMessages”：1，“EmailAttemptedDedRecipients”：1，“EmailTimings”：{“AllSendMailAverage”“：30002，“AllSendMailAttempts”：1，“SucceededSendMailAverage”：0，“SucceededSendMailAttempts”：0，“FailedSendMailAverage”：30002，“FailedSendMailAttempts”：1，“订阅者”：0，“模板提取”：0，“转换”：12}}，“日志类型”：“通知传递”，“来源”：“a96d6177-beef-477a-a2ee-2c31433214d0”，“id”：“52195e2c-6e55-4db6-aea7-e9d16279da80”，“起始时间”：”“2020-07-31T08:11:38.4594602Z”，“结束时间”：“2020-07-31T08:12:09.0511168Z”，“说明”：“通知” 电子邮件 传递，“警告”：0，“错误”：1，“活动ID”：“6bddc09f-e357-413c-9e3f-66092a38968d”，“属性”：{“JobTimeSlice”：“300000”，“JobTimeoutMultiple”：“12”，“JobRestartDelay”：“30”，“ProcessingJobDelaySeconds”：“300”

Some tentative conclusions so far:
1. The issue cannot be a App Tier machine issue nor an email server issue:
   a) Tfs Administration Console can send messages during a "hang".
   b) Only a restart of the TfsJobAgent is required to reset the "hang".
2. The TfsJobAgent process does not even try to contact the email server during the "hang".
   a) Outside of the "hang" window, Procmon can record its attempts.
   b) During the "hang" window, Procmon sees no attempt to contact the email server.
3. The TfsJobAgent code believes it has made the attempt but never actually made it.
   a) It records results to contact as "operation timed out" which procmon never saw.