Здравствуй, дорогой читатель. Меня зовут Дмитрий. Я — системный инженер компании «Веб-сервер». На протяжении моего опыта оказания услуг технической поддержки сначала в компании Nginx, а теперь и в компании разработчика российского веб-сервера Angie, мы отвечаем на очень популярный вопрос: «Как организовать мониторинг состояния веб-сервера?». А вот так.

1. Мониторинг. «Да зачем? В логах всё нормально!».

2. Веб-сервер Angie. «Зачем? Если есть *****».
   Как установить. «А есть сборка под ******?».

3. API. «Говорю же, логи есть! Сейчас, только включу их на проде».
   Что позволяет получить. «В чем разница с логами?».
   Как настроить. «Само не работает?».
   Получение конфигурации веб-сервера. «Так есть же angie -T».

4. Console Light – веб-интерфейс. «Ещё одна система мониторинга?!1?1!!!».
   Что позволяет увидеть. «Что значит в реальном времени?».
   Как установить. «Точно пару строчек конфига?».

5. API для Prometheus. «Да у меня уже используется! Ну да, логи парсим...».
   Как настроить Angie для интеграции. «Как это без njs?».
   Сравнение с Console Light. «Значения действительно совпадают?».

6. Итог. «Так вот что значит многогранный!».

1. Мониторинг. «Да зачем? В логах всё нормально!»

Итак, мы переросли ситуацию, когда реагируем на инциденты в работе информационной системы по звонку от пользователя. Теперь у нас в инфраструктуре есть полноценные системы мониторинга, со сбором данных, системой оповещения и кнопкой «всё исправить».

Отвечая на вопросы менеджеров, архитекторов или специалистов информационной безопасности о том, каким образом мы обеспечиваем наблюдаемость одной из ключевых компонент процесса обработки сетевого обращения к инфраструктуре, мы чаще всего перечисляем следующее. У нас есть системные метрики процесса веб-сервера (сколько CPU или RAM потребляет, как долго работает), есть данные из логов, реже есть возможность экспорта метрик из веб-сервера с помощью сторонних расширений.

Получать системные метрики процесса — обычная практика, санитарный минимум для любой инфраструктуры. Но порой это крайне мало. Вот мы видим минимальное потребление CPU, а на сайте — ошибка 502 Bad Gateway, и вообще всё плохо.

Получать данные из логов — это просто. Но архитекторы подмечают, что по сути, мы ретроспективно следуем за запросами, которые уже были обработаны к этому моменту времени. В случае с DoS атакой, мы увидим по логам только когда уже часть запросов отработают как «не удалось обработать». А нам надо видеть в мониторинге веб-сервера запросы, которые уже сейчас пришли, но ещё не успели обработаться вышестоящим сервером. Мониторинг, в том числе, должен показывать замах на удар, а не показывать синяк на лице.

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

Встроенные функции нашего продукта, о которых пойдёт далее речь, позволяют осуществлять полный мониторинг нагрузки на Web/Proxy сервер в режиме реального времени, а также имеют ряд расширенных возможностей интеграции с системой мониторинга в инфраструктуре клиента.

2. Веб-сервер Angie. «Зачем? Если есть *****»

Для тех, кто не в курсе, скажу, а иным напомню, что есть такой продукт Angie, созданный fork»ом от nginx, разработкой которого занимается компания «Веб‑Сервер». Компания объединяет бывших ведущих инженеров компании NGINX. Распространяется под лицензией BSD, это легально, нам так сказали.

Кодовая база веб-сервера Angie была ответвлена от Nginx 1.23.1. С тех пор мы добавляем новую функциональность, которой нет в версии nginx с открытым исходным кодом. При этом мы стараемся портировать обновления nginx в наш веб-сервер, обеспечивая возможность бесшовного перехода пользователям с nginx на Angie.

С самого первого релиза, а это было в октябре 2022 года, Angie включает в себя модуль API, который реализует HTTP RESTful интерфейс для получения базовой информации о веб-сервере в формате JSON, а также статистики по:

• клиентским соединениям

• зонам разделяемой памяти

• DNS-запросам

• HTTP-запросам

• кэшу HTTP-ответов

• сессиям модуля stream

• зонам модулей limit_conn http, limit_conn stream и limit_req

Полный список метрик можно посмотреть в документации.

Недавно вышла новая версия Angie 1.3.0, в которой реализована поддержка вывода метрик в формате Prometheus. Мы подготовили веб-интерфейс для просмотра метрик в режиме реального времени с выбранного инстанса. И пришло время сделать небольшой сравнительный тест возможностей мониторинга работы веб-сервера.

К числу отличительной функциональности Angie можно отнести:

• Поддержку API для снятия статистики, конфигурации и многого другого.

• Динамический DNS с поддержкой преобразования SRV-записей DNS.

• Привязку клиентских сессий методом sticky session или route.

