На тех же storage серверах вероятно будет стоять graphite-web для чтения данных
Ведь пользователям падение одного из ДЦ (или проблемы на фронтэндах) должны быть незаметны.
1. carbon-relay - единая точка отказа. Если он умер, то данные больше не дойдут до storage'ей.
2. Под нашей (booking.com) нагрузкой оно очень плохо масштабировалось. Начали использовать графит мы давно, когда graphite-web не умел параллельные запросы
3. Если что-то случилось с одним из сторадж серверов, то нету готовых утилит чтобы восстановить пропавшие данные. Есть множество разных утилит по работе с виспер-файлами, но у всех свои допущения, которые очень не всегда применимы.
4. Из-за пункта 3 следствие - чем больше стораджей тем медленее все.
Мы в Booking решили исправлять проблемы по мере их возникновения
То есть не менять весь стэк целиком, а исправлять проблемы в текущем.
Заменили его на carbon-c-relay, который написан на Сях, достаточно производительный (1 миллион метрик в секунду на 2-х ядрах)
Притом балансируя нагрузку он старается выбирать тот сервер, куда эта метрика уже уходила
мы также поставили его на каждый сервер, как можно ближе к источнику данных
Во первых это дало возможность сказать разработчикам "вот вам порт на локалхосте, шлите данные сюда"
А во вторых наш локальный carbon-c-relay знает о остальных relay'ах и может делать более умный failover если что-то пошло не так
К слову о failover - если у нас случилась проблема и relay не может отправить дальше, то он их какое-то время хранит в памяти. Не бесконечное, но обычно достаточно чтобы починить проблему.