Устранение неполадок обработчика событий Центров событий Azure

В этой статье приводятся решения распространенных проблем, которые могут возникнуть при использовании EventProcessorClient типа. Если вы ищете решения других распространенных проблем, которые могут возникнуть при использовании Центров событий Azure, см. статью "Устранение неполадок Центров событий Azure".

Сбои предварительных условий 412 при использовании обработчика событий

Ошибки условия предварительного выполнения 412 возникают, когда клиент пытается взять или продлить владение разделом, но локальная версия записи владения устарела. Эта проблема возникает, когда другой экземпляр процессора захватывает управление разделами. Дополнительные сведения см. в следующем разделе.

Часто изменяются права владения секциями

При изменении количества EventProcessorClient экземпляров (то есть, когда они добавляются или удаляются), работающие экземпляры пытаются сбалансировать разделы нагрузки между собой. Предполагается, что в течение нескольких минут после изменения количества процессоров владельцы разделов сменятся. После балансирования права собственности на разделы должны быть стабильными и редкими изменениями. Если владение разделами часто меняется, когда число процессоров постоянно, это, скорее всего, указывает на проблему. Мы рекомендовали вам подать запрос на GitHub с журналами и примером воспроизведения.

Владение секцией определяется с помощью записей владения в элементе CheckpointStore. В каждом интервале балансировки нагрузки EventProcessorClient выполняет следующие задачи:

1. Получите последние записи о праве собственности.
2. Проверьте записи, чтобы узнать, какие записи не обновили метку времени в течение интервала истечения срока владения разделом. Рассматриваются только записи, соответствующие этим критериям.
3. Если существуют незанятые разделы, а нагрузка не равномерно распределена между экземплярами EventProcessorClient, клиент обработчика событий попытается взять на себя управление разделом.
4. Обновите запись владения для секций, принадлежащих ей, у которых есть активная ссылка на этот раздел.

Вы можете настроить интервалы балансировки нагрузки и истечения срока владения при создании EventProcessorClient с помощью EventProcessorClientBuilder, как описано в следующем списке:

• Метод loadBalancingUpdateInterval(Duration) указывает, как часто выполняется цикл балансировки нагрузки.
• Метод partitionOwnershipExpirationInterval(Duration) указывает минимальное количество времени после обновления записи владения, прежде чем процессор считает секцию неуправляемой.

Например, если запись владения была обновлена в 9:30 утра и partitionOwnershipExpirationInterval составляет 2 минуты. Когда происходит цикл балансировки нагрузки, и система замечает, что запись владения не была обновлена за последние 2 минуты или до 9:32 утра, она будет рассматривать раздел ничейным.

Если ошибка возникает в одном из потребителей раздела, система закроет соответствующего потребителя, но не попытается восстановить его до следующего цикла распределения нагрузки.

"... текущий приемник "RECEIVER_NAME<" с эпохой ">0" становится отключенным"

Все сообщение об ошибке выглядит примерно так:

New receiver 'nil' with higher epoch of '0' is created hence current receiver 'nil' with epoch '0'
is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used.
TrackingId:<GUID>, SystemTracker:<NAMESPACE>:eventhub:<EVENT_HUB_NAME>|<CONSUMER_GROUP>,
Timestamp:2022-01-01T12:00:00}"}

Эта ошибка ожидается при балансировке нагрузки, когда экземпляры EventProcessorClient добавляются или удаляются. Балансировка нагрузки — это текущий процесс. При использовании BlobCheckpointStore с потребителем каждые 30 секунд (по умолчанию) потребитель проверяет, какие потребители имеют претензию на каждый раздел, а затем выполняет некоторую логику, чтобы определить, нужно ли «перехватить» раздел у другого потребителя. Механизм обслуживания, используемый для утверждения монопольного владения над секцией, называется эпохой.

Однако если экземпляры не добавляются и не удаляются, существует существенная проблема, которую следует решить. Дополнительные сведения см. в разделе о частом изменении прав собственности на раздел и создании обращений в GitHub.

Высокая загрузка ЦП

Высокое использование ЦП обычно связано с тем, что экземпляр владеет слишком большим количеством разделов. Рекомендуется не более трех разделов для каждого ядра ЦП. Лучше начать с 1,5 разделов для каждого ядра ЦП, а затем протестировать, увеличив число принадлежащих разделов.

