(alerting немного выходит за рамки данного обсуждения, потому что для него зачастую не нужны сильно старые данные)

Собственно говоря тут и может прийти на помощь графит.

Собственно говоря что же такое графит?
Если верить сайту graphiteapp.org, эта система которая делает хорошо три вещи:
1. Надирает задницы
2. Жует жвачку
3. Позволяет просто хранить и рисовать метрики

Собственно говоря это набор компонентов, который позволяет сохранять и визуализировать поток 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'ов

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

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