Состояние NGINX Stub: мониторинг активности веб-сервера в режиме реального времени

Что показывает статус «Stub» в NGINX

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

При этом нужно различать два вида величин: одна Снимок показывает, например, сколько клиентских соединений активны в момент запроса. Общие счетчики, такие как requests в свою очередь, показывают, сколько запросов было зарегистрировано в целом. Только сравнение нескольких показаний счетчика за известные промежутки времени позволяет сделать вывод о частоте запросов.

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

Статус «Stub» не разбивает данные по виртуальным сайтам или запрашиваемым URL-адресам. Если одна установка обслуживает несколько сайтов, по данному показателю невозможно определить, какой из них стал причиной роста. При наличии нескольких экземпляров NGINX вам следует фиксировать их значения отдельно и однозначно соотносить их.

Сам по себе запрос страницы состояния также представляет собой HTTP-запрос и незначительно влияет на отслеживаемые счетчики. Это следует учитывать при интерпретации небольшого объема запросов или очень частых запросов. Один-единственный запрос в любом случае дает лишь фрагментарную картину; только динамика показывает, изменилась ли активность.

Различать связи и запросы

Значение Активные соединения включает активные клиентские соединения, в том числе соединения в режиме ожидания. Таким образом, он учитывает не только те соединения, по которым в данный момент передается ответ. Состояния «Reading», «Writing» и «Waiting» помогают интерпретировать это общее число, но не отражают ни загрузку ЦП, ни количество запущенных приложений.

При поступлении запроса соединение находится в состоянии «Reading», пока NGINX считывает заголовок запроса. Затем состояние может перейти в «Writing», когда NGINX обрабатывает или записывает ответ. Это не означает, что в течение всего этого времени данные действительно передаются клиенту: в это время может также входить ожидание ответа от вышестоящего сервера.

Если после ответа на запрос соединение остается открытым для дальнейших запросов, оно может рассматриваться как Ожидание появляются. Это состояние включает неактивные клиентские соединения, ожидающие следующего запроса. Поэтому высокое значение параметра «Waiting» само по себе не свидетельствует о перегрузке; оно может также соответствовать режиму работы с большим количеством повторно используемых соединений.

Соединения и запросы — это разные величины: по одному соединению с поддержкой Keepalive может проходить несколько запросов подряд. В HTTP/2 через одно соединение можно передавать несколько запросов. Поэтому по количеству открытых соединений невозможно определить фиксированное количество запросов, и счетчик requests не обязательно должен увеличиваться в той же пропорции, что и счетчики соединений.

Для практической оценки целесообразно провести сравнение по нескольким запросам: если показатель «Waiting» растет, а время отклика и количество ошибок остаются в пределах нормы, это, в первую очередь, просто наблюдение, а не повод для тревоги. О том, как настроить повторное использование и определить его пределы, рассказывается в статье по теме Запросы Keepalive в NGINX.

Проверить модуль и версию

Для работы со статусом Stub тебе потребуется установка NGINX с модулем ngx_http_stub_status_module, доступ к его настройкам, а также возможность впоследствии запросить адрес защищенного конечного узла из предусмотренного сетевого пространства. Этот модуль по умолчанию не включается в сборку NGINX. Наличие этого модуля в дистрибутиве зависит от конкретного пакета и должно проверяться локально.

Проверьте в терминале версию и параметры конфигурации бинарного файла NGINX, который фактически используется службой. Следующая команда отображает эту информацию; среди параметров указаны --with-http_stub_status_module на соответствующий параметр сборки.

nginx -V

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

Версия также влияет на написание директивы. Начиная с NGINX 1.7.5 stub_status используется без аргументов; в более старых версиях требовался любой аргумент, например on. Указание версии является информацией о совместимости, а не предположением о том, какая версия установлена в вашей системе.

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

Настройка защищенного конечного пункта состояния

Для локального запроса статуса ты можешь использовать отдельный Слушатель loopback настроить. В приведенном ниже примере показан файл конфигурации для существующего http-контекст, а не терминальная команда. Для этого необходимо, чтобы модуль состояния заглушки был доступен и чтобы примерный порт 8088 по указанному адресу ещё не был занят какой-либо другой службой.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

    location = /stub_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

Связь с 127.0.0.1 ограничивает этот прослушиватель локальным IPv4-интерфейсом обратной связи. Параметр exact-location определяет только указанный путь; директива stub_status предоставляет там данные о состоянии. Таким образом, доступ к прослушивателю через другие интерфейсы IPv4 невозможен, независимо от того, являются ли остальные веб-сайты общедоступными.

Die Правила доступа дополняют правило доступа: NGINX проверяет их по порядку до первого совпадения. Разрешен локальный IPv4-адрес, все остальные адреса отклоняются. Поскольку в этом блоке (location) содержатся собственные правила, правила доступа из вышестоящего контекста дополнительно не наследуются. Поэтому проверьте полную конфигурацию, прежде чем использовать этот пример.

В случае с контейнерами решающую роль играет сетевое пространство: экспортер, расположенный в отдельном контейнере, получает доступ через собственное localhost Как правило, это не интерфейс loopback контейнера NGINX. Для удалённого запроса требуется специально спланированный частный путь соединения и соответствующие меры контроля доступа. Не следует просто открывать страницу состояния для общего доступа; она содержит информацию об эксплуатации.

