как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8

1. Мониторинг производительности web-
приложений на Python
Special for Minsk Python Meetup

2. Коротно о себе
Занимаюсь web программированием с 1999 года
Работал в Badoo, LinguaLeo и много где еще ;)
В настоящий момент работаю в http://melesta-games.com
Текущий проект небольшой
150-200 rps, 1 сервер, 300kb JSON на запрос ;)
Но мы активно РАСТЕМ

3. Виды мониторинга в web проектах
● Мониторинг программной и аппаратной
инфраструктуры (Zabbix, Icinga, Munin)
● Мониторинг пользовательской активности
(Google Analytics Alerts, внутренняя аналитика)
● Функциональный мониторинг
(Zabbix+Selenium+BrowserMob, site24x7.com)
● Мониторинг производительности приложения
(graphite, grafana, influxdb, pinba, statsd, datadoghq,
NewRelic) - НАШ ВЫБОР ;)

4. Мониторинг производительности приложения
это:● Измерение и анализ времени на обработку запроса и
различных его частей на application серверах
● Измерение и анализ времени загрузки страниц и ajax
запросов в браузере (на клиенте)
● Измерение потребления системных ресурсов (Disk,
Network, RAM, CPU) на application серверах в рамках
приложения
● Мониторинг кол-ва и аггрегация по типам ошибок,
возникающих при обработке запросов

5. Цели и особенности мониторинга производительности:
● Отвечает на вопрос какие именно участки кода
тормозят, но не отвечает на вопрос ПОЧЕМУ
● Помогает понять, какое влияние на скорость
обработки запросов оказывает то или иное изменение
в коде
● Помогает принять быстрое решение в случае
«выкатили новый релиз и все вкорячило»

6. Инструменты для сбора и анализа данных (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 - визуализация

7. Инструменты для сбора и анализа данных (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/skyline
https://github.com/nathanielc/morgoth, https://github.com/eleme/bell.js
● Оповещения
https://github.com/klen/graphite-beacon

8. Инструменты для сбора и анализа данных (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 (не пробовал, непонятно как работает)

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

11. Что такое “гистограмма распределения”
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)строим график

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

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

15. Провокационное мнение
На самом деле этих трех графиков
ДОСТАТОЧНО ;)
для понимания где “тормоза”
в проекте
в котором от 1 до 10 серверов

18. Метрики PYNBA в python коде cyclone - монитор
https://gist.github.com/Slach/00c86b1341f738bc9dd5
Класс мониторинга реализован в виде MixIn, который подмешивается во все
классы контроллеров
Перед началом обработки запроса Mixin создает экземпляр кастомного
класса наследуемого от pynba.ScriptMonitor
После завершения, получает статус ответа и размер отосланных данных
Отсылает protobuf по UDP на PINBA сервер

19. Метрики 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)

20. Метрики 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

21. Метрики 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')

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

23. Как поставить pinba1.1 + mysql5.6 в Ubuntu
Рецепт на fabric
https://gist.github.com/Slach/d61acbd153ea6d3e6c2b

24. Метрики 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’})

25. Недостатки statsd + python
● 1 метрика = 1 UDP пакет (можно отложить через pipeline)
● Нет нормальной python реализации histogram через
декораторы и контексты в pystatd (надо дописать ;)
● Нет глобального понятия “request” (надо делать замер
глобальной метрики), brubek реализация сервера не
поддерживает теги, надо включать их в название метрики

26. Дополнительные замечания
● При оценке времени не смотрите в МИНИМУМ (в идеале он должен
стремиться к нулю ;) или в СРЕДНЕЕ
● Смотрите «распределение по гистограмме»
● мы используем 0.2, 0.5, 1.0, 2.0 sec для СКРИПТОВ
● и 0.1, 0.2, 0.5, 1.0s для ТЕГОВ
● Для оценки качественных изменений, лучше смотреть перцентили (50%
и 90%)
● Снижение количества обращений к серверу может такой же хорошей
оптимизацией как и уменьшение времени работы отдельного URL

27. bloodjazman@gmail.com
skype: blooodjazman
http://github.com/Slach
http://bitbucket.com/bloodjazman
Задавайте вопросы ;)