Проблема с плагином Newrelic PHP APM — сбой, зомби, PHP-FPM и Nginx

Я пытался установить подключаемый модуль PHP APM для своих веб-серверов, однако столкнулся с проблемой и нуждаюсь в некоторой помощи.

Мы можем установить плагин без проблем, обновить конфигурацию без проблем и запустить службу без проблем. Однако вскоре после этого php_agent.log начинает показывать, что не может подключиться к демону и продолжает давать сбой.

Я проверил демон, и он показывает, что он работает, однако я обнаружил, что процесс фактически зомбирован и мертв. Перезапуск 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)
  • Ньюрелик Демон (4.23.4.113-1)
  • Ньюрелик PHP5 (4.23.4.113-1)
  • Newrelic PHP5 Общий (4.23.4.113-1)

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

Я был бы признателен за любую помощь или мысли, которые могут быть у кого-то, так как это сводит меня с ума.

Спасибо!


nginx php newrelic apm
person eengelking    schedule 22.10.2015    source источник

Ответы (3)


arrow_upward
0
arrow_downward

У вас есть процесс, который очищает файлы, находящиеся в /tmp, дольше определенного времени? Агент и демон взаимодействуют через файл сокета с именем /tmp/.newrelic.sock. Если это исчезнет, ​​вы должны увидеть ошибки "ENOENT" в журналах. У вас также могут быть проблемы с разрешениями для некоторых места/файлы.

Если проблема заключается в файле сокета, рассмотрите возможность переключения на TCP-порт вместо файла сокета, установив newrelic.daemon.port в файле конфигурации (newrelic.ini)

person REngland    schedule 23.10.2015
comment
Это именно проблема. Я также собираюсь опубликовать ответ NR на это. - person eengelking; 30.10.2015

arrow_upward
0
arrow_downward

У меня такая же проблема раньше. Единственное, что я сделал, это переустановил его в новое приложение, созданное на новой реликвии. Удачи. rpm.newrelic.com/accounts/{вашрид}/applications

person G.T.Shen    schedule 22.10.2015
comment
К сожалению, переустановка не решила проблему. @REngland пригвоздил его к носу, что совпало с ответом NR. - person eengelking; 30.10.2015

arrow_upward
0
arrow_downward

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

person eengelking    schedule 29.10.2015