Здравствуйте, ELazin, Вы писали:

EL>Здравствуйте, Sheridan, Вы писали:
EL>>>А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени?
S>>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее"

EL>Нужно определиться с макс. пропускной способностью и количеством параметров, которые нужно мониторить. Если их много и они могут часто добавляться, то RRD будет плохо работать. Нужно брать какую-нибудь нормальную базу данных, а еще лучше — базу данных для временных рядов. И от этого же будет зависеть то, сколько памяти сожрет хранение данных на глубину в один год.
Ну, на моей практике бывало пополнение 1-1,5гб\сутки. Мускуль выжил только на ssd в рейде.

EL>Помимо этого, я бы не советовал использовать встраиваемую БД, лучше использовать отдельный сервер, пусть даже в начале БД будет работать на той же машине. В этом случае, если твое приложение начнет портить память — оно не сможет испортить твою базу данных.
Конечно отдельный сервер. По другому тут никак.

EL>Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг.
с графаной?

Здравствуйте, Sheridan, Вы писали:

EL>>А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени?
S>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее"
S>По времени хранения... Думаю ориентироваться минимум на год.
А зачем это надо хранить год?

Всегда думал, что подобные системы больше для более-менее оперативного мониторинга, нет? Зачем может быть нужна инфа, как там трафик гулял по тому или иному сфичу год назад?

Здравствуйте, paucity, Вы писали:

S>>По времени хранения... Думаю ориентироваться минимум на год.
P>А зачем это надо хранить год?
P>Всегда думал, что подобные системы больше для более-менее оперативного мониторинга, нет? Зачем может быть нужна инфа, как там трафик гулял по тому или иному сфичу год назад?
Год — для анализа, чтобы увидеть тенденции и на них реагировать.
Вот например, использование дискового пространства на одном из моих серверов (да, не трафик, но наглядно)
Вид за день

Вид за месяц

Вид за год

Только за год видно что места становится меньше, но пока что еще некритично. Года через три только можно будет думать о расширении, если чистки не помогут.
Так и с трафиком. Только чуть по другому.

S>Ну, на моей практике бывало пополнение 1-1,5гб\сутки. Мускуль выжил только на ssd в рейде.
А какая схема использовалась? По опыту — 1-1.5гб/сутки это слезы. Это легко вытянет и graphite на слабенькой машине.

EL>>Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг.
S>с графаной?
http://grafana.org/

Здравствуйте, ELazin, Вы писали:

S>>Ну, на моей практике бывало пополнение 1-1,5гб\сутки. Мускуль выжил только на ssd в рейде.
EL>А какая схема использовалась? По опыту — 1-1.5гб/сутки это слезы. Это легко вытянет и graphite на слабенькой машине.
Это был zabbix. Что он там с БД (мускуль и постгрес пробовал) делал — хз, но упиралось всё в диск. Лишь ssd помогли.

EL>>>Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг.
S>>с графаной?
EL>http://grafana.org/
О, спасибо, интересная штука. Возможно и с ней клиента сделаю.

Здравствуйте, Sheridan, Вы писали:

S>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее"
S>По времени хранения... Думаю ориентироваться минимум на год.

Я полагаю, для такой задачи нет ничего быстрее, чем дописывать записи в хвост линейного файла. Если редкая потеря данных не очень критична, можно даже с "транзакционностью" не очень заморачиваться, и доверитс ОС скидывать кеш на диск по ее собственному усмотрению. Тогда в случае чего последние записи могут быть утеряны или оборваны. Время от времени файл завершать и начинать новый; старые выбрасывать. И поверх этого навесить какую-нибудь незамысловатую базу, чтобы искать по файлам было проще (база должна выдавать примерно, откуда и до куда смотреть, чтобы не прочесывать все файлы с начала и до конца).

Это будет работать на скорости, близкой к скорости аппаратуры (упрется в диск, разумеется).

Pzz>Я полагаю, для такой задачи нет ничего быстрее, чем дописывать записи в хвост линейного файла. Если редкая потеря данных не очень критична, можно даже с "транзакционностью" не очень заморачиваться, и доверитс ОС скидывать кеш на диск по ее собственному усмотрению. Тогда в случае чего последние записи могут быть утеряны или оборваны. Время от времени файл завершать и начинать новый; старые выбрасывать. И поверх этого навесить какую-нибудь незамысловатую базу, чтобы искать по файлам было проще (база должна выдавать примерно, откуда и до куда смотреть, чтобы не прочесывать все файлы с начала и до конца).

Это не будет работать, так как данные от разных источников могут приходить со смещенными метками времени, поэтому прежде чем писать на диск, их нужно кешировать и сортировать. Данные часто агрегируются на хостах и отправляются пачками раз в Х секунд (statsd так работает, например). В итоге, данные в файле у тебя будут вперемешку и что-то ты не сможешь найти, с помощью индекса.

