Не секрет, что штатные возможности мониторинга Nginx довольно скромны. Решалась эта задача различными способами: либо парсингом логов, либо сторонними модулями. При создании Angie эту проблему решили радикально и сразу несколькими способами. Начнём с исторического модуля stub_status.

Навигация по циклу

Видеоверсия

Для вашего удобства подготовлена видеоверсия этой статьи, доступна на 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. Но это мы будем разбирать в другой статье.

Мониторинг Angie с помощью Console Light и API