• Облегчённый интерфейс мониторинга Console Light.

• Нативный вывод метрик в формате Prometheus.

2.1. Как установить. «А есть сборка под ******?»

Подробная инструкция, как установить Angie, представлена на официальном сайте на русском и английском языках. 

Хотя мы и поддерживаем 11 дистрибутивов, различных версий на архитектурах x86-64 и arm64, в этой статье я лишь приведу шаги, необходимые для иллюстрации возможности мониторинга веб-сервера. Все установки буду производить на ОС Debian.

Установка Angie ничем не отличается от установки любого другого пакета из репозитория. Для начала добавьте ключ и репозиторий:

sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
                    ca-certificates curl lsb-release && \
sudo curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \
                    https://angie.software/keys/angie-signing.gpg && \
echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \
                    | sudo tee /etc/apt/sources.list.d/angie.list >/dev/null

И установите Angie:

sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
                    angie

Готово. Веб-сервер работает и страница с приветствием доступна на порту 80.

curl -I localhost
HTTP/1.1 200 OK
Server: Angie/1.3.0
....

3. API. «Говорю же, логи есть! Сейчас, только включу их на проде»

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

3.1. Что позволяет получить. «В чем разница с логами?»

А если всё-таки делать анализ логов и строить систему мониторинга на основе этих данных? В чём разница с использованием метрик через API? Есть несколько нюансов.

Во-первых, логи записываются уже после того как запрос был обработан. Другими словами, когда последний байт был отдан клиенту. Что делать в этом случае с долгоживущими соединениями или медленными клиентами? На помощь здесь приходит API. Метрика «processing» в «requests» внутри «server_zones» поможет узнать, сколько в данный момент времени сервер обрабатывает запросов.

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

Здесь нас опять выручит API. Вы можете посмотреть и рассчитать заполненность зон и вовремя реагировать на непредвиденные ситуации.

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

Возвращаясь к вопросу о сторонних решениях, читатель может задать вопрос - «Для чего мне что то менять, я долгое время использую комплексное решение на основе модуля vts?» Тут хочется отметить что решения, по типу модуля vts на самом деле не дают статистики в реальном времени, т.к. работают в лог фазе и счетчики считаются только по окончанию обработки запроса. Иными словами, данному типу решений присущи те же недостатки, что и мониторингу по логам.

3.2. Как настроить. «Само не работает?»

Для включения API достаточно добавить в конфиг директиву "api".

Давайте закомментируем директивы "allow" и "deny" в "location /status/" в файле конфигурации "/etc/angie/http.d/default.conf", чтобы мы могли сразу увидеть страничку API в браузере. (В продакшене всё же стоит правильно настроить эти директивы в целях безопасности. Это также относится и к следующим частям данной статьи):

location /status/ {
  api /status/;
  # allow 127.0.0.1;
  # deny all;
}

Добавим пару зон и upstream в конфиг для наглядности:

upstream foo {
  zone http-upstream-foo 256k;
  server 127.0.0.2 max_conns=10 max_fails=10;
  server 127.0.0.3 max_conns=10 max_fails=10;
  server 127.0.0.4 max_conns=10 max_fails=10;
}

server {
#...
    status_zone example;
#...
    location / {
#...
      status_zone location_zone;
    }
#...
}

Перезапустите Angie, чтобы применить конфигурацию:

sudo angie -t && sudo service angie reload

и на страничке /status/ вашего сервера вы уже увидите JSON с API метриками.

3.3. Получение конфигурации веб-сервера. «Так есть же angie -T»

К слову, о работе с конфигурацией веб-сервера. Как дополнительный бонус — в API появилась возможность отобразить конфигурацию вашего сервера. Именно ту, на которой в данный момент работает Angiе. Это может быть полезно в ряде случаев, например, вы по какой то невероятной причине убили все конфиги с сервера и хотите восстановить. Тут вам вывод команды «angie -T» не поможет, так как команда «angie -T» проводит проверку на синтаксис и выводит конфигурацию с диска. Бинарный файл «angie» при запуске попытается распарсить файл конфигурации, который указан по умолчанию.

Теперь, для того, чтобы понять, применилась ли обновленная конфигурация, вы можете сравнить выводы API и "sudo angie -T".

А можно поступить ещё проще, и отследить поколение конфигурации. Angie отслеживает поколение конфигурации каждого своего процесса; нумерация начинается с единицы при запуске сервера, а номера растут при каждой перезагрузке конфигурации и указаны в именах процессов.

После успешной перезагрузки конфигурации (вне зависимости от наличия изменений) номера поколений у процессов, получивших новую конфигурацию, увеличатся, и если какие-то из рабочих процессов предыдущих поколений продолжают работу, это сразу будет заметно по выводу команды "ps aux | grep angie".

Вывод API в части /status/angie/ также покажет поколение конфигурации. Но в отличии от вывода ps — вывод API покажет только новое поколение конфига.

