Золотые сигналы SRE балансировщиков нагрузки

Вольный перевод Load Balancers’ SRE Golden Signals

Балансировщики нагрузки (Load Balacers, LB) являются ключевыми компонентами большинства современных систем, обычно их ставят перед приложениеми, но все чаще и внутри систем, поддерживающих контейнеры, службы сокетов, базы данных и многое другое.

Существует несколько популярных LB, поэтому рассматриваются три наиболее распространенных:

• HAProxy - любимый всем не облачный LB
• AWS ELB - эластичный баланс нагрузки
• AWS ALB - балансировщик нагрузки приложения
  Для Nginx см. Раздел «Веб-сервер».

Некоторые общие проблемы балансировщика нагрузки

Некоторые общие вещи для балансировки нагрузки, которые гораздо сложнее, чем веб-серверы для мониторинга.

Комбинированные или отдельные фронтенды

Есть два способа посмотреть на сигналы LB - от фронтенда или бэкенда. И для фронтенда у нас может быть несколько из них, например, для разных частей сайта, для API и т. Д.

Как правило, интересны сигналы в целом для LB и, следовательно, все фронтенды, хотя возможно также отслеживать каждый фронтенд отдельно, если на самом деле существуют отдельные системы для Web, App, API, Search и т.д. Это означает, что у нас будет отдельные сигналы для всего этого.

Следует обратить внимание, что некоторые системы имеют отдельные Listener / Backends для HTTP и HTTPS, но они обслуживают в основном одни и те же URL-адреса, поэтому обычно имеет смысл объединить их в одно объединенное представление, если это возможно.

Мониторинг серверов бэкенда в LB против веб-серверов.

У LB обычно есть несколько бэкендов, и также возможно получать сигналы для каждого бэкенда. В идеальном мире этого не требуется, поскольку возможно получать более качественные данные непосредственно с бэкендов серверных веб-серверов / приложений.

Однако, как видно в разделах «Веб-сервер» и «Сервер приложений», это не совсем так, поскольку мониторинг веб-сервера отстой. Это означает, что обычно легче и лучше получать сигналы серверного бэкэнда от LB, а не от самих веб-серверов.

HAProxy

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

Внимание - однопроцессорный против многопроцессного HAProxy

Большинство, если не все версии, HAProxy сообщают статистику для одного процесса, что хорошо для 99% случаев использования. Некоторые очень высокопроизводительные системы используют многопроцессорный режим, но это сложно контролировать, так как статистика выбирается случайным образом из одного процесса. Это может быть бардак, поэтому следует стараться избегать этого, если это возможно.

Внимание - сложность

Все полезные статистические данные HAProxy представляют собой данные относительно каждого Listener или бэкенд, что полезно, но затрудняет получение полной картины. У простых веб-сайтов или приложений обычно есть один (www.) Listener и бэкенд, но в более сложных системах обычно их довольно много. Легко собрать сотни метрик и запутаться.

Необходимо решить, следует ли отслеживать сигнал для каждого Listener / фронтенда или суммировать их, чтобы получить общее представление - это зависит от того, насколько унифицирована система. Как отмечалось выше, обычно удобно объединить HTTP и HTTPS, если они обслуживают одни и те же URL-адреса. Однако, если есть отдельные Web, App, API, Search и т.д., то скорее всего, то также будет удобно разделить и сигналы.

HAProxy, как мониторить?

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

• Получение данных CSV со встроенной веб-страницы.
• Использование инструмента CLI.
• Использование Unix Socket.
  См. документацию HAProxy для получения подробной информации о том, как получить доступ к каждому из них, поскольку это сильно зависит от системы мониторинга и инструментов.

Отображая сигналы в HAProxy, наблюдается некоторая сложность:

• Request Rate - количество запросов в секунду, которые возможно получить двумя способами:
  1. Хорошо запрашивать счетчик REQ_TOT, поскольку в качестве счетчика он не пропустит скачки, но следует выполнить дельта-обработку, чтобы получить RATE. Счетчик не доступен для каждого сервера, поэтому вместо этого следует использовать RATE для серверов (хотя это только за последнюю секунду).
  2. Возможно использовать REQ_RATE (req / sec), но это только в течение последней секунды, следовательно есть возможность потерять пики данных таким образом, особенно если мониторинг получает данные только каждую минуту или еще реже.
• Error Rate - Response Errors, ERESP, который предназначен для ошибок, поступающих от серверной части. Это счетчик, поэтому следует выполнить дельта-обработку. Но следует быть осторожным, поскольку в документах говорится, что он включает «ошибку записи в клиентском сокете», поэтому неясно, к какому типу ошибок клиента (например, в мобильных телефонах) это может относиться. Также возможно получить данные для каждого внутреннего сервера.

Для получения более подробной информации и только ошибок HTTP следует просто получать количество ошибок 4xx и 5xx, поскольку они будут наиболее чувствительны к тому, что видят пользователи. Ошибки 4xx, как правило, не являются проблемами клиентов, но если они внезапно возникают, это, как правило, из-за плохого кода или какой-либо атаки. Мониторинг ошибок 5xx имеет решающее значение для любой системы.

Возможно, будет полезно посмотреть ошибки запросов, EREQ, хотя этот счетчик включает в себя закрытие со стороны клиента, что может создавать много лишних данных, особенно в медленных или мобильных сетях. Только для фронтенда.

