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


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

Azure Load Balancer предоставляет следующие возможности диагностики:

  • Многомерные метрики и оповещения: предоставляет многомерные возможности диагностики с помощью Azure Monitor для конфигураций Azure Load Balancer. Можно отслеживать, управлять и устранять неполадки ресурсов балансировщика нагрузки стандартного класса.

  • Работоспособность ресурсов: Состояние работоспособности ресурсов вашего балансировщика нагрузки можно посмотреть на странице Работоспособность ресурсов в Монитор. Эта автоматическая проверка информирует вас о текущей доступности вашего ресурса балансировщика нагрузки.

Эта статья предлагает краткий обзор этих возможностей и способов их использования для стандартного балансировщика нагрузки.

Многомерные метрики

Azure Load Balancer предоставляет многомерные метрики посредством решения "Метрики Azure" на портале Azure и позволяет получить сведения для диагностики ресурсов подсистемы балансировки нагрузки в режиме реального времени. Обратите внимание, что многомерные метрики не поддерживаются для базовых подсистем балансировки нагрузки

Различные конфигурации Load Balancer предоставляют следующие метрики:

Метрика Тип ресурса Описание Рекомендуемая агрегация
Data Path Availability (Доступность пути к данным) Общедоступный и внутренний балансировщик нагрузки Подсистема балансировки нагрузки постоянно использует маршрут передачи данных из региона к фронтэнду балансировщика нагрузки и далее к сети, поддерживающей вашу виртуальную машину. Пока остаются работоспособные экземпляры, измерение выполняется по тому же пути, что и трафик приложения с балансировкой нагрузки. Используемый путь к данным подтвержден. Измерение является невидимым для приложения и не влияет на работоспособность других операций. Средний
Статус проверки работоспособности Общедоступный и внутренний балансировщик нагрузки Подсистема балансировки нагрузки использует распределенную службу проверки работоспособности, которая отслеживает работоспособность конечной точки приложения в соответствии с параметрами конфигурации. Эта метрика предоставляет агрегированный или отфильтрованный обзор каждого экземпляра конечной точки в пуле балансировщика нагрузки. Вы можете увидеть, как балансировщик нагрузки оценивает работоспособность вашего приложения на основе конфигурации проверки работоспособности. Средний
Число SYN Публичный и внутренний балансировщики нагрузки Подсистема балансировки нагрузки не прерывает подключения протокола TCP или не взаимодействует с потоками пакетов TCP или пользовательских данных (UDP). Потоки и их согласования всегда осуществляются между источником и экземпляром виртуальной машины. Чтобы оптимизировать устранение неполадок для всех сценариев протокола TCP, вы можете использовать счетчики пакетов SYN. С их помощью можно определить число попыток подключения TCP. Эта метрика указывает количество принятых пакетов TCP SYN. Сумма
Число подключений для преобразования сетевых адресов источника (SNAT) общедоступная подсистема балансировки нагрузки; Балансировщик нагрузки сообщает количество исходящих потоков, которые замаскированы под внешний интерфейс общедоступного IP-адреса. SNAT-порты являются ограниченным ресурсом. Эта метрика может дать представление о том, насколько сильно ваше приложение зависит от SNAT для исходящих потоков. Сообщается о счетчиках успешных и неудачных исходящих потоков SNAT. Счетчики можно использовать для устранения неполадок и оценки работоспособности исходящих потоков. Сумма
Выделенные SNAT-порты общедоступная подсистема балансировки нагрузки; Подсистема балансировки нагрузки сообщает количество портов SNAT, выделенных для каждого бекенд-экземпляра. Среднее.
Используемые порты SNAT общедоступная подсистема балансировки нагрузки; Балансировщик нагрузки сообщает количество портов SNAT, используемых для каждого бекэнд-экземпляра. Среднее
Количество байтов Общедоступная и внутренняя подсистемы балансировки нагрузки Подсистема балансировки нагрузки сообщает данные, обработанные на каждом интерфейсе. Вы можете заметить, что байты не распределяются равномерно между экземплярами серверной части. Это ожидаемо, так как алгоритм Load Balancer в Azure использует потоки. Сумма
Число пакетов Публичный и внутренний балансировщик нагрузки Подсистема балансировки нагрузки сообщает о пакетах, обработанных на каждом интерфейсе. Сумма

