Собственно говоря это набор компонентов, который позволяет сохранять и визуализировать поток time-series данных.

Графит любят за то что очень просто взять и послать метрику

echo "some.name 0.01 $(date +%s)" | nc graphite-host:2003 - и готов

А чтобы получить данные есть прекрасный http api. Получить можно как готовый график, так и json. Попутно можно навалить парочку математических функций на данные, которые хочешь получить.

Ну и наконец - он модульный. Каждый компонент отдельно, не обязательно использовать все и сразу, да и если что-то пойдет не так, можно заменить только 1 компонент.

Вероятнее всего, строя свою инфраструктуру, вы прийдете к какому-то такому виду.

(по непонятной причине телеграм не хочет грузить фоточки)

Собственно на схеме можно выделить data flow - данные которые идут на запись

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

Затем они идут в carbon-relay, который уже решает стоит ли их отправить на агрегацию или нет

Или сразу сохранить. А если сохранить - то на какой storage послать

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

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

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

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

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

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

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

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

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