Привет! В этой статье мы поговорим о новом модуле для nginx, цель которого — собирать и предоставлять пользователю статистику обращений серверов к бэкендам.
Ниже под катом подробности, примеры использования, скриншоты, ссылки, а также история создания.
История
Не так давно отдел поддержки серверов нашей компании пришел к выводу, что пора что-то менять.Точнее, нужно было решить проблемы с распределением возросшей нагрузки – наши фронты стали с трудом справляться со своей задачей.
С помощью JMeter мы протестировали на стенде nginx, HAProxy, Brocade Server Iron ADX 1000 и ряд других балансировщиков.
Главным критерием выбора была возможность терминировать около 50 тысяч одновременных SSL-сессий в пиковые периоды.
После длительного тестирования по разным причинам все варианты, кроме nginx и его аппаратного конкурента Brocade Server, были отброшены, и в итоге остался только первый из них.
При прочих равных, вероятно, решающими факторами в пользу nginx стали гибкость конфигурации и легкость.
Проблема
Раньше мы использовали HAProxy в качестве балансировщика на некоторых фронтах.После перехода на nginx стало понятно, что нам не хватает какой-либо информативной статистики по работе с бэкендами.
Дело в том, что у HAProxy была такая статистика, и с ее помощью мы отслеживали проблемы, возникающие на бэкендах, и оперативно на них реагировали.
С новым балансировщиком мы оказались без этой статистики, как будто у нас нет рук.
stub_status и подобные модули нам не подошли, поскольку их функция — показывать статистику не в разрезе отдельного апстрима, а сервера в целом.
Мы хотели, чтобы для каждого апстрима/бэкэнда были данные о таких параметрах, как количество запросов к каждому серверу и номеру Ошибки HTTP 499/500/503 и TCP , а позже этот список расширился.
Решение
Поскольку готовых решений нашей проблемы мы не нашли, была предпринята попытка написать модуль, который бы предоставлял необходимую информацию в наглядном виде.Попытка, как мне кажется, удалась, и результатом работы стал модуль статы ( статистика разведки и добычи ).
Какая статистика?
Используя ustats, вы можете вести статистику по таким показателям серверной части, как- Количество запросов .
- Количество ошибок 499/500/503 .
- Количество таймаутов чтения и записи HTTP .
- Количество ошибок TCP-соединения .
- Таймер сбоя (fail_timeout) .
В nginx этот параметр настраивается одноименной директивой и определяет период времени, в течение которого должно произойти несколько неудачных обращений к бэкенду подряд (точное количество указывается директивой max_fails), по истечении которого бэкенд отключается.
помещен в черный список, и никаких вызовов к нему не происходит в течение другого периода времениfail_timeout. Обычно администратор сам в курсе, какие таймауты прописаны в конфиге его сервера, но все же иметь их перед глазами показалось хорошей идеей.
- Количество неудачных попыток работы с бэкендом (счёт неудач) .
Внутри nginx для каждого бэкенда ведется счетчик неудачных попыток.
Это число показывает, сколько раз в течение таймаута сбоя nginx пытался постучать на бэкенд и не удалось (что считается сбоем, см.
описание директивы proxy_pass).
Принцип работы счетчика достаточно прост. Когда nginx собирается перенаправить запрос, он сначала смотрит, какой бэкенд следующий в очереди (если мы говорим о циклической балансировке), проверяет его статус (внесен в черный список или нет), и если бэкенд «игнорируется», сервер смотрит на момент своей последней неудачи.
Если с этого момента времяfail_timeout уже прошло, то счетчик неудачных попыток для бэкенда сбрасывается и отправляется запрос.
Если бэкенд не был занесен в черный список, то запрос отправляется сразу, а счетчик может обнуляться в зависимости от времени, прошедшего с момента первого неудачного запроса.
- Максимальное количество неудачных запросов (max_fails) .
Определяет порог количества неудачных попыток работы с бэкендом, при достижении которого он помещается в черный список на периодfail_timeout. Этот параметр также прописан в конфиге nginx, и мы для наглядности добавили его отображение в статистике.
- Время последнего неудачного запроса в бэкэнд. Его цель должна быть ясна из предыдущих абзацев :)
Дополнительные функции
Ustats также может показать, какие серверы в настоящее время находятся в черном списке.Замечу, что под бэкендом мы подразумеваем не то, что указано в конфиге nginx директивой сервера, а непосредственно адрес, в который резолвится имя, указанное в директиве.
Если за одним именем в DNS стоит несколько адресов, модуль показывает их как отдельные бэкенды (при этом не забывая указать, от какого имени они пришли).
В дополнение к выделению серверов, занесенных в черный список, ustats выделяет отключенные серверы, т. е.
описанные в конфигурации nginx как
.И наконец, с помощью модуля можно включать и выключать серверы из топологии nginx прямо во время ее работы, через веб-интерфейс.server some.server.name down; .
Изменения не сохраняются в конфиге и призваны упростить обслуживание.
работа, предполагающая временное отключение бэкэндов.
Хочу вас предупредить: usstat не обеспечивает никакой защиты от несанкционированного выполнения данного действия, поэтому вам придется самостоятельно следить за тем, чтобы случайный человек не исключил из работы половину бэкендов на вашем сайте :)
Случаи использования
Их двое.Во-первых, модуль предоставляет всю статистику в виде веб-страницы с таблицей, которую можно отобразить в любом месте, например stub_status:
location /ustats {
Теги: #Nginx #статистика #апстрим
-
2Much Отмечает 9 Лет В Бизнесе
19 Oct, 24 -
Как Хабрацы Пишут Php-Код?
19 Oct, 24 -
Игры Начинаются И Побеждают
19 Oct, 24