Примечание.

Метрики, связанные с пропускной способностью, такие как пакет SYN, число байтов и число пакетов, не будут записывать трафик во внутреннюю подсистему балансировки нагрузки через UDR (например, из NVA или брандмауэра).

Максимальные и минимальные агрегации недоступны для метрик числа SYN, числа пакетов, числа подключений SNAT и числа байтов. Не рекомендуется использовать агрегирование Count для метрик доступности пути к данным и состояния проверки работоспособности. Вместо этого используйте среднее значение для наилучшего представления данных о здоровье.

Просмотр метрик подсистемы балансировки нагрузки на портале Azure

Портал Azure предоставляет метрики подсистемы балансировки нагрузки на странице метрик. Эта страница доступна на странице конкретного ресурса подсистемы балансировки нагрузки и на странице Azure Monitor.

Примечание.

Azure Load Balancer не отправляет пробы работоспособности для выключенных виртуальных машин. При освобождении виртуальных машин балансировщик нагрузки прекратит предоставление метрик для этой версии. Метрики, недоступные, будут отображаться как пунктирная строка на портале или отображать сообщение об ошибке, указывающее, что метрики не могут быть получены.

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

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

    • На странице ресурсов подсистемы балансировки нагрузки выберите тип метрики в раскрывающемся списке.

    • На странице Azure Monitor выберите ресурс подсистемы балансировки нагрузки.

  2. Выберите соответствующий тип объединения метрик.

  3. При необходимости настройте требуемые фильтрацию и группирование.

  4. При необходимости настройте объединение и диапазон времени. По умолчанию время отображается в формате UTC.

Примечание.

Объединение времени важно при интерпретации определенных метрик при ежеминутной выборке данных. Если для параметра времени объединения задано значение 5 минут и для типа объединения метрик выбрано "Сумма", на диаграмме пять раз будут отображаться выделенные порты SNAT.

Рекомендация: при анализе типа агрегирования метрик Sum и Count рекомендуется использовать значение времени агрегирования больше одной минуты.

Получение многомерных метрик через API-интерфейсы программным образом

Инструкции по получению определений и значений многомерных метрик с помощью API см. в статье Azure Monitoring REST API walkthrough (Пошаговое руководство по REST API Azure Monitor). Эти метрики можно записать в учетную запись хранения, добавив параметр диагностики для категории "Все метрики".

Доступен ли путь данных для фронтенда балансировщика нагрузки?

Развернуть

Метрика доступности пути данных описывает работоспособность в регионе пути к вычислительному узлу, где находятся виртуальные машины. Метрика — это отражение работоспособности подсистемы балансировки нагрузки на основе конфигурации и инфраструктуры Azure. Используя эту метрику, можно:

  • отслеживать внешнюю доступность вашей службы;

  • изучать платформу, на которой развернута служба, и определять ее работоспособность; определять, является ли гостевая ОС или экземпляр приложения работоспособными;

  • определить, к чему относится событие: к службе или к базовой плоскости данных. Не путайте эту метрику с метрикой проверки состояния здоровья.

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

  1. Убедитесь, что выбран правильный ресурс подсистемы балансировки нагрузки.

  2. В раскрывающемся списке Метрика выберите Доступность пути к данным.

  3. В раскрывающемся списке Агрегирование выберите Среднее.

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

Метрика создается службой проверки в регионе, который имитирует трафик. Служба проверки периодически создает пакет, соответствующий фронтальному интерфейсу и правилу балансировки нагрузки вашего развертывания. Затем пакет проходит по региону от источника к узлу виртуальной машины в серверном пуле. Инфраструктура подсистемы балансировки нагрузки выполняет те же операции балансировки нагрузки и преобразования, что и для остального трафика. После прибытия пробы на узел, где находится виртуальная машина в серверном пуле, узел создает ответ на службу проверки. Ваша виртуальная машина не видит этот трафик.

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

