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

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

Если проблема возникает все время (постоянная), проверьте эти параметры и другие параметры, упомянутые в разделе "Устранение проблем с постоянным подключением " в этой статье.

• Connection string
• Параметры брандмауэра вашей организации
• Параметры брандмауэра IP
• Параметры безопасности сети (конечные точки службы, частные конечные точки и т. д.) и многое другое

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

• Обновление до последней версии пакета SDK
• Выполнение команд для проверки удаленных пакетов
• Получите трассировки сети.

Устранение постоянных неполадок с подключением

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

Проверка наличия сбоев службы

Проверьте, не произошел ли сбой службы Центра событий Azure, на сайте состояния службы Azure.

Проверка строки подключения

Убедитесь, что используется строка подключения правильно. Сведения о получении строки подключения с помощью портал Azure, CLI или PowerShell см. в статье Получение строки подключения.

Для клиентов Kafka убедитесь, что файлы producer.config или consumer.config настроены правильно. Дополнительные сведения см. в разделе Отправка и получение сообщений с помощью Kafka в Центрах событий.

Какие протоколы можно использовать для отправки и получения событий?

Производители или отправители могут использовать протоколы advanced Messaging Queuing (AMQP), Kafka или HTTPS для отправки событий в концентратор событий.

Потребители или получатели используют AMQP или Kafka для получения событий из концентратора событий. Центры событий поддерживают только модель извлечения для потребителей, получая от нее события. Даже если обработчики событий используются для обработки событий из концентратора событий, обработчик событий внутренне использует модель извлечения для получения событий из концентратора событий.

AMQP

Протокол AMQP 1.0 можно использовать для отправки событий в Центры событий Azure и получения событий. AMQP обеспечивает надежную, исполнительную и безопасную связь как для отправки, так и для получения событий. Его можно использовать для высокопроизводительной и потоковой передачи в режиме реального времени и поддерживается большинством Центры событий Azure пакетов SDK.

HTTPS/REST API

События можно отправлять только в Центры событий с помощью HTTP-запросов POST. Центры событий не поддерживают получение событий по протоколу HTTPS. Он подходит для упрощенных клиентов, где прямое TCP-подключение невозможно.

Apache Kafka

Центры событий Azure имеет встроенную конечную точку Kafka, которая поддерживает производителей и потребителей Kafka. Приложения, созданные с помощью Kafka, могут использовать протокол Kafka (версия 1.0 или более поздней версии) для отправки и получения событий из Центров событий без каких-либо изменений кода.

Пакеты SDK Azure абстрагируют базовые протоколы связи и предоставляют упрощенный способ отправки и получения событий из Центров событий с помощью таких языков, как C#, Java, Python, JavaScript и т. д.

Какие порты нужно открыть в брандмауэре?

Для отправки и получения событий можно использовать следующие протоколы с Центрами событий Azure:

• Протокол AMQP 1.0
• Протокол гипертекстовой передачи 1.1 с безопасностью транспортного уровня (HTTPS)
• Apache Kafka

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

Порт HTTPS требуется для исходящего взаимодействия также при использовании AMQP через порт 5671, так как несколько операций управления, выполняемых клиентскими пакетами SDK, и приобретение маркеров из идентификатора Microsoft Entra (при использовании) выполняется по протоколу HTTPS.

Официальный пакет SDK для Azure обычно использует протокол AMQP для отправки и получения событий от Центров событий. Вариант протокола AMQP через WebSockets работает через порт TCP 443, как и API HTTP. В остальном с точки зрения функциональности он полностью идентичен обычному протоколу AMQP. Этот вариант протокола имеет более высокую начальную задержку при подключении из-за дополнительных циклов подтверждения соединения, а также требует несколько больших дополнительных расходов для совместного использования порта HTTPS. Если выбран этот режим, для обмена данными достаточно TCP-порта 443. Для выбора между обычным протоколом AMQP и режимом AMQP через WebSockets используются следующие параметры.

Какие IP-адреса нужно внести в список разрешений?