• Latency - время отклика RTIME (для каждого бэкэнда), которое вычисляется как среднее значение за последние 1024 запроса (следовательно, может пропустить скачки в загруженных системах и быть шумным при запуске). Для этих предметов нет данных счетчиков. Этот счетчик также доступен для каждого сервера.
• Saturation - использует количество запросов в очереди, QCUR. Счетчик доступен как для фронтендов (для запросов, еще не назначенных серверу), так и для каждого бэкенда (еще не отправленного на сервер).
  Вероятно, будет полезно получать сумму этих значений для общей насыщенности и для каждого сервера, если отслеживается насыщенность сервера на этом уровне (см. Раздел «Веб-сервер»). Если счетчик используется для каждого сервера, то возможно отслеживать насыщенность каждого бэкенда (хотя следует понимать, что сам сервер, вероятно, тоже стоит в очереди, поэтому любая очередь в LB указывает на серьезную проблему).
• Utilization - HAProxy, как правило, не исчерпывает свою производительность, если только он действительно не исчерпывает процессор, есть возможность отслеживать фактические сессии SCUR / SLIM.

AWS ELB & ALB

Балансировщики нагрузки AWS ELB / ALB чрезвычайно популярны для любых систем на базе AWS. Они начались с простых ELB и превратились в полноценные и мощные LB, особенно с введением новых ALB.

Как и большинство сервисов AWS, метрики извлекаются с помощью комбинации Cloud Watch и логов, передаваемых в S3. С первым довольно легко справиться, но работа с журналами, расположенными в S3, всегда немного сложна, поэтому следует стараться избегать их (отчасти потому, что невозможно на самом деле выполнять обработку в реальном времени или оповещать о них).

Описанное ниже работает не только для HTTP, но у ELB & ALB есть дополнительные метрики для соединений на основе TCP, которые возможно использовать аналогичными способами.
Подробности доступны в документации ELB CloudWatch.

Classic ELB

Метрики ELB доступны для ELB в целом, но, к сожалению, не для группы бэкендов или одного бэкенда. Следует обратить внимание, что если используется только один бэкенд на AZ, то возможно использовать AZ Dimensional Filter.

Все сигналы для ELB берутся из CloudWatch. Следует обратить внимание, что sum() части метрик являются статистическими функциями CloudWatch.

• Request Rate - количество запросов в секунду, которое получается из показателя суммы (RequestCount), деленного на настроенное время выборки CloudWatch, 1 или 5 минут. Также включает в себя ошибки.
• Error Rate - следует добавить две метрики: sum(HTTPCode_Backend_5XX) и sum(HTTPCode_ELB_5XX), которые фиксируют сгенерированные бэкендом и LB ошибки (важно для подсчета недоступности бэкэнда и отклонений из-за переполненной очереди). Также возможно добавить sum(BackendConnectionErrors).
• Latency - среднее от задержек. Тут все просто.
• Saturation - max(SurgeQueueLength), которое получает запросы в очередях бэкенда. Следует обратить внимание, что этот сигнал сфокусирован исключительно на насыщении бэкэнда, а не на самом LB, который может насыщаться по процессору (до его автоматического масштабирования), но, похоже, сейчас нет способа контролировать это. Также возможно отслеживать и оповещать о sum(SpilloverCount), которая будет больше 0, когда LB насыщен и отклоняет запросы, потому что Surge Queue переполнен. Как и в случае с ошибками 5xx, это очень серьезная ситуация.
• Utilization - нет хорошего способа получить данные об использовании на ELB, так как они автоматически масштабируются, так что их внутреннюю емкость сложно получить (хотя было бы неплохо получить ее до масштабирования, например, когда ситуация быстро изменяется в разные стороны, идет всплеск или падение нагрузки).

Предостережение для ELB Percentiling Persons. Если делать процентили и статистику по этим сигналам, обязательно следует ознакомиться с предостережениями и проблемами в разделе «Статистика для классических показателей балансировки нагрузки» документации CloudWatch.

New ALB

Данные ALB очень похожи на ELB, с более доступными данными и несколькими различиями в названиях метрик.

Метрики ALB доступны для ALB в целом и для целевой группы (через Dimension Filtering), что позволяет получать данные для заданного набора бэкендов вместо непосредственного мониторинга серверов Web / App. Данные для каждого бэкенда недоступны из ALB (хотя возможно фильтровать по AZ, который будет по каждому серверу, если есть только один целевой бэкенда на AZ).

Все сигналы для АLB берутся из CloudWatch. Следует обратить внимание, что sum() части метрик являются статистическими функциями CloudWatch.

• Request Rate - количество запросов в секунду, которое получается из показателя суммы (RequestCount), деленного на настроенное время выборки CloudWatch, 1 или 5 минут. Также включает в себя ошибки.
• Error Rate - следует добавить две метрики: sum(HTTPCode_Backend_5XX) и sum(HTTPCode_ALB_5XX), которые фиксируют сгенерированные бэкендом и LB ошибки (важно для подсчета недоступности бэкэнда и отклонений из-за переполненной очереди). Также возможно добавить sum(TargetConnectionErrorCount).
• Latency - average(TargetResponseTime). Тут все просто.
• Saturation - похоже, нет никакого способа получить какие-либо данные очереди из ALB, поэтому следует использовать sum(RejectedConnectionCount), которая подсчитывает отклонения, когда ALB достигает своего максимального количества соединений.
• Utilization - нет хорошего способа получить данные об использовании на ALB, так как они автоматически масштабируются, так что их внутреннюю емкость сложно получить (хотя было бы неплохо получить ее до масштабирования, например, когда ситуация быстро изменяется в разные стороны, идет всплеск или падение нагрузки). Следует обратить внимание, что возможно отслеживать sum(ActiveConnectionCount) в сравнении с максимальным количеством подключений, которое следует получить вручную или из AWS Config.

Предостережение для ALB Percentiling Persons. Если делать процентили и статистику по этим сигналам, обязательно следует ознакомиться с предостережениями и проблемами в разделе «Статистика для классических показателей балансировки нагрузки» документации CloudWatch.