Рабочая роль Azure, генерирующая запись непредвиденной ошибки в хранилище журнала трассировки

Question

В облаке запущена рабочая роль, которая периодически опрашивает Azure CloudQueue, получая сообщения, которые веб-роль поставила для нас. В настоящее время рабочая роль и веб-роль размещены в одном и том же приложении облачной службы, и в настоящее время мы используем только один экземпляр.

Во время тестирования у нас включено ведение журнала, поэтому содержимое сообщений и другая полезная информация отображаются в нашем облачном хранилище, которое мы просматриваем с помощью Cerebrata Azure Diagnostics Manager. (Большой продукт между прочим)

DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration ();

diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

На самом деле все работает замечательно, но иногда мы видим подробное сообщение в журнале трассировки, в котором просто "Fail". Код, из которого он создается, обернут в попытку, поэтому странно, что мы не видим сообщение этими средствами.

Может показаться, что происходит что-то, что находится вне контроля нашего кода, возможно, рабочая роль перезапускается, или облачная операционная система обнаруживает серьезную ошибку, с которой может справиться только перезапуск нашей рабочей роли. Оно восстанавливается и продолжает действовать, поэтому для нас является загадкой, что может происходить.

Что мы еще не выяснили, так это то, что мы теряем сообщение.

Любая помощь будет с благодарностью. ура Киндо Малайский

Answer 1

Если ваш экземпляр роли перезапускается после некоторого времени работы, это часто происходит потому, что ваш процесс завершился из-за необработанного исключения.

Answer 2

Без трассировки стека трудно сказать слишком много, но с многословным журналированием вполне вероятно, что вы видите какую-то внутреннюю регистрацию из одной из используемых вами библиотек.

Например, если вы выполняете запрос таблицы Azure, который вызывает определенные виды ошибок, ошибка будет выходить из системы 3 раза, поскольку клиентская библиотека хранилища перехватывает ошибку, отслеживает ее и затем повторяет попытку.

Если ошибка не перехватывается вашим блоком try catch, вероятно, вам не о чем беспокоиться.

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