Введение
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
- Установка CentOS 8.
- Настройка CentOS 8.
- Установка и настройка zabbix сервера.
То же самое на Debian 10, если предпочитаете его:
- Установка Debian 10.
- Базовая настройка Debian.
- Установка и настройка zabbix на debian.
Я буду в своем примере настраивать все на CentOS 7, но в данном случае дистрибутив не имеет принципиального значения, все так же настраивается и на других linux системах с учетом их особенностей в установке пакетов и путей для конфигов и программ.
Мы будем использовать в качестве источника информации штатные возможности nginx, apache и php-fpm, затем передавать данные в zabbix сервер и там анализировать. Я подразумеваю, что nginx или apache вы уже настроили и имеете некое представление о работе его компонентов, поэтому некоторые вещи я не разжевываю, а просто говорю, что делать.
Второй вариант — «подружить» zabbix и soapui
Сразу уточню: Zabbix-сервер развёрнут на машине под управлением Linux.
Исходим из того, что SoapUI уже установлен на машине, где крутится Zabbix-сервер. Для примера возьмём некую Soap веб-службу с единственным методом getScore, который по запросу клиента возвращает некую структуру данных: секции с наименованием полей и секции с данными.
Чтобы понять, что веб-служба работает корректно, необходимо задать критерии:А) метод возвращает корректный ответ;Б) метод возвращает корректный состав полей в секции полей;В) метод возвращает не пустой набор данных (секции данных заполнены);Г) число полей в секциях полей и данных равны;
Первое, что нужно сделать – создать сам тест, которым планируем проверять корректность работы веб-службы. SoapUI позволяет создавать тестовые сценарии для полноценного тестирования веб-служб.
Как видно на скриншоте выше, проверки по критериям А и Б реализуются штатными средствами SoapUI. Для реализации проверок по критериям Б и Г придётся «пошаманить» с элементом SoapUI «Groovy Scripts».
Дашборд zabbix для web сервера
Как и обещал, в завершении статьи по настройке мониторинга web сервера, показываю пример своего дашборда в zabbix для мониторинга bitrix сайта. Картинка очень большая, по клику открывается полная версия, если открыть в новой вкладке.
В самом верху список текущих проблем. В настоящий момент висит активный триггер о ssh подключению к серверу. Описание его настройки – мониторинг ssh подключений. Справа от списка проблем – мониторинг бэкапов в zabbix.
Рекомендую сделать обе настройки. Первая очень помогает понимать, что происходит с сайтом и сервером, если с ним работают несколько человек. Если разработчик залез на сервер по ssh – жди беды. С бэкапами и так все понятно – без них никуда. Возможно как-нибудь отдельно напишу, как я бэкаплю сайты, чтобы защищаться от различного рода угроз и быстро восстанавливать функционирование сайта после сбоев.
Ниже идут метрики с мониторинга web сайта. Выбирается контрольный набор из нескольких страниц (обычно 3-5) и настраивается мониторинг времени ответа и скорости загрузки этих страниц. Для этих параметров настроены триггеры, так как они очень важны.
По сути, это ключевые метрики. Если с ними проблемы, надо внимательно смотреть web сервер и разбираться, в чем проблема. Мониторинг web сайта нужно настраивать минимум с двух независимых серверов zabbix, иначе вы не сможете отличить проблемы доступа с сервера мониторинга к сайту от реальных проблем сайта.
Дальше идут метрики из шаблонов, которые я рассмотрел в этой статье. Если у вас вместо apache используется php-fpm, то все примерно то же самое, только в самом низу метрики от php-fpm. Не буду приводить пример с ним, чтобы не загромождать статью. Думаю, приведенного дашборда и так достаточно.
В принципе, сюда можно было бы добавить информацию по I/O дисков, инфу с сетевого стека, данные Mysql. Не стал этого делать, так как это обзорный dashboard, который беглым просмотром позволяет оценить состояние сервера. Так же этот дашборд можно показать заказчику. Для более глубокого анализа проблем, нужно собирать отдельную панель.
Мониторинг php-fpm в zabbix
Теперь настраиваем мониторинг php-fpm на сервере zabbix. Действуем по аналогии с мониторингом nginx. Забираем страницу состояния php-fpm на сервер мониторинга и там его парсим в зависимых элементах данных.
С php-fpm будет один нюанс. Нам все-таки придется менять параметры zabbix agent. Настраивать мониторинг php-fpm очень легко, потому что он из коробки умеет отдавать все свои метрики в формате json. Это очень удобно, так как его не надо парсить регулярками. Достаточно только указать JSONpath для получения необходимой метрики.
Мониторинг web-сайта в zabbix | записки системного администратора
1.Для удобства создадим отдельную группу, например, с именем Sites
2. Добавляем сайт(по аналогии с хостом)
3.Создание сценария проверки сайта
Через пару минут проверем наличие данных в
4.Создание графиков мониторинга сайта
Добавляем график по времени ответа
Аналогично добавляем график скорости доступа к сайту Download speed выбирая в качестве источника данных
5.Создание триггера о недоступности сайта
Эти параметры означают, что если в проверке значение параметра web.test.fail не будет равно 0, что означает доступность сайта, то срабатывает триггер
Можно,например,создать второй триггер,который будет срабатывать при СРЕДНЕЙ загрузке сайта дольше 8 секунд в течение двух последних проверок и использовать уровень Warning
На вкладке Depedencies добавим наш первый триггер
111
Комментирование и размещение ссылок запрещено.
§
§
Мониторинг веб-сайта при помощи zabbix – osbsd
Задача:
Настроить мониторинг вебсайта при помощи системы мониторинга Zabbix
—————————————————————
Не углубляясь в детали, можно сразу отметить, что мониторинг веб сайтов сводится к созданию сценариев проверки на уровне шаблонов. А уже шаблоны можно применить к одному или нескольким узлам (агентам забикса), которые и будут проверять доступность сайта по созданным нами сценариям.
Забиксом можно проверять время отклика, код ответа, скорость загрузки, наличие определённых слов на странице и т.д.. Все собранный данные можно использовать для графиков, тригеров и оповещения.
Для настройки необходимо в главном меню выбрать: “Configuration > Templates” и в правом верхнем углу кнопкой “Create template” создаём новый шаблон.
Вводим название шаблона и добавляем его в какую-нибудь группу или создаём новый.
На только что созданном шаблоне, нажимаем ссылку “Web”
Переходим на ссылку в правом верхнем углу “Create web scenario” и добавляем новый сценарий для мониторинга сайта.
Указываем имя сценария, можно указвать имя сайта или другую удобную информацию. Заполняем имя приложения, придумайте любое, наделённое смыслом, интервал проверки и число попыток соединения.
Так как буду проверять главную страницу сайта, я указал имя “Index”. В “URL” указал адрес проверяемой страницы. “Follow redirects” даёт возможность следовать редиректам. К примеру если у вас настроет редирект с http на https. “Required string” – слово или выражение на странице, которую zabbix будет искать. Если zabbix найдет её, будет считать, что с сайтом все в порядке. В другом случае – выдаст ошибку.
Теперь необходимо прикрепить этот шаблон к агенту заббикса. Для проверки я буду использовать сам забикс-сервер. Идем в “Configuration > Hosts“, выбираем Zabbix Server и прикрепляем к нему шаблон.
Через несколько минут в последних данных (Latest Data) можно увидеть результаты мониторинга.
Добавить нужный график можно в созданном шаблоне, нажав на ссылку “Graphs” и далее в верхнем углу “create graph”.
Для примера создам график отображающий скорость загрузки главной страницы
Результаты его можно увидеть в мониторинга хоста.
§
Задача:
Установить NextCloud сервер на FreeBSD 12.0 , MariaDB 10.3.13, PHP 7.3.3, Nginx 1.14.2, redis 4.0.14
—————————————————————
добавляем нового пользователя
pw useradd ncloud -G wheel passwd ncloud
Устанавливаем временную зону.
cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime
Обновляем порты
portsnap fetch extract portsnap update
Устанавливаем SUDO, в дальнейшем нам пригодится для администрирования nextcloud
cd /usr/ports/security/sudo make BATCH=yes install clean
Устанавливаем UNZIP
cd /usr/ports/archivers/unzip make BATCH=yes install clean
Устанавливаем ZIP
cd /usr/ports/archivers/zip make BATCH=yes install clean
Устанавливаем Midnight Commander и делаем rehash, чтобы FreeBSD обнаружила появление новых команд.
cd /usr/ports/misc/mc make BATCH=yes install clean rehash
Устанавливаем nginx
cd /usr/ports/www/nginx-naxsi make BATCH=yes install clean
Прописываем nginx в автозагрузке
echo 'nginx_enable="YES"' >> /etc/rc.conf
Запускаем веб-сервер nginx
service nginx start
Проверяем работу nginx
Устанавливаем базы данных
cd /usr/ports/databases/mariadb103-server/ make BATCH=yes install clean
Добавляем в автозагрузку и ограничиваем доступ только с локальной машины
echo 'mysql_enable="YES"' >> /etc/rc.conf echo 'mysql_args="--bind-address=127.0.0.1"' >> /etc/rc.conf
Создаём конфиг для 2 GB RAM
ee /var/db/mysql/my.cnf
Со следующим содержимым
[client] port = 3306 socket = /tmp/mysql.sock [mysqld] user = mysql socket = /tmp/mysql.sock port = 3306 old_passwords = 0 bind-address = 127.0.0.1 skip-external-locking max_allowed_packet = 16M key_buffer_size = 16M innodb_buffer_pool_size = 1024M innodb_io_capacity = 4000 innodb_file_per_table = 1 innodb_flush_method = O_DIRECT innodb_flush_log_at_trx_commit = 0 max_connections = 136 query_cache_size = 0 long_query_time = 1 expire_logs_days = 10 max_binlog_size = 100M [mysqldump] quick quote-names max_allowed_packet = 16M
Запускаем MariaDB
/usr/local/etc/rc.d/mysql-server start
Задаем пароль root для MariaDB и делаем предварительные настройки
root@websrv:/ # mysql_secure_installation NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY! In order to log into MariaDB to secure it, we'll need the current password for the root user. If you've just installed MariaDB, and you haven't set the root password yet, the password will be blank, so you should just press enter here. Enter current password for root (enter for none): Нажимаем ENTER OK, successfully used password, moving on... Setting the root password ensures that nobody can log into the MariaDB root user without the proper authorisation. Set root password? [Y/n] y New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! By default, a MariaDB installation has an anonymous user, allowing anyone to log into MariaDB without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a production environment. Remove anonymous users? [Y/n] y ... Success! Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? [Y/n] y ... Success! By default, MariaDB comes with a database named 'test' that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment. Remove test database and access to it? [Y/n] y - Dropping test database... ... Success! - Removing privileges on test database... ... Success! Reloading the privilege tables will ensure that all changes made so far will take effect immediately. Reload privilege tables now? [Y/n] y ... Success! Cleaning up... All done! If you've completed all of the above steps, your MariaDB installation should now be secure. Thanks for using MariaDB! root@websrv:/ #
Авторизуемся на сервере баз данных
mysql -p
Создаём базу для nextcloud
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud'; CREATE DATABASE IF NOT EXISTS nextcloud; GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud'; FLUSH privileges; quit
Устанавливаем PHP версии 7.3
cd /usr/ports/lang/php73/ make BATCH=yes install clean
Далее устанавливаем php73-extensions
cd /usr/ports/lang/php73-extensions/ make config
Вот список того, что нам необходимо. Список может немного отличаться в зависимости от зачач, возлагаемых на netcloud
PHP module ctype
PHP module curl
PHP module dom
PHP module GD
PHP module iconv
PHP module JSON
PHP module mbstring
PHP module openssl
PHP module posix
PHP module session
PHP module SimpleXML
PHP module XMLReader
PHP module XMLWriter
PHP module zip
PHP module zlib
PHP module pdo_mysql (MySQL/MariaDB)
PHP module fileinfo (highly recommended, enhances file analysis performance)
PHP module bz2 (recommended, required for extraction of apps)
PHP module intl (increases language translation performance and fixes sorting of non-ASCII characters)
PHP module ftp (for FTP storage / external user authentication)
PHP module imap (for external user authentication)
PHP module exif (for image rotation in pictures app)
PHP module gmp (for SFTP storage)
Собираем
make BATCH=yes install clean
Переходим к редактированию конфига PHP-FPM
vi /usr/local/etc/php-fpm.d/www.conf
Ищем строку
listen = 127.0.0.1:9000
и меняем на
listen = /var/run/php72-fpm.sock
Также ищем строки и снимаем с них комментарии
listen.owner = www listen.group = www listen.mode = 0660 clear_env = no
Также разработчики nextcloud советуют использовать следующие параметры:
pm = dynamic pm.max_children = 120 pm.start_servers = 12 pm.min_spare_servers = 6 pm.max_spare_servers = 18
В итоге получаем следующий конфиг:
root@cloud:/ # cat /usr/local/etc/php-fpm.d/www.conf | grep -v '^#' | grep -v '^$' | grep -v '^;' [www] user = www group = www listen = /var/run/php72-fpm.sock listen.owner = www listen.group = www listen.mode = 0660 pm = dynamic pm.max_children = 120 pm.start_servers = 12 pm.min_spare_servers = 6 pm.max_spare_servers = 18 clear_env = no root@cloud:/ #
Проверяем настройки
Добавляем php-fpm в автозагрузку
sysrc php_fpm_enable=YES
Запускаем php-fpm
service php-fpm start
Копируем конфигурационный файл php.ini
cp -v /usr/local/etc/php.ini-production /usr/local/etc/php.ini
Редактируем php.ini, чтобы в дальнейшем не было проблем с nextcloud
vi /usr/local/etc/php.ini
Ищем нужные параметры и меняем их. Должно получиться
memory_limit = 1024M upload_max_filesize = 1G
Правим конфиг nginx, у меня получился следующий (точнее, его можно найти на сайте разработчиков):
worker_processes 1;
#error_log /var/log/nginx/error.log;
#pid logs/nginx.pid;
events { worker_connections 1024;
}
http { include mime.types; default_type application/octet-stream; #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 logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on;
upstream php-handler { #server 127.0.0.1:9000; server unix:/var/run/php72-fpm.sock;
}
server { listen 80; listen [::]:80; server_name nc.local; # enforce https return 301 https://$server_name$request_uri;
}
server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name nc.local; ssl_certificate /etc/ssl/nc.local.crt; ssl_certificate_key /etc/ssl/nc.local.key; add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; # # WARNING: Only add the preload option once you read about # the consequences in https://hstspreload.org/. This option # will add the domain to a hardcoded list that is shipped # in all major browsers and getting removed from this list # could take several months. add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header Referrer-Policy no-referrer; # Remove X-Powered-By, which is an information leak fastcgi_hide_header X-Powered-By; # Path to the root of your installation root /usr/local/www/nextcloud/; location = /robots.txt { allow all; log_not_found off; access_log off; } # The following 2 rules are only needed for the user_webfinger app. # Uncomment it if you're planning to use this app. #rewrite ^/.well-known/host-meta /public.php?service=host-meta last; #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last; # The following rule is only needed for the Social app. # Uncomment it if you're planning to use this app. # rewrite ^/.well-known/webfinger /public.php?service=webfinger last; location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; } location = /.well-known/caldav { return 301 $scheme://$host/remote.php/dav; } # set max upload size client_max_body_size 512M; fastcgi_buffers 64 4K; # Enable gzip but do not remove ETag headers gzip on; gzip_vary on; gzip_comp_level 4; gzip_min_length 256; gzip_proxied expired no-cache no-store private no_last_modified no_etag auth; gzip_types application/atom xml application/javascript application/json application/ld json application/manifest json # Uncomment if your server is build with the ngx_pagespeed module # This module is currently not supported. #pagespeed off; location / { rewrite ^ /index.php$request_uri; } location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ { deny all; } location ~ ^/(?:.|autotest|occ|issue|indie|db_|console) { deny all; } location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/. |oc[ms]-provider/. ).php( fastcgi_split_path_info ^(. ?.php)(/.*|)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTPS on; #Avoid sending the security headers twice fastcgi_param modHeadersAvailable true; fastcgi_param front_controller_active true; fastcgi_pass php-handler; fastcgi_intercept_errors on; fastcgi_request_buffering off; } location ~ ^/(?:updater|oc[ms]-provider)(?:$|/) { try_files $uri/ =404; index index.php; } # Adding the cache control header for js and css files # Make sure it is BELOW the PHP block location ~ .(?:css|js|woff2?|svg|gif)$ { try_files $uri /index.php$request_uri; add_header Cache-Control "public, max-age=15778463"; # Add headers to serve security related headers (It is intended to # have those duplicated to the ones above) # Before enabling Strict-Transport-Security headers please read into # this topic first. # add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; # # WARNING: Only add the preload option once you read about # the consequences in https://hstspreload.org/. This option # will add the domain to a hardcoded list that is shipped # in all major browsers and getting removed from this list # could take several months. add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header Referrer-Policy no-referrer; # Optional: Don't log access to assets access_log off; } location ~ .(?:png|html|ttf|ico|jpg|jpeg)$ { try_files $uri /index.php$request_uri; # Optional: Don't log access to other assets access_log off; }
}
}Как видим в nginx имеет редирект на https и поэтому потребуется генерировать сертификаты. Если подпись CA не требуется, можно создан самоподписанный сертификат. Для этого сначала создадим
приватный ключ RSA, который мы будем использовать для создания CSR- или CRT-сертификатов.
cd /etc/ssl/ openssl genrsa -out nc.local.key 1024
Для примера и так как сервер находится в локальной сети, я использовал имя nc.local. Теперь создадим CSR сертификат
openssl req -new -key nc.local.key -out nc.local.csr
Или можно два действия выполнить одной командой
cd /etc/ssl/ openssl req -config openssl.cnf -days 3650 -subj "/C=RU/ST=Russia/L=Moscow/O=nc/OU=nc/CN=nc.local/[email protected]" -new -nodes -keyout nc.local.key -out nc.local.csr -newkey rsa:2048
Далее создаем самоподписанный сертификат CRT :
openssl x509 -in nc.local.csr -out nc.local.crt -req -signkey nc.local.key -days 1800
Переходим к установке Nextcloud. Скачиваем последнюю версию в домашнюю директорию пользователя
cd ~ fetch https://download.nextcloud.com/server/releases/latest.tar.bz2
На момент написания это была версия 15.0.5. Если вам нужна именно эта версия, то ссылка для скачивания:
fetch https://download.nextcloud.com/server/releases/nextcloud-15.0.5.zip
Распаковываем, перемещаем в директорию веб-сервера и выдаём необходимые права
tar -xvf latest.tar.bz2 mv nextcloud/ /usr/local/www/ chown -R www:www /usr/local/www/nextcloud/ chmod -R 0755 /usr/local/www/nextcloud/
Перезапускаем nginx и используя любой браузер, заходим на сервер:
Если вы увидели
После установки сразу заходим в “Общие сведения”, где можно посмотреть что ещё необходимо установить или настроить для нормальной работы сервера
Настраиваем PHP OPcache
vi /usr/local/etc/php.ini
Редактируем следующие строки:
opcache.enable=1 opcache.enable_cli=1 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.memory_consumption=128 opcache.save_comments=1 opcache.revalidate_freq=1
Перезапускаем сервисы
service nginx restart service php-fpm restart
Теперь решим проблему: ” Не настроена система кеширования. Для увеличения производительности сервера, по возможности, настройте memcache. Более подробная информация доступна в документации. “
Устанавливаем дополнительно, рекомендованный модуль: PHP module apcu (>= 4.0.6)
cd /usr/ports/devel/pecl-APCu make BATCH=yes install clean
Проверяем установился ли APC
php -m | grep apc
Для работы необходимо в любом месте конфига php.ini прописать строку apc.enable_cli = 1. Приведу часть своего конфига, я добавил в начале конфига
root@nc:/ # cat /usr/local/etc/php.ini [PHP] apc.enable_cli = 1 ;;;;;;;;;;;;;;;;;;; ; About php.ini ; ;;;;;;;;;;;;;;;;;;;
Устанавливаем и настраиваем PHP module memcached
cd /usr/ports/databases/memcached make BATCH=yes install clean
Настраиваем автоматический запуск, разрешаем слушай только на локальном интерфейсе и выделяем 64 MB памяти
sysrc memcached_enable="YES" echo 'memcached_flags="-l 127.0.0.1 -m 64"' >> /etc/rc.conf echo '#memcached_flags="-s /tmp/memcached.socket -a 0777 -m 64"' >> /etc/rc.conf
Проверяем работу memcached (мониторить работу memcached можно при помощи memcached-tool):
теперь для работы memcached с php, необходимо установить библиотеки для PHP
cd /usr/ports/databases/pecl-memcached make BATCH=yes install clean
Проверяем правильность установки
root@cloud:/ # ls /usr/local/etc/php/ | grep memcache ext-30-memcached.ini
Проверить при помощи php
root@cloud:/ # php -i | grep memcache /usr/local/etc/php/ext-30-memcached.ini, memcached memcached support => enabled libmemcached version => 1.0.18 memcached.compression_factor => 1.3 => 1.3 memcached.compression_threshold => 2000 => 2000 memcached.compression_type => fastlz => fastlz memcached.default_binary_protocol => Off => Off memcached.default_connect_timeout => 0 => 0 memcached.default_consistent_hash => Off => Off memcached.serializer => php => php memcached.sess_binary_protocol => On => On memcached.sess_connect_timeout => 0 => 0 memcached.sess_consistent_hash => On => On memcached.sess_consistent_hash_type => ketama => ketama memcached.sess_lock_expire => 0 => 0 memcached.sess_lock_max_wait => not set => not set memcached.sess_lock_retries => 5 => 5 memcached.sess_lock_wait => not set => not set memcached.sess_lock_wait_max => 150 => 150 memcached.sess_lock_wait_min => 150 => 150 memcached.sess_locking => On => On memcached.sess_number_of_replicas => 0 => 0 memcached.sess_persistent => Off => Off memcached.sess_prefix => memc.sess.key. => memc.sess.key. memcached.sess_randomize_replica_read => Off => Off memcached.sess_remove_failed_servers => Off => Off memcached.sess_sasl_password => no value => no value memcached.sess_sasl_username => no value => no value memcached.sess_server_failure_limit => 0 => 0 memcached.store_retry_count => 2 => 2 Registered save handlers => files user memcached root@cloud:/ #
Для настройки memcached также не необходимо добавить строки в php.ini и config.php.
vi /usr/local/www/nextcloud/config/config.php
Перед строкой с datadirectory, вставляем строки. Для примера привожу часть конфига если используете ip:
), 'memcache.local' => 'OCMemcacheAPCu', 'memcache.distributed' => 'OCMemcacheMemcached', 'memcached_servers' => [ [ '127.0.0.1', 11211 ], ], 'datadirectory' => '/usr/local/www/nextcloud/data', 'dbtype' => 'mysql', 'version' => '15.0.6.1', 'overwrite.cli.url' => 'https://nc.local',
Находил в интернете много информации о том, что часто возникают ошибки при использовании memcached. Если у вас также проблема, стоит попробовать Redis – это сервис кэширования данных в оперативной памяти на основе хеш-таблицы. Но для начала, если memcached уже установлен, то хотя бы отключим его в /etc/rc.conf
sed -i -e '/memcached*/s/^/#/' /etc/rc.conf
Проверим сделанное
root@nc:/ # cat /etc/rc.conf | grep mem #memcached_enable="YES" #memcached_flags="-l 127.0.0.1 -m 64" ##memcached_flags="-s /tmp/memcached.socket -a 0777 -m 64"
Устанавливаем Redis
cd /usr/ports/databases/redis make BATCH=yes install clean
прописываем в автозагрузку ( /etc/rc.conf )
sysrc redis_enable="YES"
Генерируем пароль, который будем использовать в redis
Копируем конфиг
cp /usr/local/etc/redis.conf.sample /usr/local/etc/redis.conf
Настраиваем его на работу через сокет
#port 6379 #bind 127.0.0.1 unixsocket /tmp/redis.sock unixsocketperm 766
Вот содержимое моего конфига
root@cloud:/ # cat /usr/local/etc/redis.conf | grep -v '^#' | grep -v '^$' protected-mode yes tcp-backlog 511 unixsocket /tmp/redis.sock unixsocketperm 766 timeout 0 tcp-keepalive 300 daemonize yes supervised no pidfile /var/run/redis/redis.pid loglevel notice logfile /var/log/redis/redis.log databases 16 always-show-logo yes save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /var/db/redis/ slave-serve-stale-data yes slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 requirepass 5e49d5aa132cc5e855339ba6c62c295730dbac10 lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no slave-lazy-flush no appendonly no appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble no lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes root@cloud:/ #
Запускаем редис:
/usr/local/etc/rc.d/redis start
Проверим аутентификацию по паролю, по окончанию проверки введите exit
В документации рекомендовано: PHP module redis (>= 2.2.6, required for Transactional File Locking) Устанавливаем модуль для работы redis с PHP
cd /usr/ports/databases/pecl-redis make BATCH=yes install clean
Проверяем установку PHP-redis
root@cloud:/ # ls /usr/local/etc/php/ | grep redis ext-30-redis.ini root@cloud:/ #
Теперь необходимо перенастроит конфигурационный файл nextcloud
vi /usr/local/www/nextcloud/config/config.php
Вот часть моего конфига
'memcache.local' => 'OCMemcacheAPCu' , 'memcache.distributed' => 'OCMemcacheRedis' , 'filelocking.enabled' => 'true', 'memcache.locking' => 'OCMemcacheRedis' , 'redis' => array( 'host' => '/tmp/redis.sock' , 'port' => 0 , 'dbindex' => 0 , 'password' => '5e49d5aa132cc5e855339ba6c62c295730dbac10' , 'timeout' => 1.5, ),
На сайте nextcloud рекомендуется использовать: PHP module libxml (Linux package libxml2 must be >=2.7.0) . Если конфиг для сборки не менялся он должен идти по умолчанию. Проверяем:
root@cloud:/ # php -m | grep lib libxml zlib root@cloud:/ #
Теперь переходим к предупреждениям
В системе не установлены рекомендуемые модули PHP. Для улучшения производительности и совместимости рекомендуется установим модуль imagick .
cd /usr/ports/graphics/ImageMagick6-nox11/ make BATCH=yes install clean
При установке я меня появилась ошибка
mesa-libs-18.3.2 needs Python 2.7 at most, but 3.6 was specified.
Попробуем установить по отдельности:
cd /usr/ports/graphics/mesa-libs make BATCH=yes install clean cd /usr/ports/security/gnutls make DISABLE_VULNERABILITIES=yes BATCH=yes install clean cd /usr/ports/graphics/ImageMagick6-nox11/ make BATCH=yes install clean cd /usr/ports/graphics/pecl-imagick make BATCH=yes install clean
Из рекомендованных осталось установить: PHP module smbclient (SMB/CIFS integration, see SMB/CIFS). Нужен он в том случае, если в сети есть файловый сервер и вы хотите через nextcloud организовать доступ к нему. Устанавливаем
cd /usr/ports/net/pecl-smbclient make BATCH=yes install clean
Проверяем установку pecl-smbclient
root@cloud:/ # ls /usr/local/etc/php/ | grep smb ext-20-smbclient.ini root@cloud:/ # php -m | grep smb libsmbclient smbclient root@cloud:/ #
Также на сайте nextcloud рекомендуется использовать параметр cgi.fix_pathinfo=1, ищем его в конфиге php.ini и исправляем.
Чтобы не появлялась ошибка связанная с бездействием, настраиваем выполение фоновых задач при помощи CRON. Открываем редактор от пользователя www и вписываем ниже приведенные строки
# crontab -u www -e PATH=/usr/local/bin */15 * * * * php -f /usr/local/www/nextcloud/cron.php
В панели администрирования nextcloud указываем выполнение фоновых задач, при помощи крона
Если для хранения данных пользователей используется директория, отличная от стандартной, то создаём её и настраиваем права:
root@jail:~ # mkdir -p /mnt/da1p1/data/ root@jail:~ # chown -R www:www /mnt/da1p1/data/ root@jail:~ # chmod -R 0775 /mnt/da1p1/data/
§
Настройка в zabbix мониторинга nginx
В прошлой редакции этой статьи дальше шло описание скрипта, который будет парсить вывод nginx-status и передавать данные в zabbix. Сейчас все можно сделать гораздо проще и удобнее. На агенте не надо ничего настраивать. Все выполняется исключительно в шаблоне.
Это удобный подход, который избавляет от необходимости настраивать агентов. Теперь все выполняется с сервера. Минус этого подхода только в том, что возрастает нагрузка на сервер мониторинга. Это плата за удобство и централизацию. Имейте это ввиду. Если у вас большая инсталляция мониторинга и есть средства автоматизации типа ansible, возможно вам имеет смысл по старинке парсить данные скриптом. Но в общем случае я рекомендую делать так, как я расскажу далее.
Настройка мониторинга apache
Теперь настроим мониторинг apache в zabbix server. Как обычно, я подготовил шаблон с итемами и триггерами, которые посчитал полезными. Скачиваем его – zabbix-apache-template.xml.
Обратите внимание на элемент, который забирает страницу со статусом. Его url я реализовал через макросы:
- {$S_HOST} – название виртуального хоста
- {$S_PATH} – путь к странице со статистикой
- {$S_PORT} – порт сервера apache, на котором работает статистика
Вот как выглядят настройки макроса на типичном сайте с bitrixenv.
Так же обращаю внимание на итемы проверки количества рабочих процессов и занимаемой виртуальной памяти. Для проверки процессов указан пользователь bitrix, от которого работают все воркеры. В случае проверки памяти указан пользователь root, так как основной процесс запущен от него.
Так как apache обычно работает в роле бэкенда, у него минимум триггеров, как и у php-fpm. Я сделал 2:
- Apache service not work – предупреждение о том, что системный процесс web сервера apache не запущен.
- Failed to fetch apache server status page – триггер срабатывает, если не получается загрузить страницу со статистикой.
Добавил еще пару графиков. Сами на них посмотрите. Вот в общем-то и все. После настройки шаблона для мониторинга apache, прикрепите его к хосту, не забудьте указать макросы и ждите поступления данных.
На это про мониторинг apache в zabbix все. Дальше идет пример готового Dashboard.
Первый вариант — используя функционал zabbix, настроить веб-мониторинг
Этот гайд не о том, как работать с Zabbix, поэтому я шаги буду описывать кратко.
Создаём сценарий. Настройка – Веб– Создать сценарий.
На вкладке «Сценарий» обязательно заполняем поля «Группа элементов данных» и «Имя» (сценария).
Переходим на вкладку «Шаги», добавляем шаг сценария. Заполняем поля: название шага, URL, код ответа.
Подготовка apache к мониторингу
Приступим к настройке мониторинга web сервера apache. В данном примере я буду использовать web сервер для сайта на bitrix, работающего в окружении bitrixenv. В целом, тут никаких принципиальных отличий нет от обычного apache, просто представлена готовая конфигурация с обширными настройками.
С веб сервером apache мне давно не приходилось связываться в отрыве от bitrix сайтов, поэтому решил показать его мониторинг на его примере. Здесь принцип будет такой же, как и раньше – забираем страницу с информацией о веб сервере, который apache нам предоставляет через свой модуль mod_status.
Подготовка nginx к мониторингу
Я планирую мониторить следующие параметры nginx:
| accepts per second | Число принятых соединений в секунду |
| active connections | Текущие активные соединения |
| handled per second | Число обработанных соединений в секунду |
| latency | Время ответа сервера в миллисекундах |
| memory allocated | Занимаемая память |
| process count | Число запущенных процессов |
| reading state connection count | Текущее число соединений, в которых nginx в настоящий момент читает заголовок запроса |
| requests per second | Число запросов в секунду |
| waiting state connection count | Текущее число бездействующих соединений в ожидании запроса |
| writing state connection count | Текущее число соединений, в которых nginx в настоящий момент отвечает |
| memory allocated | Сколько памяти занимают все worker process |
Сервер nginx умеет отдавать часть необходимой нам информации о своем состоянии. Для этого его надо соответствующим образом подготовить. Открываем конфиг сервера и добавляем туда следующую конструкцию:
server { listen localhost; server_name localhost; keepalive_timeout 0; allow 127.0.0.1; allow ::1; deny all; access_log off; location /nginx-status { stub_status on; }Я обычно добавляю в самый конец основного конфига nginx.conf. Сохраняем и перечитываем конфигурацию, перед этим проверив его конфиг на ошибки:
# nginx -t # nginx -s reload
Проверяем, можем ли мы получить необходимую информацию для настройки мониторинга:
Подготовка php-fpm к мониторингу
Переходим к мониторингу php-fpm. Он отдает побольше метрик, не буду описывать их все. Рассмотрю только самые основные. Мы будем наблюдать следующие параметры php-fpm:
| active processes count | Число активных процессов |
| connections per sec | Количество соединений в секунду |
| idle processes count | Количество idle процессов |
| slow requests | Количество медленных запросов |
| length of listen queue | Размер очереди ожидающих подключений |
| max children reached | Сколько раз был достигнут лимит по процессам |
| max length of listen queue | Максимальный размер очереди подключений |
Пару слов о том, зачем это нужно и как пользоваться полученными данными. Этот мониторинг актуален, если у вас динамическое создание процессов в php-fpm. К примеру, если у вас значение max children reached регулярно больше единицы, то вам рекомендуется увеличить лимит на максимальное количество процессов, если позволяют ресурсы сервера.
То же самое относится и к параметру length of listen queue. Если он больше нуля, то создается очередь из запросов, которые не успевают обработать сервер. Необходимо увеличить количество процессов, которые смогут обработать ожидающие подключения.
Приступаем к настройке мониторинга php-fpm на web сервере. Установим fcgi:
# yum install fcgi
Теперь подготовим pfp-fpm для сбора статистики. Для этого мы снова воспользуемся nginx. Редактируем его конфиг, добавляя в ту же секцию server, что и на прошлом этапе, следующую конструкцию:
location /phpfpm-status { include fastcgi_params; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}Обращаю ваше внимание на то, что я в своей конфигурации использую подключение к php-fpm через unix сокет. За это отвечает параметр конфигурации fastcgi_pass. Если вы используете в работе tcp/ip порт, обычно 127.0.0.1:9000, то нужно указать его вместо сокета, вот так: fastcgi_pass 127.0.0.1:9000
Перезапускаем nginx:
# systemctl restart nginx
Внесем необходимые изменения в конфиг php-fpm – добавим одну строку:
# mcedit /etc/php-fpm.d/www.conf pm.status_path = /phpfpm-status
Перезапускаем php-fpm:
# systemctl restart php-fpm
Проверяем, что по указанному адресу мы получаем статистику php-fpm:
Помогла статья? подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.
Цели статьи
- Подобрать набор критичных метрик web сервера для мониторинга.
- Разработать инструменты для подготовки данных и передачи в zabbix, с учетом современных нововведений последних версий.
- Подготовить шаблоны для мониторинга nginx, apache, php-fpm.
- Показать пример готового дашборда, который использую я для мониторинга за веб сервером.
Загрузка...