Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Хех, могу сказать, что rrd работает только на малых наборах значений. Если у вас больше несколько тысяч в секунду — забудьте.
Несколько тысяч в секунду… Это простите что мы такое измерять собрались? Поток квантов в запросе к WordPress? Я даже по другому спрошу — а что у нас на среднестатистическом сервере такой поток измерений выдать-то может, какой сенсор?
Наше облако, например. Несколько тысяч виртуальных машин, у каждой под десяток ресурсов, для которых нужно собирать статистику в rrd-подобном стиле.
А проблему мы решили. ~300% CPU, 6Gb памяти, около 100 IOPS. Причём программист грозится задуматься об оптимизации, особенно в районе CPU.
А проблему мы решили. ~300% CPU, 6Gb памяти, около 100 IOPS. Причём программист грозится задуматься об оптимизации, особенно в районе CPU.
Облака, белогривые лошадки…
> Несколько тысяч виртуальных машин…
Ну так это кем надо быть, чтобы всё в один rrd пихать. Что вы там в этой каше после этого увидеть хотите. Или я неверно что-то понял? Это с одной стороны. С другой стороны — это простите по какому таймеру вы 1000-чи раз их опрашивать успеваете? Шедулер с ума не сходит? Ну и с третьей стороны… Очевидно, что при большом потоке данных надо какие-то телодвижения делать, чо уж тут. А в общем случае вполне себе база и вполне себе задачи выполняет, поддёвка афтора и давление авторитетом не уместно.
> А проблему мы решили
Какую проблему? Которую сами себе придумали?
> ~300% CPU, 6Gb памяти, около 100 IOPS
— Карты!
— 17!
— Что 17?!
— А что карты?
> Причём программист грозится задуматься об оптимизации
Ну надо же. Серьёзная угроза.
> Несколько тысяч виртуальных машин…
Ну так это кем надо быть, чтобы всё в один rrd пихать. Что вы там в этой каше после этого увидеть хотите. Или я неверно что-то понял? Это с одной стороны. С другой стороны — это простите по какому таймеру вы 1000-чи раз их опрашивать успеваете? Шедулер с ума не сходит? Ну и с третьей стороны… Очевидно, что при большом потоке данных надо какие-то телодвижения делать, чо уж тут. А в общем случае вполне себе база и вполне себе задачи выполняет, поддёвка афтора и давление авторитетом не уместно.
> А проблему мы решили
Какую проблему? Которую сами себе придумали?
> ~300% CPU, 6Gb памяти, около 100 IOPS
— Карты!
— 17!
— Что 17?!
— А что карты?
> Причём программист грозится задуматься об оптимизации
Ну надо же. Серьёзная угроза.
В какой rrd? У нас для этого специализированная СУБД написана.
А машины мы не опрашиваем по таймеру, мы их аккаунтим (за все эти ресурсы деньги в реальном времени списываем), а статистика — это такой побочный выхлоп сервиса аккаунтинга.
Проблему выдумывали не мы, а наши клиенты, которые хотели видеть rrd статистику по своим машинам. Вести 30-40 тысяч RRD совсем не хотелось. Пришлось придумать красивое решение. Я, кстати, о нём писал: habrahabr.ru/company/selectel/blog/122987/
А машины мы не опрашиваем по таймеру, мы их аккаунтим (за все эти ресурсы деньги в реальном времени списываем), а статистика — это такой побочный выхлоп сервиса аккаунтинга.
Проблему выдумывали не мы, а наши клиенты, которые хотели видеть rrd статистику по своим машинам. Вести 30-40 тысяч RRD совсем не хотелось. Пришлось придумать красивое решение. Я, кстати, о нём писал: habrahabr.ru/company/selectel/blog/122987/
> В какой rrd? У нас для этого специализированная СУБД написана.
Так вы пытались тысячи значений в rrd писать или нет? Определитесь уже.
> А машины мы не опрашиваем по таймеру, мы их аккаунтим… побочный выхлоп сервиса аккаунтинга.
И где тогда тысячи значений в секунду? Что-то я не осознал.
> Пришлось придумать красивое решение. Я, кстати, о нём писал
Не, ну чтобы данные централизировать придётся попрыгать да. Но это достаточно редкий случай. Я понимаю, конечно, что был повод понтануться в каментах. И что-то вы не договариваете, или в той статье вы пытались решить проблему аппроксимации на уровне запихивания данных в СУБД. Я вообще не понимаю, зачем собирать их с такой дискретностью, если вы потом всё равно со временными метками очень фривольно себя ведёте.
Так вы пытались тысячи значений в rrd писать или нет? Определитесь уже.
> А машины мы не опрашиваем по таймеру, мы их аккаунтим… побочный выхлоп сервиса аккаунтинга.
И где тогда тысячи значений в секунду? Что-то я не осознал.
> Пришлось придумать красивое решение. Я, кстати, о нём писал
Не, ну чтобы данные централизировать придётся попрыгать да. Но это достаточно редкий случай. Я понимаю, конечно, что был повод понтануться в каментах. И что-то вы не договариваете, или в той статье вы пытались решить проблему аппроксимации на уровне запихивания данных в СУБД. Я вообще не понимаю, зачем собирать их с такой дискретностью, если вы потом всё равно со временными метками очень фривольно себя ведёте.
Вы просто rrdtool готовить не умеете.
У меня на сервере (hw.machine: i386 hw.model: Pentium III/Pentium III Xeon/Celeron hw.ncpu: 4) 10000 rrd обновляются двенадцатью потоками за 2 секунды. Что я делаю не так?
Можно ещё, конечно, было взглянуть в сторону rrdcached мне просто не подходит в силу того, что после обновления надо проверять значения, а это значит, что база данных всё равно перед проверкой будет сброшена на диск.
Ещё, в статье порадовало
Почему же мы не выбрали RRD? Ответ прост и печален: RRD не поддерживает bulk insertion — вы не можете за одну операцию сохранить несколько значений. Это означает, что вам придётся делать тысячи раздельных транзакций, каждая из которых больно бъёт по диску.
Может быть стоило почитать маны по rrdupdate
rrdtool update demo2.rrd 887457267:U 887457521:22 887457903:2.7
Update the database file demo2.rrd which expects data from a single data-source, three times.
У меня на сервере (hw.machine: i386 hw.model: Pentium III/Pentium III Xeon/Celeron hw.ncpu: 4) 10000 rrd обновляются двенадцатью потоками за 2 секунды. Что я делаю не так?
Можно ещё, конечно, было взглянуть в сторону rrdcached мне просто не подходит в силу того, что после обновления надо проверять значения, а это значит, что база данных всё равно перед проверкой будет сброшена на диск.
Ещё, в статье порадовало
Почему же мы не выбрали RRD? Ответ прост и печален: RRD не поддерживает bulk insertion — вы не можете за одну операцию сохранить несколько значений. Это означает, что вам придётся делать тысячи раздельных транзакций, каждая из которых больно бъёт по диску.
Может быть стоило почитать маны по rrdupdate
rrdtool update demo2.rrd 887457267:U 887457521:22 887457903:2.7
Update the database file demo2.rrd which expects data from a single data-source, three times.
Хм… Я правильно понимаю, что вы использовали Graphite, вляпались в python GIL и решили что самое простое будет замусорить это всё страшной системой на erlang? Что-то от указанной в ссылке статьи попахивает странными увёртками от создателя whisper и питоном оттуда же.
Ну так это кем надо быть, чтобы всё в один rrd пихать.
Ну будете вы в тыщу rrd класть и чо? Дисковая нагрузка только увеличится. Для вот таких кстати случаев и придуманы СУБД.
Ну будете вы в тыщу rrd класть и чо? Дисковая нагрузка только увеличится. Для вот таких кстати случаев и придуманы СУБД.
> Ну будете вы в тыщу rrd класть и чо? Дисковая нагрузка только увеличится
Это с чего это? Ну-ка.
> Для вот таких кстати случаев и придуманы СУБД.
Это несомненно.
Это с чего это? Ну-ка.
> Для вот таких кстати случаев и придуманы СУБД.
Это несомненно.
Для collectd кажется есть специальный кэш, который эту проблему решает и он не каждый пакет скидывает на диск. Да, есть риск потери пачки данных, но так это и решение не для атомной АС.
Одно не понятно, зачем лезть в пост про collectd/rrd со своими облаками?
Это как если бы залезть на форум автолюбителей со словами
«Чуваки, чтоб вы знали. Я подкачиваю шины на Формуле-1, и знайте, ваши запчасти там совсем не годятся.»
Это как если бы залезть на форум автолюбителей со словами
«Чуваки, чтоб вы знали. Я подкачиваю шины на Формуле-1, и знайте, ваши запчасти там совсем не годятся.»
А зачем данные collectd пересылать по UDP?.. Заработать себе проблем на пустом месте?
4.4.2 кстати действительно старая версия… и не просто старая, а старая как говно мамонта…
4.4.2 кстати действительно старая версия… и не просто старая, а старая как говно мамонта…
А можно подробнее в чем проблема?
1. Завязка на точку, собирающую данные. Точка легла — данных просто нет.
2. Завязка на сеть. Шнур для работ выдернули на 5 минут — 5 минут данных нет. Например, произошла из-за выдера шнура проблема. И сиди гадай потом — из-за этого она произошла, или был другой источник.
Собственно все эти графики реально нужны раз в полгода. Но иногда в самое невовремя.
2. Завязка на сеть. Шнур для работ выдернули на 5 минут — 5 минут данных нет. Например, произошла из-за выдера шнура проблема. И сиди гадай потом — из-за этого она произошла, или был другой источник.
Собственно все эти графики реально нужны раз в полгода. Но иногда в самое невовремя.
Согласен, но тут нигде речи не идет о том, что это все супер-мега надежно.
А на счет «графики нужны раз в полгода» — это не всегда так.
Например, у нас был случай — выкатили новую версию сервиса, через неделю по графикам увидели, что течет память. Тут же понятно когда началась утечка. Посмотрели по дате коммит, быстро нашли в чем косяк.
Даже если бы на час что-то выключали, то на надельном графике пробел был бы ну может в одну точку.
А на счет «графики нужны раз в полгода» — это не всегда так.
Например, у нас был случай — выкатили новую версию сервиса, через неделю по графикам увидели, что течет память. Тут же понятно когда началась утечка. Посмотрели по дате коммит, быстро нашли в чем косяк.
Даже если бы на час что-то выключали, то на надельном графике пробел был бы ну может в одну точку.
Зачем всё это? Не проше ли написать свой плагин? Зарегестрировать его в collectd как читателя и все данные, которые он собрал будет передавать дефолтный плагин network в colectd?
А по поводу веб обвязки, к collectd есть хорошая морда — collection3.
А по поводу веб обвязки, к collectd есть хорошая морда — collection3.
Например, у нас сервисы не только на python, но и на .NET. Не нужно никаких «читателей». Сервисы сами присылают данные.
Вообще pull-модель, когда кто-то ходит и опрашивает сервисы имеет явные недостатки (о которых я написал в самом начале) перед таким inline решением:
— приходится перенастраивать «читателя» при переносе сервисов или развертывании новых
— это более тяжеловесная модель и менее масштабируемая (см. обзор архитектуры)
Вообще pull-модель, когда кто-то ходит и опрашивает сервисы имеет явные недостатки (о которых я написал в самом начале) перед таким inline решением:
— приходится перенастраивать «читателя» при переносе сервисов или развертывании новых
— это более тяжеловесная модель и менее масштабируемая (см. обзор архитектуры)
мы, как морду для collectd, ипользуем Graphite — шикарная вещь!!! — всем советую
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собираем свои счетчики через collectd протокол