Сообщения «Время выполнения истекло» в очереди хранилища Azure - записи базы данных не отправляются в поисковый индекс в течение последних нескольких дней

Question

Вся приведенная ниже информация может быть необязательна для диагностики / помощи, но для всего этого необходимо предоставить:

Каждые 24 часа серия хранимых процедур Azure SQL Server (2016) в сочетании с кодом микросервисов, размещенным в Azure Service Fabric, передает наши последние записи базы данных в наш индекс ElasticSearch. Я отметил сегодня, что индекс ElasticSearch не получил никаких новых записей за последние 6 дней.

Я проверил нашу очередь индексов в обозревателе хранилищ Azure и обнаружил, что все эти записи за последние 6 дней застряли в очереди. Это впервые, когда это приложение было запущено в производство несколько месяцев назад.

В связанной очереди отравлений есть два разных сообщения об ошибках, ни одно из которых я не могу расшифровать. Наиболее распространенная ошибка между ними:

Исключение ":" ОПЕРАЦИЯ = Архив; ИСКЛЮЧЕНИЕ = Истекло время ожидания выполнения.
Время ожидания истекло до завершения операции или сервер не отвечает. PAYLOAD = 12241;

StackTrace =
в System.Data.SqlClient.SqlCommand.EndExecuteNonQueryAsync (IAsyncResult asyncResult) \ r \ n
в System.Threading.Tasks.TaskFactory 1.FromAsyncCoreLogic(IAsyncResult iar, Func 2 endFunction, действие 1 endAction, Task 1 обещание, логическое значение требует синхронизации) \ r \ n --- Трассировка конца стека от предыдущего местоположения, где было сгенерировано исключение

в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () \ r \ n
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (Задача) \ r \ n
в Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.d__17.MoveNext () \ r \ n --- Трассировка конца стека от предыдущего местоположения, где было сгенерировано исключение

в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () \ r \ n
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (Задача) \ r \ n
в Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.d__13.MoveNext () \ r \ n
Трассировка конца стека от предыдущего местоположения, где было сгенерировано исключение

в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () \ r \ n
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (Задача) \ r \ n
в CANTREL.SOURCES.PERSISTENCE.REPOSITORIES.SOURCESREPOSITORY.d__3.MoveNext () \ r \ n --- Конец трассировки стека из предыдущего местоположения, где было сгенерировано исключение --- \ r \ n
в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () \ r \ n
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (Задача) \ r \ n
на CANTREL.SERVICES.SOURCES.ARCHIVER.SOURCEARCHIVER.d__7.MoveNext () "," Id ":" 455983d9-c68b-4a5d-84ff-5e9be4547af5 "," Content ": null}

Два проекта, которые начинаются с CANTREL, являются единственными элементами в этом сообщении, которые я узнаю / понимаю - у меня есть доступ к этим решениям ASP.NET, но я не могу себе представить, что это корень проблемы, поскольку код в Эти проекты остались нетронутыми с момента публикации.

Вот поток приложения:

1. Записи записываются в таблицу хранения базы данных каждую ночь.
2. SQL Server Trigger реплицирует записи в другую таблицу и помечает каждую запись в статусе 501 (готов к синхронизации).
3. Удерживающий стол обрезан.
4. Выполняется серия из 3 хранимых процедур, чтобы определить, какие записи необходимо поместить в индекс ElasticSearch, а также удалить ненужные записи.
5. Микросервис индексатора в Azure каждые 12 часов проверяет таблицу на наличие новых 501 и помещает их в вышеупомянутую очередь для отправки в индекс ElasticSearch.
6. Очередь помещает записи в индекс, и микросервис индексатора изменяет состояние записей в таблице базы данных на 1 (индексированный).

Где-то в шагах 5 и 6 возникает проблема. Очередь в настоящее время составляет 200 тыс. Записей, и это число увеличивается с каждой минутой. Мне нужна помощь, чтобы выяснить, как вывести эти элементы из этой очереди в индекс.

Пока что я запустил запрос к базе данных, чтобы проверить blocking processes. Там нет ни одного. Я не знаю, что еще может быть причиной проблемы. Другие функции базы данных, такие как INSERTS, DELETES и SELECTS, могут выполняться без проблем.

За 2 дня до того, как это начало происходить, я увеличил эту базу данных в Azure до более высокого уровня, который был отмечен как успешный. Я увеличил и уменьшил много раз без проблемы. Кроме того, я перезапускал наш сервис ElasticSearch несколько раз в четверг, но это было через несколько дней после проблема началась. Тем не менее, я счел, что стоит упомянуть эти пункты, поскольку это единственные выдающиеся изменения, внесенные в что-либо , относящиеся к этому приложению, с тех пор или примерно во время, когда это начало происходить.

Любое руководство будет с благодарностью.

EDIT # 1 - 2018-09-03: Я добавил строку кода в класс DBContext, чтобы увеличить время ожидания соединения с базой данных до 300 секунд. Это, похоже, создает временную «полосу» для ситуации, так как ошибки тайм-аута больше не появляются и очередь начинает очищаться (хотя и очень медленно). Но так как время ожидания 30 секунд было нашей установкой в ​​течение многих месяцев без проблем, это лишь временное решение, и мне все еще нужно провести анализ первопричин.