Доклад является обобщением моего опыт по работе с системами мониторинга серверных приложений в Qiwi. Цель доклада: - Получить общее представление о подходах к мониторингу серверных приложений - Разобраться с популярными средствами для мониторинга серверных приложений Оглавление: - Мотивация - Теория ---- Определение ---- Модель системы с точки зрения мониторинга ---- Классификация систем мониторинга ---- Уровни мониторинга ---- Инструменты мониторинга - Практика ---- Системы мониторинга и сбора логов ---- Интерфейсы мониторинга ---- Инструменты мониторинга в JVM-based приложениях

1. Доклад
«Мониторинг
или
есть жизнь после релиза»
старший программист
Орлов Г.А.

2. Цель доклада
• Получить общее представление о подходах к
мониторингу серверных приложений
• Разобраться с существующими в компании
средствами для мониторинга серверных
приложений

3. Введение
• Данный доклад является обобщением моего
опыта по работе с мониторингом в рамках
работы в командах P3 и процессинг QW и
работы с рамках рабочей группы по SRE

4. План доклада
1.Мотивация
2.Теория
3.Практика

5. Мотивация (1)
1.Выпустили систему в прод
2.В проде обнаружились ошибки бизнес-
логики
3.В проде обнаружились ошибки
производительности
4.Бизнес теряет деньги
5.Бизнес теряет репутацию

6. Мотивация (2)
• Факт 1 - писать без ошибок невозможно
(неполное ТЗ, ошибки реализации)
• Факт 2 - тестирование всё не покрывает
• Факт 3 - чем больше покрытие, тем больше
времени отнимает написание тестов
• Факт 4 - тестирование требует ресурсов
людских, вычислительных и временных
(особенно, интеграционное и нагрузочное)

7. Мотивация (3)
• Надо смириться с тем, что в проде всё равно
будут проблемы
• И надо научится быстро их диагностировать
и исправлять

8. Теория
• Определение
• Модель системы с точки зрения мониторинга
• Классификация систем мониторинга
• Уровни мониторинга
• Инструменты мониторинга

9. Мониторинг.
Определение.
• наблюдение за какими-либо
характеристиками процесса или системы с
целью выявления интересующих событий
для последующей их обработки

10. Модель системы с точки
зрения мониторинга
• Будем считать что система состоит из
процессов, которые могут проводить
обработку приходящих к ним запросов
• Онлайн система - система, в которой
запросы приходят снаружи системы
• Оффлайн система - система, в которой
запросы создаются внутри самой системы
(например, по таймеру)

11. Модель онлайн системы с
точки зрения мониторинга

12. Модель оффлайн системы с
точки зрения мониторинга

13. Классификация (по
предметной области)
• Бизнес-мониторинг (прибыль, оборот и т.д.)
• Эксплуатационный мониторинг
(производительность, доступность,
потребление ресурсов и т.д.)
• ИБ-мониторинг
• и т.д.

14. Классификация (по
способу сбора)
• Неинвазивный (когда система сама
предоставляет метрики)
• Инвазивный (когда метрики собираются
внешней системой без участия приложения)

15. Классификация
(по источнику)
• Внешние (когда характеристика собираются
не с самой системы, а с её клиента)
• Внутренние (когда характеристика
собираются с самой системы)

16. Классификация
(по времени реакции)
• реального времени
• отложенный

17. Классификация
(по глубине)
• Сквозной мониторинг (когда временные
метки ставятся внутри системы на запрос и
далее куда-то сбрасываются)
• Независимый мониторинг (когда каждый
интерфейс мониторится сам по себе)

18. Уровни мониторинга
(Где?)
• Уровень бизнес-процессов (счета, платежи,
авторизация)
• Уровень приложений (и БД)
• Уровень инфраструктуры (ОС, сеть, ВМ,
железо)

19. Уровни мониторинга

20. Мониторинг БП.
Достоинства
• Обычно его очень просто настроить
(например, один запрос в БД)
• Требует мало ресурсов, так как мало данных
• Показывает состояние самой крупной
абстракции - БП
• Поэтому позволяет оценить степень влияния
проблемы на бизнес

21. Мониторинг БП.
Недостатки
• Низкая степень локализации (не видно, в
какой части конвейера сломалось)
• Легко не заметить мелкие проблемы
(например, на общей очереди платежей
можно не заметить исчезновения мелкого
провайдера)

22. Мониторинг приложений.
Достоинства.
• Высокая степень локализации (до
конкретного интерфейса конкретного
экземпляра приложения)
• Чаще всего указывает на конкретный
источник проблем, так как основа БП -
приложение

