Устранение ошибки "Нет такого файла или каталога", вызванной несоответствиями между конфигурацией мониторинга Monit и PHP-FPM.

Кровавая бойня, вызванная цепочкой контактов разъема.

История такова.

У меня есть друг, у которого в прошлом месяце снова сломался сервер.

Он пришел ко мне и сказал, что Monit постоянно выдает ошибки, сообщая, что не может найти файл сокета php-fpm, после чего служба начала часто перезапускаться, и нагрузка резко возросла. В три часа ночи ему позвонили по экстренному вызову, чтобы он починил сервер.

Я же говорил тебе не паниковать и показать мне журналы мониторинга.

Когда я посмотрел на это, я был поражен: там было полно подобных ошибок:

ошибка: Ошибка подключения к сокету Unix /run/php/php8.4-fpm.sock — Нет такого файла или каталога ошибка: 'php8.4-fpm' faiтест протокола светодиодов [DEFAULT] в /run/php/php8.4-fpm.sock — Невозможно создать сокет Unix для /run/php/php8.4-fpm.sock

Я спросил его: «Где теперь ваш файл сокета?»

Он сказал, что не знает, поэтому я просто установил его с настройками по умолчанию.

Я же просил подождать, я сейчас проверю.

Затем я подключился по SSH и увидел, что его файл сокета назывался... /run/php/php8.4-fpm-etufo.org.sock.

Я сказал: "Дружище, путь к сокету — это две разные вещи, было бы чудом, если бы они могли взаимодействовать".

Сегодня я подробно разберу эту проблему и предложу её решение.

Вы думаете, что слежка вас защищает, но на самом деле она вам вредит.

Начнём с обсуждения наиболее распространённого типа ошибок в журналах мониторинга.

Когда вы это увидите:

Ошибка: Ошибка подключения к сокету Unix /run/php/php8.4-fpm.sock — Нет такого файла или каталога

Это указывает на то, что Monit пытается обнаружить службу php-fpm через этот сокет, но не может найти файл.

Далее monit попытается перезапустить службу, и в логах отобразится следующее:

info: 'php8.4-fpm' попытка перезапуска info: 'php8.4-fpm' остановка: '/usr/sbin/service php8.4-fpm stop' info: 'php8.4-fpm' запуск: '/usr/sbin/service php8.4-fpm start'

Выглядит довольно умно, правда? Оно самовосстанавливается автоматически.

Но проблема в том, что именно частые перезагрузки и являются настоящей катастрофой.

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

Журналы также раскроют дополнительную информацию, например, такую:

ошибка: 'etНЛО.org' loadavg (15min) of 8.8 matches resource limit [loadavg (15min) > 8.0] error: 'etНЛОИспользование ЦП системой .org составляет 33.9%, что соответствует лимиту ресурсов [использование ЦП системой > 30.0%].

Сервер и так был сильно загружен, но система мониторинга продолжала постоянно перезапускать службу. Это не тушило пожар, а лишь подливал масла в огонь.

Суть проблемы: ключ и замок не подходят друг к другу.

При более внимательном рассмотрении проблема оказывается довольно простой.

Путь к сокету, указанный в конфигурационном файле monit, следующий:/run/php/php8.4-fpm.sock

Однако фактический путь к сокету, через который работает php-fpm, следующий:/run/php/php8.4-fpm-etufo.org.sock

Если одна функция предназначена для обнаружения файла A, а другая на самом деле является файлом B, то обнаружение, очевидно, не удастся.

Это что-то невероятное.

У вас есть ключ, запертый в другой комнате.

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

На самом деле, замок не сломан; просто ваш ключ не подходит к замку.

решатьМониторинг мониторингаКонфигурация несовместима с PHP-FPM.

Вариант 1: Изменить конфигурацию монитора.

Если вы хотите сохранить существующую конфигурацию сокетов php-fpm, измените конфигурацию monit.

Найдите файл конфигурации monit и внесите следующие изменения:

if failed unixsocket /run/php/php8.4-fpm.sock then restart

Измените его на:

if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart

Затем выполните перезагрузку:

sudo monit reload

Вот и все.

Вариант 2: Изменить конфигурацию php-fpm.

Если вы хотите использовать путь по умолчанию, измените конфигурацию пула php-fpm.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confИзмените команду прослушивания на:

listen = /run/php/php8.4-fpm.sock

Затем перезапустите php-fpm:

sudo systemctl restart php8.4-fpm

Вот и все.

Оба решения могут устранить проблему; выбор зависит от ваших конкретных обстоятельств.

Сколько сайтов размещено на вашем сервере? У каждого сайта свой отдельный сокет? Если сайтов всего один, то путь по умолчанию будет проще.

Позвольте мне высказаться от всего сердца.

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

Если путь к сокету указан неправильно, на первый взгляд всё может казаться спокойным, но в действительности система мониторинга будет выдавать ложные тревоги, служба будет произвольно перезапускаться, а нагрузка будет необъяснимо резко возрастать.

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

Как однажды сказал один из старших коллег: «Точность мониторинга — это первая линия защиты для обеспечения стабильности работы сервиса».

Успех или неудача зависят от деталей, и это абсолютно верно в серверной среде.

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

Спасибо за прочтение моей статьи. До встречи в следующий раз.