Вероятнее всего захочется поставить графит в несколько датацентров - чтобы если один сдох, то данные все еще были бы доступны

Да и серверов для хранения данных тоже будет явно больше чем 1 - данных то будет тоже не мало

На тех же storage серверах вероятно будет стоять graphite-web для чтения данных

Над которым будет находится кластер frontend'ов

Над фронтэндами будет какой-то балансировщик нагрузки.

Ведь пользователям падение одного из ДЦ (или проблемы на фронтэндах) должны быть незаметны.

Но у этой схемы есть несколько проблем

1. carbon-relay - единая точка отказа. Если он умер, то данные больше не дойдут до storage'ей.

2. Под нашей (booking.com) нагрузкой оно очень плохо масштабировалось. Начали использовать графит мы давно, когда graphite-web не умел параллельные запросы

3. Если что-то случилось с одним из сторадж серверов, то нету готовых утилит чтобы восстановить пропавшие данные. Есть множество разных утилит по работе с виспер-файлами, но у всех свои допущения, которые очень не всегда применимы.

4. Из-за пункта 3 следствие - чем больше стораджей тем медленее все.

Мы в Booking решили исправлять проблемы по мере их возникновения

То есть не менять весь стэк целиком, а исправлять проблемы в текущем.

Собственно первым делом мы взялись за carbon-relay

Заменили его на carbon-c-relay, который написан на Сях, достаточно производительный (1 миллион метрик в секунду на 2-х ядрах)

Может делать балансировку нагрузки зная о протоколе

Притом балансируя нагрузку он старается выбирать тот сервер, куда эта метрика уже уходила

мы также поставили его на каждый сервер, как можно ближе к источнику данных

Во первых это дало возможность сказать разработчикам "вот вам порт на локалхосте, шлите данные сюда"

и дальше это не их забота как они дойдут до хранилища

А во вторых наш локальный carbon-c-relay знает о остальных relay'ах и может делать более умный failover если что-то пошло не так