Диагностика Load Balancer (цен. категория "Стандартный") с помощью метрик, оповещений и сведений о работоспособности ресурсов

Azure Load Balancer (цен. категория "Стандартный") предоставляет такие возможности диагностики:

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

  • Работоспособность ресурсов. Состояние работоспособности ресурсов Load Balancer доступно на странице "Работоспособность ресурсов" в разделе "Монитор". Эта автоматическая проверка информирует о текущей доступности ресурса Load Balancer. Эта статья содержит краткий обзор этих возможностей и способов их использования для Load Balancer уровня "Стандартный".

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

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

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

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

Примечание

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

Примечание

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

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

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

Чтобы просмотреть метрики для ресурсов Load Balancer уровня "Стандартный", сделайте следующее:

  1. Перейдите к странице решения "Метрики" и выполните одно из следующих действий:
    • На странице ресурсов подсистемы балансировки нагрузки выберите тип метрики в раскрывающемся списке.
    • На странице Azure Monitor выберите ресурс подсистемы балансировки нагрузки.
  2. Выберите соответствующий тип объединения метрик.
  3. При необходимости настройте требуемые фильтрацию и группирование.
  4. При необходимости настройте объединение и диапазон времени. По умолчанию время отображается в формате UTC.

Примечание

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

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

Metrics for Standard Load Balancer

Рисунок. Метрика доступности пути к данным для Load Balancer (цен. категория "Стандартный")

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

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

Доступен ли путь к данным для внешнего интерфейса Load Balancer?

Развернуть

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

  • отслеживать внешнюю доступность вашей службы;
  • получить более подробную информацию о том, нормально ли функционирует платформа, на которой развернута служба, и узнать состояние работоспособности гостевой ОС или экземпляра приложения;
  • определить, к чему относится событие: к службе или к базовой плоскости данных. Не путайте эту метрику с состоянием пробы работоспособности ("Доступность серверного экземпляра").

Чтобы получить сведения о доступности пути к данным для ресурсов Load Balancer уровня "Стандартный", сделайте следующее:

  1. Убедитесь, что выбран правильный ресурс подсистемы балансировки нагрузки.
  2. В раскрывающемся списке Метрика выберите Доступность пути к данным.
  3. В раскрывающемся списке Агрегирование выберите Среднее.
  4. Кроме того, добавьте фильтр по интерфейсному IP-адресу или порту в качестве измерения с необходимым внешним IP-адресом или портом, а затем сгруппируйте их по выбранному измерению.

VIP probing

Рисунок. Сведения о проверке интерфейсного IP-адреса Load Balancer

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

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

Сбой доступности пути к данным возникает по следующим причинам:

  • в серверном пуле вашего развертывания не осталось исправных виртуальных машин;
  • произошел сбой инфраструктуры.

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

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

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

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

Чтобы получить сведения о состоянии пробы работоспособности для ресурсов Load Balancer (цен. категория "Стандартный"), сделайте следующее:

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

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

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

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

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

Развернуть Метрика подключений SNAT предоставляет сведения о числе успешных и неудачных подключений для [исходящих потоков](./load-balancer-outbound-connections.md).

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

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

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

SNAT connection

Рисунок. Количество подключений SNAT для Load Balancer

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

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

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

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

  1. Задайте для объединения времени диаграммы значение 1 минута, чтобы обеспечить отображение нужных данных.
  2. Выберите Used SNAT Ports (Используемые порты SNAT) и/или Allocated SNAT Ports (Выделенные порты SNAT) в качестве типа метрики и Среднее в качестве объединения.
    • По умолчанию эти метрики определяют среднее количество портов SNAT, выделенных для каждой серверной виртуальной машины или масштабируемого набора виртуальных машин, которые соответствуют всем интерфейсным общедоступным IP-адресам, сопоставленным с Load Balancer, объединенным по протоколам TCP и UDP.
    • Чтобы просмотреть все порты SNAT, используемые или выделенные для подсистемы балансировки нагрузки, используйте объединение метрик Сумма
  3. Фильтрация по определенному Типу протокола, набору Серверных IP-адресов и (или) Интерфейсных IP-адресов.
  4. Для мониторинга работоспособности серверного или интерфейсного экземпляра примените разделение.
    • Обратите внимание, что одно разделение позволяет отображать только одну метрику за раз.
  5. Например, чтобы отслеживать использование SNAT для TCP-потоков на компьютере, выполните объединение по Среднему, выполните разделение по серверным IP-адресам и отфильтруйте по Типу протокола.

SNAT allocation and usage

Рисунок. Выделение и использование портов TCP SNAT по среднему для набора серверных виртуальных машин

SNAT usage by backend instance

Рисунок. Использование TCP-портов SNAT серверным экземпляром

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

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

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

SYN connection

Рисунок. Количество подключений SYN для Load Balancer

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

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

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

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

  1. Выберите тип метрики Bytes Count (Количество байтов) и (или) Packet Count (Количество пакетов), а также тип объединения Сумма.
  2. Выполните одно из приведенных ниже действий.
    • Примените фильтр к определенному интерфейсному IP-адресу, интерфейсному порту, IP-адресу серверной части или порту серверной части.
    • Получите общую статистику для ресурсов подсистемы балансировки нагрузки без какой-либо фильтрации.

Byte count

Рисунок. Количество байтов Load Balancer

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

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

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

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

Combining Data Path Availability and Health Probe Status metrics

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

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

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

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

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

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

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

  1. Перейдите в подколонку предупреждений для подсистемы балансировки нагрузки
  2. Создание правила генерации оповещений
    1. Настройка условия предупреждения
    2. (Необязательно) Добавление группы действий для автоматического исправления
    3. Назначение предупреждению уровня серьезности, имени и описания, что позволяет интуитивно понятно реагировать

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

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

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

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

Можно также оповещать на уровне серверного пула, не прерывая ни одного измерения и не используя тип объединения Среднее. Это позволит настроить правила оповещений, такие как предупреждение, если 50 % элементов серверного пула находятся в неработоспособном состоянии.

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

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

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

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

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

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

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

Чтобы просмотреть работоспособность ресурсов общедоступной службы Load Balancer уровня "Стандартный", сделайте следующее:

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

    Monitor page

    Рисунок. Ссылка "Работоспособность службы" в Azure Monitor

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

    Resource health status

    Рисунок. Выбор ресурса для представления работоспособности

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

    Load Balancer health status

    Рисунок. Представление работоспособности ресурса Load Balancer

Общее описание состояния работоспособности ресурсов доступно в документации RHC. Состояния Azure Load Balancer перечислены в следующей таблице:

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