> удовлетворить возникшую потребность товарищей - их гораздо меньше чем ты нафантазировал.] Если они через 5 лет всерьез приползают, их реальная потребность таки перестать жрать тормозную жидкость.
> агрегированная - означает что разрешение намеренно ограничено.
Ну так надо определиться какое разрешение разумное и угомониться. Врядли тебе нужен посекундный лог за 10 лет. Чего с ним делать?
> Иначе нахрен бы нужно то агрегирование?
Чтобы избежать неограниченного роста базы по времени, например.
> Весь смысл RR - что старые записи - вытесняются новыми.
> А сохраняется огрубленная информация, и та удаляется по тому же принципу.
Это однако ничего не говорит о том сколько и чего будет удалиться. Зачем надо посекундно 10-летний период? Чтобы хранилки впаривать, побольше и подороже? Ну это вариант, конечно :) А так - толку то тебе от знаний 10-летней давности? С тех пор многое могло измениться.
> будет хранить детальную информацию, оно лопнет раньше чем sql база в
> силу абсолютно неэффективного поиска и хранилища, двадцать лет назад уже устаревших.
Чего там такого "неэффективного"? Да еще по сравнению с монструозным скулем? Маркетинговый булшит чтоли? А, ну да, rrdtool просто работает, а не разводит голимый пиар :)
> Пол-часа - это вообще можно не хранить. Хранить надо изменения состояния, которые
> важны для сервиса - обычно это минуты, а иногда и секунды.
Вот прямо минуты и секунды - за последние 10 лет? Вопрос: что за изменения такие и чего это знание должно кому-то дать? Конкретные примеры, блин, давай, куда и как приткнуть тухляк десятилетней давности.
> А иногда ничего не меняется, и их можно вообще не хранить
> (достаточно хранить факт "не изменилось")
Это весьма годная оптимизация, но это как-то очень странно. Для кладбища, наверное, работает. Покуда новых клиентов не привозят.
> потому что волшебство, да? Пятое измерение открыли? Нет, братело - этот "фиксированный
> расход" у тебя за счет того что данные просто удаляются.
И что характерно - я нахожу такой подход очень разумным. Он сохраняет общий вид и пригоден для понимания нагрузок по временам суток/года/etc. А копаться под микроскопом в данных 10-летней давности в общем случае идиотизм. Хотя для поха нормально, он эксперт в простреливании своих пяток.
> А чтобы они не удалялись - надо прямо сейчас занять то место,
> которое заполнилось бы за год - верх экономии, не включая мозгов.
> А буде понадобится пять лет - то занять место на пять лет вперед.
Ну так это место все равно займется. Не, намного лучше будет если все про это забудут, поюзают место, а через 4.5 года - БАБАХ - no free space left on device. Во круто.
> И я тебе страшную тайну открою - удалить данные можно и из sql.
Можно. Но это гораздо более кривое и сложное действо.
> позволяющего нарисовать бесполезный график за год, за месяц и за неделю. Обычно
> у васянов, любителей rrd, такие. Которые мне как раз абсолютно не нужны.
Ну, не нужны так и не пользуйся. Можно подумать кто-то заставляет.
> нельзя. Он и не предназначен для этого, и не способен переварить такой объем.
Вообще он изначально все-таки не для этого.
> А вот sql на энтерпрайзном железе - вообще говоря, способен.
А, понятно, цель таки раскрутить контору на бабки.
> базе вида "что показывал этот параметр в 23:00:06.123".
Я не особо понимаю этот юзкейс. Большинство нагрузок на хосты, оборудование и проч имеет ярко выраженные паттерны по времени суток, года, ... - и смысл смотреть что было именно 23:00:06.123, 10 лет назад - ну даже если и посмотреть, то чего? С тех пор скорее всего многое изменилось.
> Для этого существуют базы, предназначенные хранить именно метрики. Но rrd среди них
> - давным-давно самый устаревший и бесполезный. Придуман когда компьютеры еще были
> большие, а емкость дисков и памяти - крохотными.
И таки я считаю что для обычных юзкейсов он вполне себе катит. А экономное отношение к ресурсам позволяет втулить его и туда где иначе на мониторинг просто забили бы.
