например понадобилось нам - добавили количество горутин

перестало быть нужно - выкинули нафиг

Миссия девелопера:
- Не пишите код основываясь на интуции, соберите, блин, данные!
- Учитесь observability
- Пусть observability будет центром сбора данных

вопросов нет, доклад закончился, пойду заедать фейспалмы от доклада.

Graphite at Scale @ Criteo: BigGraphite

https://fosdem.org/2018/schedule/event/graphite_at_scale_at_criteo_biggraphite/

#talk #fosdem2k18 #fosdem

Графайт умеет 2 вещи:
1. хранить данные
2. рисовать данные

Два главных компонента:
1. carbon
это софтина которая пишет данные на диск. База - виспер. Один файл одна метрика. Имя кодирует путь.

Еще есть carbon-relay, carbon-aggregator. Балансер и агрегатор. Они стоят перед carbon-cache (могут и не стоять).

graphite-web - UI и API/

Django. Как UI многие ушли на графану.

Как API:
/metrics/find/?query=my.metrics.*
/render/?target=sum(my.metrics.*)&from=-10m

У чуваков нагрузка - 800к точек в секунду на запись, 20к метрик в секунду чтение

Поэтому они решили переделать все

Ведь распределенные базы - это кассандра и риак, уже есть. И кворум для запросов и данные чинятся.

А масштабировать можно через consistent hash

Так начался BigGraphite

OpenTSDB - не совместим с графитом. HBase не очень нравился. Сложно кросс-дц

Cyanite - хочет ElasticSearch а его не хотелось тащить

ведет себя не так как графит

KairosDB - те же проблемы что у Cyanite