echo "some.name 0.01 $(date +%s)" | nc graphite-host:2003 - и готов
А чтобы получить данные есть прекрасный http api. Получить можно как готовый график, так и json. Попутно можно навалить парочку математических функций на данные, которые хочешь получить.
Ну и наконец - он модульный. Каждый компонент отдельно, не обязательно использовать все и сразу, да и если что-то пойдет не так, можно заменить только 1 компонент.
Вероятнее всего, строя свою инфраструктуру, вы прийдете к какому-то такому виду.
(по непонятной причине телеграм не хочет грузить фоточки)
Собственно на схеме можно выделить data flow - данные которые идут на запись
Это могут быть метрики от серверов, приложений, сетевых устройств - не важно от чего
Затем они идут в carbon-relay, который уже решает стоит ли их отправить на агрегацию или нет
Или сразу сохранить. А если сохранить - то на какой storage послать
Вероятнее всего захочется поставить графит в несколько датацентров - чтобы если один сдох, то данные все еще были бы доступны
Да и серверов для хранения данных тоже будет явно больше чем 1 - данных то будет тоже не мало
На тех же storage серверах вероятно будет стоять graphite-web для чтения данных
Ведь пользователям падение одного из ДЦ (или проблемы на фронтэндах) должны быть незаметны.
1. carbon-relay - единая точка отказа. Если он умер, то данные больше не дойдут до storage'ей.
2. Под нашей (booking.com) нагрузкой оно очень плохо масштабировалось. Начали использовать графит мы давно, когда graphite-web не умел параллельные запросы
3. Если что-то случилось с одним из сторадж серверов, то нету готовых утилит чтобы восстановить пропавшие данные. Есть множество разных утилит по работе с виспер-файлами, но у всех свои допущения, которые очень не всегда применимы.
4. Из-за пункта 3 следствие - чем больше стораджей тем медленее все.