Мониторинг производительности web-приложений на Python

Special for Minsk Python Meetup

Коротно о себе

Занимаюсь web программированием с 1999 года

Работал в Badoo, LinguaLeo и много где еще ;)

В настоящий момент работаю в http://melesta-games.com

Текущий проект небольшой

150-200 rps, 1 сервер, 300kb JSON на запрос ;)

Но мы активно РАСТЕМ

Виды мониторинга в web проектах● Мониторинг программной и аппаратной

инфраструктуры (Zabbix, Icinga, Munin)● Мониторинг пользовательской активности

(Google Analytics Alerts, внутренняя аналитика)● Функциональный мониторинг

(Zabbix+Selenium+BrowserMob, site24x7.com)● Мониторинг производительности приложения(graphite, grafana, influxdb, pinba, statsd, datadoghq, NewRelic) - НАШ ВЫБОР ;)

Мониторинг производительности приложения это:● Измерение и анализ времени на обработку запроса и

различных его частей на application серверах● Измерение и анализ времени загрузки страниц и ajax

запросов в браузере (на клиенте)● Измерение потребления системных ресурсов (Disk,

Network, RAM, CPU) на application серверах в рамках приложения

● Мониторинг кол-ва и аггрегация по типам ошибок, возникающих при обработке запросов

Цели и особенности мониторинга производительности:

● Отвечает на вопрос какие именно участки кода тормозят, но не отвечает на вопрос ПОЧЕМУ

● Помогает понять, какое влияние на скорость обработки запросов оказывает то или иное изменение в коде

● Помогает принять быстрое решение в случае «выкатили новый релиз и все вкорячило»

Инструменты для сбора и анализа данных (1 из 3)

● Время исполнения на клиенте: https://github.com/dpp-name/jinba - сбор метрик

● Время исполения на сервере:https://github.com/johnnoone/pynba - сбор метрикhttp://statsd.readthedocs.org - сбор метрикhttp://pinba.org/, https://bitbucket.org/bloodjazman/pinba2graphite - аггрегация метрикhttps://github.com/github/brubeck - аггрегация метрикhttp://influxdb.org/ - хранение метрикhttp://graphite.readthedocs.org - хранение метрикhttp://grafana.org/ - визуализацияhttp://github.com/urbanairship/tessera - визуализация

Инструменты для сбора и анализа данных (2 из 3)

● Системные метрики и сервисы (PostgreSQL, redis, rabbit etc)https://github.com/python-diamond/Diamond

● Ошибки во время исполненияhttps://github.com/getsentry/sentry

● Детекторы аномалийhttp://github.com/etsy/oculus, https://github.com/etsy/skylinehttps://github.com/nathanielc/morgoth, https://github.com/eleme/bell.js

● Оповещенияhttps://github.com/klen/graphite-beacon

Инструменты для сбора и анализа данных (3 из 3)

● SaaS (все в одном)http://newrelic.com/application-monitoring/pricing https://www.datadoghq.com/pricing/ (хороший free пакет)http://okmeter.io/ http://www.appdynamics.com/pricing/

● SaaS Детекторы аномалийhttps://anomaly.io/pricing/ (не пробовал, потому что дорого :)http://t.onthe.io (не пробовал, непонятно как работает)

ЧТО Я ПОЧУВСТВОВАЛ КОГДА СОБРАЛ ВСЕ ЭТО ВМЕСТЕ ;)

Что такое “гистограмма распределения”1) t = time.time()

timer = time.time()-t # время ms

2)отправляем таймер на “сервер статистики” (с названием и с тегами)

3)Один раз за период (1 минута) аггрегируем ЧАСТОТУ срабатывания таймера (сколько раз было) по ПЕРИОДУ (1 минута), по “категориям значений” (<0.1s, 0.1-0.2s, 0.2-0.5s, 0.5s-1s, >1s)

4)строим график

Хорошая производительность ;)

Плохая производительность ;)

Провокационное мнение

На самом деле этих трех графиков ДОСТАТОЧНО ;)

для понимания где “тормоза” в проекте

в котором от 1 до 10 серверов

Метрики PYNBA в python коде cyclone - монитор

https://gist.github.com/Slach/00c86b1341f738bc9dd5

Класс мониторинга реализован в виде MixIn, который подмешивается во все классы контроллеров

Перед началом обработки запроса Mixin создает экземпляр кастомного класса наследуемого от pynba.ScriptMonitor

После завершения, получает статус ответа и размер отосланных данныхОтсылает protobuf по UDP на PINBA сервер

Метрики PYNBA в python коде cyclone - контроллерclass SetProfileHandler(CustomPynbaMonitoringMixin, cyclone.web.RequestHandler): @defer.inlineCallbacks def post(self): with self.pynba.timer(state='parse_request'): parsed_request = service.unpack_request(self.request)... with self.pynba.timer(state='save_profile_data'): yield profile.save_to_keyvalue(profile_data)

Метрики PYNBA в python коде - flask - монитор

https://gist.github.com/Slach/0cfdcc99711869d1764e

Добавляется старт pynba.utils.ScriptMonitor в функции с декораторами @app.before_first_request, @app.before_request

И отсылка UDP protobuf пакета в фукнции с декораторами@app.after_request, @app.teardown_request

Метрики PYNBA в python коде - flask - контроллер

@app.route('/test_action/', methods=['POST'])

def test_action():

with app.pynba.timer(state='flask_timer_global'): # do something with database

data = {'var': 'All OK'}

status = 200

# вложенный таймер

with app.pynba.timer(state ='flask_generate_response'): resp_string = app.render(data, 'template.html')

response = flask.Response(response=resp_string, status=status, mimetype='text/html')

return response

Недостатки pynba + pinba

В cyclone код асинхронный, значит в python процессе одновременно существует несколько RequestHandler и соответсвенно необходимо оборачивать “библиотечный” код в контект сразу в коде контоллера, либо пробрасывать self.pynba через параметры внутрь библиотечного кода

Сложно анализировать ситуацию если есть вложенные куски кода, которые нужно померить отдельными таймерами

Как поставить pinba1.1 + mysql5.6 в Ubuntu

Рецепт на fabric

https://gist.github.com/Slach/d61acbd153ea6d3e6c2b

Метрики statsd в python

pip install dogstatsd-python

import statsd

self.statsd = statsd.DogStatsd()

t = time.time()# do something …

self.statsd.histogram(‘metric_name’,time.time() - t, tags={‘script’:self.request.uri’})

Недостатки statsd + python

● 1 метрика = 1 UDP пакет (можно отложить через pipeline)

● Нет нормальной python реализации histogram через декораторы и контексты в pystatd (надо дописать ;)

● Нет глобального понятия “request” (надо делать замер глобальной метрики), brubek реализация сервера не поддерживает теги, надо включать их в название метрики

Дополнительные замечания

● При оценке времени не смотрите в МИНИМУМ (в идеале он должен стремиться к нулю ;) или в СРЕДНЕЕ

● Смотрите «распределение по гистограмме»● мы используем 0.2, 0.5, 1.0, 2.0 sec для СКРИПТОВ ● и 0.1, 0.2, 0.5, 1.0s для ТЕГОВ● Для оценки качественных изменений, лучше смотреть перцентили (50%

и 90%)● Снижение количества обращений к серверу может такой же хорошей

оптимизацией как и уменьшение времени работы отдельного URL

bloodjazman@gmail.comskype: blooodjazman

http://github.com/Slachhttp://bitbucket.com/bloodjazman

Задавайте вопросы ;)