4. Console Light – веб-интерфейс. «Ещё одна система мониторинга?!1?1!!!»

Начиная с версии Angie 1.3.0, добавилась функция Console Light – это легковесная визуальная консоль для мониторинга активности в реальном времени, она отображает ключевые показатели нагрузки и производительности сервера. И в целом облегчает админу задачи отслеживания жизнеспособности и состояние сервера.

4.1. Что позволяет увидеть. «Что значит в реальном времени?»

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

Собственно, все те метрики, которые упоминали ранее, здесь сгруппированы по рекомендованным вкладкам для отслеживания.Например, метрику "processing" в "requests" вы сможете найти на вкладке HTTP Zones. Здесь она будет называться Current. А заполненность зон вы можете посмотреть на вкладках Shared Zones и Caches.

Нашу демоверсию Console Light вы можете посмотреть по адресу https://console.angie.software/, а подробное описание вкладок и собранных там метрик можно найти в разделе документации.

4.2. Как установить. «Точно пару строчек конфига?»

Эта функциональность поставляется в виде отдельного пакета, пусть этот факт не смущает моего читателя. Console Light полностью интегрирована с Angie и API.  Установим пакет Console Light, чтобы посмотреть текущую статистику сервера.

Для этого просто выполните:

sudo apt-get install angie-console-light

Затем подключите Console Light, поместив "location /console" в контекст "server" файла конфигурации Angie ("/etc/angie/http.d/default.conf").
Вот так:

location /console {

  alias /usr/share/angie-console-light/html;
  index index.html;

    location /console/api/ {
      api /status/;
  }
}

Более подробную информацию вы найдёте на официальном сайте.

Перезапустим Angie:

sudo angie -t && sudo service angie reload

И, зайдя на /console, мы увидим страничку с метриками. Тут вы сразу увидите как наполняются метрики Requests и Responses. Так как мы настраиваем нашу консоль в том же "server" где располагаются и "status_zone", то мы видим, как сама консоль, обращаясь к API, накручивает нам статистику. Оговорюсь, опять же, что в продакшене такую настройку не стоит делать. Лучше использовать отдельный "server"-блок, используемый только для мониторинга.

5. API для Prometheus. «Да у меня уже используется! Ну да, логи парсим...»

Довольно популярное решение построения системы мониторинга – это использовать Prometheus для сбора метрик. Предполагаем, что этот сервис у вас уже установлен. Скорее всего, вы наполняете его через анализ логов или используете сторонние экспортеры.

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

5.1. Как настроить Angie для интеграции. «Как это без njs?»

В новый пакет уже добавлен шаблон со всеми доступными метриками, так что будет достаточно просто включить отдачу этих метрик в удобном нам location, добавив директиву "prometheus".

location /metrics/ {
  prometheus all;
}

Перезапустим Angie:

sudo angie -t && sudo service angie reload

И по запросу на адрес /metrics/ мы увидим знакомый формат Prometheus.
В сети можно найти примеры экспорта метрик из nginx с помощью njs. В нашем случае никакого рантайма js не используется, вычисление и отдача происходят в рантайме веб-сервера с минимальными накладными расходами.

5.2. Сравнение с Console Light. «Значения действительно совпадают?»

Мне, как инженеру, было интересно посмотреть, а есть ли разница, смотреть на метрики через Prometheus+Grafana или через Console Light. Я собрал простой стенд, настроил веб-сервер, интеграции с Prometheus и Console Light. Создал искусственную нагрузку на веб-сервер с помощью wrk и скриптов. На скриншотах ниже можно сравнить соответствующие метрики. Получилось довольно интересно.

В целом, метрики во всём схожи, отличия начинаются, когда увеличим интервал сбора метрик. Если Console Light ходит за метриками каждую секунду, то в Grafana интервал 2 минуты показывает метрики с запозданием и с некоторой разницей. И, как следствие, на скриншотах отличия.

В то время, когда использование диска начало угрожающе расти, Grafana всё ещё рисовала, что всё у неё хорошо.

Конечно, в итоге показатели сравнялись.

Ситуация с показателями запросов в рантайме также схожа.

Очень многое зависит от настроек самой Grafana и Prometheus, вам придётся выбрать подходящие для вас интервалы. Но будьте готовы, что с уменьшением интервалов, сервисам придётся хранить больше данных на диске.

6. Итог. «Так вот что значит многогранный!»

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

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

Так вот, про разносторонний способ мониторинга. Многогранность выражается в том, что вы можете продолжать анализировать логи, можете воспользоваться веб-сервером Angie, который предоставляет API с расширенными метриками. Можете подсматривать состояние веб-сервера на простенькой веб-странице Console Light. И, наконец, можете сделать полноценную интеграцию информации о состоянии веб-сервера в вашу систему сбора метрик на базе Prometheus.

Пожалуйста, пользуйтесь! Мне было приятно вам помочь!