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

SeVlad, ISPManager (как я понимаю, из скринов - это она) подобного функционала даже не предполагает. Ни уведомлений, ни процессов, ничего. Это, на самом деле, головная боль.. Панельку надо допиливать, но с обновлениями она все допилы легко превращает в тыкву, поэтому тут единственно правильное поведение - или хостер пишет свои костыли (нахрена ему клаудлинукс, правда, тогда нужен будет), или быстренько снимает блокировки и пытается как-то разобраться.

Вообще же, косвенно выводы можно сделать, почитав акцесс.лог (да, может быть в это время на сайте была дикая посещаемость или долбежка с определённых IP).

На практике мы уже столкнулись, когда некоторые сайты некоторых клиентов (преимущественно, ИМ) начинают парсить какими-то дикими парсерами, которые не закрывают коннекты, медленно загружая странички и забивая слоты апача. Решаем или настройкой файрволла, или переводом таких сайтов на Nginx + PHP-FPM, с апачем всё печально. Наверняка, способы решения проблемы и с апачем есть, но нам так проще.

Она, родимая :) Понятно спс.

Я вообще-то не особо на ISP надеялся. но думал, может что специальное для CL есть. Всё таки коммерческий продукт, заточенный под хостинг. Ну или если не на уровне ОС, то может какой-то сторонний мониторинг существует (ну типа top, только для контроля юзеров), который хостинги устанавливают.

CL тем и хороша, что сама разблокирует акк когда нагрузка падает.

Вообще же во время это траблы сайты периодически были доступны (на минуту-другую). Мне в почту 100500 писем свалилось от стороннего мониторинга :)

А вот от хостера я так ничего и не добился.. :(

А есть какой-то удобный инструмент (для юзера в см), чтобы как-то удобно их проанализировать?

Или копипаст в эксель и глазками-фильтарми?

Ну ага, да. Просто панельку купить дешевле, чем сопровождать своё решение. На самом деле, штатного такого функционала часто нет по той причине, что оно само по себе не хило так ресурсов кушать будет. Как бы это имеет смысл только в кровавом энтерпрайзе (я про список процессов). Даже профилировщики PHP - экзотика, а вы прям хотите, чтоб оно статистику контейнера снапшотило ;). Вообще не плохо было бы перед блокировкой запускать некоторый скрипт, но CLoudLinux - просто тюнингованная CentOS и любой пряморукий хостер может делать всё то же самое без её покупки. Блокировка выполняется механизмами системы и на уровне системы, панель тут никак не участвует.

Ну, а ISP - мрак и ужас, если честно, только ценой и берёт. Ну и привычкой к ней пользователей..

Ну, на самом деле, там разные механизмы можно применить, в дефолте это и правда так, но никакой детальной статистики.

Если у хостера не подрублен учет статистики типа AWstats или WebAlizer - то именно так. Все остальные инструменты обычно - это консоль и консольные утилиты системного админситратора или любимая IDE/текстовый редактор, увешанные нужными плагинами. Эксель будет намного проще для среднестатистического пользователя. Если я не прав - было бы интересно почитать про нормальные инструменты. Как минимум, парсинг логов апача выполняется или спец. софтом на сервере, или руками под Win-машинами. Можно поставить виртуалку и загрузить в неё соответсвующие логи, потом сгенерировать статистику, но вряд ли оно вам надо (много телодвижений).

Я про это не раз слышал, но в реальности ни разу не встречал таких :)

А LSAPI так вообще.. экзотика можно сказать :)

1) ну да, нормальная как из моей практики, они же предоставили ресурсы согласно тарифу, всё что выше - ошибка 503.

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

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

Да я не против 503.. Но на протяжении нескольких часов эта 503 (и 500 кстати тоже) возникала 100500 раз. Буквально каждую минуту- две. Т.е. явно же была какая-то проблема. Либо из вне (ДДОС напр) либо изнутри (ну что-то глюкнуло или криво обновилось).

Вот я мне и стало интересно - неужели такие нештатные ситуации не видятся хостерами.

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

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

