Доклад о Bosun (http://bosun.org) — мониторинге от StackExchange и его использовании в https://www.onetwotrip.com/ за 1,5 года. Строить мониторинг сложно, не работает подход "посадить людей смотреть на дашборды" либо обнаруживать аномалии во всех данных. Алерты должны соответствовать реальности и проверять сложные сценарии. В Bosun, как и во многих современных продуктах, метрики (данные) ортогональны правилам (коду) обнаружения алертов. Это позволяет гораздо быстрее создавать и настраивать правила, в том числе тестируя их на данных из прошлого. Вместо итераций в дни или недели теперь минуты. Workflow настройки мониторинга точно такой же, как у всех остальных разработчиков, причём они сами могут принимать участие без помощи админов, так же создавая оповещения, перенаправляя инциденты на себя. Таким образом принимая ответственность за то, что они выкатывают в продакшн. В Bosun продуманная схема данных, а также мощный язык их обработки, напоминающий R/pandas. В несколько строк пишутся map/reduce выражения, проверяющие соотношения, например, входящего трафика и загрузки бэкендов. Всё это после серьёзного, но благодарного труда, работает в динамической инфраструктуре и не срабатывает без повода, а если уж срабатывает, то к каждому инциденту можно приложить какой угодно контекст с состоянием (графиком параметров) системы, вычислением условий и ссылками на дашборды. MIT лицензия, продукт созданный в StackExchange для решения собственных задач, на мой взгляд, ориентирован на компании со средней+ инфраструктурой.

1. Bosun: современный мониторинг
Дима Медведев, OneTwoTrip
v. 0.7

2. Мониторинг это –
● Обнаружение проблем
● Выяснение причин
● Данные для принятия решений

3. Потребности продакшена
● Мониторинг
● Решение инцидентов
● Постмортемы
● Релизы
● Тестирование
● Планирование нагрузки
● Разработка
● Продукт

4. OneTwoTrip
● 2.5 миллиона поисков в день
● Мгновенное влияние на выручку
● Динамическая мультиоблачная инфраструктура
● Полная зависимость от внешних провайдеров
● Авиа и ЖД билеты, отели, страховки, перелёт+отель,
кредиты, аренда машин, мобильные приложения

5. ElasticSearch Logstash Kibana(ELK)
● Логов может быть много
● Дашбордов тоже
● Секретные данные
● Сложный обмен опытом
● Не всегда очевидные лог-сообщения
● Связанные данные и правила алертинга
● Проблемы производительности при авариях

6. Дашборды
Плюсы
● Легче создать
● Лучше видно аномалии
● Больше показывают
Минусы
● На них нужно смотреть

7. Zabbix
● Ручная конфигурация
● Отсутствие истории изменений
● Бесполезные для нас алерты
● Грязные приёмы для регистрации хостов

8. #monitoringsucks объекты
инфраструктуры
нотификации

9. Going Postal, 2010 by Terry Pratchett, Jon Jones et al.

10. #monitoringrocks
объекты
инфраструктуры
нотификации

11. Автоматический поиск аномалий
● Нет работающих примеров
● Много шума
● Нужна экспертиза

12. Проблема выбора
Ноябрь 2014 года:
● SAAS решения
● Riemann
● Bosun

13. Новые инструменты
«In recent years, monitoring has
undergone a Cambrian
Explosion:Riemann, Heka, Bosun, and
Prometheus have emerged as open
source tools that are very similar to
Borgmon’s time-series–based
alerting.»

14. Качественные алерты
● Срабатывают по реальной проблеме
● Понятные, есть контекст
● Проверяют общее, показывают частное
● Требуют осмысленной реакции человека
● Эволюционируют вместе с системой

15. Bosun, главное
Поддержка запросов в
● OpenTSDB
● Graphite
● ElasticSearch
● InfluxDB
● Продуманный жизненный
цикл инцидентов
● Alert design IDE
● DSL, ориентированный на
данные
● Тестирование
срабатывания на прошлом
● Шаблоны для полного
контекста аварии

16. Жизненный цикл алерта
Разработка
ТестированиеДеплой

17. Жизненный цикл алерта
alert printer_on_fire{
$query=avg(q(''avg:printer.status{n...
crit = $query > s
From: 1985-10-26
To: 2015-10-21
Test printer_on_fire

18. Тестирование на прошлом

19. Вовлечение разработчиков
● Пишем метрики
● Изучаем поведение системы
● Создаем алерт
● Тестируем на имеющихся данных
● PR в мониторинговый репозиторий

20. Состояния алертов

21. Going Postal, 2010 by Terry Pratchett, Jon Jones et al.

22. Состояния алертов
ACK FIX CLOSE

23. Что на самом деле важно?

24. Что на самом деле важно?

25. Пример алерта от OneTwoTrip

26. Пример алерта от OneTwoTrip

27. Пример алерта от OneTwoTrip

28. Пример алерта от OneTwoTrip

29. Пример алерта от OneTwoTrip

30. Пример алерта от OneTwoTrip

31. История одной аварии

32. История одной аварии

33. История одной аварии

34. История одной аварии

35. OneTwoTrip и запросы смерти
● Redis mem free, %
● 6GB за 3 минуты
● без изменений в io
● добавили метрик
● нашли баг, но не тот

36. Пример алерта от Vimeo
● Graphite
● timeShift()
● 2 макроса
● median-now / median-historical < X
● (deviation-now * median-historical) /
((deviation-historical * median-now) > Y

37. Взаимоотношения с upstream
● Плотное общение с upstream разработчиками
● Опенсорс – это (не всегда) быстро
● Собственные сборки
● Keep calm and always use master branch

38. Hadoop – это не страшно
● Сложная, но стабильная архитектура
● Современные удобные фреймворки (Ambari)
● Наши невысокие требования к производительности

39. Bosun & Chef
● Chef-bosun
● Chef-scollector
● Настройка метрик для каждого типа серверов
● Сборка scollector с нашими патчами
● Собственный deb репозиторий

40. Метрики из приложения
● Telegraf statsd (агрегация)
● Scollector + httpUnit
● Bosun + HAProxy + OAuth proxy
● OpenTSDB
● Grafana + Bosun datasource

41. Благодарности
● Kyle Brandt
● Matt Jibson
● Craig Peterson
● Greg Bray
● Jason Harvey
● Dieter Plaetinck

42. Ссылки
http://bosun.org/resources
http://dieter.plaetinck.be/post/practical-fault-detection-on-timeseries-part-2/
https://github.com/onetwotrip/

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