Sergius

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

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

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

с виду все 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, но на это я не хотел засорят тему.

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

Добрый вечер

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


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


Задача:

Сервер-мониторинг > 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, для сигнализации какой нибудь СМС сервис.


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

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

простой пример:

В бд 2 колонки (id, content)

Например:
5, "first content"
7, "second content"

index.html

<body>
    <div id="navi">
        <a href="/5">First content</a>
        <a href="/7">Second content</a>
    </div>
    <div id="content">
        <?php $id = $_GET['id']; ?>
        // Из дб достаешь content по id
        <?php include_once($content); ?>
    </div>
</body>

.htaccess

RewriteEngine on 
RewriteRule ^(.*)$ index.php?id=$1

www.domain.tld/1234 ==> www.domain.tld/index.php?id=1234

не проверял, но примерно так

А какие преимущества есть (были бы) у Exim+Dovecot для моего случая ?

Не понял вопроса, преимущества по сравнению с чем?

Иначе получается диалог:

Я: 2+2=4
ВЫ: А какие преимущества что 4?

ps. для вашей задачи подойдет google apps 100%

А какие преимущества есть (были бы) у Exim+Dovecot для моего случая ?

Не понял вопроса, преимущества по сравнению с чем?

Иначе получается диалог:

Я: 2+2=4
ВЫ: А какие преимущества что 4?

ps. для вашей задачи подойдет google apps 100%

Я наверное вопрос не так сформулировал,
имелось введу преимущества Exim например к Postfix.

Спасибо всем, я ещё раз пересмотрю вариант с GoogleApps-Mail.

phpdude, adw0rd

спасибо за быстрые ответы,

GoogleApps я уже рассматривал как вариант,

но во первых он стоит 40 €/user, (есть конешно наверное и бесплатний ограничений вариант)
во вторих мне надо чтобы рассылка производилась с моего адреса (чтобы к лудям письма приходили не от @google.tld)

А какие преимущества есть (были бы) у Exim+Dovecot для моего случая ?

Здравствуйте пыхари и пыхаришки,

сразу извиняюсь за мой русский, я уже живу в Германии 20 лет, и всё забыл так что не ругайтесь.

Я немножко почитал ваш форум и вроде многие не плохо разбираются в администрации серверов и давно уже с ним профессионально работают :-)

Я программист (C++, C#, PHP, Perl, и куча других языков, около 25), мой последний проект был Sacred 2 (наверное кто-то знает эту игрушку, участвовал там в разработке Netzwork, GraphicEngine и EventSystem для GameConvention). Но в администрации серверов к сожалению нету огромного опыта.

Подскажите пожалуйста какой Email-Server лучше поставит на Debian (Postfix, Courier, ….) и почему ?

Требования просты:
- будет всего около 20 Emails (к примеру [email protected], [email protected], [email protected], …)
- Fronted не надо, должен быть IMAP (POP3 не нужен)
- рассылка будет происходит через Skripts (perl) и программы (к примеру Thunderbird)

Думаю для этих требований не надо гигантов как Postfix.

Заранее благодарен!

ivanscm, на freebsd будешь поднимать? Я просто статью все дописать хочу по установке "Dovecot, Exim, Postfixadmin, Roundcube, Clamav и SpamAssassin" на FreeBSD, да надо проверить все конфиги и т.д. на ком-то, если дашь доступ по ssh, то я сам тебе это все подниму!

Мне главное конфиги применить и последовательность действий точнее описать

Привет adw0rd ,

если желание есть, могу предложит ещё Debian Lenny.
Если статью и конфиги напишеш, пиши в личку.