Не секрет, что штатные возможности мониторинга Nginx довольно скромны. Решалась эта задача различными способами: либо парсингом логов, либо сторонними модулями. При создании Angie эту проблему решили радикально и сразу несколькими способами. Начнём с исторического модуля stub_status.
Навигация по циклу
Настройка location в Angie. Разделение динамических и статических запросов.
Перенаправления в Angie: return, rewrite и примеры их применения.
Сжатие текста в Angie: статика, динамика, производительность.
Мониторинг Angie с помощью Console Light и API.
Видеоверсия
Для вашего удобства подготовлена видеоверсия этой статьи, доступна на Rutube, VKVideo и YouTube.
Мониторинг с помощью модуля stub_status
Долгое время модуль stub_status был единственным стандартным модулем для мониторинга Nginx. Настроить его довольно просто — достаточно выделить локацию (location) для предоставления статистики (также желательно закрыть её от внешнего доступа).
location = /angie-status {
auth_basic "Identify yourself!";
auth_basic_user_file /etc/angie/passwd;
allow 127.0.0.0/24;
stub_status;
}Посмотрим, что можно узнать с помощью stub_status:
curl localhost/angie-status
...
Active connections: 2
server accepts handled requests
114809 114809 346721
Reading: 0 Writing: 1 Waiting: 1В основном это статистика по различным статусам соединений: активные (Active), получающие (Reading) и отправляющие данные (Writing), ожидающие (Waiting). Также есть данные о количестве принятых (accepts) и обработанных подключений (handled), а также о суммарном количестве запросов (requests).
На этом возможности модуля заканчиваются. Дальше для Nginx — ресурсоёмкий парсинг логов (а‑ля Nginx Amplify) или сборка сторонних модулей (например, VTS и STS). Но в Angie реализован специальный модуль API, который собирает и предоставляет статистику по десяткам внутренних метрик без создания дополнительной нагрузки на процессор. Эти метрики эффективно хранятся в зонах разделяемой памяти и обновляются в реальном времени самим сервером.
Модуль API и его метрики
Основой мониторинга Angie является модуль API — именно он отвечает за сбор и представление метрик для мониторинга. Кроме задач мониторинга, модуль API может предоставлять информацию о конфигурации сервера, а для версии Angie PRO — еще и управление этой конфигурацией.
На момент написания статьи модуль поддерживает следующие типы объектов:
общий статус сервера (/server/angie);
статистика соединений (/status/connections);
статистика DNS‑резолвера (/status/resolvers/<зона>);
зоны разделяемой памяти (/status/slabs/<зона>);
HTTP‑зоны серверов (/status/http/server_zones/<зона>);
HTTP‑зоны location (/status/http/location_zones/<зона>);
Stream‑зоны для TCP/UDP серверов (/status/stream/server_zones/<зона>);
зоны кэширования ответов (/status/http/caches/<cache>);
HTTP‑зоны для ограничения подключений (/status/http/limit_conns/<зона>);
Stream‑зоны для ограничения подключений (/status/stream/limit_conns/<зона>);
HTTP‑зоны для ограничения запросов (/status/http/limit_reqs/<зона>);
группы HTTP‑серверов (/status/http/upstreams/<upstream>);
группы TCP/UDP‑серверов (/status/stream/upstreams/<upstream>);
API динамической конфигурации Angie PRO (/config/).
В адресах метрик значение в угловых скобках будет содержать название зоны, а как его задавать мы обсудим в следующем разделе статьи.
Включение модуля происходит достаточно просто — нужно определить location, в котором мы хотим видеть метрики и конфигурацию сервера:
location /status/ {
api /status/;
api_config_files on;
auth_basic "Identify yourself!";
auth_basic_user_file /etc/angie/passwd;
allow 127.0.0.0/24;
}В данном случае мы можем получить доступ к метрикам по URI /status/. Директива api отвечает за включение REST‑интерфейса модуля API, а api_config_files добавляет объект с содержимым конфигрурационных файлов сервера. Путь в директиве api необязателен, но может использоваться, чтобы открыть частичный доступ к метрикам (по аналогии с директивой alias), например, только для раздела HTTP‑зон (/http/server_zones/):
location /stats/ {
api /status/http/server_zones/;
}Получить значения метрик можно с помощью HTTP‑запроса с указанием нужного раздела (посмотрим на метрики HTTP‑зон):
curl http://localhost/status/http/server_zones
{
"balance": {
"requests": {
"total": 16593,
"processing": 1,
"discarded": 0
},
"responses": {
"200": 16586,
"304": 4,
"502": 2
},
"data": {
"received": 5630052,
"sent": 13705111
}
},
"static_site": {
"requests": {
"total": 0,
"processing": 0,
"discarded": 0
},
"responses": {},
"data": {
"received": 0,
"sent": 0
}
}
}Формат вывода метрик — JSON, описание отдельных метрик можно посмотреть в документации модуля API.
На этом этапе может возникнуть закономерный вопрос: нужно ли что‑то дополнительно настраивать для получения полного набора метрик по всем разделам? Да, нужно, и об этом поговорим дальше.
Настройка зон для сбора метрик
Для различных типов объектов метрики подключаются по-разному. Например, если у вас подключен HTTP-кэш (есть директива proxy_cache_path), то метрики будут собираться автоматически, а имя зоны метрик будет определено именем зоны кэширования. То же самое касается всех зон ограничений модулей limit_req и limit_conn. Также все зоны разделяемой памяти будут мониториться по умолчанию.
Сбор метрик для объектов серверного уровня (server) и location подключается директивой status_zone:
server {
listen 80 default_server;
status_zone balance;
server_name _;
location / {
status_zone location_root;
proxy_pass http://backend;
}
}В директиве status_zone единственный параметр — имя зоны, по которому можно будет получить значения метрик, например:
curl http://localhost/status/http/server_zones/balance
{
"requests": {
"total": 30461,
"processing": 1,
"discarded": 0
},
"responses": {
"200": 30447,
"304": 11,
"502": 2
},
"data": {
"received": 10383383,
"sent": 24770338
}
}
curl http://localhost/status/http/location_zones/location_root
{
"requests": {
"total": 1426,
"discarded": 0
},
"responses": {
"200": 1424,
"502": 2
},
"data": {
"received": 424322,
"sent": 3907588
}
}
Чтобы собирать метрики групп серверов (HTTP или stream), следует использовать директиву zone. Таким образом, мы создаём разделяемую между рабочими процессами область памяти, которая будет хранить состояние серверов.
upstream backend {
zone upstream-backend 10m;
server 127.0.0.1:9000;
server 127.0.0.1:9001;
}Как видно из примера, в директиве два параметра: имя зоны и размер.
Для мониторинга DNS‑резолверов необходимо добавить параметр status_zone в директиве resolver:
resolver 127.0.0.53 ipv6=off valid=30s status_zone=local;Таким образом, мы настроили сбор метрик по интересующим объектам. Теперь статистика доступна по REST API, но это еще не всё. Практически все метрики можно визуализировать с помощью компонента Angie Console Light.
Angie Console Light
Для решения задачи оперативного мониторинга системы в реальном времени пригодится панель с визуализацией метрик, которые предоставляет модуль API. Эту функцию выполняет панель Angie Console Light, еще один компонент веб‑сервера Angie.
Традиционно, начинаем с установки пакета из фирменного репозитория:
sudo apt install angie-console-light
dnf install angie-console-lightДля Angie PRO пакет будет называться angie-pro-console-light. После установки нужно выбрать подходящий блок server и настроить location для консоли. Далее вы получите доступ к консоли через этот server. Минимальная конфигурация будет иметь следующий вид.
location /console/ {
alias /usr/share/angie-console-light/html/;
index index.html;
location /console/api/ {
api /status/;
}
}Для Angie PRO дополнительно доступна возможность управления конфигурацией групп серверов, для этой фичи добавляем следующий location.
location /console/api/config/ {
api /config/;
}Конечно, не забываем про безопасность и закрываем доступ к консоли с помощью директив модулей Access, Auth Basic или других. Например, можно использовать набор директив из начала статьи:
location /console/ {
auth_basic "Identify yourself!";
auth_basic_user_file /etc/angie/passwd;
allow 127.0.0.0/24;
...
}Итак, панель настроена, можем заходить по настроенному location /console/. Главная страница консоли покажет общую статистику сервера. Также видны все блоки верхнего уровня, для которых мы настроили мониторинг.
Полное описание метрик и элементов интерфейса есть в документации, поэтому пробежимся по доступным на сегодня страницам. На странице «HTTP‑зоны» можно найти серверные зоны и зоны для location.
Там же в нижней части можно наблюдать за работой лимитов по частоте запросов и по количеству соединений. При клике на любой лимит открывается динамический график.
Далее доступна статистика по HTTP‑апстримам. Здесь можно посмотреть их состояние и основные метрики. Для версии PRO здесь также доступно управление (изменение свойств каждого сервера, перевод его в другой режим).
Далее можно посмотреть аналогичные разделы для L4 — TCP/UDP зоны.
Следующая страница: TCP/UDP‑апстримы. Структура аналогична HTTP‑апстримам. Кстати, на картинке видно, что можно применить фильтр «Только проблемные» к списку, а также раскрыть список апстримов.
Далее доступна статистика кэша. На этой странице можно посмотреть ��спользование зоны разделяемой памяти, размер кэша на диске, трафик и процент попадания в кэш.
Следующий раздел — Общие зоны. Здесь представлены зоны разделяемой памяти и процент их использования.
Наконец, финальная страница консоли: DNS‑резолверы. На этой странице выводится статистика резолверов.
Для оперативного мониторинга удобно, что данные обновляются без обновления страницы. Кстати, частоту обновлений можно изменить в панели настроек (правый верхний угол).
Проект Angie Console Light активно развивается, поэтому стоит следить за выпусками новых версий.
Итоги
Мы начали рассмотрение вопросов мониторинга с классического модуля stub_status. Далее рассмотрели новый модуль API и возможность прямого доступа к значениям метрик. На основе этих метрик работает визуальная консоль Angie Console Light, которую мы настроили в конце статьи. На этом возможности мониторинга в Angie не заканчиваются; например, есть встроенный экспортер Prometheus. Но это мы будем разбирать в другой статье.
