После моей недавней заметки про Angie, в комментариях появился один из разработчиков этого продукта и дал более конкретную информацию. Так как комментарии читают не все, я хочу зафиксировать основную информацию отдельным сообщением.
1️⃣ Angie это не пересборка Nginx для перепродажи в России. Над развитием продукта работают разработчики. Изменения вносятся в том числе в open source версию и это будет продолжаться. Angie Pro не копия Nginx Plus. Это другой продукт.
2️⃣ Другой сайт будет. То, что сейчас на Тильде, это временно. Сейчас фокус на сам продукт, его код и другие организационные моменты.
3️⃣ У Angie есть свой Telegram канал - https://t.me/angie_software.
4️⃣ На сайте после моей заметки появилась обзорная статья: Сходства и различия Angie и nginx. (nginx почему-то с маленькой буквы, а Angie с большой 😁) Основные моменты оттуда (что-то в сокращении):
🔹в Angie нет кода NGINX Plus, закрытой коммерческой версии nginx; более того, у нас нет цели сделать наш платный веб-сервер, Angie PRO, стопроцентной функциональной копией NGINX Plus
🔹Angie сознательно ориентируется на платформы, для которых “официальный” nginx будет собираться еще нескоро: это такие сертифицированные в России ОС, как ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”.
🔹Мы решили упростить их жизнь и ведем единообразную сборку готовых пакетов для целого ряда таких модулей в своих репозиториях, используя свой опыт и знания.
Последнее прокомментирую, так как это важно. Разработчики Angie решили сами собирать популярные динамические модули веб сервера, чтобы упростить жизнь пользователям. Недавно у меня была публикация, где я рассказывал, как собрать Nginx с нужными модулями. А здесь разработчики озаботились и решили эту проблему сами. Список готовых модулей можно посмотреть на сайте. Там всё наиболее популярное присутствует (brotli, lua, geoip и т.д.) Не нашёл только vts. Думаю, разработчикам имеет смысл обратить на него внимание тоже. Все модули собраны в пакеты и доступны из репозитория. Вообще, это существенный плюс в пользу того, чтобы поставить Angie вместо Nginx, если тебе нужен какой-то модуль.
🔹Следующий фактор, на который мы обращаем внимание в своей работе, — ускорение работы самого веб-сервера за счет устранения лишних задержек. Мы:
◽добавили API-интерфейс динамической конфигурации и средства адаптивной DNS-адресации;
◽реализовали механизм привязки пользовательских сессий к проксируемому серверу;
◽внедрили активные проверки работоспособности проксируемых серверов, уменьшающие вероятность отправки реального запроса на неработающий сервер;
◽создали возможность сегментировать прокси-кэш, тем самым более эффективно задействуя все ресурсы сервера.
🔹Еще одна область, в которой мы хотим добиться улучшений, — это гибкость и удобство настройки веб-сервера. Мы:
◽добавили для групп проксируемых серверов упомянутый выше API-интерфейс динамической конфигурации;
◽предоставили ряд других настроек, менее масштабных, но весьма полезных.
🔹Наконец, важным для нас аспектом развития Angie является мониторинг состояния самого веб-сервера и проксируемых серверов. Мы:
◽реализовали в API-интерфейсе возможность получения базовой информации о веб-сервере, а также статистики по всем основным аспектам его функционирования в популярных современных форматах;
◽внедрили уже упомянутые активные проверки проксируемых серверов, самостоятельно следящие за их работоспособностью;
◽добавили семейство настроек для сбора статистики по сессиям передачи данных и запросам разрешения адресов.
Спасибо за подробные комментарии и описание отличий. Все эти изменения выглядят очень привлекательно для эксплуатации. Наглядно видно развитие и фокус внимания на реальные потребности пользователей. Обязательно попробую этот веб сервер в деле.
#webserver #nginx #angie #отечественное
1️⃣ Angie это не пересборка Nginx для перепродажи в России. Над развитием продукта работают разработчики. Изменения вносятся в том числе в open source версию и это будет продолжаться. Angie Pro не копия Nginx Plus. Это другой продукт.
2️⃣ Другой сайт будет. То, что сейчас на Тильде, это временно. Сейчас фокус на сам продукт, его код и другие организационные моменты.
3️⃣ У Angie есть свой Telegram канал - https://t.me/angie_software.
4️⃣ На сайте после моей заметки появилась обзорная статья: Сходства и различия Angie и nginx. (nginx почему-то с маленькой буквы, а Angie с большой 😁) Основные моменты оттуда (что-то в сокращении):
🔹в Angie нет кода NGINX Plus, закрытой коммерческой версии nginx; более того, у нас нет цели сделать наш платный веб-сервер, Angie PRO, стопроцентной функциональной копией NGINX Plus
🔹Angie сознательно ориентируется на платформы, для которых “официальный” nginx будет собираться еще нескоро: это такие сертифицированные в России ОС, как ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”.
🔹Мы решили упростить их жизнь и ведем единообразную сборку готовых пакетов для целого ряда таких модулей в своих репозиториях, используя свой опыт и знания.
Последнее прокомментирую, так как это важно. Разработчики Angie решили сами собирать популярные динамические модули веб сервера, чтобы упростить жизнь пользователям. Недавно у меня была публикация, где я рассказывал, как собрать Nginx с нужными модулями. А здесь разработчики озаботились и решили эту проблему сами. Список готовых модулей можно посмотреть на сайте. Там всё наиболее популярное присутствует (brotli, lua, geoip и т.д.) Не нашёл только vts. Думаю, разработчикам имеет смысл обратить на него внимание тоже. Все модули собраны в пакеты и доступны из репозитория. Вообще, это существенный плюс в пользу того, чтобы поставить Angie вместо Nginx, если тебе нужен какой-то модуль.
🔹Следующий фактор, на который мы обращаем внимание в своей работе, — ускорение работы самого веб-сервера за счет устранения лишних задержек. Мы:
◽добавили API-интерфейс динамической конфигурации и средства адаптивной DNS-адресации;
◽реализовали механизм привязки пользовательских сессий к проксируемому серверу;
◽внедрили активные проверки работоспособности проксируемых серверов, уменьшающие вероятность отправки реального запроса на неработающий сервер;
◽создали возможность сегментировать прокси-кэш, тем самым более эффективно задействуя все ресурсы сервера.
🔹Еще одна область, в которой мы хотим добиться улучшений, — это гибкость и удобство настройки веб-сервера. Мы:
◽добавили для групп проксируемых серверов упомянутый выше API-интерфейс динамической конфигурации;
◽предоставили ряд других настроек, менее масштабных, но весьма полезных.
🔹Наконец, важным для нас аспектом развития Angie является мониторинг состояния самого веб-сервера и проксируемых серверов. Мы:
◽реализовали в API-интерфейсе возможность получения базовой информации о веб-сервере, а также статистики по всем основным аспектам его функционирования в популярных современных форматах;
◽внедрили уже упомянутые активные проверки проксируемых серверов, самостоятельно следящие за их работоспособностью;
◽добавили семейство настроек для сбора статистики по сессиям передачи данных и запросам разрешения адресов.
Спасибо за подробные комментарии и описание отличий. Все эти изменения выглядят очень привлекательно для эксплуатации. Наглядно видно развитие и фокус внимания на реальные потребности пользователей. Обязательно попробую этот веб сервер в деле.
#webserver #nginx #angie #отечественное
Продолжу тему веб серверов, которую недавно начал. В свете последних новостей про Angie она заиграла новыми красками. Есть один популярный модуль, который часто используют и включают в различные сборки Nginx, типа nginx-more и не только. Речь пойдёт про модуль Headers More.
С помощью этого модуля можно очень гибко управлять добавлением или редактированием заголовков (headers). Стандартно Nginx позволяет добавлять заголовки только с помощью
В базовой сборке Nginx этого модуля нет. Чтобы добавить, нужно собрать его самостоятельно из исходников. Эту задачу существенно упростили разработчики Angie, собрав все популярные модули в своих репозиториях в виде пакетов. Так что дальше я покажу примеры с установкой и использованием модуля в этом веб сервере. Установить его сразу с нужным модулем проще простого. Показываю на примере Debian:
Установили веб сервер Angie с модулем headers-more. Чтобы подключить модуль, достаточно в конфиг
После этого можно управлять заголовками. Я покажу пару примеров, чтобы вы поняли суть. Для начала заменим стандартный заголовок Server, где веб сервер указывает свою версию, на что-то своё. Для этого в
Теперь сервер будет представляться как my_secret_server. Причём вы можете в разных виртуальных хостах указывать разное значение. Модуль headers-more позволяет управлять заголовками глобально для всего веб сервера, отдельно для каждого виртуального хоста или даже отдельного location. А также добавлять различные условия.
Например, вы можете добавить отдельный заголовок в какой-то виртуальный хост для всех запросов, которые будут отдавать 404-й код ответа. Делается это так:
Новый заголовок Error со значением 404 будет добавлен только к 404-м ошибкам. Через пробел можно добавить разные коды в одну настройку:
В заголовках можно и тип документа изменить. Например, отдадим страницу с 404 ошибкой в виде plain text, а не html, которая отдаётся по умолчанию:
Пример синтетический, чтоб показать возможности модуля. Если будете его тестировать, то на таких примерах легко проверить работу и разобраться в принципе работы.
В заголовки можно добавлять переменные, использовать условия, очищать или перезаписывать заголовки и т.д. Более подробно всё это можно посмотреть в описании модуля на github.
В ванильном Nginx всё это настраивается точно так же 1 в 1.
#webserver #angie #nginx
С помощью этого модуля можно очень гибко управлять добавлением или редактированием заголовков (headers). Стандартно Nginx позволяет добавлять заголовки только с помощью
add_header. Модуль Headers More существенно расширяет эту функциональность. Примеры я покажу ниже. В базовой сборке Nginx этого модуля нет. Чтобы добавить, нужно собрать его самостоятельно из исходников. Эту задачу существенно упростили разработчики Angie, собрав все популярные модули в своих репозиториях в виде пакетов. Так что дальше я покажу примеры с установкой и использованием модуля в этом веб сервере. Установить его сразу с нужным модулем проще простого. Показываю на примере Debian:
# 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" \| tee /etc/apt/sources.list.d/angie.list > /dev/null# apt update && apt install angie angie-module-headers-moreУстановили веб сервер Angie с модулем headers-more. Чтобы подключить модуль, достаточно в конфиг
/etc/angie/angie.conf добавить в основную секцию main:load_module modules/ngx_http_headers_more_filter_module.so;После этого можно управлять заголовками. Я покажу пару примеров, чтобы вы поняли суть. Для начала заменим стандартный заголовок Server, где веб сервер указывает свою версию, на что-то своё. Для этого в
/etc/angie/angie.conf, в секцию http добавляем свой заголовок:more_set_headers "Server: my_secret_server";Теперь сервер будет представляться как my_secret_server. Причём вы можете в разных виртуальных хостах указывать разное значение. Модуль headers-more позволяет управлять заголовками глобально для всего веб сервера, отдельно для каждого виртуального хоста или даже отдельного location. А также добавлять различные условия.
Например, вы можете добавить отдельный заголовок в какой-то виртуальный хост для всех запросов, которые будут отдавать 404-й код ответа. Делается это так:
more_set_headers -s '404' 'Error: 404';Новый заголовок Error со значением 404 будет добавлен только к 404-м ошибкам. Через пробел можно добавить разные коды в одну настройку:
more_set_headers -s '404 500 502' 'Status: Not OK';В заголовках можно и тип документа изменить. Например, отдадим страницу с 404 ошибкой в виде plain text, а не html, которая отдаётся по умолчанию:
more_set_headers -s '404' -t 'text/html' 'Content-Type: text/plain' 'Error: 404 txt';Пример синтетический, чтоб показать возможности модуля. Если будете его тестировать, то на таких примерах легко проверить работу и разобраться в принципе работы.
В заголовки можно добавлять переменные, использовать условия, очищать или перезаписывать заголовки и т.д. Более подробно всё это можно посмотреть в описании модуля на github.
В ванильном Nginx всё это настраивается точно так же 1 в 1.
#webserver #angie #nginx
Сегодня вышло крупное обновление веб сервера Angie 1.3.0. Кто не читал, посмотрите две мои предыдущие заметки про него (1, 2). Изменения затронули open source версию, так что попробовать и оценить их сможет каждый.
Перечислю наиболее заметные нововведения.
1️⃣ В конфигурации location теперь можно использовать одновременно несколько шаблонов uri. Это упрощает конфигурацию location с одинаковыми настройками. То есть можно сделать примерно вот так:
Сейчас у меня то же самое записано вот так:
Там есть нюанс, что между модификатором и uri не допускается пробел. Немного синтаксис другой получается, не как у одиночных шаблонов. Я возможно что-то с синтаксисом напутал, но идею, думаю, вы поняли. Чуть позже обновится документация и можно будет уже точно смотреть, как это настраивается.
2️⃣ Angie научился самостоятельно экспортировать свою статистику в формате Prometheus, что явно упростит настройку мониторинга. Не нужен отдельный exporter для этих целей. Было бы неплохо сразу и шаблон для Zabbix сделать, не дожидаясь, пока кто-то из энтузиастов это реализует. Достаточно распарсить вывод для Prometheus.
3️⃣ Отдельной настройкой можно включить возможность экспорта содержимого конфигурационных файлов запущенной версии веб сервера через API.
Остальные изменения:
◽детальная информация и метрики по группам проксируемых stream-серверов в интерфейсе статистики, предоставляемом директивой "api"
◽опция "resolve" директивы "server" в блоке "upstream" модуля "stream", позволяющая отслеживать изменения списка IP-адресов, соответствующего доменному имени, и автоматически обновлять его без перезагрузки конфигурации
◽опция "service" директивы "server" в блоке "upstream" модуля "stream", позволяющая получать списки адресов из DNS-записей SRV, с базовой поддержкой приоритета
◽отображение номера поколения конфигурации в именах процессов, что позволяет с помощью утилиты "ps" отслеживать успех перезагрузок конфигурации и количество поколений рабочих процессов с предыдущими версиями конфигурации.
Согласитесь, изменения существенные, которые повышают удобство использования веб сервера. История с мониторингом особенно нравится. Плюс, не забываем, про готовые собранные наиболее популярные модули для веб сервера, которые можно ставить из собранных пакетов разработчиков и подключать в конфигурации. В бесплатной версии Nginx всего этого нет, что требует дополнительные телодвижения при настройке.
#webserver #angie
Перечислю наиболее заметные нововведения.
1️⃣ В конфигурации location теперь можно использовать одновременно несколько шаблонов uri. Это упрощает конфигурацию location с одинаковыми настройками. То есть можно сделать примерно вот так:
location =~/.git ~*^/(\.ht|xmlrpc\.php)${ return 404;}Сейчас у меня то же самое записано вот так:
location ~ /.git {return 404;}location ~* ^/(\.ht|xmlrpc\.php)$ { return 404;}Там есть нюанс, что между модификатором и uri не допускается пробел. Немного синтаксис другой получается, не как у одиночных шаблонов. Я возможно что-то с синтаксисом напутал, но идею, думаю, вы поняли. Чуть позже обновится документация и можно будет уже точно смотреть, как это настраивается.
2️⃣ Angie научился самостоятельно экспортировать свою статистику в формате Prometheus, что явно упростит настройку мониторинга. Не нужен отдельный exporter для этих целей. Было бы неплохо сразу и шаблон для Zabbix сделать, не дожидаясь, пока кто-то из энтузиастов это реализует. Достаточно распарсить вывод для Prometheus.
3️⃣ Отдельной настройкой можно включить возможность экспорта содержимого конфигурационных файлов запущенной версии веб сервера через API.
Остальные изменения:
◽детальная информация и метрики по группам проксируемых stream-серверов в интерфейсе статистики, предоставляемом директивой "api"
◽опция "resolve" директивы "server" в блоке "upstream" модуля "stream", позволяющая отслеживать изменения списка IP-адресов, соответствующего доменному имени, и автоматически обновлять его без перезагрузки конфигурации
◽опция "service" директивы "server" в блоке "upstream" модуля "stream", позволяющая получать списки адресов из DNS-записей SRV, с базовой поддержкой приоритета
◽отображение номера поколения конфигурации в именах процессов, что позволяет с помощью утилиты "ps" отслеживать успех перезагрузок конфигурации и количество поколений рабочих процессов с предыдущими версиями конфигурации.
Согласитесь, изменения существенные, которые повышают удобство использования веб сервера. История с мониторингом особенно нравится. Плюс, не забываем, про готовые собранные наиболее популярные модули для веб сервера, которые можно ставить из собранных пакетов разработчиков и подключать в конфигурации. В бесплатной версии Nginx всего этого нет, что требует дополнительные телодвижения при настройке.
#webserver #angie
В предпоследнем обновлении веб сервера Angie, которое я из-за занятости пропустил, была анонсирована удобная веб панель наблюдения за сервером - Console Light. Только в последнем обновлении заметил это и решил навести справки.
Сразу покажу как поставить, потому что сам это проделал для того, чтобы оценить. Пример для Debian 12:
Добавляем в конфиг виртуального хоста:
Доступ лучше ограничить списком адресов. Я убрал ограничение для локального теста. Набор доступных виджетов и метрик в них зависит от настроек панели. К примеру, если хотите видеть через веб интерфейс конфигурационные файлы Angie с красивым форматированием и подсветкой синтаксиса, добавьте в location /console/api/ параметр api_config_files:
Удобное новшество. Можно быстро оценить всю рабочую конфигурацию, собранную из всех присоединённых файлов. Очень удобно для окружения Bitrix, где этих конфигов десятки.
На тестовом сервере смотреть особо не на что, кроме базовых метрик по соединениям. Оценить функциональность панели можно в публичном демо:
⇨ https://console.angie.software
Статья с подробным описанием этой панели и всего мониторинга в целом есть на хабре:
⇨ Многогранный мониторинг Angie
И там же свежее интервью с руководителем отдела разработки:
⇨ Интервью с Валентином Бартеневым: как бывшие сотрудники Nginx разрабатывают отечественный веб-сервер Angie
В принципе, в панели представлена та же информация, что и во встроенном модуле метрик для Prometheus, который был анонсирован в более старых обновлениях. Особенность встроенной панели в том, что там метрики можно смотреть практически в режиме реального времени, без задержки попадания метрик в привычный мониторинг.
Мне немного лениво работающие сервера переводить на Angie, но если что-то новое придётся настраивать, буду делать на нём. Плюсы относительно Nginx очевидны и наглядны. Готовый мониторинг и веб панель - это прям самый сок.
#angie #webserver #отечественное
Сразу покажу как поставить, потому что сам это проделал для того, чтобы оценить. Пример для Debian 12:
# 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" | tee /etc/apt/sources.list.d/angie.list > /dev/null# apt update && apt install angie angie-console-lightДобавляем в конфиг виртуального хоста:
location /console { #allow 127.0.0.1; #deny all; alias /usr/share/angie-console-light/html; index index.html; location /console/api/ { api /status/; } }Доступ лучше ограничить списком адресов. Я убрал ограничение для локального теста. Набор доступных виджетов и метрик в них зависит от настроек панели. К примеру, если хотите видеть через веб интерфейс конфигурационные файлы Angie с красивым форматированием и подсветкой синтаксиса, добавьте в location /console/api/ параметр api_config_files:
location /console/api/ { api /status/; api_config_files on; }Удобное новшество. Можно быстро оценить всю рабочую конфигурацию, собранную из всех присоединённых файлов. Очень удобно для окружения Bitrix, где этих конфигов десятки.
На тестовом сервере смотреть особо не на что, кроме базовых метрик по соединениям. Оценить функциональность панели можно в публичном демо:
⇨ https://console.angie.software
Статья с подробным описанием этой панели и всего мониторинга в целом есть на хабре:
⇨ Многогранный мониторинг Angie
И там же свежее интервью с руководителем отдела разработки:
⇨ Интервью с Валентином Бартеневым: как бывшие сотрудники Nginx разрабатывают отечественный веб-сервер Angie
В принципе, в панели представлена та же информация, что и во встроенном модуле метрик для Prometheus, который был анонсирован в более старых обновлениях. Особенность встроенной панели в том, что там метрики можно смотреть практически в режиме реального времени, без задержки попадания метрик в привычный мониторинг.
Мне немного лениво работающие сервера переводить на Angie, но если что-то новое придётся настраивать, буду делать на нём. Плюсы относительно Nginx очевидны и наглядны. Готовый мониторинг и веб панель - это прям самый сок.
#angie #webserver #отечественное
Решил не откладывать в долгий ящик и перевести один из веб серверов на Angie. Как и обещали разработчики, с конфигами Nginx полная совместимость. Установил Angie и скопировал основной конфиг сервиса, а также виртуальных хостов. Виртуальные хосты вообще не трогал, а основной конфиг немного подредактировал, изменив в include пути с
Остановил Nginx, запустил Angie. Никаких проблем. Всё мгновенно подхватилось новым веб серверов. Простой пару секунд.
Заметку пишу не про переход, а про мониторинг. Согласно документации настроил передачу метрик сервера через API, веб консоль и метрики Prometheus. С прометеусом пока не разбирался, веб консоль просто для красоты включил, а внимание уделил API. Настроил шаблон Zabbix для сбора метрик через API. Сделал по аналогии с Nginx, но кое-что изменил по своему усмотрению. Шаблон можно скачать тут. Это первая версия. Немного попользуюсь и надеюсь, что оформлю всё это в полноценную статью с какими-то правками, которые наверняка накопятся по мере использования.
В шаблоне используются 2 макроса:
◽{$STATUS_HOST} - ip адрес сервера
◽{$STATUS_PATH} - часть урла для API.
У меня доступ к API настроен по IP, а полный путь выглядит так: http://1.2.3.4/status/. Соответственно, первый макрос - 1.2.3.4, второй - /status/.
На картинке ниже метрики, которые я посчитал полезными и добавил в шаблон. Триггера сделал три: не отвечает внешний порт веб сервера, нет ни одного процесса angie на сервере, не поступают данные от API в мониторинг. Также добавил 4 графика и оформил всё в панель. Картинку панели покажу в комментариях.
#angie #zabbix
/etc/nginx на /etc/angie. Ещё параметр pid изменил с /var/run/nginx.pid на /run/angie.pid. Больше ничего не менял. Остановил Nginx, запустил Angie. Никаких проблем. Всё мгновенно подхватилось новым веб серверов. Простой пару секунд.
Заметку пишу не про переход, а про мониторинг. Согласно документации настроил передачу метрик сервера через API, веб консоль и метрики Prometheus. С прометеусом пока не разбирался, веб консоль просто для красоты включил, а внимание уделил API. Настроил шаблон Zabbix для сбора метрик через API. Сделал по аналогии с Nginx, но кое-что изменил по своему усмотрению. Шаблон можно скачать тут. Это первая версия. Немного попользуюсь и надеюсь, что оформлю всё это в полноценную статью с какими-то правками, которые наверняка накопятся по мере использования.
В шаблоне используются 2 макроса:
◽{$STATUS_HOST} - ip адрес сервера
◽{$STATUS_PATH} - часть урла для API.
У меня доступ к API настроен по IP, а полный путь выглядит так: http://1.2.3.4/status/. Соответственно, первый макрос - 1.2.3.4, второй - /status/.
На картинке ниже метрики, которые я посчитал полезными и добавил в шаблон. Триггера сделал три: не отвечает внешний порт веб сервера, нет ни одного процесса angie на сервере, не поступают данные от API в мониторинг. Также добавил 4 графика и оформил всё в панель. Картинку панели покажу в комментариях.
#angie #zabbix
На днях разработчики Angie анонсировали свой готовый Dashboard для мониторинга веб сервера через Prometheus и Grafana. Решил сразу его попробовать. Забегая вперёд скажу, что всё это существенно упрощает настройку мониторинга, который и так уже был на хорошем уровне в Angie. Стало просто отлично.
Напомню, что у Angie есть встроенный prometheus exporter. Включаем его так. Добавляем куда-нибудь location. Я обычно на ip адрес его вешаю в default сервер и ограничиваю доступ:
И добавляем в секцию http:
Далее добавляем в prometheus:
Только убедитесь, что ваш веб сервер отдаёт метрики по http://1.2.3.4/p8s. Либо какой-то другой url используйте, который настроили.
Вот и всё. Теперь идём в свою Grafana и добавляем готовый дашборд. Вот он:
⇨ https://grafana.com/grafana/dashboards/20719-angie-dashboard
Дашборд полностью автоматизирован. Сам подхватывает все настройки из Angie. Покажу, как это работает. Допустим, вы хотите получать метрики по какому-то конкретному виртуальному хосту. Идём в него и добавляем в секцию server:
Перезапускаем Angie и переходим в Dashboard. В разделе HTTP Server Zones появится отдельная статистика по этому виртуальному хосту. То же самое можно сделать с отдельными location. Добавим отдельную зону в основной location и с php бэкендом:
или
Идём в раздел HTTP Location Zones и смотрим там статистику по указанным location.
Статистика по бэкендам, зонам с лимитами тоже подхватывается автоматически, если они у вас настроены, и сразу видна в дашборде.
Сделано всё очень удобно. Мониторинг веб сервера настраивается максимально быстро и при этом очень функционально.
Отдельно напомню, что у Angie вся эта же статистика видна в веб интерфейсе Console Light. И так же доступна через модуль API. Я через него сделал шаблон для Zabbix с основными метриками. Шаблон по ссылке стоит рассматривать только как пример создания. Он был сделан на скорую руку. Я его у себя немного доделал, но новую версию не выкладывал. Уже не помню, какие там отличия. С выходом этого дашборда для графаны мне шаблоном для Zabbix заниматься не хочется. Довольно хлопотно всё это реализовывать в нём и не особо имеет смысл, раз уже всё сделано за нас. Графаной я и так постоянно пользуюсь в связке с Zabbix, и Prometheus тоже использую.
📌 Ссылки по теме:
⇨ Настройка панели Prometheus
⇨ Модуль API
⇨ Директива status_zone
⇨ Web Console Demo
Как по мне, возможностей бесплатного веб сервера Angie на текущий момент существенно больше, чем у бесплатного Nginx. И речь не только о мониторинге. Там есть много других удобств. Разница в функциональности тянет уже на отдельную заметку.
#angie #мониторинг #grafana
Напомню, что у Angie есть встроенный prometheus exporter. Включаем его так. Добавляем куда-нибудь location. Я обычно на ip адрес его вешаю в default сервер и ограничиваю доступ:
location =/p8s { prometheus all; allow 127.0.0.1; allow 1.2.3.4; allow 4.3.2.1; deny all; }И добавляем в секцию http:
include prometheus_all.conf;Далее добавляем в prometheus:
scrape_configs: - job_name: "angie" scrape_interval: 15s metrics_path: "/p8s" static_configs: - targets: ["1.2.3.4:80"]Только убедитесь, что ваш веб сервер отдаёт метрики по http://1.2.3.4/p8s. Либо какой-то другой url используйте, который настроили.
Вот и всё. Теперь идём в свою Grafana и добавляем готовый дашборд. Вот он:
⇨ https://grafana.com/grafana/dashboards/20719-angie-dashboard
Дашборд полностью автоматизирован. Сам подхватывает все настройки из Angie. Покажу, как это работает. Допустим, вы хотите получать метрики по какому-то конкретному виртуальному хосту. Идём в него и добавляем в секцию server:
server { server_name serveradmin.ru; status_zone serveradmin.ru; ................}Перезапускаем Angie и переходим в Dashboard. В разделе HTTP Server Zones появится отдельная статистика по этому виртуальному хосту. То же самое можно сделать с отдельными location. Добавим отдельную зону в основной location и с php бэкендом:
location / { status_zone main; ...............}или
location ~ \.php$ { status_zone php; ...................}Идём в раздел HTTP Location Zones и смотрим там статистику по указанным location.
Статистика по бэкендам, зонам с лимитами тоже подхватывается автоматически, если они у вас настроены, и сразу видна в дашборде.
Сделано всё очень удобно. Мониторинг веб сервера настраивается максимально быстро и при этом очень функционально.
Отдельно напомню, что у Angie вся эта же статистика видна в веб интерфейсе Console Light. И так же доступна через модуль API. Я через него сделал шаблон для Zabbix с основными метриками. Шаблон по ссылке стоит рассматривать только как пример создания. Он был сделан на скорую руку. Я его у себя немного доделал, но новую версию не выкладывал. Уже не помню, какие там отличия. С выходом этого дашборда для графаны мне шаблоном для Zabbix заниматься не хочется. Довольно хлопотно всё это реализовывать в нём и не особо имеет смысл, раз уже всё сделано за нас. Графаной я и так постоянно пользуюсь в связке с Zabbix, и Prometheus тоже использую.
📌 Ссылки по теме:
⇨ Настройка панели Prometheus
⇨ Модуль API
⇨ Директива status_zone
⇨ Web Console Demo
Как по мне, возможностей бесплатного веб сервера Angie на текущий момент существенно больше, чем у бесплатного Nginx. И речь не только о мониторинге. Там есть много других удобств. Разница в функциональности тянет уже на отдельную заметку.
#angie #мониторинг #grafana
Существует эффективный стандарт сжатия zstd. Не так давно современные браузеры стали его поддерживать, так что можно использовать в веб серверах. Разработчики Angie подсуетились и подготовили модуль для своего веб сервера, так что включить сжатие zstd максимально просто и быстро. Достаточно установить модуль в виде deb пакета и добавить настройки в конфигурацию, которые идентичны настройкам gzip, только название меняется на zstd.
По этому поводу вышел очень информативный ролик на ютубе:
⇨ Zstd (Zstandard): новый стандарт сжатия текста. Полный тест
Автор не только показал, как настроить zstd на веб сервере, но и сравнил его эффективность с привычными gzip и brotli. Результаты тестирования в динамическом сжатии получились очень любопытные. Zstd оказался лучше всех. Но если разница с brotli не сильно заметна, то вот gzip на фоне остальных выглядит очень медленным. Буквально в разы в некоторых случаях.
Я решил провести свои тесты, чтобы убедиться в такой большой разнице. Сразу скажу, что если не настроено https, то браузеры не будут использовать ни brotli, ни zstd. Не знаю, с чем это связано, но я потратил некоторое время, пока не разобрался с тем, почему не работает ничего, кроме gzip. И второй момент. Если на веб сервере настроены все 3 типа сжатия, то разные браузеры выбирают разное сжатие: либо brotli, либо zstd. Gzip не выбирает никто.
Тестировал так же, как и автор ролика. Установил Angie и оба модуля сжатия:
Подключил оба модуля в angie.conf:
И добавил для них настройки:
Если использовать ванильный Nginx, то придётся самостоятельно собирать его с нужными модулями 🤷♂️
Тестировал с помощью ab, передавая ему метод компрессии через заголовок:
Не буду приводить свои результаты, так как они получились примерно такие же, как у автора ролика, только разница между zstd и brotli с компрессией 4 поменьше. Zstd по rps (247) быстрее всех. Brotli чуть лучше жмёт в плане объёма, то есть трафик будет ниже, но и rps (211) немного меньше, чем у zstd.
В Angie очень легко настроить и brotli, и zstd, и gzip, так что имеет смысл это сделать. Клиент пусть сам выбирает, какой тип сжатия он будет использовать.
Один важный момент, который я вынес из этой темы. Не нужно ставить сжатие выше 3 или 4. Дальше идёт очень существенное падение производительности при незначительном уменьшении размера файлов. Я раньше бездумно ставил 9 и думал, что современные процессоры и так нормально вытягивают, если сервер не нагружен в потолок. Это не так. Смысла в высокой компрессии нет.
#webserver #angie
По этому поводу вышел очень информативный ролик на ютубе:
⇨ Zstd (Zstandard): новый стандарт сжатия текста. Полный тест
Автор не только показал, как настроить zstd на веб сервере, но и сравнил его эффективность с привычными gzip и brotli. Результаты тестирования в динамическом сжатии получились очень любопытные. Zstd оказался лучше всех. Но если разница с brotli не сильно заметна, то вот gzip на фоне остальных выглядит очень медленным. Буквально в разы в некоторых случаях.
Я решил провести свои тесты, чтобы убедиться в такой большой разнице. Сразу скажу, что если не настроено https, то браузеры не будут использовать ни brotli, ни zstd. Не знаю, с чем это связано, но я потратил некоторое время, пока не разобрался с тем, почему не работает ничего, кроме gzip. И второй момент. Если на веб сервере настроены все 3 типа сжатия, то разные браузеры выбирают разное сжатие: либо brotli, либо zstd. Gzip не выбирает никто.
Тестировал так же, как и автор ролика. Установил Angie и оба модуля сжатия:
# 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" | tee /etc/apt/sources.list.d/angie.list > /dev/null# apt update && apt install angie angie-module-zstd angie-module-brotliПодключил оба модуля в angie.conf:
load_module modules/ngx_http_zstd_static_module.so;load_module modules/ngx_http_zstd_filter_module.so;load_module modules/ngx_http_brotli_static_module.so;load_module modules/ngx_http_brotli_filter_module.so;И добавил для них настройки:
gzip on; gzip_static on; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf; gzip_comp_level 4; gzip_proxied any; gzip_min_length 1000; gzip_vary on; brotli on; brotli_static on; brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf; brotli_comp_level 4; zstd on; zstd_static on; zstd_min_length 256; zstd_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf; zstd_comp_level 4;Если использовать ванильный Nginx, то придётся самостоятельно собирать его с нужными модулями 🤷♂️
Тестировал с помощью ab, передавая ему метод компрессии через заголовок:
# ab -n 1000 -k -c 1 -H "Accept-Encoding: zstd" https://10.20.1.36/scripts.jsНе буду приводить свои результаты, так как они получились примерно такие же, как у автора ролика, только разница между zstd и brotli с компрессией 4 поменьше. Zstd по rps (247) быстрее всех. Brotli чуть лучше жмёт в плане объёма, то есть трафик будет ниже, но и rps (211) немного меньше, чем у zstd.
В Angie очень легко настроить и brotli, и zstd, и gzip, так что имеет смысл это сделать. Клиент пусть сам выбирает, какой тип сжатия он будет использовать.
Один важный момент, который я вынес из этой темы. Не нужно ставить сжатие выше 3 или 4. Дальше идёт очень существенное падение производительности при незначительном уменьшении размера файлов. Я раньше бездумно ставил 9 и думал, что современные процессоры и так нормально вытягивают, если сервер не нагружен в потолок. Это не так. Смысла в высокой компрессии нет.
#webserver #angie
Если обратиться к веб серверу на базе Nginx по IP адресу, то увидите либо первый виртуальных хост в конфигурации, либо тот, где указана директива default в параметре listen. Показывать виртуальный хост не очень хочется, поэтому обычно на IP адрес ставят какую-то заглушку. Например, так:
С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
Используем его:
Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
Объединил для удобства оба протокола. Ключевой момент тут в настройке
Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
server { listen 80 default_server; server_name _; return 404;}С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
server { listen 443 ssl default_server; server_name _; return 404;}То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/certs/nginx.key -out /etc/nginx/certs/nginx.crtИспользуем его:
server { listen 443 ssl default_server; server_name _; ssl_certificate /etc/nginx/certs/nginx.crt; ssl_certificate_key /etc/nginx/certs/nginx.key; return 404;}Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
server { listen 80 default_server; listen 443 ssl default_server; server_name _; ssl_reject_handshake on; return 404;}Объединил для удобства оба протокола. Ключевой момент тут в настройке
ssl_reject_handshake on. Когда она включена, веб сервер отклоняет все попытки соединения, где адрес сервера не совпадает с тем, что указано в директиве server_name. Тут у нас в этой директиве _, так что все соединения будут сразу отклоняться. Пользователь сразу увидит ошибку без необходимости выполнять какие-либо действия. Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie