Prometheus, в отличие от классических систем, даёт возможность легко поднять и поддерживать мониторинг быстро меняющихся и сложно организованных систем. Я расскажу об опыте внедрения, подводных камнях и неожиданном поведении, покажу способы быстрой конфигурации всей системы, включая уведомления и дашборды. В дополнение к классическим проблемам мониторинга монолитного приложения, микросервисы создают массу новой головной боли для мониторинга. Расположение сервисов постоянно меняется, часто появляются новые сервисы, меняются зависимости между ними, временные job'ы запускаются в случайном месте — пропадает понятие стабильной конфигурации. Пропадает понятие продакшна: в одной среде запущено множество версий одного сервиса — при деплое, для разных сегментов аудитории, для тестов и т.п. Разработчики же при виде такого счастья склонны быстро улучшать приложение, создавать много новых метрик, постоянно убивать старые и, несмотря на это, ожидать работающий мониторинг и реакции на новые проблемы. Prometheus построен по мотивам Google Borgmon и отлично решает эти проблемы, предоставляя инструменты для автоматического и быстрого ручного обновления конфигурации. Запустился новый сервер, новый сервис, новая версия — и они уже подключены в мониторинг. Остановились — их там нет, если не нужны. Пропала неактуальная метрика — алертинг умеет с этим жить. После этого доклада у вас будет понимание, насколько Prometheus подходит для использования в ваших системах.

1. Prometheus
мониторинг микросервисных
приложений
v 1.3
Виталий Левченко

2. О чём доклад
Some people, when confronted with a problem, think “I know, I'll use regular
expressions.” Now they have two problems. © Jamie Zawinski

3. О чём доклад
● Принёс проблемы микросервисы
● Не осилил мониторинг
● Внедрил Prometheus
● Походил по граблям

4. О себе
● Приношу проблемы

5. О себе
● Приношу проблемы
● Web developer
● Technology evangelist

6. Генезис
Не было печали — микросервисы внедряли

7. Микросервисы
● High availability
● Docker

8. Микросервисы
● Много похожих сервисов
● Запущены где повезёт
● Упал — не проблема

9. «Продакшна» не существует
● Continuous delivery
● A/B tests

10. «Продакшна» не существует
● Трафик идёт куда повезёт
● Перегрузки нужно мониторить

11. «Продакшна» не существует
● Трафик идёт куда повезёт
● Перегрузки нужно мониторить
● Упал — не проблема
● Быстро убранное не считается упавшим

12. А проблемы известные
● The twelve factor app (12factor.net)

13. Хотелки
● Не менять приложение для новых алертов и графиков
● Не менять сборщики
● Мониторить временные задачи
● СМС только когда всё очень плохо, и только тогда
● Keep it simple, stupid!

14. Решения
«У человека должен быть выбор … даже если это выбор между плохим и
очень плохим вариантом»

15. Zabbix, Munin + Nagios
● Всё руками
● Алерты на реконфигурацию
● Агрегация снаружи

16. CollectD + InfluxDB + Riemann
● Всё так же руками
● Riemann не умеет агрегацию
● CollectD синхронный (!)
● Медленные запросы

17. Prometheus
● Like Google Borgmon
● Автоконфигурация
● Модульный, Go
● Производительный из коробки
● “Betta than nothing”

18. Prometheus
David: Why do you think your people made me?
Charlie Holloway: We made you because we could.

19. Правильные метрики
● Метки: server, env, handler, error type whatever
● Агрегаты по любым срезам
● Космически быстрая диагностика!

20. Правильные функции
ALERT DiskWillFillIn4Hours
IF predict_linear(node_filesystem_free{job='node'}
[1h], 4*3600) < 0
FOR 5m
LABELS {
severity="page"
}

21. Pull metrics
● Push хуже масштабируется
● Push поздно сообщает, что упал
● Prometheus в dev

22. StatsD
● Почти все нестабильны
● Prometheus exporter стабилен!
● Не умеет гистограммы, gauge etc
● Используйте push gateway!

23. Автоконфигурация
● AWS, Consul, Kubernates, Zookeeper whatever
● Даже из файлов!
● Отдельно автоматизировать дашборды

24. Сбор метрик с серверов и БД
● Node exporter
● PostgreSQL exporter
● …
● Напишите свой, это просто (Go)
● Use systemd, Luke!

25. Без агрегации
● Внимательно читайте документацию!
● Метрики сбрасываются при рестарте
● Лучше без этого

26. Отказоустойчивость
● rm -r <storage path>/* © docs
● Federation
● Сбор в несколько серверов
● Ждём openTSDB

27. Summary vs histogram
● Гистограммы хороши для SLA
● Саммари умеют квантили, но не агрегацию
● Гистограммы медленные на запросы
● Use recording rules

28. Что собирать с сервисов
● Входящие и исходящие запросы (latency + count)
● В том числе запросы в БД
● Ошибки
● Активные коннекты (!)
● Метрики производительности + статистика

29. Итоги Prometheus
● Умеет микросервисы
● Удобный сбор, дашборды, алерты
● Любовь программистов
● Новая боль для админов
● Внедрение от пары часов до пары дней

30. Вопросы?

31. Контакты
● Виталий Левченко
● levtchenko@gmail.com