Едва ли сегодня найдется системный администратор, который не слышал про NGINX — программу, способную выполнять очень много функций, от кэширования и отдачи статического контента сайта до балансировки нагрузки и построения узлов CDN.
Правильная настройка NGINX влияет на работоспособность и производительность использующих его сайтов.
Из нашей статьи вы узнаете, как установить NGINX в ОС Debian и настроить мониторинг этой программы с помощью SAAS-сервиса NGINX Amplify, а также с помощью Zabbix.
Если на вашем сервере есть панель, такая как ISPmanager или Hestia Control Panel, то, скорее всего, NGINX уже установлен. Вы можете проверить это такой командой:
# systemctl status nginx
Если NGINX отсутствует, то вы увидите сообщение:
Unit nginx.service could not be found.
При наличии на сервере упомянутых выше панелей следует устанавливать NGINX только через них. Если же панелей нет, то установите NGINX, как описано в документации.
Далее мы привели краткую инструкцию по установке, опустив проверку ключа:
# apt install curl gnupg2 ca-certificates lbs.-release debian-archive-keyring
# curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
# echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/debian `lsb_release -cs` nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list
# apt update
# apt install nginx
Для запуска NGINX используйте команду systemctl:
# systemctl start nginx
# systemctl enable nginx
Проверить состояние NGINX можно с помощью той же команды, что и при проверке на наличие программы в панели:
# systemctl status nginx
Если все хорошо, то сервис nginx будет в состоянии active (running) и enabled:
● nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-09-26 15:33:34 MSK; 2s ago
Docs: https://nginx.org/en/docs/
Process: 1951723 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Main PID: 1951724 (nginx)
Tasks: 5 (limit: 4676)
Memory: 3.9M
CPU: 20ms
CGroup: /system.slice/nginx.service
├─1951724 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
├─1951725 nginx: worker process
├─1951726 nginx: worker process
├─1951727 nginx: worker process
└─1951728 nginx: worker process
Здесь видно, что файл конфигурации NGINX /etc/nginx/nginx.conf
передается программе /usr/sbin/nginx
при запуске сервиса.
Если сервис запущен, то работает один мастер-процесс, а также несколько рабочих процессов (в нашем случае их четыре). Количеством рабочих процессов можно управлять, редактируя файл конфигурации с последующим перезапуском сервиса nginx.
Файлы конфигурации NGINX находятся в каталоге /etc/nginx и его подкаталогах. Основной файл конфигурации etc/nginx/nginx.conf
подключает файлы конфигурации, расположенные в подкаталогах каталога /etc/nginx
. Состав этих подкаталогов может изменяться, если на сервере установлена панель управления, например, ISPmanager.
Когда мы будем подключать мониторинг NGINX, а также оптимизировать эту программу для повышения производительности, нам потребуется редактировать файлы конфигурации.
В каталоге /etc/nginx
есть ряд файлов и каталогов:
# ls -1 /etc/nginx
conf.d
fastcgi.conf
fastcgi_params
koi-utf
koi-win
mime.types
modules
modules-enabled
nginx.conf
proxy_params
scgi_params
sites-available
sites-enabled
snippets
uwsgi_params
win-utf
В каталоге conf.d находятся файлы конфигурации, которые включаются в основной файл nginx.conf с помощью оператора include:
include /etc/nginx/conf.d/*.conf;
Этот оператор добавляет все файлы с расширением имени conf к основному файлу конфигурации.
Каталог sites-available содержит файлы конфигурации для виртуальных хостов, а каталог sites-enabled — ссылки на эти файлы конфигурации для активных хостов.
Если на сервере установлена панель ISPmanager, к перечисленному выше каталогу добавляются еще несколько:
vhosts
vhosts-includes
vhosts-resources
Они подключаются к основному файлу конфигурации nginx:
include /etc/nginx/vhosts/*/*.conf;
В каталоге vhosts содержатся файлы конфигурации сайтов, принадлежащих пользователям. Что же касается каталога vhosts-includes, то там находятся дополнительные файлы конфигурации, которые панель ISPmanager записывает при установке таких сайтов и систем, как phpMyAdmin, Roundcube, awstats и аналогичных:
awstats-nginx.conf
blacklist-nginx.conf
disabled.conf
letsencrypt.conf
phpmyadmin-nginx.conf
roundcube-nginx.conf
В других панелях управления сервером состав, назначение и расположение файлов конфигурации NGINX может быть иным.
Чтобы контролировать работу NGINX с помощью Zabbix или SAAS-сервиса NGINX Amplify, необходимо добавить в конфигурацию NGINX следующий блок:
server {
listen 127.0.0.1:80;
server_name 127.0.0.1;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
Запишите эту конфигурацию в файл /etc/nginx/conf.d/stub_status.conf
, а затем проверьте её, перезапустите сервис nginx и убедитесь, что он работает:
# nginx -t
# systemctl restart nginx
# systemctl status nginx
Если на сервере установлена панель ISPmanager, запишите этот файл в каталог /etc/nginx/vhosts-includes/
вместо каталога /etc/nginx/conf.d/
.
Далее с помощью curl проверьте доступность сайта http://127.0.0.1/nginx_status:
$ curl http://127.0.0.1/nginx_status
Если все сделано правильно, вы увидите на консоли такие строки (у вас будут другие цифры):
Active connections: 185
server accepts handled requests
3801461 3801356 11950677
Reading: 0 Writing: 16 Waiting: 171
Теперь отредактируйте формат журналов доступа и ошибок в файле /etc/nginx/nginx.conf
. Сразу после установки NGINX в этом файле журнал ошибок, журнал доступа, а также формат журнала определены так:
error_log /var/log/nginx/error.log notice;
access_log /var/log/nginx/access.log main;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
Закройте символом комментария определение журнала доступа и определение пути к журналу access_log, добавив другие определения:
log_format main_ext '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' '"$host" sn="$server_name" ' 'rt=$request_time ' 'ua="$upstream_addr" us="$upstream_status" ' 'ut="$upstream_response_time" ul="$upstream_response_length" ' 'cs=$upstream_cache_status' ;
# access_log /var/log/nginx/access.log main;
access_log /var/log/nginx/access.log main_ext;
После внесения изменений проверьте конфигурацию NGINX и перезапустите сервис, как мы это делали раньше.
SAAS-сервис NGINX Amplify от создателей NGINX несложен в подключении, бесплатен при добавлении до 5 узлов и обладает большими возможностями мониторинга. Этот сервис выполняет сбор статистики при помощи собственного агента, который потребуется установить на контролируемый сервер.
Если нужно контролировать много узлов или хочется все держать в своих руках, а также если у вас уже имеются серверы Zabbix, возможно, вам больше подойдет мониторинг NGINX при помощи Zabbix, о чем мы расскажем ниже в этой статье.
Прежде чем приступить к установке агента NGINX Amplify, необходимо установить NGINX и настроить сбор метрик NGINX, как это было описано ранее в нашей статье.
Обратите внимание, что в процессе установки будет добавлен файл репозитория /etc/apt/sources.list.d/nginx-amplify.list
.
Если на сервере установлена панель управления, такая как ISPmanager, убедитесь, что эта операция не приведет к конфликтам. В том случае, когда разработчики панели управления сервером не гарантируют совместимость с агентом NGINX Amplify, рассмотрите возможность использования для мониторинга NGINX средств Zabbix.
На момент написания этой статьи поддержка компании ISPsystem ответила, что совместимость NGINX Amplify с ISPmanager 6 не тестировалась, а добавлять сторонние репозитории не рекомендуется.
Если панели ISPmanager на сервере нет, приступим к установке. Зарегистрируйтесь на сайте https://amplify.nginx.com/. После регистрации на экране появится инструкция для установки агента NGINX Amplify на контролируемый сервер (рис. 1).
Прежде всего в этой инструкции предлагается скачать скрипт установки агента. Для Debian можно использовать команду wget:
# wget https://github.com/nginxinc/nginx-amplify-agent/raw/master/packages/install.sh
Далее запустите скрипт установки (часть ключа мы закрыли символами «», у вас будет свой ключ):
# API_KEY='485*********************6f5' sh ./install.sh
Если установка прошла успешно, то примерно через одну минуту на странице сервиса появится информация о состоянии добавленного узла (рис. 2).
В данном случае показаны графики для тестового узла, нагруженные при помощи сервиса https://loaddy.com/. Ошибки на графике NGINX HTTP Errors появились из-за попыток доступа сервиса к несуществующей странице.
Полная документация по установке и настройке NGINX Amplify доступна на сайте проекта.
SAAS-сервис NGINX Amplify анализирует значительное количество метрик, имеющих отношение к NGINX, к операционной системе, собирает метрики PHP-FRM, метаданные NGINX, а также информацию об операционной системе, такую как имя узла, время uptime и так далее.
Полный список метрик можно найти здесь.
С помощью веб-интерфейса NGINX Amplify, доступного зарегистрированным пользователям, удобно просматривать текущее состояние сервиса NGINX и узлов, на которых он запущен. Также можно получить сведения о конфигурации NGINX и ОС, и, что ценно, рекомендации по настройке конфигурации NGINX.
Веб-интерфейс состоит из нескольких страниц, описанных в документации.
Overview
По содержимому страницы Overview вы можете быстро определить состояние вашей системы — посмотреть общее количество запросов, ошибок с кодом 5xx, среднее время запросов, трафик, а также использование CPU.
Graphs
На странице Graphs можно просмотреть предопределенный набор графиков, отражающих состояние основных метрик, как для NGINX, так и для системы.
Dashboards
Открыв страницу Dashboards, вы сможете создать и настроить панели с графиками нужных вам метрик.
Тут можно создать новые наборы данных для графиков, новые графики и добавить в мониторинг новые значения.
Analyzer
На этой странице можно получить отчеты по конфигурации выбранной системы, а также рекомендации по настройке параметров в файле конфигурации NGINX с точки зрения повышения производительности и улучшения безопасности.
Alerts
На странице Alerts можно создать правила оповещения о событиях, требующих реакции. Извещения могут быть отправлены на электронную почту или в Slack.
С помощью шаблона Nginx by Zabbix agent можно очень просто организовать мониторинг NGINX. К сожалению, от такого мониторинга вы не получите рекомендаций по настройке конфигурации NGINX, однако упомянутый шаблон содержит необходимые метрики и триггеры. Анализируя метрики, можно оптимизировать настройки NGINX вручную.
Кроме того, мониторинг Zabbix можно использовать в тех случаях, когда SAAS-сервис NGINX Amplify не применим по тем или иным причинам.
Описание шаблона можно найти в документации.
Настройка мониторинга с помощью шаблона Nginx by Zabbix agent заключается в подключении этого шаблона к узлу, где работает NGINX, а также в добавлении файла конфигурации с таким содержимым:
location = /basic_status {
stub_status;
allow 127.0.0.1;
allow ::1;
deny all;
}
Вы можете записать эту конфигурацию в файл /etc/nginx/conf.d/stub_status.conf
, как мы это делали при настройке NGINX для NGINX Amplify.
При использовании на сервере панели ISPmanager запишите файл stub_status.conf в каталог /etc/nginx/vhosts-includes
.
После добавления файла проверьте конфигурацию, перезапустите сервис nginx и убедитесь, что он работает:
# nginx -t
# systemctl restart nginx
# systemctl status nginx
Далее с помощью curl проверьте доступность сайта по адресу http://127.0.0.1/basic_status:
$ curl http://127.0.0.1/basic_status
На консоли должна появиться такая информация:
Active connections: 238
server accepts handled requests
3963975 3963870 12559829
Reading: 0 Writing: 46 Waiting: 229
Если вы сделали настройки, как это было описано в предыдущем разделе статьи, вам, скорее всего, не придется изменять макросы шаблона Nginx by Zabbix agent (рис. 3).
При необходимости вы можете изменить параметры, определяющие подключение к сайту сбора метрик NGINX — {$NGINX.STUB_STATUS.HOST}, {$NGINX.STUB_STATUS.PATH} и {$NGINX.STUB_STATUS.PORT}.
Например, если вы раньше настраивали этот сайт для NGINX Amplify, то в макросе {$NGINX.STUB_STATUS.PATH} вместо basic_status укажите nginx_status.
Параметр {$NGINX.DROP_RATE.MAX.WARN} определяет порог срабатывания триггера, сигнализирующего о потерянных соединениях, а параметр {$NGINX.RESPONSE_TIME.MAX.WARN} — максимальное время ответа для использования в триггерах.
В шаблоне Nginx by Zabbix agent определены все метрики, необходимые для контроля работоспособности и производительности NGINX (рис. 4).
Это состояние сервиса, время его ответа, количество дочерних процессов, запущенных сервисом NGINX, память, зарезервированная для NGINX и использованная этим сервисом, использование CPU, а также параметры, имеющие отношение к соединениям, которые клиенты устанавливают с сервисом NGINX.
Полный перечень метрик вы найдете в описании агента.
В шаблоне Nginx by Zabbix agent определены триггеры, срабатывающие при возникновении ситуаций, требующих внимания системного администратора (рис. 5).
Самый высокий уровень важности High у триггера Nginx: Process is not running. Этот триггер срабатывает, когда сервис NGINX не активен. Возможно, он не запустился после изменения конфигурации и перезапуска из-за недостатка оперативной памяти или перестал работать по какой-то другой причине.
Средний уровень важности Average у триггера Nginx: Service is down, который устанавливается, если не запущен агент Nginx by Zabbix agent или если не работает сервис NGINX.
Остальным триггерам назначен уровень предупреждения Warning.
Срабатывание триггера Nginx: High connections drop rate говорит о том, что NGINX не успевает обрабатывать все соединения, и такая ситуация требует исследования и настройки конфигурации.
Триггер Nginx: Service response time is too high срабатывает, если время ответа NGINX больше, чем это определено в соответствующем макросе. Такая ситуация также требует проверки и оптимизации настроек конфигурации NGINX.
И, наконец, срабатывание триггера Nginx: Failed to fetch stub status page говорит о невозможности мониторинга состояния NGINX, так как сайт сбора метрик, такой как http://127.0.0.1/basic_status, не возвращает состояние NGINX. В этом случае нужно проверить настройки данного сайта.
В шаблоне имеются четыре графика с наиболее важной информацией NGINX, которые можно добавить в панель (рис. 6).
Это графики, имеющие отношение к соединениям, интенсивности запросов и установки соединений, а также к использованию оперативной памяти. Анализируя эти графики, а также факт срабатывания триггеров Nginx: High connections drop rate и Nginx: Service response time is too high, можно сделать заключение о необходимости оптимизации настроек сервиса NGINX.
Оптимизируя настройки сервиса NGINX, можно в десятки раз повысить скорость работы сайтов, размещенных на сервере.
Для изменения настроек сделайте резервную копию файла /etc/nginx/nginx.conf
, а затем отредактируйте его. Далее проверьте конфигурацию NGINX, перезапустите сервис и убедитесь, что он запустился:
# nginx -t
# systemctl restart nginx
# systemctl status nginx
Параметры описаны в документации. В данной статье приведены рекомендации по настройке параметров.
Также, возможно, вам будет полезна книга «The Complete NGINX Cookbook», которую можно загрузить бесплатно с сайта разработчика. Вопросы оптимизации рассмотрены там в главе 15.
Далее мы расскажем об основных настройках.
Как мы уже говорили, параметр worker_processes задает количество рабочих процессов NGINX, которые запускает мастер-процесс этого сервиса.
Вы можете задать количество процессов равное количеству ядер CPU в вашей системе, или позволить NGINX определить это количество автоматически, указав параметр auto:
worker_processes auto;
Количество ядер в системе можно определить при помощи команды lscpu:
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 40
On-line CPU(s) list: 0-39
…
Можно также использовать команду, которая покажет на консоли только количество ядер:
# grep processor /proc/cpuinfo | wc -l
40
По умолчанию NGINX допускает 512 одновременных соединений. Если умножить это значение на worker_processes, то получим максимальное количество клиентов, обслуживаемых NGINX одновременно.
Значение worker_connections рекомендуется установить равным максимальному количеству файловых дескрипторов, которое можно определить так:
# ulimit -n
1024
Ниже мы привели пример установки worker_connections:
worker_connections 1024;
Если нужно ускорить работу NGINX за счет сокращения обращений к диску, то в различных статьях рекомендуют либо совсем отключить журналы доступа и ошибок, либо добавить буферизацию журнала доступа.
Отключить журнал ошибок можно так:
#error_log /var/log/nginx/error.log warn;
error_log /dev/null error
Иногда рекомендуется записывать в журнал только критичные ошибки:
error_log /var/log/nginx/error.log crit;
Но надо сказать, что эти варианты едва ли приведут к значительной экономии ресурсов. К тому же так можно пропустить важные сообщения.
Для отключения журнала доступа используйте следующую конструкцию:
#access_log /var/log/nginx/access.log main;
access_log off;
Хороший способ сокращения количества обращений к диску за счет журнала доступа — включить его буферизацию:
access_log /var/log/nginx/access.log main buffer=32k;
Подробнее о логах и буферизации можно прочитать здесь.
Если вы используете для мониторинга NGINX Amplify, то при отключении журнала доступа и журнала ошибок мониторинг не получит полную информацию о состоянии NGINX.
Чтобы уменьшить объем передаваемых данных и ускорить загрузку в браузер содержимого текстовых страниц, скриптов и других файлов, добавьте в конфигурацию NGINX (для всего сервиса или только для отдельных сайтов) следующие строки:
gzip on;
gzip_comp_level 5;
gzip_disable "msie6";
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
В приведенном примере включается сжатие (компрессия) gzip, при этом уровень сжатия устанавливается равным 5 (можно указывать от 1 до 9, уровень 5 — оптимальный). Чем больше уровень сжатия, тем меньше передается данных, но тем больше тратится ресурсов процессора.
Строка «gzip_disable "msie6"» отключает сжатие для устаревшего браузера Microsoft IE 6.
С помощью оператора gzip_types вы можете перечислить типы данных, которые нужно сжимать перед отправкой клиенту.
Чтобы сократить трафик, можно кэшировать статический контент в браузере, добавляя заголовок Cache-control. Для этого можно использовать настройку expires:
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
expires 7d;
try_files $uri $uri/ @fallback;
}
Здесь данные перечисленных в location типов кэшируются браузером на 7 дней.
Подробнее об этой возможности читайте здесь.
Еще одна возможность касается кэширования контента на дисках сервера средствами NGINX. Этой теме можно было бы посвятить отдельную статью, а сейчас мы ограничимся ссылкой на соответствующий раздел документации и на статьи по этой теме:
Подключая кэширование контента на сервере при помощи NGINX, продумайте процедуру полной или выборочной очистки кэша.
При тестировании конфигурации командой «nginx -t» на консоль выводятся обнаруженные ошибки и предупреждения. Некоторые из них могут быть связаны с большим количеством сайтов, определенных в конфигурации NGINX.
Например, можно столкнуться с таким предупреждением:
nginx: [warn] could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 512 or server_names_hash_bucket_size: 64; ignoring server_names_hash_bucket_size
В данном случае помогло включение в конфигурацию NGINX следующих строк:
http {
...
server_names_hash_max_size 512;
server_names_hash_bucket_size 128;
...
}
Это решение было найдено здесь. Также эта ситуация описана в документации.
Сообщество NGINX очень большое, поэтому, если в предупреждении или сообщении об ошибке нет конкретных рекомендаций, вы всегда сможете найти ответ при помощи поиска.
на главную сниппетов