При работе с Azure иногда необходимо разрешать определенные диапазоны IP-адресов или URL-адреса на корпоративном брандмауэре или прокси-сервере, чтобы получить доступ ко всем службам Azure, которые вы используете или пытаетесь использовать. Убедитесь, что разрешен трафик на IP-адреса, используемые Центрами событий. IP-адреса, используемые Центрами событий Azure, см. в разделе Диапазоны IP-адресов и теги служб Azure — общедоступное облако.

Кроме того, убедитесь, что IP-адрес вашего пространства имен добавлен в список разрешений. Чтобы найти правильные IP-адреса для добавления в список разрешений, выполните следующие действия.

1. В командной строке выполните следующую команду:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Запишите IP-адрес, возвращенный в Non-authoritative answer.

Если вы используете пространство имен, размещенное в более старом кластере (на основе Облачные службы — CNAME, заканчивающееся *.cloudapp.net), а пространство имен является избыточным по зонам, необходимо выполнить несколько дополнительных действий. Если пространство имен находится в новом кластере (на основе масштабируемого набора виртуальных машин — CNAME, заканчивающееся *.cloudapp.azure.com) и избыточности зоны, можно пропустить следующие действия.

1. Сначала следует запустить nslookup в пространстве имен.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Запишите имя в разделе не заслуживающий доверия ответ, который имеет один из следующих форматов:

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. Выполните команду nslookup для каждого из них с суффиксами s1, s2 и s3, чтобы получить IP-адреса всех трех экземпляров, работающих в трех зонах доступности.

   Примечание.

   IP-адрес, возвращенный командой nslookup, не является статическим. Однако он остается постоянным до тех пор, пока базовое развертывание не будет удалено или перемещено в другой кластер.

Какие IP-адреса клиента отправляют события в мое пространство имен или получают события из него?

Сначала включите фильтрацию IP-адресов в пространстве имен.

Затем включите журналы диагностики для событий подключения виртуальной сети Центров событий, следуя инструкциям в разделе Включение журналов диагностики. Вы увидите IP-адрес, для которого запрещено подключение.

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

Убедитесь, что тег службы Центров событий разрешен в группах безопасности сети

Если приложение работает в подсети и есть связанная группа безопасности сети, убедитесь, разрешен ли исходящий трафик в Интернет или тег службы Центров событий (EventHub) разрешен. Найдите в статье Теги службы виртуальной сети сведения об EventHub.

Проверьте, нужно ли запускать приложение в определенной подсети виртуальной сети.

Убедитесь, что приложение выполняется в подсети виртуальной сети, которая имеет доступ к пространству имен. Если это не так, запустите приложение в подсети, которая имеет доступ к пространству имен, или добавьте IP-адрес компьютера, на котором выполняется приложение, в брандмауэр для IP-адресов.

При создании конечной точки службы виртуальной сети для пространства имен концентратора событий пространство имен принимает трафик только из подсети, привязанной к конечной точке службы. Но есть одно исключение. Вы можете добавить определенные IP-адреса в брандмауэр IP для включения доступа к общедоступной конечной точке концентратора событий. Дополнительные сведения см. в статье Конечные точки сетевых служб.

Проверкак пространства имен в параметрах брандмауэра для IP-адресов

Убедитесь, что общедоступный IP-адрес компьютера, на котором работает приложение, не заблокирован брандмауэром IP-адресов.

По умолчанию пространства имен Центров событий доступны из Интернета при условии, что запрос поступает с действительной аутентификацией и авторизацией. С помощью брандмауэра IP-адресов его можно ограничить только набором адресов IPv4 или IPv6 или диапазонов адресов в нотации CIDR (маршрутизация между доменами без классов).

Правила брандмауэра для IP-адресов применяются на уровне пространства имен Центров событий. Поэтому они действуют для всех клиентских подключений по любым поддерживаемым протоколам. Любая попытка подключения с IP-адреса, который не соответствует правилу разрешения IP-адресов для пространства имен Центров событий, отклоняется, как несанкционированная. В ответе клиенту не упоминается правило для IP-адресов. Правила фильтрации IP-адресов применяются по порядку, поэтому первое правило, которое соответствует IP-адресу, определяет действие (принять или отклонить).

