Настройка журнала доступа
Каждый раз, когда клиентский запрос обрабатывается, Nginx генерирует новое событие в журнале доступа. Каждая запись события содержит отметку времени и включает различную информацию о клиенте и запрошенном ресурсе. Журналы доступа могут показать вам местоположение посетителей, страницу, которую они посещают, сколько времени они проводят на странице и многое другое.
Директива позволяет вам определять формат регистрируемых сообщений. Директива включает и устанавливает расположение файла журнала и используемый формат.
Самый простой синтаксис директивы следующий:
Где — это полный путь к файлу журнала, а — формат, используемый файлом журнала.
Журнал доступа можно включить в блоке , или .
По умолчанию журнал доступа глобально включен в директиве в основном файле конфигурации Nginx.
/etc/nginx/nginx.conf
Для удобства чтения рекомендуется создавать отдельный файл журнала доступа для каждого серверного блока. Директива установленная в директиве директиву, установленную в директиве (более высокого уровня).
/etc/nginx/conf.d/domain.com.conf
Если формат журнала не указан, Nginx использует предопределенный комбинированный формат, который выглядит следующим образом:
Чтобы изменить формат ведения журнала, отмените настройку по умолчанию или определите новую. Например, чтобы определить новый формат ведения журнала с именем custom, который расширит комбинированный формат значением, показывающим заголовок добавьте следующее определение в директиву или :
Чтобы использовать новый формат, укажите его имя после файла журнала, как показано ниже:
Хотя журнал доступа предоставляет очень полезную информацию, он занимает дисковое пространство и может повлиять на производительность сервера. Если на вашем сервере мало ресурсов и у вас загруженный веб-сайт, вы можете отключить журнал доступа. Чтобы сделать это, установите значение директиву :
FPM
SAPI, он же Server API. В php есть несколько таких API для разных вариантов его работы:
-
CLI SAPI — в качестве консольной команды `php` для запуска наших кронов и других cli-программ (Command Line Interface)
-
apxs2 SAPI — в качестве модуля к apache2
-
CGI SAPI — в качестве запускаемого на каждом запросе CGI (сейчас так почти никто не делает)
-
FPM SAPI — Fast Process Manager, написанный для PHP разработчиками из комании Badoo и теперь поддерживаемый сообществом
Работа с FPM отличается от работы с Apache в первую очередь тем, что FPM — это только PHP. Это не веб-сервер, не что-то умное. Это наоборот — максимально простой, легкий и быстрый менеджер процессов для PHP. В отличие от апача, он даже не использует http-протокол, а работает со специальным fastcgi-протоколом. В первую очередь FPM быстрее обрабатывает запросы благодаря его легковесности и простоте.
Во вторую очередь, FPM действительно умный менеджер процессов. Он контролирует количество работающих PHP-процессов, частоту их перезапуска для борьбы с утечками памяти (да, модули php как и всегда текут) и прочие простые вещи, необходимые для контроля сервера.
Нужно помнить, что независимо от того, какое SAPI вы используете, будь то модуль Apache, CGI или PHP-FPM — это не отнимает ни каких особенностей php. А первая его особенность:
-
Один процесс одновременно обрабатывает один запрос. Это абсолютно так же свойственно для PHP-FPM, как и для Apache.
-
Количество процессов определяет, сколько одновременно может «висеть» запросов в обработке.
-
Точно также, как и Apache, FPM подвержен DoS-атакам путем «длительных запросов». Допустим, у Вас на сервере работает не более 50-ти процессов PHP-FPM, а это значит, что если 50 пользователей одновременно начнут делать upload файла (пусть даже небольшого, но главное, чтобы они делали это медленно) — пятьдесят первый пользователь получит ошибку 504, т.к. FPM не возьмет его запрос на обработку, пока не разберется с теми, что у него уже есть.
Подготовка сервера
На сервере нужно, предварительно, выполнить следующие настройки.
Время
Для правильной фиксации времени логов, необходимо настроить его синхронизацию.
Сначала задаем правильный часовой пояс:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* в данном примере мы использовали московское время.
Затем устанавливаем и запускаем chrony.
а) на системе CentOS / Red Hat:
yum install chrony
systemctl enable chronyd
systemctl start chronyd
б) на системе Ubuntu / Debian:
apt-get install chrony
systemctl enable chrony
systemctl start chrony
Брандмауэр
Если используется брандмауэр, необходимо открыть порты TCP/UDP 514.
а) с помощью firewalld:
firewall-cmd —permanent —add-port=514/{tcp,udp}
firewall-cmd —reload
б) с помощью iptables:
iptables -A INPUT -p tcp —dport 514 -j ACCEPT
iptables -A INPUT -p udp —dport 514 -j ACCEPT
в) с помощью ufw:
ufw allow 514/tcp
ufw allow 514/udp
ufw reload
SELinux
Проверяем, работает ли в нашей системе SELinux:
getenforce
Если мы получаем в ответ:
Enforcing
… необходимо либо настроить SELinux:
semanage port -m -t syslogd_port_t -p tcp 514
semanage port -m -t syslogd_port_t -p udp 514
… либо отключить его командами:
setenforce 0
sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config
Установка phpmyadmin
Кратко расскажу про установку phpmyadmin в контексте данной статьи. Подробно не буду останавливаться на этом, так как статья и так получается очень объемная, а я еще не все рассказал. Вопрос настройки phpmyadmin я очень подробно рассмотрел отдельно. За подробностями можно сходить туда.
Устанавливаем phpmyadmin через yum. Если ранее все сделали правильно, то конфликтов с зависимостями быть не должно.
# yum install phpmyadmin
Phpmyadmin по-умолчанию сконфигурирована для работы с httpd. Для того, чтобы в будущем автоматически обновлять ее, просто сделаем символьную ссылку из директории с исходниками панели в наш виртуальный хост.
# rm -df /web/sites/p1m2a.zeroxzed.ru/www # ln -s /usr/share/phpMyAdmin /web/sites/p1m2a.zeroxzed.ru/www
Выставляем правильные права на директорию с php сессиями. Без этого работать phpmyadmin не будет.
# chown nginx:nginx /var/lib/php/session/
Можно заходить и проверять работу phpmyadmin. Ее установка закончена.
Дашборд Zabbix для Web сервера
Как и обещал, в завершении статьи по настройке мониторинга web сервера, показываю пример своего дашборда в zabbix для мониторинга bitrix сайта. Картинка очень большая, по клику открывается полная версия, если открыть в новой вкладке.
В самом верху список текущих проблем. В настоящий момент висит активный триггер о ssh подключению к серверу. Описание его настройки — мониторинг ssh подключений. Справа от списка проблем — мониторинг бэкапов в zabbix.
Ниже идут метрики с мониторинга web сайта. Выбирается контрольный набор из нескольких страниц (обычно 3-5) и настраивается мониторинг времени ответа и скорости загрузки этих страниц. Для этих параметров настроены триггеры, так как они очень важны. По сути, это ключевые метрики. Если с ними проблемы, надо внимательно смотреть web сервер и разбираться, в чем проблема. Мониторинг web сайта нужно настраивать минимум с двух независимых серверов zabbix, иначе вы не сможете отличить проблемы доступа с сервера мониторинга к сайту от реальных проблем сайта. Только если оба сервера мониторинга сигнализируют о проблемах, можно сделать однозначный вывод о том, что с сайтом и web сервером что-то не так.
Дальше идут метрики из шаблонов, которые я рассмотрел в этой статье. Если у вас вместо apache используется php-fpm, то все примерно то же самое, только в самом низу метрики от php-fpm. Не буду приводить пример с ним, чтобы не загромождать статью. Думаю, приведенного дашборда и так достаточно.
В принципе, сюда можно было бы добавить информацию по I/O дисков, инфу с сетевого стека, данные Mysql. Не стал этого делать, так как это обзорный dashboard, который беглым просмотром позволяет оценить состояние сервера. Так же этот дашборд можно показать заказчику. Для более глубокого анализа проблем, нужно собирать отдельную панель.
Установка phpmyadmin на CentOS 7
Для удобства управления базами веб сайтов я всегда использую phpmyadmin. Установим ее:
# yum install -y phpmyadmin
Копируем файлы панели в наш виртуальный домен, созданный ранее:
# cp -R /usr/share/phpMyAdmin/* /web/sites/pma.site1.ru/www # chown -R nginx:nginx /web/sites/pma.site1.ru/www
Заходим по адресу http://pma.site1.ru/ и проверяем, все ли в порядке.
У меня при первом запуске в браузере открылся просто белый лист. Начал разбираться в чем дело. В логе ошибок nginx этого виртуального хоста увидел ошибку:
Немного погуглил на эту тему и нашел, в чем причина ошибки. Проблема с директорией для файлов сессий. Чтобы исправить ошибку, создаем эту директорию и выставляем на нее нужные права:
# cd /var/lib/php/ # mkdir session # chown nginx:nginx session/
После этого загрузилась панель phpmyadmin:
Более подробную информацию об установке и настройке phpmyadmin смотрите в отдельной статье.
На этом все, настройка nginx + php-fpm на CentOS7 закончена.
Онлайн курс по Linux
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Что даст вам этот курс:
- Знание архитектуры Linux.
- Освоение современных методов и инструментов анализа и обработки данных.
- Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
- Владение основными рабочими инструментами системного администратора.
- Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
- Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
Установка
Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.
Измени строку приветствия Web-сервера
Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:
Замени их на что-то вроде этого:
Удали все неиспользуемые тобой nginx-модули
Некоторая часть модулей nginx подключается к Web-серверу прямо во время компиляции, и любой из них таит в себе потенциальную опасность. Возможно, в будущем в одном из них будет найдена уязвимость, и твой сервер окажется под угрозой. Отключив ненужные модули, ты сможешь значительно снизить риск возникновения такой ситуации.
Выполни сборку с помощью следующих команд:
Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘—help’.
Объяснение
SQL Server не удалось открыть указанный файл из-за указанной ошибки ОС.
Если SQL Server не удается открыть базу данных и (или) файлы журнала транзакций, в событии приложения Windows или в журнале ошибок SQL Server может появиться сообщение об ошибке 17207. Вот пример такого сообщения.
Эти ошибки могут возникнуть во время запуска экземпляра SQL Server или любой операции с базой данных, при которой выполняется попытка запустить базу данных (например, ALTER DATABASE). В некоторых сценариях могут возникнуть ошибки 17207 и 17204, а в других случаях может возникнуть только одна из них.
Если такие ошибки происходят в пользовательской базе данных, она остается в состоянии RECOVERY_PENDING, а приложения не могут получить доступ к базе данных. Если такие ошибки происходят в системной базе данных, экземпляр SQL Server не запускается и вы не можете подключиться к SQL Server. Это также может привести к тому, что ресурс отказоустойчивого кластера SQL Server перейдет в режим «вне сети».
Если проблема связана с файловой группой FileStream в SQL Server, вы увидите, что вместо имени файла указан только полный путь к каталогу. Ниже приведен пример.
Как читать логи. Пример
Существует довольно много форматов записи, combined — один из наиболее распространенных. В нем строчка кода может выглядеть так:
%h %l %u %t \»%r\» %>s %b \»%{Referer}i\» \»%{User-Agent}i\»
Директивы имеют следующее значение:
- %h — IP-адрес, с которого был сделан запрос;
- %l — длинное имя удаленного хоста;
- %u — удаленный пользователь, если запрос был сделан аутентифицированным юзером;
- %t — время запроса к серверу и его часовой пояс;
- %r — тип и содержимое запроса;
- %s — код состояния HTTP;
- %b — количество байт информации, отданных сервером;
- %{Referer} — URL-источник запроса;
- %{User-Agent} — HTTP-заголовок.
Еще один пример чтения логов можно посмотреть в статье «Как читать логи сервера».
Опытные веб-мастера для сбора и чтения лог-файлов используют программы-анализаторы. Они позволяют читать логи сервера без значительных временных затрат. Вот некоторые из наиболее востребованных:
- Analog. Один из самых популярных анализаторов, что во многом объясняется высокой скоростью обработки данных и экономным расходованием системных ресурсов. Хорошо справляется с объемными записями, совместим с любыми ОС.
- Weblog Expert. Программа доступна в трех вариациях: Lite (бесплатная версия), Professional и Standard (платные релизы). Версии отличаются функциональными возможностями, но каждая позволяет анализировать лог-файлы и создает отчеты в PDF и HTML.
- SpyLOG Flexolyzer. Простой аналитический инструмент, позволяющий получать отчеты с высокой степенью детализации. Интегрируется c системой статистики SpyLOG, позволяет решать задачи любой сложности.
Cron logs
Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.
Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.
cron.* /var/log/cron.log
По умолчанию, она присутствует в конфиге, но закомментирована. Вам нужно убрать # в начале строки, чтобы раскомментировать ее. Так же я рекомендую сделать так, чтобы эти логи не дублировались в общий системный лог. Для этого немного измените следующую строку.
*.*;auth,authpriv.none,cron.none -/var/log/syslog
Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.
sudo systemctl restart rsyslog sudo systemctl restart cron
Проверяем cron.log
sudo cat /var/log/cron.log
Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.
Источник ошибок Error_log.dll
Как правило, error_log.dll проблемы атрибут поврежденного/отсутствующего error_log.dll. Как внешний файл (error_log.dll), это делает проблемы Third-Party Application более вероятными.
Проблемы с Third-Party Application из-за нерегулярного завершения работы ОС, заражения вирусами или других проблем, связанных с error_log.dll, приводят к повреждению. Повреждение файла error_log.dll плохо загружает его, что приводит к ошибкам Third-Party Application.
Редко проблемы с записями реестра Windows для Third-Party Application могут вызвать ошибку error_log.dll. Недопустимые ссылки препятствуют правильной регистрации error_log.dll, создавая проблемы с Third-Party Application. Неверная установка/удаление Third-Party Application, error_log.dll, который перемещен, или отсутствующий error_log.dll может создать эти неработающие ссылки на путь к файлам.
В первую очередь, проблемы с error_log.dll, созданные:
- Недопустимая (поврежденная) запись реестра error_log.dll.
- Файл error_log.dll поврежден от заражения вредоносными программами.
- Аппаратный сбой, связанный с Windows Software Developer, например видеокарта, повреждает error_log.dll.
- Требуется версия другого программного обеспечения перезаписала версию error_log.dll.
- error_log.dll ошибочно удален (или злонамеренно) несвязанным приложением Third-Party Application.
- error_log.dll злонамеренно (или ошибочно) удален другой мошенникой или действительной программой.
Установка php-fpm 7.1
Установка и настройка 7-й версии php на centos не очень простая задача. Ранее я уже рассказывал как обновить php до 7-й версии, но в итоге откатился назад. Прошло прилично времени и откатываться уже не будем, так как большинство проблем исправлены.
Вторая проблема в том, что надо определить, какой репозиторий использовать для установки php7. Их существует очень много. К примеру, мой хороший знакомый в своей статье по настройке web сервера использует репозиторий Webtatic. В принципе, чтобы просто поставить php 7-й версии это нормальный вариант. Но если вы после этого захотите установить phpmyadmin через yum уже ничего не получится. Будет ошибка зависимостей, которые нужно будет как-то руками разбирать.
То же самое будет и с другими пакетами. К примеру, zabbix без плясок с бубнами скорее всего не встанет. В сторонних репозиториях есть еще одна проблема. Иногда они закрываются. И это станет для вас большой проблемой на боевом сервере. Так что к выбору репозитория нужно подходить очень аккуратно и внимательно. Я до сих пор иногда встречаю настроенные сервера centos 5 с очень популярным в прошлом репозиторием centos.alt.ru, который закрылся. Сейчас это уже не так актуально, так как таких серверов осталось мало, но некоторое время назад мне это доставляло серьезные неудобства.
Для установки свежей версии php я буду использовать репозиторий Remi. Это известный и популярный репозиторий, который ведет сотрудник RedHat. И хотя надежность репозитория, который ведет один человек не так высока, но ничего лучше и надежнее remi лично я не нашел для своих целей. Если вы можете что-то посоветовать на этот счет — комментарии в вашем распоряжении. Буду благодарен за дельный совет.
Подключаем remi репозиторий для centos 7.
# rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm
Я получил ошибку:
Retrieving http://rpms.remirepo.net/enterprise/remi-release-7.rpm
warning: /var/tmp/rpm-tmp.nwcDV1: Header V4 DSA/SHA1 Signature, key ID 00f97f56: NOKEY
error: Failed dependencies:
epel-release = 7 is needed by remi-release-7.3-2.el7.remi.noarch
Тут все понятно, нужен репозиторий epel. Те, кто готовили сервер по моей статье по базовой настройке сервера его уже подключили, а те кто не делали этого, подключают сейчас:
# yum install epel-release
После этого повторяем установку remi, все должно пройти нормально. Проверим список подключенных репозиториев.
# yum repolist
У меня такая картинка получилась.
Активируем репу remi-php71, для этого выполняем команду:
# yum-config-manager --enable remi-php71
Если получаете ошибку:
bash: yum-config-manager: command not found
то установите пакет yum-utils.
# yum install yum-utils
Теперь устанавливаем php7.1.
# yum install php71
Установим php-fpm и наиболее популярные модули, которые могут пригодится в процессе эксплуатации веб сервера.
# yum install php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-pecl-memcache php-opcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip
Запускаем php-fpm и добавляем в автозагрузку.
# systemctl start php-fpm # systemctl enable php-fpm
Проверяем, запустился ли он.
# netstat -tulpn | grep php-fpm tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 9084/php-fpm: maste
Все в порядке, повис на порту 9000. Запустим его через unix сокет. Для этого открываем конфиг /etc/php-fpm.d/www.conf и комментируем строку:
;listen = 127.0.0.1:9000
Вместо нее добавляем несколько других:
listen = /var/run/php-fpm/php-fpm.sock listen.mode = 0660 listen.owner = nginx listen.group = nginx
Заодно измените пользователя, от которого будет работать php-fpm. Вместо apache укажите nginx.
user = nginx group = nginx
Перезапускаем php-fpm.
# systemctl restart php-fpm
Проверяем, стартовал ли указанный сокет.
# ll /var/run/php-fpm/php-fpm.sock srw-rw----. 1 nginx nginx 0 Oct 26 18:08 /var/run/php-fpm/php-fpm.sock
На текущий момент с настройкой php-fpm закончили, двигаемся дальше.
Для того, чтобы проверить работу нашего веб сервера, нужно установить ssl сертификаты. Без них nginx с текущим конфигом не запустится. Исправляем это.
Выводы
Применив описанные в статье рекомендации, ты получишь гораздо более защищенный Web-сервер. Но имей в виду, что не все техники подойдут к твоей конфигурации. Например, защита от брутфорса, основанная на урезании размеров буферов, выделяемых nginx под обработку запросов клиентов, может привести к падению производительности, а в некоторых случаях и к сбоям в обработке запросов. Ограничение на количество подключений нанесет сильный удар по производительности даже средненагруженного Web-сайта, но принесет пользу, если страница имеет низкий поток посетителей. Всегда проверяй, как внесенные тобой изменения повлияли на производительность и общую работоспособность Web-страницы.
О герое дня
Nginx – один самых производительных и популярных Web-серверов в мире. Согласно данным Netcraft, он используется для поддержки более чем 12 миллионов Web-сайтов по всему миру, включая таких мастодонтов как Rambler, Yandex, Begun, WordPress.com, Wrike, SourceForge.net, vkontakte.ru, megashara.com, Либрусек и Taba.ru. Грамотная архитектура, основанная на мультиплексировании соединений с помощью системных вызовов select, epoll (Linux), kqueue (FreeBSD) и механизме управления памятью на основе пулов (небольших буферов от 1 до 16 Кб), позволяет nginx не проседать даже под очень высокими нагрузками, выдерживая свыше 10000 одновременных соединений (так называемая проблема C10K). Изначально написан Игорем Сысоевым для компании Rambler и открыт в 2004 году под BSD-подобной лицензией.
Взято с xakep.ru
