Мониторинг CloudLinyx на шареде

Не так.

Это задача Вашего программиста но не хостера!

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

А не будет ли с моей стороны наглость попросить прочитать стартпост и больше не писать такое?

Ок скажу кратко: от др хостеров в случае нагрузок я получал сообщения аля "ваш скрипт xxxx.php откушивает много памяти. Срочно примете меры". Причем получал быстрее чем от внешних мониторингов, фиксирующий полное падение сайта.

Я прочитал Ваш старт пост, а так же все сообщения в теме, от сюда и написал выводы.

Такое встречается как правило при работе с cPanel, там просто в момент запуска скрипта берётся первый, который создаёт повышенную нагрузку, не смотря на то, что он отработал всего одну секунду. Другие могут висеть часами, но с меньшей нагрузкой и Вы об этом из письма не узнаете!

Это и с ISP было и самописными. (Я на СПанель забил много лет назад и не горю желанием с ней связываться)

А если погуглить напр "admin-ajax.php нагрузка на сервер", то можно увидеть, что это была весьма распространённая проблема, не зависящая от панелей, но юзерам хостеры как-то сообщали о причинах.

Принцип работы таких уведомлений, это скрипт, который берёт из топа юзера на момент проверки скрипты с самой высокой нагрузкой на процессор.

Других вариантов в данный момент нет, т.к. для этого либо потребуется куча сотрудников которые будут следить и анализировать, либо ИИ!

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

Да мне в общем-то всё равно на "принцип". Мне интересно узнать причину почему так произошло и кто виноват. Если какой-то мой сайт - какой именно, какой именно процесс/скрипт что сделал.. Или же это косяк у хостера.

А узнать сам я это не могу. Тем более посфактум.

Тем более что 3 часа ночи - это отсутствие и работ и трафа на сайтах (кроме возможных ботов/ДДОСа) и возможно бекапов (или иных профилактических работ) у хостера.

Это только анализ логов + программист.

Ни один хостер Вам не даст точную информацию если это не DOS атака или подвисший скрипт!

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

SeVlad, попробую Вам объяснить доступным языком, вы платите за хостинг 100 рублей в месяц но превышаете ресурсы, переходите на другой тарифный план, который дороже но снова начинаете превышать ресурсы, дальше уже идёт VDS, потом выделенный сервер даже если у вас посещаемость 10 человек в сутки, а в этот момент настаёт задача, либо вы уже арендуете кластер серверов, либо прибегаете к услугам программиста, т.к. бюджет ограничен и не сходится с кол-вом посетителей, но нагрузка высокая!

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

Вы лично если бы были (или есть) программистом согласны за 10 железных рублей прибыли в месяц потратить минимум 12 часов на разбор скриптов клиента? Думаю Ваш ответ будет нет, от сюда и стоит сбавить требования к хостеру.

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

Также в Cloudlinux есть система уведомлений - может уведомляться конкретный пользователь, может администратор, есть лимит по уведомлениям, например слать все ограничения не чаще раза в сутки и т.п., есть шаблоны для писем, которые он может слать:

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

P.S. >но не может сказать что же вызвало это превышение (в 3 часа ночи!).

Скорее всего в это время либо пришёл бот и сканировал ваш сайт (выясняется просто по логам Apache/Nginx), либо выполнялся скрипт на сервере - например бэкап или оптимизация баз данных, который использовал всё доступное IO диска, чем вызвал долгую работу пользовательских скриптов и как следствие переполнение по памяти у конкретного юзера, т.к. появилось большое количество пользовательских запущенных процессов. Если диск не загружен (нормальная работа днём) - процессы быстро отрабатывают и закрываются и памяти юзера хватает.