Дополнительные сведения см. в статье Настройка правил брандмауэра для IP-адресов для пространства имен Центров событий Azure. Чтобы проверить наличие проблем с IP-фильтрацией, виртуальной сетью или цепочкой сертификатов, ознакомьтесь с разделом Устранение проблем, связанных с сетью.

Проверка возможности доступа к пространству имен с использованием только частной конечной точки

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

Служба "Приватный канал Azure" предоставляет доступ к Центру событий Azure через частную конечную точку в виртуальной сети. Частная конечная точка — это сетевой интерфейс, который защищенно и надежно подключается к службе через Приватный канал Azure. Частная конечная точка использует частный IP-адрес из виртуальной сети, по сути, перемещая службу в виртуальную сеть. Весь трафик к службе может маршрутизироваться через частную конечную точку, поэтому шлюзы, устройства преобразования сетевых адресов (NAT), подключения ExpressRoute и VPN, а также общедоступные IP-адреса не требуются. Трафик между виртуальной сетью и службой проходит через магистральную сеть Майкрософт. Это позволяет избежать рисков общедоступного Интернета. Вы можете подключиться к экземпляру ресурса Azure, обеспечивая наивысшую степень детализации в управлении доступом.

Дополнительные сведения см. в статье о настройке частных конечных точек. Чтобы убедиться в использовании частной конечной точки, см. раздел Проверка работоспособности подключения к частной конечной точке.

Устранение неполадок, связанных с сетью

Чтобы устранить проблемы Центра событий, связанные с сетью, выполните следующие действия.

Перейдите на страницу https://<yournamespacename>.servicebus.windows.net/ или воспользуйтесь wget. Это поможет проверить наличие проблем с IP-фильтрацией, виртуальной сетью или цепочками сертификатов (чаще всего возникают при использовании пакета SDK для Java).

Пример сообщения об успешном выполнении:

<feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

Пример сообщения об ошибке или сбое:

<Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

Устранение временных неполадок с подключением

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

Использование последней версии клиентского пакета SDK

Некоторые временные проблемы с подключением, возможно, были исправлены в более поздних версиях пакета SDK, чем то, что вы используете. Убедитесь, что в приложениях используется последняя версия клиентских пакетов SDK. Пакеты SDK постоянно усовершенствуются новыми и обновленными функциями и исправлениями ошибок, поэтому всегда проверяйте последний пакет. Просмотрите в заметках о выпуске проблемы, которые были устранены, а также добавленные или обновленные компоненты.

Сведения о клиентских пакетах SDK см. в статье Центры событий Azure — клиентские пакеты SDK.

Выполнение команды для проверки на наличие отброшенных пакетов

Если возникают периодические проблемы с подключением, выполните следующую команду, чтобы проверить наличие отброшенных пакетов. Эта команда пытается установить 25 разных TCP-подключений каждые 1 секунды со службой. Вы сможете увидеть, сколько попыток завершились успешно, а сколько — сбоем, а также увидеть задержку TCP-подключения. Средство psping можно скачать здесь.

.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner     

Также можно использовать аналогичные команды, если вы используете другие средства, такие как tnc, ping и прочие.

Если предыдущие шаги не помогли в решении проблемы, получите трассировку сети и проанализируйте ее с помощью таких средств, как Wireshark. При необходимости обратитесь в службу поддержки Майкрософт.

Обновление или перезапуск службы

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

• Может возникнуть падение входящих сообщений и запросов.
• Файл журнала может содержать сообщения об ошибках.
• Приложения могут быть отключены от службы в течение нескольких секунд.
• Запросы могут быть мгновенно регулироваться.

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

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

См. следующие статьи:

• Устранение проблем с проверкой подлинности и авторизацией