[наивный бред пион..нецветочка - skipped. Мы храним логи. Те, которые нужны, чтобы удовлетворить возникшую потребность товарищей - их гораздо меньше чем ты нафантазировал.]> Дык rrdtool как раз для чего-то такого и катит, если агрегированная база с достаточным
> разрешением.
агрегированная - означает что разрешение намеренно ограничено. Иначе нахрен бы нужно то агрегирование? Весь смысл RR - что старые записи - вытесняются новыми. А сохраняется огрубленная информация, и та удаляется по тому же принципу.
rrdtool "для такого" феерически бесполезен, поскольку если создать такое чудовище, которое будет хранить детальную информацию, оно лопнет раньше чем sql база в силу абсолютно неэффективного поиска и хранилища, двадцать лет назад уже устаревших.
> Все там видно, если достаточно точек. Можно каждые полчаса хранить в годовом графике.
Признайся честно - ты мониторишь только васян-хост, да?
Пол-часа - это вообще можно не хранить. Хранить надо изменения состояния, которые важны для сервиса - обычно это минуты, а иногда и секунды. А иногда ничего не меняется, и их можно вообще не хранить (достаточно хранить факт "не изменилось")
> При том заметь, это фиксированный расход, он не растет по времени.
потому что волшебство, да? Пятое измерение открыли? Нет, братело - этот "фиксированный расход" у тебя за счет того что данные просто удаляются. А чтобы они не удалялись - надо прямо сейчас занять то место, которое заполнилось бы за год - верх экономии, не включая мозгов. А буде понадобится пять лет - то занять место на пять лет вперед.
И я тебе страшную тайну открою - удалить данные можно и из sql.
> Его пойнт в том чтобы уменьшить объем агрегированных данных до вменяемого размера.
позволяющего нарисовать бесполезный график за год, за месяц и за неделю. Обычно у васянов, любителей rrd, такие. Которые мне как раз абсолютно не нужны.
> Наверное, rrdtool тоже можно в такой режим загнать
нельзя. Он и не предназначен для этого, и не способен переварить такой объем.
А вот sql на энтерпрайзном железе - вообще говоря, способен. Причем не надо пытаться заранее угадать, а потом плакать что огрубление произошло слишком сильно - всегда можно оставить себе запас, а поудалять потом, когда убедишься, что такая детализация тебе не пригодилась, а мощности начнет (если вообще начнет) не хватать.
Идея же хранения агрегированных данных совсем другая. Никому не интересны запросы к базе вида "что показывал этот параметр в 23:00:06.123". Во-первых, такого значения там нет. Ближайшее снято в 23:00:00.354, потому что этот параметр проверяется раз в две минуты, и проверка не мгновенна. Поиск подобных диапазонов в sql - неэффективен сам по себе. Во-вторых, мы не это на самом деле увидеть хотели. Мы хотели увидеть, вероятно, "возможное значение в этот момент, угаданное по известным точкам" (это ни разу не "среднее!"). А может и вовсе всего лишь получить примерную точку для графика, среди прочих пары тысяч с нужным интервалом (все подряд - не требуются, график крупный. А вот экстремумы не прочавкать - не помешало бы).
Это опять не лучшая задача для sql.
Для этого существуют базы, предназначенные хранить именно метрики. Но rrd среди них - давным-давно самый устаревший и бесполезный. Придуман когда компьютеры еще были большие, а емкость дисков и памяти - крохотными.
