Система управления хостингом. Пресловутая "панелька", в частности.
У семи нянек дитя без глазу...
Это прежде всего дорогое решение. Во-первых - потребует постоянных услуг квалифицированного администратора. А во-вторых, удвоит стоимость оборудования (покуда у Вас реально 2-3 сервера). Хостинг весьма не бюджетный будет.
А чего вдруг падают-то?
Имеет.
Грамотная инфраструктура управления вашим хостингом, админы, организация техподдержки - вот что реально "увидят" ваши клиенты в первую очередь. А не мифическую "отказоустойчивость" из полтора сервера...
V(o)ViK и Pavel.Odintsov Вам дело говорят.
Вот это уже ближе к реальному описанию проблемы. Если это, конечно, не Ваши фантазии, что так у Вас должно быть, а Вы реально это наблюдаете.
Насколько "увеличивается время загрузки"?
Головой лучше об стенку побейтесь - смысл тот же, равно как и результат. Вам уже не раз объясняли, что делать что-либо имеет смысл только если вы понимаете смысл действий полностью.
Ерунду думаете, как обычно. В логах может быть информация о проблемах. Например, какое-то соединение не обработано (таймаут к-л и т.п.). То, что что-то работало, но медленно - проблемой не является. Так что скорее всего в логах увидите мусор.
Нужно было головой думать раньше. Настроить мониторинг и смотреть в момент проблемы, собирать метрики производительности интересующих Вас приложений. Искать корреляции.
См. выше. Другой вопрос - а зачем вообще смотреть? В чем, собственно, проблема-то проявляется?
Блин, Вы в состоянии разобраться что в текущий момент на сервере запущено и что делает? Если нет - едиенственный еще разумный совет (помимо перечисленных выше): забить на всю эту ерунду и нанять квалифицированного администратора. Не жадничайте - боком выйдет.
Удосужились бы прочитать ман - знали бы, что данный вариант ровно ничем не отличается от приведенного ТС.
Это для работы с m/monit. Покуда m/monit не связывался с monit - id сервиса установить нельзя.
PS: Вообще, такие вещи тоже описаны в документации. Если Вы не хотите в принципе читать документацию - пользуйтесь готовыми примерами. Для стандартных сервисов (apache/mysql/nginx) - это подойдет.
Выше уже написали:
И что? Солнце теперь не светит? Что случилось-то?
А кто Вам сказал, что туда пид должен записываться?
Мануал, блин, прочитать. Разобраться почему "не отвечает" сервис.
Ну убрать нафиг эту проверку по порту. Или сделать ее более осмысленной - для TCP с SEND/EXPECT, например.
Нет, нельзя. Диски с зараженного сервера имеет смысл скопировать в сторонку - можно потом посмотреть в чем было дело.
Утилита, скорее всего - man. Убедитесь, что на файлы не выставлены к-л атрибуты, запрещающие модификацию (man lsattr, man chattr).
Переустановите с нуля и пусть сервер просетапит нормальный администратор.
Насчет "специальной защиты" риторический вопрос - а какая "неспециальная" использовалась?
