Расшифровка доклада 2016 года Виталия Левченко "Prometheus мониторинг микросервисных приложений"
Prometheus, в отличие от классических систем, даёт возможность легко поднять и поддерживать мониторинг быстро меняющихся и сложно организованных систем. Я расскажу об опыте внедрения, подводных камнях и неожиданном поведении, покажу способы быстрой конфигурации всей системы, включая уведомления и дашборды.
В дополнение к классическим проблемам мониторинга монолитного приложения, микросервисы создают массу новой головной боли для мониторинга. Расположение сервисов постоянно меняется, часто появляются новые сервисы, меняются зависимости между ними, временные job'ы запускаются в случайном месте — пропадает понятие стабильной конфигурации. Пропадает понятие продакшна: в одной среде запущено множество версий одного сервиса — при деплое, для разных сегментов аудитории, для тестов и т.п. Разработчики же при виде такого счастья склонны быстро улучшать приложение, создавать много новых метрик, постоянно убивать старые и, несмотря на это, ожидать работающий мониторинг и реакции на новые проблемы.
Prometheus построен по мотивам Google Borgmon и отлично решает эти проблемы, предоставляя инструменты для автоматического и быстрого ручного обновления конфигурации. Запустился новый сервер, новый сервис, новая версия — и они уже подключены в мониторинг. Остановились — их там нет, если не нужны. Пропала неактуальная метрика — алертинг умеет с этим жить.
После этого доклада у вас будет понимание, насколько Prometheus подходит для использования в ваших системах.
Доклад о том, что мир меняется и те системы мониторинга, которые мы использовали до этого в огромном количестве, сейчас не пригодны. Появляются проблемы, которые мониторинг не решает. Prometheus их решает, поэтому мы его используем. Примерно так:
- Принес проблемы, связанные с тем, что необходимо бизнесу.
- Не осилили мониторинг вообще никак.
- Внедрили Prometheus.
- Это как-то работает.
И я по большей части этим занимаюсь. Я приношу проблемы. И после этого окружающие их решают. Я сейчас буду об этом рассказывать.
Если кратко, то я не админ, я developer. И действительно создаю проблемы админам. В этом моя работа. И привлекаю всякие технологии.
Проблема в том, что у нас большой сервис, много программистов и хочется, чтобы это быстро развивалось.
Что мы хотим? Мы хотим микросервисы. Мы хотим высокую доступность сервисов. Мы хотим docker. Мы хотим, чтобы сервисов было много и не можем без этого жить просто потому, что отдельные сервисы можно разработать быстро, быстро выкатывать и они независимы.
Проблема в том, что их очень много похожих. Мониторинг у них шаблонный. Если на мониторинг каждого сервиса нужно много времени, то это очень больно. Если мониторинг очень сильно привязан к тому, на каких серверах он запущен, а приложение каждый день запущено на разных серверах – это очень больно. И в чем самая большая проблема? То, что у нас на конкретной машине выключен сервис – это не является проблемой. Является проблемой, если у нас в production сервисов недостаточно.
Вторая проблема еще более глобальная – в современном мире production не существует. У нас в production есть 10 разных версий и это нормально. У нас есть свежий Мастер, выкаченный в рамках continuous delivery. У нас есть всевозможные stages. У нас есть бесконечные тесты. У нас есть длительные и не длительные тесты. Этого всего много и это нормально.
Трафик идет, куда повезет. И это настраивается динамически. Это настраивают программисты.
При это проблема в том, что перегрузки у всего этого мероприятия нужно мониторить. Если нам не хватает производительности, мы должны об этом узнать до того, как упало.
И вторая проблема аналогичная. То, что падают сервисы – это не проблема. То, что падают какие-то environments – это не проблема. Если это stage environment, то трафик перенаправится на другой environment, на более production.
Аналогично то, что быстро откатили, не считается упавшим. Это некий нонсенс для админов. Но если мы выкатили неработающий релиз, если мы его откатили через 20 секунд, об этом не нужно слать СМСку.
Об этих проблемах многие пишут. The twelve factor app – это базовая штука про конфигурацию Production. Все пишут, все знают, просто далеко не все используют. Очень рекомендую – это очень удобно.
И в целом у нас есть хотелки от мониторинга глобальные, без которых жить тяжело.
Мы хотим не менять приложение при настройке мониторинга. Т. е. мы хотим, чтобы люди, которые настраивают мониторинг, крутили графики. Посмотрели – вот график. Он не нравится. Выведем на дашборд. Вот здесь у нас случилась проблема и мы из этого сделаем алерт. И для это не нужно тратить неделю, т. е. на каждый цикл доработки отдельного графика, отдельной метрики и прочее. Это важно. Без этого нельзя нормально поддерживать мониторинг.
С остальным примерно тоже понятно – мы не хотим менять ничего. Мы хотим мониторить временные задачи. Это аналогичная большая проблема почти всех мне известных систем мониторинга, кроме, например, Graphite, который работает через StatsD. Там другая проблема, но все системы мониторинга, которые не push based, они не умеют мониторить временные задачи. И это плохо.
И самое важное – мы хотим, чтобы система оставалась очень простой, т. е. мы конфигурировали только то, что можно и то, что не нужно не конфигурировали вообще никогда.
Когда я пришел в последнюю компанию, там была масса решений, связанных с мониторингом. Я расскажу про основные, которые использовали. Я не буду упоминать про Graphite, про который рассказывал предыдущий докладчик. С ним есть проблема. Например, 100 000 метрик в секунду – это проблема. Много метрик – это проблема, потому что у нас 100 000 файловых дескрипторов. Новая каждая метрика – это новый дескриптор. Это очень круто, но это не про 21 век программирования. И, естественно, нет шардинга, нет отказоустойчивости в хорошем виде.
Кто использует production Zabbix или что-нибудь подобное? Спасибо. На самом деле – это не стыдно. Т. е. Zabbix – это отличная штука, потому что это хотя бы работающий мониторинг. Он хотя бы есть. И это несравнимо больше, чем ничего.
Проблема в том, что катастрофически все руками приходится делать. Все, что можно хотя теоретически настраивать, в Zabbix настраивается только руками. Про Nagios и прочие я даже говорить не хочу. Проблема в том, что это выглядит, как примерно на картинке. Т. е. мы делаем вид, что у нас автомобиль, а по факту нечто что-то ручное.
И вторая важная проблема, которая также не решается, у нас очень много агрегации, которая нужна для вывода базовых графиков. Zabbix их нормально не умеет вообще выводить. Это нужно агрегировать заранее, например, в Redis. Это очень грустно.
Вторая система, которую мы пробовали, более похожа на современную. Это InfluxDB и обертки вокруг. Это работает. В отличии от Graphite, InfluxDB умеет переваривать много метрик, потому что он делает на каждую метрику по одному файлику, а в базе данных гранит.
Но беда InfluxDB в том, что они перепробовали три или четыре систем хранилищ. Они разрабатывают систему уже три года. И за это время не сделали ни одного production. Т. е. в любой версии у вас есть гарантия, что при рестарте сервиса вы потеряете данные. При апгрейте вы потеряете данные. При любой операции вы можете потерять данные.
Я не знаю, почему его используют. При этом они говорят, что у них есть шардирование, репликация. Это неправда. У них нет репликации вообще нормальной. Вместо шардирования у них есть федерация (агрегированных?) запросов. Так нельзя. Это непригодно.
Вторая проблема таких систем в том, что, когда мы выносим систему уведомлений наружу от системы мониторинга, она работает по другим метрикам. Т. е. у нас на графиках одни красивые цифры, уведомление приходит по другим цифрам. Это конец света. Мы получаем СМСки, смотрим на график – все хорошо. Так нельзя.
При этом Riemann совсем не умеет агрегацию. Мы даже не можем сказать: «Дайте мне среднюю нагрузку CPU за минуту». Мы получаем циферки загрузки CPU – то 100 %, то 0 %. И живи с этим как хочешь.
И самый конец света этой схемы – это то, что CollectD синхронный. Он собирает все метрики, которые можно собрать. И после этого шлет их в InfluxDB. И если что-то зависло, что-то долго отвечает, что-то случилось с сервером, то CollectD зависает и ждет, пока ему ответят. Это очень удобная система для того, чтобы получать СМСки о том, что сервер умер.
И самая большая проблема InfluxDB в том, что там базы данных совсем не оптимизированы под time-series метрики, поэтому запросы очень медленные.
На фоне всей этой прелести есть Prometheus. В чем он хорош?
Его делают три человека из Google, которые знают, как работает хороший мониторинг, которые взяли структуру Google Borgmom, которые взяли систему хранения метрик по типу той, что сделана в Facebook. Эта система профессионального мониторинга, которая сделана людьми, которые знают, как это работает и что там должно быть. Это самое важное. Уже ради этого его можно брать.
Он умеет автоконфигурацию, т. е. при любом изменении production (при выкатке новой версии, при установке нового сервера, при установке нового сервиса, при переносе машинки слева на право) он умеет это делать, он подхватывает с коробки. Этого не умеет больше никто. Уже за это Prometheus надо брать.
Он модульный. Это полноценный комбайн. В Prometheus есть много сборщиков, так называемые экспортеры. Плюс приложения сами экспортируют метрики.
Там есть система хранилища, там есть система уведомлений. Есть deprecate-система рисования графиков. Рекомендую Grafana. В целом Grafana работает, она пригодна.
И самое важное, что Prometheus производительный из коробки. Он реально переваривает миллион метрик в секунду. Т. е. то, что порядка 20 000 метрик в секунду на ядро – это правда. С обычной 24-ядерной машины переваривает 400 000 метрик в секунду особо не напрягаясь. Ставим 3 машины, получаем 1 200 000. Это очень много.
Но при этом это не production версия. Они периодически что-то меняет. Например, за прошедшие полгода они поменяли систему уведомления. Это нужно понимать. И если вы это внедряете, то там может что-то поменяться в процессе.
Одна из важных вещей, о которой говорил предыдущий докладчик, это теги или метрики, т. е. мы для любой метрики можем назначить теги. Это environment. Это server, на котором он запущен. Это handler через который он обрабатывает всякие типы ошибок. Все что угодно и все что нравится. Это умножает количество метрик. Но Prometheus это нормально переваривает. Для него нормально, когда много метрик.
И это удобно программисту, потому что мы записываем одну метрику, а в реальности это очень много метрик. В случае любой другой системы, кроме тех, которые имеют теги, это сотни метрик. И это очень неправильно. Это никто не предусматривает, поэтому метрики пишутся на ходу. И система гораздо менее полноценная.
Что еще хорошо? При этих тегах агрегаты рисуются по любым срезам. Мы можем просить: «Дайте мне данные от этого вида environment со всех серверов, кроме конкретно и с конкретным типом ошибки». И это будет работать.
Это позволяет по общим графикам по определенным срезам очень быстро диагностировать проблему. Если что-то случается, то мы смотрим и через минуту мы уже знаем, что случилось чаще всего. Для тех, кто разбирал формат проблемы, почему упал этот сервис или почему в конкретном месте произошел акт производительности, о котором мы узнали через день – это реально решает.
В Prometheus есть правильные функции, т. е. функции, которые реально решают проблемы.
Вот это пример такой функции. Эта функция делает очень простую вещь. Она говорит, что через 4 часа закончится место на диске. И такой степени выразительности нет практически нигде. Мы чаще всего отслеживаем, сколько у нас свободного места на диске. А если у нас Zookeeper, которому стало плохо и который пишет со скоростью записи на диск, то у нас … 95 % диска заполнилось, через 20 минут оно заполнилось на 100 %. Не успели отреагировать. И такие штуки – они реально решают. И таких функций много. И это все из коробки. Они это умеют, это работает.
Кто-то ругается по поводу pull metrics и push metrics. Я не хочу в это вдаваться, но на самом деле pull metrics удобнее.
StatsD – удобная штука для перехода от того же Graphite, например. StatsD удобен для того, чтобы туда сохранять метрики приложения. Он отлично агрегирует. Его можно использовать.
Но его основная проблема в том, что exporter не стабилен. Мы туда записываем, например, 50 000 метрик в секунду. Мы записываем много реплик и ему становится плохо. Это грустно, когда сервису, который используем в production, становится плохо и это не крутится никакими настройками.
StatsD exporter Prometheus стабилен. Но он от этого не перестает быть StatsD, причем не полноценным StatsD, который не умеет нормальных gauge etc, гистограммы и прочих полноценных метрик.
И исходя из этого проще использовать push gateway и сохранять прямо из приложения push’ом. Это канонический путь Prometheus. Если у вас StatsD, то переходите на push gateway и станет лучше.
С автоконфигурацией все здорово. Раньше нужно было писать небольшой кусок программы, который конфигурирует Prometheus, исходя из ваших серверов, сервисов и прочего. Т. е. явно прописываем, что нужно собирать метрики с этих серверов и айпишников, и портов. А сейчас этого нет. Сейчас он умеет прямо из коробки собирать данные из любого Amazon, из любого Kubernetes, из любого Mesos, из любого Consul и это работает. Т. е. они это протестировали, они это впилили и это работает.
Более того, если у вас Ansible, он умеет из файлов собирать все данные. Т. е. вы как-то распихали сервисы, распихали базы данных, записали, где и что у вас находится и это возьмется. И главное, это будет сходу работать без рестарта Prometheus. Там reload надо будет сделать, но это не проблема.
И основная проблема этого процесса в том, что нужно отдельно автоматизировать дашборды. Если у вас есть отдельные экраны по сервисам, где отдельные графики по серверам, то это нужно отдельно автоматизировать. Нужно брать javascript и пользоваться. Это реальная проблема, это боль и мы ее не очень осилили. Но надо.
Нам еще нужно уметь собирать метрики с серверов и БД. И нужно это как-то между собой синхронизировать.
В Prometheus все это есть. Есть нативно поддерживаемые экспортеры. Есть экспортеры open source. Например, Postgres exporter – он не нативный, он просто написан и работает. Есть Node exporter, который экспортирует данные с серверов.
Фишка в том, что экспортеры пишутся очень просто. Это несколько сотен строк кода, и они собирают почти все нужные метрики. Вы можете взять и сами написать то, что вам нужно собирать. Это очень здорово.
И почти все метрики системы он собирает через systemd. И это очень здорово.
Другая проблема, если мы не используем агрегацию. Если мы не используем агрегацию на графиках, то у нас происходят всякие интересные вещи.
У нас происходят разрывы графиков и прочее. Например, у нас аккаунтеры начинают с нуля сразу после старта сервиса. И это нормально. Аналогично, если мы не записали метрику, то ее нет. Просто прочитайте документацию, там подробно написано, что с этим делать. Документация у Prometheus удобная. Т. е. это не документация как у Influx, в которой можно потеряться.
Но в идеале рисовать графики лучше с агрегацией. Это удобнее.
С отказоустойчивостью все здорово. Их документация рекомендует, что если у вас какие-то проблемы с БД, то просто удалите ее. Это основная рекомендация того, что делать, если она не подцепилась. Я не шучу – это строчка из документации –rm – r <storage path/*. Это реальность. У них файловое хранилище очень кастомное. И оно, условно, production. Оно стабильно, оно работает, но бывают тонкости.
Но с другой стороны у нас есть federation, который позволяет раскидывать это на много серверов, причем federation бывает как горизонтальный, так и вертикальный.
Плюс мы можем собирать метрики на несколько серверов. Т. е. физически в двух разных Prometheus серверах их одинаково конфигурировать и с них отображать. В этом нет проблемы.
Но они делают openTSDB и рано или поздно закончат. И после этого проблемы отказоустойчивости не станет, будет просто в качестве хранилища. И в openTSDB есть много проблем, связанных с уведомлением, но с системой хранения у них все хорошо, кроме того, что это Hadoop.
Другая проблема, с которой периодически сталкиваются, это то, что не понятно, что такое histogram и summary. Не понятно, где это использовать и куда девать.
Условно мы говорим, что все запросы, которые меньше 100 миллисекунд – это хорошо. От 100 до 300 – это средне. И то, что больше 300 – это конец света. Это про histogram. Они говорят, что они умеют рисовать … квантили, но, пожалуйста, не делайте этого. Это неправильно. Оно про другое. И проблема в том, что если вот таких histogram делается много, то оно медленно агрегируется. Если у вас таких 10 состояний, то агрегация будет в 10 раз медленнее. На этом можно ловить тайм-аут и прочее. Это нужно понимать в каждый момент времени, но на этот случай есть recording rules. Она есть, она работает, просто конфигурировать удобно. Единственное, это нужно конфигурировать заранее.
Summary – это отдельная штука. Summary работает ровно наоборот. Summary умеют квантили ровно те, которые вы попросили. Но проблема в том, что я физически видел, как люди пытаются складывать квантили, пытают рисовать среднее значение. Не надо так. Это немножко получится не то, что вы ожидаете. Аналогично, если вы попытаетесь просуммировать 99-ый процентиль, то вы ничего хорошего не получите, т. е. вы получите не то, что будете ожидать. Это важно.
Но при этом summary умеют квантили именно с отдельной метрики. Т. е. если их не агрегировать или агрегировать минимум либо максимум, то это пригодно.
Теоретически квантили умеют еще всякие тайм-метрики. Но не используйте их. Это тяжело и не одна система мониторинга современная не умеет складывать квантили.
Как этим пользоваться? С чего начать собирать метрики? Если у нас микросервисы, то самое простое, что мы собираем, это:
- Все входящие и исходящие соединения. Можно взять оттуда всю статистику, связанную с запросами, т. е. количество запросов, latency запросов, количество ошибок, количество активных запросов и просто вывести на графике. Этого достаточно для диагностики 99 % проблем. На оставшийся процент мы можем собирать внутренние статистические метрики, чтобы заранее ловить, что что-то стало плохо. Вот это вот впиливается за полдня. Это очень круто и очень удобно.
- В том числе запросы в БД.
- Ошибки.
- Активные коннекты.
- Метрики производительности + статистика.
Чем он хорош?
- Он умеет микросервисы. Действительно, умеет. Он их прямо из коробки использует. Мы запускаем на одной машине 10 сервисов, и он все 10 ловит, и со всех 10 собирает метрики, причем сам из коробки. (При использовании Service Discovery)
- Он очень удобен в плане сбора метрик, в плане дашбордов и прочего. Grafana реально решает массу проблем. Там есть своя система вывода графиков, которая позволяет очень быстро диагностировать по срезам. Мы можем спросить: «Дай мне все графики по серверам». И она увидит 10 графиков по серверам с нужными агрегациями. Аналогично, есть очень удобный алерт. Им приятно и удобно пользоваться. Мы настроили, что у нас является проблемой и пометили их метками, и после это в зависимости от метрик рассылаем это разным людям.
- Настройка из коробки – это быстро и можно настроить то, что нужно. Эту штуку любят программисты. Т. е. физически мы взяли, впихнули, это работает и главное, все показывает то, что нужно.
- Для админов – это боль, как любая новая штука, которую непонятно, как бэкапить, например.
- И самое приятное в том, что Prometheus можно внедрить за пару часов. Я не шучу. Мы собираем самые простые метрики, ставим Prometheus прямо из docker. И это работает. Это офигительно. Наш кейс внедрения – два дня. Это очень круто. Я не знаю аналогов этому.
Вопросы
Добрый день! Спасибо за доклад! Первый вопрос по поводу Zabbix. Здесь много тех, кто его использует. Есть небольшая сеть магазинов, которая называется Магнит. У них несколько тысяч точек, которые разворачиваются автоматически при подключении новой точки на базе шаблонов, которые достаточно развиты в самом Zabbix. Насколько у вас часто меняется environment, чтобы вам нужно было каждый раз вручную менять шаблоны?
Очень часто. Любой деплой – это новый environment, по сути. (Имеется виду что используется Kubernetes либо Service Discovery)
Т. е., я правильно понимаю, что вы developer, который идет в любую сторону с новыми технологиями? Т. е. вы постоянно экспериментируете с environment?
Это удобно.
Удобно экспериментировать с environment?
Не экспериментировать с environment. Мы запускаем тесты и у нас уже два environment. Запускаем еще один тест и у нас еще один environment. Мы запихнули свежий Мастер, у нас третий environment, мы запихнули последний stable – четвертый environment. (Имеется виду что используется Kubernetes либо Service Discovery)
Нет, я имею в виду используемые технологии. Т. е. вы мониторите какие-то метрики, которые генерируются той или иной библиотекой, сервисом. Соответственно, вы далее агрегируете их и получаете какой-то результат. Т. е. для того, чтобы можно было вносить какие-то изменения в шаблон, нужно, чтобы эти метрики менялись. Насколько часто у вас появляются новые метрики, которые необходимо вносить в систему мониторинга?
На моем опыте использования Zabbix в большом production, поскольку мы большое количество агрегатов заранее не сохраняем, их нужно доделывать. Нужно реально впиливать, потому что мы выясняем, что у нас есть новые проблемы, новые сервисы и еще что-то. Это занимает full time одного человека, если он целенаправленно этим занимается. Успешный кейс работы с Zabbix, когда быстро, удобно для всех, это команда из 3-4-х человек. Если компания готова поддерживать 3-4-х людей на зарплате, то Zabbix – это отличное решение. Реально все решает.
Имеете в виду, что 3 человека занимается конкретно Zabbix?
Да.
Хорошо. Тогда второй вопрос. Какое время у вас команда developers тратит на настройку самого Prometheus?
Нисколько.
В смысле? Он у вас сам разворачивается и получает сам метрики?
Он один раз развернутый работает.
Хорошо. Раз у вас меняется постоянно environment, то у вас все равно должен быть какой-то агент или sender, который отправляет в Prometheus метрики.
Там не sender. Prometheus работает следующим образом. У нас в сервисах есть API http’шный, который выгружает метрики. И есть конфигурация через Consul, в которую смотрит Prometheus и узнает о том, где запущены сервисы. И он туда просто сходит за метриками.
Это я понимаю. Я к тому, что внутри самого контейнера с сервисом, там бежит какая-то служба дополнительная или сам сервис отправляет данные в Prometheus?
Да, в сам сервис нужно впилить библиотеку и сохранить метрики. Это два часа.
Хорошо. Вне зависимости от используемого мониторинга docker’ом, по сути, мы в любом случае, если хотим мониторить контейнеры, мы должны в каждый из контейнеров положить какую-то систему, которая будет проверять состояние самого контейнера. И здесь вопрос overhead, который используется. Т. е. вы впиливаете библиотеку, которая проверяет состояние контейнера?
Зачем?
Вы же пересылаете данные.
У нас есть health handler, в который мы стучимся. Если он ответил, значит, все работает. Если не ответил, значит, ничего не работает.
Добрый день! Спасибо за доклад! У меня всего лишь 4 вопроса. На одном из слайдов вы сравнивали StatsD, говорили, что он синхронный, что у него все очень грустно. Зачем вы смотрите на StatsD, если есть родной Influx’ский Telegraf?
Затем, что до этого был StatsD, который сохранился после Influx.
Ok. Была тема о том, что дашборды в Grafana сложно настраивать. Да, мы тоже с этим же столкнулись. И у нас один из разработчиков просто за выходные написал утилиту на Go, которая берет и по шаблонам дашборды разворачивает. Может быть, вам будет это интересно и после доклада могу показать.
Вы ее сделайте open source, и всем станет хорошо.
Она на GitHub лежит, просто нужно ссылочку показать. Следующий вопрос. Вы используете federation, правильно?
На самом деле, нет. Но это в планах.
Ok. Используете ли вы алерт-менеджер?
Разумеется, без него жить нельзя.
Вы немного расскажите про количество метрик, которые у вас во всех средах держит ваша система. И какая нагрузка? И как она масштабируется?
В плане количества метрик я сейчас не помню статистики. Надо смотреть, я не помню. Это порядка 100 000 метрик. Может, 200 000-300 000. Возможно, больше, возможно, меньше, но порядок примерно такой. Примерно такой же масштаб у меня был с Zabbix, это тоже работало. С Influx такой масштаб метрик не работал, т. е. там сохранялось успешно, но не работали queries нормально.
Что с проактивным мониторингом?
Что вы имеете в виду?
Что, если там вдруг что-то сломалось, то сам мониторинг все починит, переключит.
Если хотите, то запускайте скрипты из алерт-менеджера и будет вам счастье. Но это в любом случае руками надо делать, т. е. все есть.
