Проблема с плагином Newrelic PHP APM — сбои, зомби, PHP-FPM и Nginx
Я пытался установить плагин PHP APM для своих веб-серверов, однако я попал в стену и мне нужна помощь.
Мы можем установить плагин в рамках проблемы, обновить конфигурацию без проблем и запустить сервис без проблем. Однако вскоре после этого php_agent.log начинает показывать, что он не может подключиться к демону и продолжает отказывать.
Я проверил демона, и он показывает, что он работает, однако я обнаружил, что процесс на самом деле отключен от zombie и мертв. Перезапуск PHP-FPM удаляет зомби, и сервис снова работает в течение нескольких минут, но вскоре после этого возвращается в состояние зомби.
Я могу повторить эту проблему на всех моих веб-серверах. Я даже развернул совершенно новый ящик и развернул его, добавив те же конфигурации, что и остальные, и он тоже начал зомби вскоре после запуска.
Моя конфигурация выглядит следующим образом:
- CentOS 7 (ядро 3.10.0-229.11.1.el7.x86_64)
- PHP-FPM (5.5.30-1.el7.remi)
- Nginx (1: 1.6.3-6.el7)
- Newrelic Daemon (4.23.4.113-1)
- Newrelic PHP5 (4.23.4.113-1)
- Newrelic PHP5 Common (4.23.4.113-1)
Чтобы добавить оскорбление ране, кажется, что если мы покидаем зомби слишком долго, это в конечном итоге приводит к сбою веб-сайта на всех серверах. Правда, боль в тылу.
Я был бы признателен за любую помощь или мысли, которые кто-либо может иметь, так как это сводит меня с ума.
Спасибо!
Решение
Есть ли у вас процесс очистки файлов, находящихся в / tmp, в течение определенного времени? Агент и демон взаимодействуют через файл сокета с именем /tmp/.newrelic.sock. Если он исчезнет, вы должны увидеть ошибки «ENOENT» в журналах. Вы также можете иметь выдача разрешения для некоторых мест / файлов.
Если проблема с файлом сокета, рассмотрите возможность переключения на порт TCP вместо файла сокета, установив newrelic.daemon.port в вашем конфигурационном файле (newrelic.ini)
Другие решения
У меня та же проблема раньше. Единственное, что я сделал, это переустановил его в новое приложение, созданное на новой реликвии. Удачи.
rpm.newrelic.com/accounts/{yourid}/applications
По NewRelic:
[Для CentOS] в файле модуля systemd по умолчанию для httpd для директивы PrivateTmp установлено значение true, что означает, что httpd ожидает, что личный временный каталог будет использоваться процессом (-ами). В результате наш PHP-агент и демон не могут обмениваться данными при новой установке, поскольку наш RPM-пакет устанавливает файл сокета при установке пакета через yum. Этот файл сокета по умолчанию находится вне какого-либо частного временного каталога, что означает, что агент и демон не могут использовать для связи (в результате активации агента через процесс httpd), и правильный файл сокета не будет создан во время перезапусков. , поскольку агент и демон считывают местоположение как уже существующее.Итак, подведем итог: проблема двоякая:
- Частные временные каталоги для установки httpd по умолчанию не позволяют установке нашего агента PHP по умолчанию взаимодействовать с демоном.
- Файл сокета по умолчанию, установленный нашим RPM-пакетом, предотвращает создание нового файла в правильном месте.
Текущий обходной путь, который мы реализовали, состоит в том, чтобы удалить файл сокета по умолчанию в /tmp/.newrelic.sock, а затем выдать остановку службы newrelic-daemon, затем остановку службы httpd и, наконец, запуск службы httpd. (Я видел, что простой перезапуск httpd иногда не работает) Эта проблема будет препятствовать всем новым установкам агента PHP на CentOS 7. Еще одна вещь, которую стоит отметить, — это стандартные файлы модулей для nginx и php-fpm, также использующие частные временные каталоги. и поэтому подвержены тем же потенциальным проблемам.
detector