Метрика доступности пути данных может быть понижена по следующим причинам:

  • В вашем развертывании отсутствуют исправные виртуальные машины в пуле серверов.

  • произошел сбой инфраструктуры.

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

Для большинства сценариев используйте способ агрегации Среднее.

Отвечают ли серверные экземпляры для моего Load Balancer на пробы?

Развернуть

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

Чтобы получить метрику статуса проверки работоспособности для ресурсов балансировщика нагрузки:

  1. Выберите метрику Состояние пробы работоспособности с типом агрегации Среднее.

  2. Примените фильтр для соответствующего интерфейсного IP-адреса или порта (или обоих вместе).

Проверки здоровья прерываются по следующим причинам:

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

  • Группа безопасности сети, брандмауэр гостевой ОС виртуальной машины или фильтры уровня приложений не разрешают трафик пробы работоспособности.

Для большинства сценариев используйте агрегацию Среднее.

Как проверить статистику исходящего подключения?

Расширить

Метрика подключений SNAT предоставляет сведения о числе успешных и неудачных подключений для исходящих потоков.

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

Чтобы получить статистику по подключениям SNAT, сделайте следующее:

  1. Выберите тип метрики SNAT Connections (Подключения SNAT) и тип агрегирования Сумма.

  2. Сгруппируйте подключения SNAT по состоянию подключения (успешные и неудачные), число которых будет представлено разными линиями.

Как проверить использование и выделение портов SNAT?

Развернуть

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

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

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

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

  2. Выберите Используемые порты SNAT и/или Выделенные порты SNAT в качестве типа метрики и Среднее в качестве объединения.

    • По умолчанию эти метрики — это среднее количество портов SNAT, выделенных или используемых каждой серверной виртуальной машиной или масштабируемым набором виртуальных машин. Они соответствуют всем внешним общедоступным IP-адресам, сопоставленным с подсистемой балансировки нагрузки, агрегированным по протоколу TCP и UDP.

    • Чтобы просмотреть все порты SNAT, используемые или выделенные для подсистемы балансировки нагрузки, используйте объединение метрик Сумма.

  3. Фильтрация по определенному Типу протокола, набору Серверных IP-адресов и (или) Интерфейсных IP-адресов.

  4. Для мониторинга состояния серверной или клиентской инстанции примените разделение.

    • Обратите внимание, что разделение на части позволяет отображать только одну метрику за раз.
  5. Например, чтобы отслеживать использование SNAT для TCP-потоков на компьютере, выполните объединение по Среднему, выполните разделение по серверным IP-адресам и отфильтруйте по Типу протокола.

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

Развернуть Метрика пакетов SYN предоставляет сведения о числе принятых или отправленных пакетов TCP SYN (для исходящих потоков), связанных с определенным внешним интерфейсом. Эта метрика позволяет проанализировать попытки подключения TCP к вашей службе.

Дополнительные сведения об исходящих подключениях см. в разделе Преобразование исходных сетевых адресов (SNAT) для исходящих подключений.

Для большинства сценариев используйте тип статистической обработки Сумма.

Как проверить потребление пропускной способности сети?

Развернуть

Метрика счетчиков байтов и пакетов описывает объем байтов и пакетов, которые отправляются или принимаются вашей службой на каждом внешнем интерфейсе.

Для большинства сценариев используйте тип статистической обработки Сумма.

Чтобы получить статистику количества байтов или пакетов, сделайте следующее:

  1. Выберите тип метрики Bytes Count (Количество байтов) и (или) Packet Count (Количество пакетов), а также тип объединения Сумма.

  2. Выполните одно из приведенных ниже действий.

    • Примените фильтр для определенного внешнего IP-адреса, внешнего порта, внутреннего IP-адреса или внутреннего порта.

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

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

Развернуть

