Поделиться через

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

Протокол Порты Сведения
AMQP 5671 и 5672 См. Руководство по использованию протокола AMQP.
HTTPS 443 Этот порт используется для HTTP или REST API и для AMQP через WebSockets.
Kafka 9093 См. Использование Центров событий Azure из приложений Apache Kafka.

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

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

Язык Вариант
.NET Свойство EventHubConnectionOptions.TransportType со значением EventHubsTransportType.AmqpTcp или EventHubsTransportType.AmqpWebSockets
Java Свойство com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype со значением AmqpTransportType.AMQP или AmqpTransportType.AMQP_WEB_SOCKETS
Узел Объект EventHubConsumerClientOptions со свойством webSocketOptions.
Python Свойство EventHubConsumerClient.transport_type со значением TransportType.Amqp или TransportType.AmqpOverWebSocket

Какие 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), а пространство имен является избыточным по зонам, вам потребуется выполнить несколько дополнительных действий ниже. Если пространство имен находится в новом кластере (на основе масштабируемого набора виртуальных машин (VMSS) — 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"
}

Внимание

Журналы виртуальной сети создаются только в том случае, если пространство имен разрешает доступ с конкретных IP-адресов (правила фильтрации IP-адресов). Если вы не хотите ограничить доступ к пространству имен с помощью этих функций и по-прежнему хотите получать журналы виртуальной сети для отслеживания IP-адресов клиентов, подключающихся к пространству имен Центров событий, можно использовать следующее решение: включить фильтрацию IP-адресов и добавить общий диапазон ip-адресов IPv4 () и диапазон IPv6 (0.0.0.0/1128.0.0.0/1 - - ::/18000::/1).

Примечание.

В настоящее время невозможно определить исходный IP-адрес для отдельного сообщения или события.

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

Если приложение работает в подсети и есть связанная группа безопасности сети, убедитесь, разрешен ли исходящий интернет или разрешен тег службы Центров событий (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, это значит, что политика повтора уже встроена и активна. Приложение повторно подключается без значительного влияния на приложение или рабочий процесс. Перехват этих временных ошибок, отключение и повторная попытка вызова гарантирует устойчивость кода к этим временным проблемам.

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

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