Недостаток памяти и выбор размера кучи

Проблема нехватки памяти (OOM) может произойти, если текущий максимальный объем кучи для JVM недостаточен для работы приложения. Может потребоваться измерить требование кучи приложения. Затем на основе результата определите размер кучи, установив подходящий максимальный размер памяти кучи с помощью параметра JVM -Xmx.

Не следует указывать -Xmx значение, превышающее доступное или ограничение памяти для узла (виртуальной машины или контейнера), например память, запрошенная в конфигурации контейнера. Чтобы хост поддерживал кучу Java, необходимо выделить достаточно памяти.

Ниже описан типичный способ измерения максимального значения для кучи Java.

1. Запустите приложение в среде, близкой к рабочей среде, где приложение отправляет, получает и обрабатывает события под пиковой нагрузкой в рабочей среде.

2. Подождите, пока приложение достигнет устойчивого состояния. На этом этапе приложение и JVM загружали все доменные объекты, типы классов, статические экземпляры, пулы объектов (TCP, пулы подключений базы данных) и т. д.

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

   

3. Когда приложение достигнет устойчивого состояния, принудительно выполните полную сборку мусора (GC) с помощью таких средств, как JConsole. Наблюдайте за памятью, занятой после полной сборки мусора (GC). Вы хотите размер кучи таким образом, чтобы только 30% занято после полной сборки GC. Это значение можно использовать для задания максимального размера кучи (с помощью -Xmx).

Если вы используете контейнер, то задайте его размер с дополнительными ~1 ГБ памяти для потребностей вне кучи экземпляра JVM.

Клиент процессора перестает получать

Клиент обработчика часто постоянно работает в хост-приложении в течение нескольких дней. Иногда он замечает, что EventProcessorClient не обрабатывает одну или несколько секций. Как правило, недостаточно информации, чтобы определить, почему произошло исключение. Остановка EventProcessorClient является симптомом основной причины (т. е. состояния гонки), которая произошла при попытке восстановиться после временной ошибки. Для получения необходимой информации см. Создание проблем на GitHub.

Повторяющееся событие, полученное при перезапуске процессора

EventProcessorClient Служба Центров событий гарантирует по крайней мере один раз доставку. Можно добавить метаданные для распознавания повторяющихся событий. Дополнительные сведения см. в статье "Гарантируют ли центры событий Azure доставку хотя бы один раз?" на Stack Overflow. Если вам требуется доставка только один раз, следует рассмотреть Service Bus, который ожидает подтверждения от клиента. Сравнение служб обмена сообщениями см. в статье "Выбор между службами обмена сообщениями Azure".

Низкоуровневый клиент-потребитель перестает получать

EventHubConsumerAsyncClient — это низкоуровневый клиент-потребитель, предоставляемый библиотекой Центров событий, предназначенный для расширенных пользователей, которым требуется больший контроль и гибкость над их реактивными приложениями. Этот клиент предлагает низкоуровневый интерфейс, позволяющий пользователям управлять обратным сжатием, потоком и восстановлением в цепочке реакторов. В отличие от EventProcessorClient, EventHubConsumerAsyncClient не включает механизмы автоматического восстановления для всех фатальных причин. Таким образом, пользователи должны обрабатывать события терминала и выбирать соответствующих операторов Реактора для реализации стратегий восстановления.

Метод EventHubConsumerAsyncClient::receiveFromPartition выдает критическую ошибку, когда подключение обнаруживает неустранимую ошибку или если ряд попыток восстановления подключения завершается последовательно, исчерпав максимальный предел повторных попыток. Хотя получатель низкого уровня пытается восстановиться после временных ошибок, пользователи клиента-потребителя, как ожидается, будут обрабатывать события терминала. Если требуется непрерывный прием событий, приложение должно изменить цепочку Реактора, чтобы создать новый клиент-потребитель при окончании события.

Миграция из прежних версий в новую клиентную библиотеку

Руководство по миграции включает шаги по миграции из устаревшего клиента и миграции устаревших контрольных точек.

Дальнейшие действия

Если рекомендации по устранению неполадок в этой статье не помогают устранить проблемы при использовании клиентских библиотек пакета SDK Azure для Java, мы рекомендуем создать проблему в репозитории Azure SDK для Java на GitHub.