23. Мониторинг приложений.
Недостатки.
• Для высокой степени локализации надо много
сделать в коде или в инфраструктуре
• Часто такие метрики бывают динамическими
(например, содержат URL клиентов, которые
изменяются)
• Поэтому требует много ресурсов, так как много
данных
• Надо поддерживать больше число графиков,
панелей и т.д.

24. Мониторинг
инфраструктуры.
• Если проблема в инфраструктуре, то
метрики приложения часто не помогают
(например, когда кончается место на диске в
приложении надо будет парить логи на
наличие конкретного сообщения)
• Без мониторинга приложений сложно
связать их с проблемами в БП
• Обычно ими занимается эксплуатация

25. Выводы по уровням
мониторинга
• Нужны мониторинги на всех уровнях
• Начинать можно с уровня БП, так как это
быстро и дешево

26. Инструменты мониторинга
(Чем?)
• Журналы событий aka логи
• Метрики событий
• Health check

27. Инструменты
мониторинга.
• Каждый следующий инструмент можно
построить на базе предыдущего

28. Журналы событий
• Упорядоченные по времени события в
системе

29. Журналы событий.
Преимущества
• Детальные (время события, поток, контекст
вызова, контекст запроса)
• Просто использовать
• Не требуют специальных инструментов
обработки

30. Журналы событий.
Недостатки.
• Высокая скорость появления записей (в
нагруженной системе)
• Занимают много места (в нагруженной системе)
• Сложно обрабатывать, так как надо знать
какие записи обрабатывать и структуру этих
записей
• Подсистема журналирования должна быть в
хорошем состоянии

31. Метрики
• Числовые характеристики процессов и
событий системы

32. Метрики.
Преимущества.
• Более агрегированные по сравнению с
логами
• Их обычно существенно меньше, чем
вариантов логов
• Занимают существенно меньше места на
диске
• Просто обрабатывать, так как структура
обычно простая

33. Метрики.
Недостатки.
• Мало контекста по сравнению с логами
• Иногда надо писать более одной строчки
кода для метрик

34. Health check
• Бинарный (да/нет) интерфейс в системе,
который говорит о том, работает система
или нет.
• И опционально, если не работает, то какая
подсистема.

35. Healthcheck.
Преимущества.
• Один интерфейс на процесс
• В идеале единый для всех систем
• Очень просто обрабатывать

36. Healthcheck.
Недостатки.
• Ещё меньше контекста
• Надо писать специальную логику

37. Виды метрик
• Значение
• Счетчик
• Количество событий в единицу времени
(например, запросов). Обычно в секунду.
• Распределение времени событий (например,
обработки запроса). Обычно - персентили.

38. Принципы мониторинга БП
(Как?)
• Определить вместе с бизнесов основные БП
и замониторить хотя бы их
• Но в идеале надо мониторить все
• Делать общие и детализированные
показатели (например, все платежи и
платежи по типам протоколов)

39. Принципы мониторинга приложений
(Как?) (1)
• Мониторить все точки интеграции с обоих
сторон, то есть и с серверной и с клиентской
• Делать метрики как можно гранулярнее
(чтобы проще и быстрее локализовывать)
• Мониторить все количественные ресурсы
(пулы соединений, очереди потоков и т.д.)
• Не забываем мониторить свою виртуальную
машину !

40. Принципы мониторинга приложений
(Как?) (2)
• Выводить метрики по кластеру суммарно и
отдельно по машинам
• Выводить персентили времени ответа (хотя
бы 95), количество запросов в секунду,
отношение ошибок к общему числу запросов
• Для HTTP ещё и отношение групп или
отдельных кодов ошибок к общему числу
запросов

41. Выводы по инструментам
мониторинга
• Сразу делать подробные логи
• Метрики выводить для серверных и
клиентских интерфейсов и для внутренних
ресурсов
• В метриках выводить qps, персентили
времени ответа (хотя бы 95й) и отношение
ошибок к общему числу запросов
• Вывести health check

42. Практика
• Системы мониторинга и сбора логов
• Интерфейсы мониторинга
• Инструменты мониторинга в JVM-based
приложениях

43. Система централизованной
обработки логов.
• RELK (RabbitMQ + Elasticsearch + Logstash +
Kibana)
• traceId

44. Системы мониторинга.
• Zabbix
• Graphite
• Dynatrace

45. Системы мониторинга
Zabbix.
• Бесплатный и открытый
• Всё-в-одном (сбор, хранение, обработка, оповещения)
• Гибкие настройки прав доступа
• Pull-модель
• Умеет масштабироваться сам и можно масштабировать БД
• Плохо умеет работать с динамическими метриками
• Не умеет обрабатывать метрики «на лету»
• Плохая интеграция с инструментов визуализации Grafana

46. Системы мониторинга
Graphite.
• Бесплатный и открытый
• Нет оповещений. Надо брать сторонние решения
• Нет разграничений доступов.
• Push-модель и простой протокол
• Сам по себе не умеет масштабироваться
• Отлично работает с динамическими метриками
• Позволяет легко обрабатывать метрики «на лету»
• Отличная интеграция с инструментов визуализации Grafana

47. Системы мониторинга
Dynatrace.
• Стоит денег, причём немало
• Инвазивный мониторинг + профилировщик
• Удобный интерфейс и визуализация

48. Интерфейсы
мониторинга.
• Pull
• JMX
• Http
• Файл
• Push

49. Интерфейсы мониторинга.
Pull. JMX. Преимущества.
• Eсть в самой JVM, а средства управления
есть в JDK
• То есть можно что-то моментальное
посмотреть и без внешней системы
мониторинга
• Есть система разграничения прав с
аутентификацией и двумя ролями
• Есть плагины для систем мониторинга

50. Интерфейсы мониторинга.
Pull. JMX. Недостатки.
• Графики рисует только с момента
подключения и после отключения
сбрасывает
• Данные не сохраняются между запусками
приложения
• Для подключения к внешней системе
мониторинга нужен агент, который будет
вызывать эти интерфейсы

51. Интерфейсы мониторинга.
Pull. HTTP. Преимущества.
• Не нужно специальных средств для вызова
• Просто парсить ответ

52. Интерфейсы мониторинга.
Pull. HTTP. Недостатки.
• В оффлайн приложения надо добавлять веб-
сервер
• Надо придумывать логику для авторизации и
аутентификации
• Для подключения к внешней системе
мониторинга нужен агент, который будет
вызывать эти интерфейсы

53. Интерфейсы мониторинга.
Pull. Файл. Преимущества.
• Не нужно специальных средств для
формирования метрик
• Не нужно специальных средств для вызова
• Просто парсить ответ
• Готовые средства для разграничения
доступа

54. Интерфейсы мониторинга.
Pull. Файл. Недостатки.
• Нужно место на диске
• Нужна синхронизация между периодами
сброса данных на диск и периодом их забора
с сервера
• Для подключения к внешней системе
мониторинга нужен агент, который будет
читать файл

55. Интерфейсы мониторинга.
Push. Достоинства.
• Для подключения метрик не нужно их явно
прописывать в отдельной системе. Особенно
если прописывать их там имеют права
отдельные от разработчиков люди.
• Динамические метрики просто работают.
• При добавлении/удалении экземпляров
приложений ничего не надо делать

56. Интерфейсы мониторинга.
Push. Недостатки.
• Всё равно надо что-то придумывать с AAA
• Можно легко залить тестовые или кривые
метрики в прод систему

57. Выводы по интерфейсам
мониторинга
• Для JVM всегда выводить метрики в JMX
• Для приложений push удобнее, чем pull, так
как можно быстрее получить рабочее
решение и часто бывают динамические
метрики
• То есть Graphite

58. Библиотеки для приложений.
Dropwizard metrics.
• Есть все виды метрик
• Есть интеграции для Spring и Guice
• Есть интеграции с популярными библиотеками и
серверами (httpclient, jetty и т.д.)
• Есть возможность вывода метрик в разные интерфейсы
(файл, JMX, Graphite и т.д.)
• Есть возможность писать декларативно (на аннотациях)
и императивно
• Используется в разных проектах (например, Cassandra)

59. Особенности работы с
Graphite
• Выбранный формат метрик: $type.type.
$cluster.cluster.$host.host.$metric.metric
• БД - RRD (Round-robin database)
• Между точками - каталоги. Последнее название
- файл.
• Свой веб-интерфейс не очень
• Но Grafana из коробки отлично работает с
Graphite

60. Что почитать
• Книга «Site Reliability Engineering»от Google
• Книга «Release it! Проектирование и дизайн ПО
для тех, кому не всё равно»
• Статья в Qiwipedia «Средства диагностики и
мониторинга серверных приложений Qiwi»
• Статья в Qiwipedia «Эксплуатационные
требования к серверному приложению»
• RTFM

61. Спасибо за
внимание!