Сочетание метрик доступности пути к данным и состояния проверки работоспособности на одной диаграмме позволяет определить, где искать проблему, и решить её. Благодаря этой информации вы можете удостовериться в том, что Azure работает правильно. Кроме того, с помощью этих сведений можно достоверно определить, что является первопричиной проблемы: конфигурация или приложение.

Вы можете использовать метрики пробы работоспособности, чтобы понять, как Azure рассматривает работоспособность вашего развертывания в соответствии с предоставленной вами конфигурацией. Просмотр проверок состояния — отличный первый шаг при мониторинге или выявлении причины.

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

Объединение метрик доступности пути к данным и состояния проверки работоспособности.

Рисунок. Объединение метрик доступности канала данных и состояния мониторинга работоспособности

На диаграмме представлена следующая информация:

  • Инфраструктура, в которой размещены виртуальные машины, была недоступна и в начале диаграммы составляла 0 %. Позднее инфраструктура стала работоспособной и ВМ стали доступны, а на сервере были размещены несколько виртуальных машин. Синяя линия отображает доступность пути данных, которая впоследствии стала 100 %.

  • Состояние пробы работоспособности, обозначенное фиолетовой трассировкой, равно 0 % в начале диаграммы. Кругом зеленого цвета отмечен период, когда система получила статус пробы работоспособности. В этот момент развертывание клиента смогло принять новые потоки.

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

Настройка оповещений для многомерных метрик

Azure Load Balancer поддерживает легко настраиваемые оповещения для многомерных метрик. Настройте пользовательские пороговые значения для конкретных метрик, чтобы активировать предупреждения с различными уровнями серьезности и повысить эффективность мониторинга ресурсов без вмешательства пользователя.

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

  1. Перейдите на страницу оповещений для подсистемы балансировки нагрузки

  2. Создание правила генерации оповещений

    1. Настройка условия генерации оповещений (Примечание: чтобы избежать шумных оповещений, рекомендуется настроить оповещения с типом агрегации, установленным на 'Средний', использовать пятиминутное окно данных и пороговое значение 95%).

    2. (Необязательно) Добавление группы действий для автоматического исправления

    3. Назначьте предупреждению степень серьезности, имя и описание, что обеспечивает возможность интуитивной реакции.

Входящее предупреждение о доступности

Примечание.

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

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

С помощью доступности пути к данным можно активировать предупреждения всякий раз, когда определенное правило балансировки нагрузки становится недоступным. Это предупреждение можно настроить, задав условие предупреждения для доступности пути к данным и разбиения по всем текущим и будущим значениям для внешнего порта и внешнего IP-адреса. Если задать для логики предупреждения значение меньше или равное 0, это предупреждение будет запускаться каждый раз, когда любое правило балансировки нагрузки перестанет отвечать. Задайте точность объединения и частоту оценки в соответствии с требуемой оценкой.

С состоянием пробы работоспособности можно предупредить, если заданный серверный экземпляр не сможет реагировать на пробу работоспособности в течение значительного времени. Настройте условие срабатывания оповещений, чтобы использовать метрику состояния проверки работоспособности и разделить по внутреннему IP-адресу и внутреннему порту, используя тип агрегирования Средний. Это гарантирует, что вы можете генерировать оповещения отдельно для способности каждого экземпляра обслуживать трафик на определенном порту.

Исходящее предупреждение о доступности

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

Для обнаружения сбоев исходящих подключений настройте предупреждение с помощью метрики количества подключений SNAT и фильтрации по значению Состояние соединения = Сбой. Используйте агрегацию Всего. Затем вы можете разделить это по IP-адресам серверной части, установив их для всех текущих и будущих значений, чтобы оповещения генерировались отдельно для каждого экземпляра серверной части, в случае если возникают сбои подключений. Установите пороговое значение больше нуля или большее число, если вы ожидаете сбои исходящих подключений.

