В Яндексе (см. доклад с Яка 2013) используется graphite-web (+патчи, назначение некоторых из которых я не знаю, но вроде все это было нужно) + свой форк ceres (апстрим слегка умер, а у Дмитрия Куликовского на его гитхабе лежат фиксы ceres-maintaince и еще каких-то мелких багов в самом ceres) + свой форк carbon (использеутся ветка megacarbon, она по тестам была быстрее чем просто карбон и в целом управляется легче).
К сожалению инструкция, которая была на Ярушке, недоступна больше. Из чего-то вменяемого я бы посоветовал http://anatolijd.blogspot.de/2013/06/graphitemegacarbonceres-multi-node.html (и вообще в том блоге о Ceres есть заметки, интересные и полезные), только брать форки от Дмитрия.
Почему Ceres а не Whisper расказано на докладе с яка 2013 (вкратце - церес быстрее).
Из особенностей:
1) carbon-writer любит ssd'шки, поэтому лучше держать базу графита на ssd (это в общем касается даже rrd).
2) carbon написан на питоне и, видимо, не самым лучшим образом, поэтому один инстанс writer'а (и relay'а) может прокачать примерно 250 тысяч точек в минуту (при условии что диск столько запишет).
3) carbon-relay призван делать роутинг (притом с consistent hashing'ом, чтобы одни и те же метрики всегда попадали одному и тому же writer'у), но у него те же проблемы что и у остальных carbon-демонов. Как решение - можно взять carbon-relay-ng (https://github.com/graphite-ng/carbon-relay-ng), он написан на Go и сильно быстрее (один инстанс может прокачать до 1.2млн метрик в минуту, что уже близко к разумному пределу на Ceres'е). Плюс еще есть места, где его можно оптимизировать и выжать больше. но у него нет consistent hashing'а (пока), поэтому прийдется или впиливать руками или ждать пока впилят за тебя (есть в ближайших планах)
4) Касательно морды - есть штатная морда, graphite-web, она довольно жирная (Django и все такое), есть альтернативная - graphite-api, но она не умеет ceres (нужно плагин портировать), сам церес нужно подпачить слегка (есть PR https://github.com/dkulikovsky/ceres/pull/2 на это), он на flask'е, тоньше, быстрее и чище (и у него очень адекватный апстрим, всегда можно поговорить с разработчиком и хорошие PRы разработчик быстро принимает).
Но вся эта штука очень любит CPU - что graphite-web/graphite-api, что carbon. И узкое место будет именно в процессоре (при наличии ссд дисков конечно же).
Как альтернативную базу данных для графита, можно взять influxdb (influxdb.com + https://github.com/vimeo/graphite-influxdb), на запись оно работает довольно адекватно (хотя возможно есть баги), но вот чтение данных лучше делать как можно реже (оно очень медленно данные читает, вот прям очень-очень).
Касателньо конкретных цифр - яндексовая схема вида: haproxy -> 8x carbon-relay -> 12x carbon-writer выжимает примерно 1-1.5млн точек в минуту на 2x e5-2660, 64GB Ram, Raid 10 из 4x300GB Intel 520 (SSD). Замена carbon-relay на carbon-relay-ng позволит пиково получать примерно 4-5 млн точек в минуту (примерно столько же и на influxdb), но постоянная скорость будет ограничена диском уже (примерно на уровне 2 млн, может даже меньше), у influx'а - 4млн точек в минуту легко будет писаться почти что сколь угодно долгое время (я сам тестировал на более слабом железе, примерно 12 часов записи по 4млн в минуту оно выдерживало). Только вот прочитать эти данные будет сложновато.
И еще небольшой UPD: graphite-api конечно быстрый, но с очень большим колличеством запросов тоже плохо справляется. Он прекрасно (с виду) работает с pypy-2.4, притом прекрасно = в несколько раз быстрее.
У графита есть tcp + udp, и tcp работает постабильнее в данном случаи.