Проверить конфигурацию и получить информацию о состоянии

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

nginx -t

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

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

curl -i http://127.0.0.1:8088/stub_status

Ожидается успешный HTTP-ответ со статусом в виде Текст, а не в формате JSON. В случае ошибки код статуса и журналы NGINX помогут сузить круг поиска. Однако успешный локальный запрос лишь показывает, что этот путь доступа работает: он не доказывает, что никакая другая конфигурация не делает конечную точку доступной извне.

Считывание значений состояния и расчет скоростей

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

Из счетчика requests можно рассчитать среднее Доля запросов Рассчитать для интервала: вычти первое значение из второго и раздели разницу на количество прошедших секунд. Наглядный пример расчёта (не измерение): если значение за 60 секунд увеличивается с 12 000 до 12 600, то 600, деленное на 60, даёт в среднем 10 запросов в секунду.

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

Если вы сравниваете интервалы разной длительности, учитывайте фактически прошедшее время, а не запланированный интервал между запросами. Например, для запроса с задержкой в две минуты требуется другой делитель, чем для запроса через одну минуту. Более длительный период наблюдения в большей степени сглаживает краткосрочные колебания; короткие интервалы делают изменения более заметными, но при этом увеличивают долю запросов о статусе.

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

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

Анализ ошибок и ограничений

Если конечная точка состояния возвращает статус HTTP 403, сначала проверьте фактический исходный адрес, поступающий в NGINX, и правила доступа для данного местоположения. allow и deny оцениваются по порядку до первого совпадения. Собственные правила локации при необходимости заменяют унаследованные правила; они не дополняют их автоматически.

При ошибке HTTP 404 сначала следует проверить другие аспекты: верны ли порт и прослушиватель, запрошенный путь и выбранный блок серверов? Кроме того, проверьте, действительно ли заданная конфигурация стала активной после перезагрузки. Успешный локальный вызов через другой порт или по другому пути не доказывает, что был обращён запрос именно к нужному ресурсу.

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

Для текущего анализа ошибок целесообразно сравнить общие счетчики принимает и обрабатывает. Обычно эти значения совпадают. Если разница между ними увеличивается, это может быть связано с превышением лимита ресурсов; однако само по себе сравнение значений счетчиков не позволяет установить ни конкретную причину, ни количество отклоненных HTTP-запросов. Поэтому при расследовании следует учитывать журналы ошибок и настройки.

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

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

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

Анализ хода событий и классификация проблем на этапе добычи

Один запрос статуса отражает только момент времени. В то же время повторные запросы с фиксированными интервалами помогают определить, превышают ли показатели состояния соединения нормальный уровень или снижаются ли они после пика. Отслеживайте несколько экземпляров NGINX отдельно и фиксируйте, какой экземпляр стоит за каждым временным рядом; в противном случае переключение между конечными точками может исказить динамику.

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

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

Для выявления причин помогут дополнительные данные: журналы доступа и зарегистрированные времена отклика серверов выше по цепочке показывают, какие запросы и бэкэнды вызывают подозрения; журналы ошибок содержат указания на неудачные подключения. Если речь идет о нагрузке на ЦП или память, вам понадобятся соответствующие системные метрики. Если проблема связана с повторяющимися попытками установления соединения с бэкендом, статья о NGINX: Keepalive на стороне исходного сервера настройка многократно используемых соединений с вышестоящими серверами.

От статуса к мониторингу

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

Официальный Экспортер NGINX для Prometheus Для этого предусмотрен отдельный компонент: он запрашивает статус у Stub и предоставляет данные в виде метрик Prometheus. Затем Prometheus запрашивает конечную точку экспортера. Необходимо запланировать доступность и ограничения доступа для обоих путей, то есть как к конечной точке статуса, так и к выводу метрик экспортера.

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

Дополнительный сбор данных не превращает базовые показатели в подробные метрики времени отклика или классов HTTP-статусов. Для анализа медленных URL-адресов, ошибочных ответов или отдельных источников трафика необходимы соответствующие журналы доступа и дополнительные телеметрические данные. Кроме того, более подробная API NGINX Plus Следует проводить различие между «Stub Status» в NGINX и «Open Source»; их доступность и настройка не являются взаимозаменяемыми.

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

Пороги срабатывания сигналов тревоги должны определяться исходя из нормального поведения конкретного экземпляра и целей службы, а не на основе общих значений для показателей «Waiting» или «Writing». Сравните отклонения от нормы с задержками, ошибками и доступными ресурсами и проверьте, действительно ли тревога требует принятия мер. Таким образом, отдельный показатель становится поводом для целенаправленного исследования, а не для поспешного диагноза.

При планировании сигналов тревоги учитывайте также возможность сбоя канала сбора данных: отсутствие данных — это не то же самое, что отсутствие запросов или отсутствие соединений. Отдельная проверка доступности помогает отличить сбой запроса от ситуации, когда активность действительно низкая. Кроме того, определите, кто будет обрабатывать тревогу и какие дополнительные данные должны быть доступны для диагностики.