1. Это один из вариантов.
2. Чтобы проблему решить до того, как она станет критичной. В рамках крупного ДЦ это может и нафиг не нужно, согласен.
Последнее можно почти исключить, проверяя сразу разными алгоритмами.
Вы верно говорите - в среднем(!).
Статистика в панели показывает нагрузку на процессор среднюю.
Данный же график снимает показания раз в минуту и те, которые на момент снятия были. (т.е. в данную секунду, когда снимались показания).
Поэтому и различия. За минуту вы могли 20 раз нагрузить сервер на 2%, а в момент снятия на 0%. (средняя будет 2%, а на текущем графике 0%)
Да и время сейчас не пиковое, на графике http://my.author-media.ru/graph/moscow-day.png видно, что нагрузка бывает до 15%, а это 30% нагрузки на один процессор.
P.S.: И учитывайте, что если вам не хватает процессора, то бОльшую часть времени ваш аккаунт и будет потреблять предельно допустимые ресурсы. А если ресурсов "с запасом", то запрос потребит нужные ему ресурсы и снова потребление будет 0%.
1. Вы вряд ли едите 3% 24 часа в сутки.
2. 4,55 суммарно - это чуть больше 9% по тарифам. Это текущая нагрузка на процессор всеми клиентами. Скажем сейчас один клиент потребляет 2%, а вы 1%, а через минуту он потребляет 0%, а вы 3%. Тогда график естественно не изменится.
Нет клиентов, которые свои ресурсы потребляют постоянно. В любом случае, потребление варьируется. Если бы клиент потребляет всегда не ниже своих ресурсов, то ему явно не хватило бы тарифа и в какой-то момент это создало бы проблемы для сайтов. (я полагаю, что если в 3% упирается всегда, то ему нужно не менее 10% в идеале)
На самом деле не редкость и у крупных компаний.
Хотя не обязательно речь в экономии, могут быть другие причины. К примеру - условия труда и т.п.
А я не сторонник полностью автоматических средств защиты от подобного рода вещей.
Я люблю полуавтоматические, которые исключают ложные блокировки хрен знает чего.
1. Засекаем аномалии различными методами.
2. Сервер должен позволить сдерживать поток подключений. Т.е. не блокировать, а не давать достигнуть такого количетсва подключений, которые не сможет обработать тот же web-сервер. (это скорее применимо на случай http-флуда. Хотя он и самый популярный)
В случае других атак - аномалии тоже с большой вероятностью засечь можно.
3. Уведомляем админа, которые уже разруливает атаку. (уже можно и автоматизировать под конкретно текущую проблему. Накидать скрипт не так долго, который по определённым признакам заблокирует именно эту атаку и ничего лишнего).
По ситуации. Где-то можно отличить, а где-то не очень просто.
Здравствуйте.
В любое время дня и ночи можете писать в web-чат у меня в подписи
По сути, любой ДДОС, это увеличение количества обращений к серверу.
Почему не ловить подобные аномалии? В смысле уведомлять администратора о подобных изменениях.
В рамках shared-хостинга разницы нет.
Можно мониторить количество пакетов в секунду. Это можно "снимать" и с интерфейса сервера и с роутера (если есть тот же snmp). Можно смотреть разницу между in/out, смотреть конкретно in.
Тот же http-флуд не даст значительного прироста трафика, чтобы его поймать, а вот количество входящих пакетов обычно возрастает в разы.
1. По ОЗУ графиков нет, т.к. не вижу в них необходимости. Памяти на сервере обычно в 3-5 раз больше, чем требуется сайтам клиентов и она используется под дисковый кэш и прочие нужды. На текущем сервере памяти 24 Гб. (на текущий момент её используется 10,5Гб вместе с кэшем MySQL, вместе с памятью для xcache и т.п.)
2. Среднее время ответа на тикеты клиентов не имеет отношения к графикам нагрузки сервера, поэтому его там и нет. Могу сказать, что среднее время ответа 5-10 минут.
Можно и эту статистику опубликовать, только немного позже и отдельно.
Нам нечего скрывать, поэтому открываем статистику VIP-сервера в Москве, где сейчас активируются новые заказы!
Графики обновляются раз в сутки и доступны по ссылке http://my.author-media.ru/graph/moscow.html
Нагрузка на CPU показывается суммарная по всем аккаунтам сервера. Т.е. сколько CPU потребляют все клиенты в целом.
Прошу обратить внимание, что показывается суммарная нагрузка на все процессоры сервера, когда нагрузка по тарифам считается от 1 процессора. (т.е. чтобы понять, сколько % от одного процессора сейчас используется - нужно умножить число на 2)
Вы можете в любом время убедиться, что сервера всегда имеют большой запас производительности!
Если интересуют какие-то дополнительные графики, пишите :)
