- PVSM.RU - https://www.pvsm.ru -
28 мая на проходившей в рамках фестиваля РИТ++ 2018 конференции RootConf 2018 [1], в секции «Логирование и мониторинг», прозвучал доклад «Мониторинг и Kubernetes». В нём рассказывается об опыте настройки мониторинга с Prometheus, который был получен компанией «Флант» в результате эксплуатации десятков проектов на Kubernetes в production.
По традиции рады представить видео с докладом [2] (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!
Существует множество систем мониторинга:
Казалось бы, взять и установить одну из них — вот и всё, вопрос закрыт. Но практика показывает, что это не так. И вот почему:
Мониторинг — это пирог из трёх слоёв, каждый из которых критичен:
Грамотная настройка системы мониторинга, которая действительно работает, — непростая задача, требующая вдумчивого подхода к реализации даже без Kubernetes. А что же происходит с его появлением?
С Kubernetes многое меняется, потому что инфраструктура становится больше и быстрее. Если раньше, с обычными железными серверами, их количество было весьма ограниченным, а процесс добавления — очень долгим (занимал дни или недели), то с виртуальными машинами количество сущностей значительно выросло, а время их введения в бой сократилось до секунд.
С Kubernetes же количество сущностей выросло ещё на порядок, их добавление полностью автоматизировано (управление конфигурациями необходимо, т.к. без описания новый pod просто не может быть создан), вся инфраструктура стала очень динамичной (например, при каждом деплое pod’ы удаляются и создаются снова).
Что это меняет?
Начну с такого сравнения:
Так вот классические системы мониторинга думают, что они детский сад, а не бассейн: они предполагают, что объект для мониторинга к ним пришёл навсегда или надолго, и выдают им шкафчики соответствующим образом. Но реалии в Kubernetes иные: pod пришёл в бассейн (т.е. был создан), поплавал в нём (до нового деплоя) и ушёл (был уничтожен) — всё это происходит быстро и регулярно. Таким образом, система мониторинга должна понимать, что объекты, за которыми она следит, живут короткую жизнь, и должна уметь полностью о нём забывать в нужный момент.
Другой важный момент — с появлением Kubernetes у нас одновременно существуют две «реальности»:
Один и тот же контейнер в «виртуальной реальности» Kubernetes (сверху) и физическом мире узлов (снизу)
И в процессе мониторинга нам необходимо постоянно сопоставлять физический мир контейнеров с реальностью Kubernetes. Например, когда мы смотрим на какое-то пространство имён, мы хотим знать, где находятся все его контейнеры (или контейнеры одного из его подов). Без этого алерты не будут наглядными и удобными в использовании — ведь нам важно понимать, о каких объектах они сообщают.
Разные варианты алертов — последний нагляднее и удобнее в работе, чем остальные
Выводы здесь таковы:
Итак, у нас есть три необходимых условия, чтобы всё вообще могло получиться:
И вот, чтобы действительно получилось, остаётся лишь приложить действительно много усилий! Кстати, почему именно Prometheus?..
На вопрос о выборе Prometheus можно отвечать двумя путями:
Для первого я воспользовался данными опроса от The New Stack (из электронной книги The State of the Kubernetes Ecosystem [3]), согласно которым Prometheus как минимум популярнее других решений (и Open Source, и SaaS), а если разобраться, то и вовсе имеет пятикратное статистическое преимущество.
Теперь посмотрим, как устроен Prometheus, параллельно разбираясь с тем, как его возможности сочетаются с Kubernetes и решают связанные вызовы.
Prometheus написан на языке Go и распространяется как один бинарный файл, в который встроено всё необходимое. Базовый алгоритм его работы следующий:
Как выглядит эта таблица? Для каждой записи в ней хранятся URL, к которому обращаться для получения метрик, частота обращений и лейблы.
Лейблы используются для того самого сопоставления «миров» Kubernetes и физического. Например, чтобы найти pod с Redis нам необходимо иметь значения namespace, service (используется вместо deployment ввиду технической особенности для конкретного случая) и собственно pod'а. Соответственно, эти 3 лейбла хранятся в записях таблицы целей для метрик Redis.
Эти записи в таблице формируются на основе конфига Prometheus, в котором описаны объекты мониторинга: в секции scrape_configs
определяются job
'ы, где указывается, по каким лейблам искать объекты для мониторинга, как их фильтровать, какие их лейблы записывать.
prometheus-custom-target
в описание service.
Полученные данные (описаны выше) используются для отправки алертов и создания графиков. Графики мы рисуем с помощью Grafana. И важной «деталью» здесь является PromQL — язык запросов в Prometheus, который отлично интегрируется с Grafana.
Он достаточно прост и удобен для большинства задач (но, например, делать join'ы в нём уже неудобно, а всё равно придётся). PromQL позволяет решать все необходимые задачи: быстро выбирать нужные метрики, сравнивать значения, выполнять над ними арифметические действия, группировать, работать с временными интервалами и многое другое. Например:
Кроме того, у Prometheus есть исполнитель запросов (Evaluator), который с помощью такого же PromQL может обращаться к TSDB с указанной периодичностью. Зачем это? Пример: начинать отправлять алерты в тех случаях, если у нас есть, согласно имеющимся метрикам, 500 ошибка на веб-сервере на протяжении последних 5 минут. В данные для алертов помимо лейблов, которые были в запросе, Evaluator добавляет дополнительные (как мы настроим), после чего они отправляются в формате JSON в другой компонент Prometheus — Alertmanager.
Prometheus периодически (раз в 30 секунд) отправляет алерты в Alertmanager, который дедуплицирует их (получив первый алерт, он его отправит, а последующие такие же отправлять повторно не будет).
Примечание: Мы у себя не используем Alertmanager, а отправляем данные из Prometheus напрямую в свою систему, с которой работают наши дежурные, но принципиального значения в общей схеме это не имеет.
Давайте теперь посмотрим, как работает вся эта связка Prometheus в рамках Kubernetes:
kube-prometheus
).Чего же здесь не хватает?..
При сборе данных каждые 30 (или 60) секунд очень быстро заканчивается место для их хранения, а ещё хуже, что для этого требуется много вычислительных ресурсов (при получении и обработке такого большого количества точек из TSDB). Но мы ведь хотим хранить и иметь возможность загружать информацию за большие временные интервалы. Как этого достигнуть?
Достаточно добавить в общую схему ещё одну инсталляцию Prometheus (мы называем её longterm), в которой Service Discovery отключён, а в таблице целей — единственная статическая запись, ведущая к основному Prometheus (main). Это возможно благодаря федерации [7]: Prometheus позволяет возвращать последние значения всех метрик одним запросом. Таким образом, первая инсталляция Prometheus работает по-прежнему (обращается каждые 60 или, например, 30 секунд) ко всем целям в кластере Kubernetes, а вторая — раз в 5 минут получает данные с первой и хранит их для возможности смотреть данные за большой период (но без глубокой детализации).
Второй инсталляции Prometheus не нужен Service Discovery, а таблица целей будет состоять из одной строки
Картина в целом с инсталляциями Prometheus двух видов: main (сверху) и longterm
Финальный штрих — подключение Grafana к обеим инсталляциям Prometheus и создание dashboards специальным образом, чтобы появилась возможность переключаться между источниками данных (main или longterm). Для этого требуется с помощью механизма шаблонов подставить переменную $prometheus
вместо data source во всех панелях.
Два ключевых момента, которые стоит учитывать при организации графиков, — это поддержка примитивов Kubernetes и возможность быстрого drill down от общей картины (или более «низкого» представления) к специфической службе и наоборот.
Про поддержку примитивов (пространства имён, поды и т.п.) уже говорилось — это необходимое в принципе условие для комфортной работы в реалиях Kubernetes. А вот пример про drill down:
И помните, что содержимое важнее системы, т.е. первичны правильные графики и алерты, а не Prometheus (или любой другой аналогичный софт) как таковой.
Видео с выступления (около часа):
Презентация доклада:
Другие доклады в нашем блоге:
Вероятно, вас также заинтересуют следующие публикации:
Автор: distol
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/282278
Ссылки в тексте:
[1] RootConf 2018: http://rootconf.ru/moscow-rit/2018
[2] видео с докладом: https://www.youtube.com/watch?v=zj6SlzzBRaA&index=5&list=PL1mJ-PkCYnmB9vljnjxCMP3dlxQY3Dfcq
[3] The State of the Kubernetes Ecosystem: https://thenewstack.io/ebooks/kubernetes/state-of-kubernetes-ecosystem/
[4] информацию об объектах: https://github.com/kubernetes/kube-state-metrics/tree/master/Documentation
[5] так далее: https://github.com/prometheus/node_exporter#enabled-by-default
[6] так далее: https://prometheus.io/docs/alerting/configuration/#%3Creceiver%3E
[7] федерации: https://github.com/prometheus/prometheus/blob/master/docs/federation.md
[8] Лучшие практики CI/CD с Kubernetes и GitLab: https://habr.com/company/flant/blog/331188/
[9] Собираем Docker-образы для CI/CD быстро и удобно вместе с dapp: https://habr.com/company/flant/blog/324274/
[10] Практики Continuous Delivery с Docker: https://habr.com/company/flant/blog/322686/
[11] Устройство и механизм работы Prometheus Operator в Kubernetes: https://habr.com/company/flant/blog/353410/
[12] Мониторинг с Prometheus в Kubernetes за 15 минут: https://habr.com/company/flant/blog/340728/
[13] Инфраструктура с Kubernetes как доступная услуга: https://habr.com/company/flant/blog/341760/
[14] Источник: https://habr.com/post/412901/?utm_campaign=412901
Нажмите здесь для печати.