Работая с использованными портами SNAT, вы можете предупредить о более высоком риске истощения SNAT и сбоя исходящего подключения. При использовании этого предупреждения убедитесь, что разделение выполняется по серверному IP-адресу и протоколу. Используйте Среднее агрегирование. Установите пороговое значение, превышающее процентное соотношение количества выделенных портов на экземпляр, который вы определили как ненадежный. Например, настройте предупреждение с низким уровнем серьезности, когда серверный экземпляр использует 75 % выделенных портов. Настройте предупреждение с высоким уровнем серьезности, когда будет задействовано 90 % или 100 % выделенных портов.

Состояние работоспособности ресурсов

Состояние работоспособности стандартных ресурсов балансировщика нагрузки можно узнать на странице Работоспособность ресурсов в разделе Монитор > Работоспособность служб. Показатель вычисляется каждые две минуты путем измерения доступности пути к данным, которая определяет, доступны ли интерфейсные конечные точки балансировки нагрузки.

Состояние работоспособности ресурсов Описание
В наличии Ресурс стандартной подсистемы балансировки нагрузки работоспособен и доступен.
Деградация Стандартная подсистема балансировки нагрузки имеет инициированные платформой или пользователем события, влияющие на производительность. Показатель доступности канала передачи данных показал уровень доступности ниже 90%, но больше 25% в течение как минимум двух минут. С этим статусом вы испытываете умеренное до серьезное влияние на производительность. Ознакомьтесь с руководством по устранению неполадок RHC, чтобы определить наличие событий, инициированных пользователем, которые негативно сказываются на доступности.
Недоступно Ваш стандартный балансировщик нагрузки не работает. Метрика доступности пути к данным сообщила, что уровень работоспособности был менее 25% в течение как минимум двух минут. При таком состоянии вы испытываете значительное влияние на производительность и/или отсутствие доступности для входящих подключений. Возможно, недоступность вызывают события на стороне пользователя или платформы. Ознакомьтесь с руководством по устранению неполадок RHC, чтобы определить наличие событий, инициированных пользователем, которые негативно влияют на доступность.
Неизвестно Состояние работоспособности для ресурса подсистемы балансировки нагрузки не было обновлено или не получило сведений о доступности пути к данным за последние 10 минут. Это временное состояние. Правильное состояние будет отображено сразу после получения данных.

Чтобы просмотреть работоспособность ресурсов стандартного общедоступного балансировщика нагрузки, выполните следующее:

  1. Выберите Монитор>Работоспособность службы.

  2. Выберите Работоспособность ресурсов и убедитесь, что выбран идентификатор подписки, а для типа ресурса установлено значение Load Balancer.

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

Общее описание состояния работоспособности ресурсов доступно в документации по работоспособности ресурсов.

Оповещения о состоянии ресурсов

Оповещения о здоровье ресурсов Azure могут уведомлять вас практически в реальном времени, когда состояние балансировщика нагрузки изменяется. Рекомендуется настроить оповещения о работоспособности ресурсов, чтобы уведомить вас о том, что ресурс подсистемы балансировки нагрузки находится в состоянии "Понижение" или "Недоступно".

При создании оповещений о работоспособности ресурсов Azure для Load Balancer Azure отправляет уведомления о работоспособности ресурсов в подписку Azure. Вы можете создавать и настраивать оповещения на основе:

  • Затронутая подписка
  • Затронутая группа ресурсов
  • Тип ресурса, на который это влияет (балансировщик нагрузки)
  • Конкретный ресурс (любой ресурс подсистемы балансировки нагрузки, для который вы решили настроить оповещение)
  • Состояние события затронутого ресурса Подсистемы балансировки нагрузки
  • Текущее состояние затронутого ресурса Подсистемы балансировки нагрузки
  • Предыдущее состояние затронутого ресурса Подсистемы балансировки нагрузки
  • Тип причины затронутого ресурса Подсистемы балансировки нагрузки

Вы также можете настроить, кому следует отправить оповещение:

  • Новая группа действий (которая может использоваться для будущих оповещений)
  • Существующая группа действий

Дополнительные сведения о настройке этих оповещений о работоспособности ресурсов см. в следующих статье:

Следующие шаги