Some random GrafanCon EU 2k18 Notes – Telegram
Some random GrafanCon EU 2k18 Notes
73 subscribers
312 photos
9 files
54 links
Заметки по докладам на которые я пошел (начинаются с #talk) и флуд фоточками.

Связаться с автором можно так: @Civiloid
Download Telegram
Уф, из отеля наверное можно написать и про свой доклад.
Graphite@Scale or How to store millon metrics per second
#talk
Зачем вообще хранить метрики?
Стоит выделить несколько основных моментов, когда хочется это делать не просто долго, а очень долго:
1. Планирование.
Периодически, нужно обращаться к старым данным и смотреть, насколько система выросла. Зачастую это все связано с планированием бюджета на ближайшее будущее.
2. Постмортемы и решение возникающих проблем во время эксплуатации системы. Например после нового релиза сильно выросло время ответа пользователям. Графики производительности различных компонентов системы (приложения, сервера) помогут понять момент когда на самом деле начались проблемы и дадут какое-то понимание о причинах.
3. Данные для бизнеса. Иногда в том числе и бизнес хочет подкрепить свои годовые отчеты какими-нибудь красивыми графиками о том, как хорошо идут дела в компании.
это не все, но на мой взгляд основные моменты
(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 - данных то будет тоже не мало