Система мониторинга

[USSA]

Добрый день.
Помогите пожалуйста с системой мониторинга, которая бы позволяла реализовать требования, которые описаны в пункте "Требования". Каким программным средством возможно реализовать задачу?

Текущее состояние:
- Для мониторинга мы используем Cacti + RRDTool - мониториться огромное количество параметров, как то технические параметры (статистика по загрузке процессора, выделению ОП, количеству запущенных процессов и т.д.), так и параметры, отвечающие за различные параметры сайта (количество логинов, оплат, активностей и т.д.) в итоге около 2 тысяч графиков с различными параметрами! За изменением параметров следит группа мониторинга, задачей которых является контроль за динамикой изменения параметров и информирование ответственных лиц, если значение параметра критически изменилось;
- Применяем плагин Thold для SMS уведомление ответственных о падении определенных параметров.

Требования:
- Т.к мы используем огромное количество графиков и отслеживаем изменение большого количество параметров - это отнимает много времени. Основная идея - это разработать систему, которая согласно заложенного алгоритма оповещала группу мониторинга, о том, что на графике №1 (пример) критически изменились параметры;
- разработать систему уведомлений по средствам SMS (e-mail) с возможностью анализировать и сравнивать падение или рост показателя не в течении суток, а варьировать этот промежуток вручную т.к. для одних параметров критическим является падение(увеличение) в рамках недели (соответственно необходимо сравнивать текущий показатель с показателем недельной давности), для других достаточно и суточного изменения.

Ограничения Cacti + RRDTool:
Т.к. система RRDTool агрегирует данные за сутки то физически невозможно сравнивать текущий показатель с показателем, который имеет значение более суток т.е. мы можем сравнить данные только за ограниченный промежуток времени (сутки), но такой малый промежуток времени не всегда может объективно показать ситуацию иногда для анализа нужно больший период.

Надеюсь на Ваши советы и помощь. Спасибо.

[gescheit]

zabbix определенно подходит!

[USSA]

Спасибо, за ответ.
Можно ли подробнее описать какими средствами zabbix реализуемы мои требования?
Использование Zabbix базы MySQL - это ощутимый плюс, но если данные агрегируются какждые сутки как и в RRDTool это минус. В каком виде данные храняться в MySQL?

[Skyridge]

http://www.zabbix.com/documentation/ru/1.8/manual/start
Тут и про графики и про статистики и про оповещения, хоть даже в jabber. Заббикс штука такая пластилиновая и про него лучше почитать. Главное всё просто, хотя не всегда)

[zalex_ua]

Можно ли подробнее описать какими средствами zabbix реализуемы мои требования?

Могу качественно сравнить то о чем вы говорите. Поехали.
Итак, когда вы в Cacti создали новую метрику, то при первом ее опросе будет создан новый файл данных .rrd. В нем будут жестко прописаны периоды агрегации и глубина истории для каждого периода. Да, если вы наперед можете прикинуть а какую глубину истории вам нужно иметь без агрегации для истории, то вы можете это предусмотреть и задать до первого опроса метрики. Но на практике когда имеете дело с шаблонами и индивидуальными особенностями устройств то все это предусматривать нереально (это из личного опыта).
Или например вы получили в администрирование уже запущенный кактус с накопленной некоторой историей и вы НИКАК не можете изменить параметры агрегации (которые сохранены в каждом индивидуальном файле .rrd) без потери данных. Все - это тупик. Можно конечно удалить нужный файл .rrd и он пересоздастся при следующем опросе и с текущими (подкорректированными) параметрами агрегации, но вы и утратите накопленную историю.
Это огромный минус который перекрывает главный плюс .rrd - компактное хранение истории.

Какая ситуация в заббиксе - база СКЛ это совсем не принцип РРД. В каждого элемента данных (метрики) есть две характеристики - глубина истории и глубина тренда (динамики изменений). В добавок третий - это частота опроса.
Их можно менять в любой момент времени и эти изменения скажем так "начинают действовать" сразу. Вы не буде те терять истории. Можете управлять этим как на уровне шаблонов так и индивидуально в элементах данных.

В результате если вам нужно получить больший период без агрегации - просто увеличиваете, или например исчезла необходимость хранить историю динамики два года, а стало достаточно 6 месяцев - меняете в настройках и ненужная история само очистится в БД, высвободив некоторое пространство в БД (зависит от движка БД).
Это снимает главную проблему - вы не должно суперточто единоразово предусматривать настройки агрегации, а можете менять их в любой момент и получать исходные данные для построения нужных вам триггеров.
А по поводу функционала кактусовского плагина Thold по сравнению с гибкостью идеологии триггеров и уведомлений в Заббиксе - тут вообще говорить нечего - Кактус тупо отдыхает по сравнению с Заббиксом.


Я сам однажды перешел с Кактуса на Заббикс из-за описанных выше проблем.

[USSA]

Спасибо огромное за развернутый ответ, Вы мне очень помогли.