Мониторинг, когда не тестируешь

31
monitoring when no testing Иван Круглов|08.04.2017

Transcript of Мониторинг, когда не тестируешь

Page 1: Мониторинг, когда не тестируешь

monitoring when no testingИван Круглов|08.04.2017

Page 2: Мониторинг, когда не тестируешь

fast reverts visibility

ownership

• 70 роллаутов в день

• 1000+ активных экспериментов

Booking Fast Development by Vedran Mikulichttps://2014.codefest.ru/lecture/937

Page 3: Мониторинг, когда не тестируешь

повестка дня

• ключевые метрики• пожар!• инструменты оповещения• инструменты мониторинга• graphite stack

Page 4: Мониторинг, когда не тестируешь

кол-во броней

ключевые метрики

бюджет на ошибки

Page 5: Мониторинг, когда не тестируешь

пожар!

• начальные коммуникации в jabber• конференц-связь

▸ единый номер доступный везде• лидер

▸ координация, оповещение и привлечение нужных ресурсов• RFO (reason for outage)

▸ В чем причина?▸ Могли ли мы избежать данного класса ошибок?▸ Как можно уменьшить ущерб от данного класса ошибок?▸ Насколько эффективны алерты?

• post-mortem

Page 6: Мониторинг, когда не тестируешь

инструменты оповещения (alerting)

• ddos_detector▸ events -> ddos_detector

picture by Maxim Vuets

Page 7: Мониторинг, когда не тестируешь

server

server

server

eventspipeline

consumer

Page 8: Мониторинг, когда не тестируешь

инструменты оповещения (alerting)

• ddos_detector▸ events -> ddos_detector▸ реалтайм анализ трендов▸ оповещение если что-то где-то идет не так

• nagios▸ технические алерты

• bosun

picture by Maxim Vuets

Page 9: Мониторинг, когда не тестируешь

инструменты мониторинга

• flog▸ errors/warnings▸ grumbles▸ events -> flog-processor -> ES

Page 10: Мониторинг, когда не тестируешь

flog

aggregated err/warn

Page 11: Мониторинг, когда не тестируешь

инструменты мониторинга

• flog▸ errors/warnings▸ grumbles▸ events -> flog-processor -> ES

• graphite/grafana▸ миллионы метрик разной природы▸ несколько источников данных

• kibana▸ rsyslog -> kafka -> ES

Page 12: Мониторинг, когда не тестируешь

источники данных для graphite

• diamond и др.▸ системные метрики (/proc, mysql, nginx, uwsgi, др.)

• graphite-processor▸ events -> graphite-processor -> graphite▸ метрики специфичные для приложения▸ доступен для всех▸ строит “завершенные” графики

• ddos_detector▸ стандартизованные метрики которым можно доверять▸ бизнес метрики (распределение по странам, провайдерам, и др.)▸ технические метрики (pv, error/warning, wallclock percentiles, др.)▸ задача оставаться realtime

Page 13: Мониторинг, когда не тестируешь
Page 14: Мониторинг, когда не тестируешь

“завершённый” график

Page 15: Мониторинг, когда не тестируешь

realtime график

Page 16: Мониторинг, когда не тестируешь

graphite setup

frontend• 32 сервера• 400 RPS• 40K метрик

backend• 200 серверов• 11 Gbps• 2.5M уникальных метрик в

секунду (10M на сторадже) • 130 TB метрик

все компоненты заменены!

Page 17: Мониторинг, когда не тестируешь

graphite stack

• проект начат Damian Gryski и Fabian Groffen▸ в активном развитие

• более подробно:“Graphite@Scale or How to store millions metrics per second”https://fosdem.org/2017/schedule/event/graphite_at_scale/

Page 18: Мониторинг, когда не тестируешь
Page 19: Мониторинг, когда не тестируешь

• carbon-relay — SPOF • данные различаются

после ошибок записи• время ответа растет

линейно с ростом кол-ва серверов

• сложно масштабировать

Что не так?

Page 20: Мониторинг, когда не тестируешь
Page 21: Мониторинг, когда не тестируешь

carbon-c-relay

• написан на C • работает с 1М метрик в секунду на 2 ядрах• L7 LB for graphite line protocol• может выполнять роль carbon-aggregator• буферизирует данные если upstream недоступен

Page 22: Мониторинг, когда не тестируешь

carbon-zipper

Page 23: Мониторинг, когда не тестируешь

carbon-zipper

• написан на Go• carbon-zipper <->

carbon-server =2700 RPS

• graphite-web <-> carbon-cache80 RPS

Page 24: Мониторинг, когда не тестируешь

carbonapi

• можно делать больше сложных запросов

• новые тяжелые математические функции

~0.8 сек

~15 сек

Page 25: Мониторинг, когда не тестируешь

• carbonzipper — github.com/dgryski/carbonzipper• go-carbon — github.com/lomik/go-carbon• carbonsearch — github.com/kanatohodets/carbonsearch• carbonapi — github.com/dgryski/carbonapi• carbon-c-relay — github.com/grobian/carbon-c-relay• carbonmem — github.com/dgryski/carbonmem

все в open-source

Page 26: Мониторинг, когда не тестируешь

трюк с graphite №1

• используйте корректные функции агрегации▸ по умолчанию - среднее

• мы используем следующий способ именования▸ _sum .sum _count .count▸ _last .last▸ max_ _max .max▸ min_ _min .min

Page 27: Мониторинг, когда не тестируешь

трюк с graphite №2

Page 28: Мониторинг, когда не тестируешь

трюк с graphite №2

Page 29: Мониторинг, когда не тестируешь

• consolidateBy(seriesList, consolidationFunc)

Takes one metric or a wildcard seriesList and a consolidation function name. Valid function names are ‘sum’, ‘average’, ‘min’, and ‘max’.

When a graph is drawn where width of the graph size in pixels is smaller than the number of datapoints to be graphed, Graphite consolidates the values to to prevent line overlap. The consolidateBy() function changes the consolidation function from the default of ‘average’ to one of ‘sum’, ‘max’, or ‘min’. This is especially useful in sales graphs, where fractional values make no sense and a ‘sum’ of consolidated values is appropriate.

&target=consolidateBy(Sales.widgets.largeBlue, 'sum') &target=consolidateBy(Servers.web01.sda1.free_space, 'max')

Page 30: Мониторинг, когда не тестируешь

Спасибо!

Иван КругловSenior [email protected]

https://workingatbooking.com

SRE or Software Developer

Page 31: Мониторинг, когда не тестируешь

disclaimer

• this is my personal view on the available tools at Booking.com• might be inaccurate and biased• there might be better way of using them