SeVlad, это некомпетентность хостера, если точнее, то отсутствие системного администратора.

Есть не только в CL. Это вообще прикручивается куда угодно.

ну просто потому, что это и не надо. Дело в том, что основное преимущество CL - установка ядра без перезагрузки, доступна и в патном RHEL. В CentOS надо заботиться самому.

Остальное:

LVE - ну, блин, это cgroups, который лучше работать в CL не стал. Но там его настраивают, и делают удобным. Как бы дело хозяйское, но при серьезном подходе вы и не узнаете об этом, ибо это должен уметь каждый.

CageFS - ну, опять же, ноги растут из OpenVZ. Собственно, ядро там от OpenVZ фактически, ЕМНИП.

Тут следует понимать, что CL обеспечивает фактически пользователей уже настроенными виртуалками под OVZ. Со всеми вытекающими.

Т.е. CL - фактически контейнеризация. Решает следующие задачи из коробки:

Зарезать пользователей по ресурсам, как это сделано на виртуалках (одна из причин, почему предлагают ВПС - с ними проще) - тогда проще оверселлить;

запретить выход пользователям из песочницы (некоторый аналог docker) ;

У каждого свой выбор, при правильном подходе решает кучу проблем, но есть нюансы. Доводить CentOS до такого состояния просто не имеет смысла: это уже не совсем шаред. Например, на обычном шареде проблему бы увидел мониторинг, просигнализировал админу и блокирнуло бы пользователя только в крайнем случае, в обычном случае бы прилетело предупреждение. А админ, может, побанил бы нарушителей и помог бы другим пользователям. Т.е. если какая-то школота организовала бы ддос по L7 на сайт, то шаред бы с большой долей вероятности отбился перебанив этих ботов, а CL сразу отрубило пользователя. Кроме того, такой подход лишает пользователя возможностей (специфических, правда: те, кому они нужны берут как минимум ВПС), доступных на обычном шареде с SSH.

---------- Добавлено 20.07.2019 в 00:00 ----------

Или админ спал. В любом случае, в дефолте CL режет по установленным ресурсам, а там хоть кол на голове теши. Для этого его и ставят.

---------- Добавлено 20.07.2019 в 00:01 ----------

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

---------- Добавлено 20.07.2019 в 00:11 ----------

Посмотрел репозитории, от OVZ вроде отошли, но в остальном - примерно так как я описал.

У меня такое мнение уже давно:) Но, если не считать вот таких вот редких косяков - в целом всё нормально. Да, бывали разные проблемы, но решались. А у какого хостера их нет :)

Опять же - это я всё уже не раз слышал, но в реальности не видел.

Надо. Это намного лучше чем Nginx + PHP-FPM на шареде*.

Это я говорю как юзер, поюзавший (и юзающий) разные хостинги с разными набором ПО.

*Уточню: лучше для ВП при тех "типовых" конфигурациях/настройках которые есть у хостеров.

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

Так ведь?

Со стороны пользователя. Я же предпочитаю давать на сервере выбор самому пользователю. LSAPI я не ставлю в шаред по той причине, что это приведёт к дополнительным телодвижениям по поддержке, к которым я не готов. Того же мнения и мои коллеги: выигрыш перед mpm-itk минимален и заметен только в хайлоаде.

Нет, он вряд ли вам может сказать, насколько именно грузят именно _ваши_ запросы сервер БД. Он может показать только запросы, которые выполняются дольше какого-то времени (это я имел ввиду). Ну так у большинства, сервер БД весьма интересная штука с этой точки зрения.

А вот для этого нужно ставить или профилировщики, приводящие сами по себе к повышению нагрузки, или хотя бы переводить режим работы в CGI (что само по себе медленно и печально) и парсить системные ФС. Нет, этого он делать не будет: дорого получается. Только если клиент очень важный, или платит достаточно много денег. Массово же с такими клиентами за те цены, что сейчас на рынке возиться не выгодно: проще выпнуть.