Конечные точки диспетчера трафика Azure показывают пониженную производительность, даже если возвращается 200

У меня есть профиль диспетчера трафика Azure с двумя конечными точками (виртуальная машина Linux с RabbitMQ).

Конечные точки имеют тип «Конечная точка Azure», а тип целевого ресурса - «общедоступный IP-адрес».

Когда я смотрю на профиль диспетчера трафика, он сообщает, что статус профиля - «Включен», а статус монитора - «Degraded».

На каждой из конечных точек он сообщает, что их статус «Включен», а статус монитора - «Ухудшился».

У меня есть профиль диспетчера трафика, настроенный с использованием протокола как «HTTP», порта как 15672 и пути как «/index.html».

Проблема в том, что я не могу сказать, почему он сообщает "Degraded", потому что если я выполняю команду wget.

wget <vmname1>.cloudapp.azure.com:15672/index.html

Resolving <vmname1>.cloudapp.azure.com... <ip address>
Connecting to <vmname1>.cloudapp.azure.com|<ip address>|:15672... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1419 (1.4K) [text/html]

Вся «документация» (которая, к сожалению, представляет собой просто сообщения в блогах) говорит, что если она возвращает 200, то она должна быть «в сети», а не «деградировать».


azure rabbitmq azure-traffic-manager
person Kyro    schedule 25.05.2016    source источник
comment
с какой машины вы запускали wget?   -  person CtrlDot    schedule 25.05.2016

Ответы (2)


arrow_upward
2
arrow_downward

Судя по вашему ответу, весьма вероятно, что проблема в том, что проверки работоспособности диспетчера трафика блокируются вашими правилами NSG.

Сегодня у нас нет простого способа настроить диспетчер трафика в группах безопасности сети, и мы не публикуем исходные IP-адреса для проверки работоспособности диспетчера трафика. Это пробелы, которые мы планируем восполнить. В то же время рекомендуется использовать специальную страницу проверки работоспособности, работающую на другом TCP-порте для диспетчера трафика, и применять NSG только к порту, используемому вашим приложением.

person Jonathan Tuliani - MSFT    schedule 27.05.2016
comment
Я не могу настроить другой порт для проверки работоспособности, потому что RabbitMQ имеет только 15672 для управления и 5672 для фактической активности. Если я просто настрою проверку работоспособности на каком-то другом случайном порте для сервера, это не скажет мне, запущен ли RabbitMQ. - person Kyro; 28.05.2016

arrow_upward
0
arrow_downward

Прочтите эту статью, который может вам помочь.

Я не могу быть уверен в приведенном вами описании, но лучше всего предполагаю, что в вашем случае конечная точка возвращает перенаправление 301/302 на другой URL-адрес, а второй URL-адрес - это то, что на самом деле возвращает 200 OK. Зонды работоспособности диспетчера трафика не поддерживают переадресацию. Вы можете проверить это, например, с помощью инструментов разработчика F12 в IE.

Джонатан Тулиани, менеджер программы, диспетчер трафика Azure

person Jonathan Tuliani - MSFT    schedule 25.05.2016
comment
wget (с моей машины) не сообщает о возврате перенаправления. В инструментах разработчика IE F12 он также сообщает результат = 200 для URL-адреса. Есть ли какое-то специальное правило группы безопасности сети, которое мне нужно добавить, чтобы, возможно, разрешить диспетчер трафика? - person Kyro; 26.05.2016
comment
К сожалению, в этом случае нет подходящего обходного пути. Вы можете проголосовать за необходимую функцию на нашем сайте отзывов: feedback.azure.com/forums/217313-networking/suggestions/. У нас очень большое отставание. - person Jonathan Tuliani - MSFT; 30.05.2016