Pzz>Это будет работать на скорости, близкой к скорости аппаратуры (упрется в диск, разумеется).
В случае современных TSDB это не так, так как там есть сжатие. Допустим, один элемент данных это 24 байта (id — 8 байт, метка времени — 8 байт, значение — 8 байт). Допустим у нас в системе установлен SSD, который может записывать данные в лог последовательно со скоростью 100Мб/сек. Пропускная способность в результате будет порядка 4 миллионов значений в секунду. Но по факту, 24 байта на значение это очень дорого. Если мы пишем со скоростью 100К значений в секунду, то за сутки сожрем примерно 200Гб. За год — под 100Тб.

В то же время, современные TSDB умеют сжимать эти данные примерно до 3х байт на элемент данных. Пропускная способность от этого страдает, так как процесс записи становится CPU bound, но зато вместо 200Гб в сутки, можно ограничиться 25Гб (при той же скорости записи). Это примерно 10Тб в год, не так уж много.

Здравствуйте, ELazin, Вы писали:

EL>Это не будет работать, так как данные от разных источников могут приходить со смещенными метками времени, поэтому прежде чем писать на диск, их нужно кешировать и сортировать. Данные часто агрегируются на хостах и отправляются пачками раз в Х секунд (statsd так работает, например). В итоге, данные в файле у тебя будут вперемешку и что-то ты не сможешь найти, с помощью индекса.

Всякая проблема имеет, однако, решение.

Во-первых, можно проставлять временные метки по часам принимающего хоста. Это может даже и правильно. Во-вторых, можно искать с запасом (скажем, плюс-минус 10 минут, в надежде, что настолько часы не врут).

Pzz>>Это будет работать на скорости, близкой к скорости аппаратуры (упрется в диск, разумеется).
EL>В случае современных TSDB это не так, так как там есть сжатие. Допустим, один элемент данных это 24 байта (id — 8 байт, метка времени — 8 байт, значение — 8 байт). Допустим у нас в системе установлен SSD, который может записывать данные в лог последовательно со скоростью 100Мб/сек. Пропускная способность в результате будет порядка 4 миллионов значений в секунду. Но по факту, 24 байта на значение это очень дорого. Если мы пишем со скоростью 100К значений в секунду, то за сутки сожрем примерно 200Гб. За год — под 100Тб.

Линейный файл тоже никто не мешает сжимать по ходу записи. Только скорость, боюсь, очень сильно просядет.

Современный винчестер и современная SSD в режиме линейной записи дают примерно одинаковую скорость. Но только место на диске стоит на порядок дешевле, чем на флешке. Флешку имеет смысл использовать, когда доступ идет случайный, там она очень сильно выигрывает за счет отсутствия необходимости чего-либо механически крутить или перемещать.

Pzz>Всякая проблема имеет, однако, решение.
Конечно имеет, в данном случае это кеширование в памяти и сортировка перед записью на диск.

Pzz>Во-первых, можно проставлять временные метки по часам принимающего хоста. Это может даже и правильно.
Это точно неправильно. Я приводил пример statsd, который накапливает в себе данные за flush interval и потом отправляет все скопом. Flush interval может быть 10 секунд, а может и минуту. В случае devops задач тебе может потребоваться связать какое-нибудь событие на графике, например с данными в логе на удаленной машине или в кибане, тут то окажется что метки времени отличаются и все это бесполезно абсолютно.

Pzz>Во-вторых, можно искать с запасом (скажем, плюс-минус 10 минут, в надежде, что настолько часы не врут).
Это да, но помимо этого, тебе придется каждый раз сортировать данные, когда ты захочешь их прочитать и проанализировать, ну или просто, несколько графиков в одном окне нарисовать.

Pzz>Линейный файл тоже никто не мешает сжимать по ходу записи. Только скорость, боюсь, очень сильно просядет.
Ну будешь ты сжимать gzip-ом каким-нибудь на лету. Будет не 24 байта на элемент данных а 22. Я сам не проверял, но КМК, все будет плохо. Алгоритмы сжатия временных рядов сильно круче жмут чем generic алгоритмы. Те же метки времени обычно имеют фикс. шаг (и точность) и соответственно хорошо жмутся с помощью тупого delta-RLE. Для float-ов есть свой аналог delta-encoding, который жмет оч. хорошо, если у тебя не совершенно случайные данные.

Pzz>Современный винчестер и современная SSD в режиме линейной записи дают примерно одинаковую скорость. Но только место на диске стоит на порядок дешевле, чем на флешке. Флешку имеет смысл использовать, когда доступ идет случайный, там она очень сильно выигрывает за счет отсутствия необходимости чего-либо механически крутить или перемещать.
На самом деле это не так, скорость последовательной записи на SSD сильно выше (зависит от конкретного SSD и его интерфейса).