А еще таким макаром можно включать фичи по частям и увеличивать сколько людей получают новые фичи!

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

Очень хочется знать откуда баг появился

Идея! Давайте тегировать error rate еще и build number'ом

В конце дня наш девелопер научилась тестировать в продакшене, смотреть в мониторинг и ваще стала лучше

(или нет, прим. записывающего человека)

Тут слайд про проверку гипотиз, запросы и действия по результатам проверки гипотиз, но он еще более капитанский чем все что выше

А давайте посмотрим на http запросы! Иногда ведь помогает понять что нам возвращается мусор или не то что нужно!

Best Practices:
1. Структурированные данные
2. Именуем все в единой манере.
3. Пусть юзкейс диктует то как данные попадают в систему.

Например каждый рид реквест стоит интерументировать, а запись вот не очень

А еще можно добавлять временные поля если надо

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

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

Миссия девелопера:
- Не пишите код основываясь на интуции, соберите, блин, данные!
- Учитесь 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