ФорумРазработкаУстановка и администрирование ПОВебсервер → Прошу обсудить концерт (Мониторинг + forecast)

Прошу обсудить концерт (Мониторинг + forecast)

  • Sergius

    Сообщения: 7 Репутация: N Группа: Кто попало

    Spritz 18 апреля 2010 г. 0:30

    Добрый вечер

    не нашёл к сожалению подходящего раздела ф форуме, поетому пишу здесь, прошу не ругаться :-)


    Хотел посоветоваться с вами с концепцией / реализацией одного проекта.


    Задача:

    Сервер-мониторинг > 1000 серверов, с разными системами (SLES, Debian, Ubuntu, Windows, AIX, …)
    Мониторинг должен считывать такие данные как: HDD, CPU, RAM, …

    После чего данные должны автоматически прогнозироваться (forecast) на следующее время (1-12

    месяцев), и при возможных перегрузках в будущем заранее отправлять сигнал администраторам.


    Для чего это надо:

    Одна компания занимается хостингом довольно важных данных, и хочет увеличить достигаемость серверов

    более чем 99,9% (в словах 99,9% = мах. 35 часов в год offline). Проблема в том, что этой компании

    нужно несколько недель/месяцев чтобы получить подтверждение на разрешение замены или увеличения

    компонентов систем.

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

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

    В итоге кроме автоматических сигналов, администраторы должны иметь возможность смотреть все эти

    данные (актуальные и прогнозы) через web-fronted, с кучей опций.

    Я понимаю, что на длительное время делать прогнозы это задача трудная, но речь не об этом, а об

    мониторинге и системе администрирования данных.


    Мои мысли концепции:

    Я просмотрел много различных (полу-)готових продуктов,
    таких как: NMON, Munin, Nagios, Zmanda, …

    Во первых все они выполняют либо часть задачи, либо не достаточно гибкие, или в конце концов не

    бегут на всех требуемых системах, поэтому требуется собственное решение.

    1.Проблема: Добыча данных
    2.Проблема: Доставка данных
    3.Проблема: Хранение данных
    4.Проблема: Прогнозы (forecast)
    5.Проблема: Сигналы и визуализация

    1.Проблема: Добыча данных

    Так как очень много разных систем и версий систем, она является одной из главных.
    Большинство систем поддерживают NMON, но не все. К тому же NMON например не знает LVM (logic volumen

    manager). Поэтому думаю придётся добывать некоторые данные в ручную (perl, bash, … и запускать

    через cronjob каждые X минут).

    2.Проблема: Доставка данных

    Все данные должны хранится на одном центральном сервере и быть достаточно актуальними (мах 1 час) из

    за многих соображений.
    Идея была что каждый из серверов (clients) через SFTP или SNMP, каждый час переправляет накопившуюся

    информацию на центральний сервер и начинает собирать новую.

    3.Проблема: Хранение данных

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

    пришли: NMON, Munin, свои скрипты, …) и переводится в базу данных. Тоесть должен бит набор

    скриптов, который трансферирует data2db.

    В итоге такой сценарий
    1000 серверов * 20 данных про сервер * 365 дней * 60 часов = 438.000.000 данных в год.
    438.000.000 * 3 (id, timestamp, data) * 4 Byte = 5 Gigabyte в год.

    Исходя из этого сценария и ежедневных SELECTs для обработки forecasts нужно выбрать подходящую базу

    данных. Я думаю взять PostgreSQL.

    4.Проблема: Прогнозы (forecast)

    Тут есть достаточно много "готовых" решений, которые меня пока устраивают, такие как ARIMA X11, BV,

    Holt Winters, …

    5.Проблема: Сигналы и визуализация

    Ну это уже дело вкуса, думаю возьму тут для frontend PHP (Zend MVC) и для построения графиков

    pChart, для сигнализации какой нибудь СМС сервис.


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

    Заранее очень признателен.

  • rider-sx

    Сообщения: 2706 Репутация: N Группа: Адекваты

    Spritz 18 апреля 2010 г. 1:22, спустя 51 минуту 40 секунд

    Пишете на сях программулину которая добывает данные и отправляет их на сервер собирающий, запускаете по крону ее, а там уж собираете храните обрабатывайте))
  • phpdude

    Сообщения: 26624 Репутация: N Группа: в ухо

    Spritz 18 апреля 2010 г. 2:08, спустя 46 минут 19 секунд

    да в общем то ничего тут сложного нет с виду, просто брать и делать имхо :)

    бд можно не постгре и тп юзать, если скорость нужна нефигическая, то можно юзать свой "бд" сервер который можно оптимизировать под колоссальную скорость если делать именно под эту задачу
    Спустя 16 сек.
    с виду все 3 проблемы - не проблема :)
    Сапожник без сапог
  • Givi

    Сообщения: 2284 Репутация: N Группа: Адекваты

    Spritz 18 апреля 2010 г. 3:45, спустя 1 час 36 минут 43 секунды

    Sergius, а нафига собрать стату каждый час, если данная фишка решает проблему недель/месяцев? Думаю вполне достаточно 1, максимум 2 раза в день собирать стату. Более точного прогнозирования нафиг не нужно.
    И в любом случае эта система никак не учитывает человеческий фактор. А именно он решающий при определении необходимости апгрейда, так как именно юзеры могут создать лишнюю нагрузку на сервер, залить файлы, "съесть" лишней памяти. И все это может произойти в течении очень короткого промежутка времени… и после этого опять те же недели/месяцы ожидания разрешения на апгрейд.

    п.с. Думаю хреновая затея. По крайней мере из описания её задачи.
  • Sergius

    Сообщения: 7 Репутация: N Группа: Кто попало

    Spritz 18 апреля 2010 г. 11:18, спустя 7 часов 32 минуты 55 секунд


    Пишете на сях программулину которая добывает данные и отправляет их на сервер собирающий, запускаете по крону ее, а там уж собираете храните обрабатывайте))


    в принципе это и была описанная идея



    да в общем то ничего тут сложного нет с виду, просто брать и делать имхо :)

    с виду все 3 проблемы - не проблема :)


    Cогласен, это не проблема,
    но есть несколько нюансев, которые я хотел би уточнит и посоветоваться.

    Как я сказал, к примеру НМОН не работает на всех системах и считывает не все необходимые данные.
    http://www.ibm.com/developerworks/aix/library/au-analyze_aix/
    Может посоветуете какие-нибудь альтернативы или скрипты, например для считывания LVM.

    Другая задача, не возникнет ли проблем при током объёме информации (пара миллиардов sets) на PostgreSQL или MySQL и их регулярном считывании realtime.

    Если смысл кешировать обработанную информацию (составленные графики, предыдущие расчёты forecast) или при вызове составлять заново.

    Допускается возможность, что данные будут приходит от clients не постоянно, к примеру если один из них находится в режиме update или restart.
    Для просчёта forecast алгоритмов требуется информация без перерыва, то-есть в таком случае нужна какая-нибудь интерполяция, известны какие-нибудь алгоритмы для этого ?



    Sergius, а нафига собрать стату каждый час, если данная фишка решает проблему недель/месяцев? Думаю вполне достаточно 1, максимум 2 раза в день собирать стату. Более точного прогнозирования нафиг не нужно.
    И в любом случае эта система никак не учитывает человеческий фактор. А именно он решающий при определении необходимости апгрейда, так как именно юзеры могут создать лишнюю нагрузку на сервер, залить файлы, "съесть" лишней памяти. И все это может произойти в течении очень короткого промежутка времени… и после этого опять те же недели/месяцы ожидания разрешения на апгрейд.

    п.с. Думаю хреновая затея. По крайней мере из описания её задачи.


    Ты прав, для форецаст будут использоваться данные по averaging за пол дня или за день,
    но для Live-Statistic надо будет отображать 5 мин данные за какой-нибудь период, для этого надо иметь полную информацию в базе данных.

    Человеческий фактор будет учитываться также, и обрабатываться кучей настроек в backend, но на это я не хотел засорят тему.

    Этот проект не будет являться ключевым для всех решений, но он будет давать дополнительную информацию, для облегчения принятия решений.
  • phpdude

    Сообщения: 26624 Репутация: N Группа: в ухо

    Spritz 18 апреля 2010 г. 12:11, спустя 52 минуты 56 секунд

    Sergius, в обещм смотри, тебе для лив статистики можно юзать все записи из бд за последние х минут, а для "что было такого то числа в такой то интервал времени" - подсчитанную кешированную статистику, итого у тебя будет допустим не 5 * х записей (раз в минуту), а 1 * х записей. это как мысль, если углубиться, можно много что попроще сделать чем это сейчас выглядит
    Сапожник без сапог

Пожалуйста, авторизуйтесь, чтобы написать комментарий!