Zabbix nginx мониторинг 500 ошибок

access log сайта расположен в /var/log/nginx/newsite_com_ssl_access.log

Пользователь zabbix от которого запущен агент Zabbix не имеет прав доступа на чтение лога.

Доступ к лог-файлам в директории /var/log/nginx имеет владелец www-data и группа adm. Проверить можно командой:

ls -l /var/log/nginx/ 

Для возможности чтения логов nginx, добавим пользователя zabbix в группу adm:

usermod -aG adm zabbix

После изменений прав доступа пользователя zabbix, необходимо перезапустить агент Zabbix:

systemctl restart zabbix-agent

Проверяем изменения, получаем последние записи лог-файла от имени пользователя zabbix:

sudo -u zabbix bash -c 'tail -f /var/log/nginx/newsite_com_ssl_access.log' 

Далее создадим элемент данных в Zabbix:

Регулярное выражение: ^(S+) (S+) (S+) [([w:/]+s[+-]d{4})] "(S+)s?(S+)?s?(S+)?" (d{3}|-) (d+|-)s?"?([^"]*)"?s?"?([^"]*)" разбивает каждую строку лога на несколько групп. Код состояния HTTP находится в 8-й группе.

Второй вариант получения статус-кодов HTTP с помощью скрипта на bash:

vi /opt/get_response_http_codes.sh

#!/bin/bash

tail -n 1 /var/log/nginx/newsite_com_ssl_access.log | awk '{print $9}'

Меняем владельца скрипта и предоставляем права на выполнение:

chown zabbix /opt/get_response_http_codes.sh
chmod u+x /opt/get_response_http_codes.sh

Разрешаем выполнение удаленных команд агенту Zabbix:

vi /etc/zabbix/zabbix_agentd.conf

EnableRemoteCommands=1

После внесенных изменений, необходимо перезапустить агент Zabbix:

systemctl restart zabbix-agent

Далее создадим элемент данных в Zabbix:

Едва ли сегодня найдется системный администратор, который не слышал про NGINX — программу, способную выполнять очень много функций, от кэширования и отдачи статического контента сайта до балансировки нагрузки и построения узлов CDN.

Правильная настройка NGINX влияет на работоспособность и производительность использующих его сайтов.

Из нашей статьи вы узнаете, как установить NGINX в ОС Debian и настроить мониторинг этой программы с помощью SAAS-сервиса NGINX Amplify, а также с помощью Zabbix.

Установка NGINX

Если на вашем сервере есть панель, такая как 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

Файлы конфигурации 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

Чтобы контролировать работу 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

SAAS-сервис NGINX Amplify от создателей NGINX несложен в подключении, бесплатен при добавлении до 5 узлов и обладает большими возможностями мониторинга. Этот сервис выполняет сбор статистики при помощи собственного агента, который потребуется установить на контролируемый сервер.

Если нужно контролировать много узлов или хочется все держать в своих руках, а также если у вас уже имеются серверы Zabbix, возможно, вам больше подойдет мониторинг NGINX при помощи Zabbix, о чем мы расскажем ниже в этой статье.

Установка NGINX Amplify

Прежде чем приступить к установке агента NGINX Amplify, необходимо установить NGINX и настроить сбор метрик NGINX, как это было описано ранее в нашей статье.

Обратите внимание, что в процессе установки будет добавлен файл репозитория /etc/apt/sources.list.d/nginx-amplify.list. 

Если на сервере установлена панель управления, такая как ISPmanager, убедитесь, что эта операция не приведет к конфликтам. В том случае, когда разработчики панели управления сервером не гарантируют совместимость с агентом NGINX Amplify, рассмотрите возможность использования для мониторинга NGINX средств Zabbix.

На момент написания этой статьи поддержка компании ISPmanager ответила, что совместимость 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 Amplify, доступного зарегистрированным пользователям, удобно просматривать текущее состояние сервиса NGINX и узлов, на которых он запущен. Также можно получить сведения о конфигурации NGINX и ОС, и, что ценно, рекомендации по настройке конфигурации NGINX.

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

Overview

По содержимому страницы Overview вы можете быстро определить состояние вашей системы — посмотреть общее количество запросов, ошибок с кодом 5xx, среднее время запросов, трафик, а также использование CPU.

Graphs

На странице Graphs можно просмотреть предопределенный набор графиков, отражающих состояние основных метрик, как для NGINX, так и для системы.

Dashboards

Открыв страницу Dashboards, вы сможете создать и настроить панели с графиками нужных вам метрик.

Тут можно создать новые наборы данных для графиков, новые графики и добавить в мониторинг новые значения.

Analyzer

На этой странице можно получить отчеты по конфигурации выбранной системы, а также рекомендации по настройке параметров в файле конфигурации NGINX с точки зрения повышения производительности и улучшения безопасности.

Alerts

На странице Alerts можно создать правила оповещения о событиях, требующих реакции. Извещения могут быть отправлены на электронную почту или в Slack.

Мониторинг NGINX с помощью Zabbix

С помощью шаблона 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

Если вы сделали настройки, как это было описано в предыдущем разделе статьи, вам, скорее всего, не придется изменять макросы шаблона 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 by Zabbix agent определены все метрики, необходимые для контроля работоспособности и производительности NGINX (рис. 4).

Это состояние сервиса, время его ответа, количество дочерних процессов, запущенных сервисом NGINX, память, зарезервированная для NGINX и использованная этим сервисом, использование CPU, а также параметры, имеющие отношение к соединениям, которые клиенты устанавливают с сервисом NGINX.

Полный перечень метрик вы найдете в описании агента.

Триггеры шаблона Nginx by Zabbix agent

В шаблоне 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 by Zabbix agent

В шаблоне имеются четыре графика с наиболее важной информацией NGINX, которые можно добавить в панель (рис. 6).

Это графики, имеющие отношение к соединениям, интенсивности запросов и установки соединений, а также к использованию оперативной памяти. Анализируя эти графики, а также факт срабатывания триггеров Nginx: High connections drop rate и Nginx: Service response time is too high, можно сделать заключение о необходимости оптимизации настроек сервиса NGINX.

Оптимизация настроек сервиса NGINX

Оптимизируя настройки сервиса NGINX, можно в десятки раз повысить скорость работы сайтов, размещенных на сервере. 

Для изменения настроек сделайте резервную копию файла /etc/nginx/nginx.conf, а затем отредактируйте его. Далее проверьте конфигурацию NGINX, перезапустите сервис и убедитесь, что он запустился:

# nginx -t
# systemctl restart nginx
# systemctl status nginx

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

Также, возможно, вам будет полезна книга «The Complete NGINX Cookbook», которую можно загрузить бесплатно с сайта разработчика. Вопросы оптимизации рассмотрены там в главе 15.

Далее мы расскажем об основных настройках.

Количество рабочих процессов worker_processes

Как мы уже говорили, параметр 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

Максимальное количество соединений worker_connections

По умолчанию 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. Этой теме можно было бы посвятить отдельную статью, а сейчас мы ограничимся ссылкой на соответствующий раздел документации и на статьи по этой теме:

• https://ru.linuxcapable.com/nginx-optimization-tuning-with-caching/

• https://itnan.ru/post.php?c=1&p=520016 

• https://habr.com/ru/post/428127/

• https://searchengines.guru/ru/forum/879527 

Подключая кэширование контента на сервере при помощи 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 очень большое, поэтому, если в предупреждении или сообщении об ошибке нет конкретных рекомендаций, вы всегда сможете найти ответ при помощи поиска.

Автор статьи: Александр Фролов.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.

ciao @dotneft ,
sure, for example errors related to memory_limit exceeded, you can easily test by set ZBX_MEMORY_LIMIT to a very low value, for example «1» and monitor the zabbix-web container log (docker logs -f ) while trying to open the dashboard, that should fail with just a white page, nothing is shown in the logs, just the access attempts returning HTTP/500 with no details:

x.x.x.x - - [09/Oct/2020:11:58:00 +0000] "GET /zabbix.php?action=dashboard.view HTTP/1.1" 500 5 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0" "-"

but if you remove the php_admin_value[error_log] parameter, restart the container and try opening the dashboard again, it will of course still fail with a blank page, but you’ll see the actual error in the container logs:

2020/10/09 11:59:00 [error] 17#17: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 163840 bytes) in /usr/share/zabbix/include/defines.inc.php on line 1536" while reading response header from upstream, client: x.x.x.x, server: zabbix, request: "GET /zabbix.php?action=dashboard.view HTTP/1.1", upstream: "fastcgi://unix:/tmp/php-fpm.sock:", host: "x.x.x.x:8081"

x.x.x.x- - [09/Oct/2020:11:59:00 +0000] "GET /zabbix.php?action=dashboard.view HTTP/1.1" 500 5 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0" "-"

I hope this helps!

thanks

очень помог, спасибо
пока я сделал так

UserParameter=nginx_codes[*],cat /var/log/nginx/access.log | awk '{print $9}' | grep -c $1
UserParameter=nginx_codes_all,cat /var/log/nginx/access.log | wc -l

item:

• nginx_codes[500]
• nginx_codes[502]
• nginx_codes[503]

и потом уже вычисляемые item

• 100*last(«nginx_codes[500]»)/last(«nginx_codes_all»)
• …

но каждый раз дергать лог который бывает под 500 мб или больше как-то не оч хорошо, хотелось бы какого-то более гибкого или готового решения

Garcia ★

(14.12.18 16:48:19 MSK)

Последнее исправление: Garcia 14.12.18 16:48:54 MSK
(всего

исправлений: 1)