Как реализовать систему мониторинга ресурсов и микросервисов для Microsoft Azure

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Всем привет! Меня зовут Олег Тарасенко, я DevOps Engineer в финтех-компании Wirex. В этой статье я хочу рассказать о том, как можно внедрить эффективную систему мониторинга для Microsoft Azure.

Если вы когда-либо работали со сложной, мультикомпонентной или высоконагруженной облачной инфраструктурой, вы, вероятно, понимаете, насколько критична для надлежащей работы продукта эффективная система мониторинга.

К сожалению, не всегда есть готовые решения, которые могут гарантировать должный охват всех необходимых метрик и ресурсов и предоставить дополнительную кастомизацию. Даже если вам удастся найти подходящее решение, скорее всего оно будет стоить немалых денег, а возможно, и обойдется вашей компании в целое состояние. Именно поэтому наша команда Wirex R&D хочет поделиться своим опытом внедрения системы мониторинга для Microsoft Azure, которая охватывает большое количество метрик, поддерживает кастомизацию и при этом позволяет оставаться эффективным инструментом для ежедневного использования.

Для лучшего понимания наших целей, следует также сказать пару слов о самом продукте.

Мы используем облачные ресурсы от Microsoft Azure для хостинга нашей платформы. Инфраструктура сложная и многокомпонентная, с тысячами транзакций и миллионами ивентов каждый день. Как финтех-продукт с более 3,5 млн клиентов, наша платформа использует криптовалюты в дополнение к традиционным деньгам. Поэтому мы не можем позволить себе, чтобы клиенты испытывали какие-либо трудности во время совершения платежей или задержки при обмене валют. Это создает определенные риски и проблемы, а также формирует особые требования к системе мониторинга, поскольку она должна быть более продвинутой и динамичной.

Какие проблемы мы пытались решить с внедрением системы мониторинга для Microsoft Azure

Основные цели:

• Мультикомпонентный мониторинг. Сбор и покрытие метриками максимального количества критически важных компонентов инфраструктуры.
• Мониторинг virtual machines scale sets (VMSS), (далее — скейл сетов). Скейл сеты — составляющая часть кластера Service Fabric. Без их должного мониторинга у нас отсутствует полноценный мониторинг кластера.

• Мониторинг микросервисов. Наша платформа и продукт состоят из множества отдельных сервисов, которые взаимосвязаны между собой и работают в кластере как единое целое. К сожалению, стандартная система мониторинга Microsoft Azure не предоставляет возможности мониторить микросервисы. А это — достаточно критический момент, поскольку нам необходимо знать, что происходит с нашими микросервисами еще на этапе разработки и тестирования.
• Возможность «непрерывной доставки» системы мониторинга. Падение или длительное обновление новой конфигурации системы мониторинга влечет за собой незнание реальной картины происходящего, будь-то на уровне приложения или инфраструктуры, поэтому максимально быстрый процесс деплоймента здесь очень важен. Именно простота, скорость и регулярность автоматического деплоя взята в данном случае за основу подхода «непрерывной доставки».
• Alerts. Наша цель — получать алерты по всем критически важным ресурсам и метрикам.

Прежде чем продолжить, давайте рассмотрим с чем мы имеем дело:

• Более 150 скейл сетов, в нашем случае, один сет может включать до 25 виртуальных машин.
• Более 1000 баз данных (далее — БД).
• Более 150 виртуальных машин.
• 12 активных Azure Service Fabriс окружений.
• Более 50 приложений и более 370 микросервисов в каждом окружении.

Мы ставим себе цель, мониторить каждое окружение, каждый сет и получать метрики по каждому микросервису.

Какие инструменты можно использовать для мониторинга инфраструктуры в Microsoft Azure

Начнем с самого начала — что предлагает Microsoft «из коробки». Это Azure Monitor, благодаря которому можно получить множество различных инсайтов — Applications, Storage Accounts, VM, Key Vaults, Network, SQL, также есть возможность настроить алерты. Кроме того, сервис предоставляет опцию конфигурации автоматического уведомления по статусам ресурсов и отправку уведомлений на почту или мессенджер.

В целом, Microsoft предлагает гораздо больше, но мы не будем описывать все доступные инструменты. Главное, что нужно подчеркнуть, — мы все еще не можем получить всю необходимую нам информацию, включая детали по микросервисам и скейл сетам.

Помимо Azure Monitor, у нас также используются дополнительные сервисы для мониторинга инфраструктуры:

• Grafana —наш основной инструмент для визуализации метрик;
• Prometheus;
• Splunk — используется в качестве лог-аналитики и для работы с Big Data;
• Интеграция с Azure Monitor — при помощи нее мы можем выводить метрики с Azure Monitor по достаточно большому количеству ресурсов, за исключением скейл сетов;
• ELK;

Что мы мониторили до начала имплементации системы мониторига скейл сетов и микросервисов

Благодаря интеграции Grafan’ы с Azure Monitor мы получили возможность вывести все желаемые метрики по Application Insights, метрики по Azure Cache for Redis, базам данных, виртуальным машинам, Storage Accounts и т.д. У нас был реализован мониторинг Key Vaults, включая мониторинг статусов сертификатов. Ниже приведен лишь краткий обзор того, что мы визуализировали и настроили в Grafana.

Но, к сожалению, данная интеграция не дает возможности вывести информацию, по скейл сетам, не говоря уже о состоянии микросервисов.

Решение проблемы с помощью имплементации Prometheus

Как работает Prometheus

Согласно официальной документации, Prometheus собирает метрики, публикуемые удаленными агентами, напрямую или через промежуточный push-gateway. Всю собранную информацию сервис хранит локально, но также есть возможность использования удаленного хранилища. Далее Prometheus применяет правила для собранных данных — они либо агрегируются и к ним записываются новые данные, либо генерируются алерты. Также данные могут передаваться и сторонним сервисам, например, таким как Grafana для последующей визуализации всей собранной информации.

Источник

Одно из преимуществ Prometheus, по нашему мнению, заключается в поддержке как локальной time series database (TSDB), так и удаленной системы хранения данных. Наличие локальной БД может положительно сказаться на изначальной и последующих этапах деплоя системы, а также может снизить риск сбоя при подключении и увеличить скорость за счет «прямых» обращений к БД.

Также, большой плюс в том, что Prometheus при правильной интеграции с Azure, позволяет автоматически обнаруживать Azure ресурсы, как старые, так и новосозданные, в том числе и скейл сеты.

Преимущество этого подхода заключается в том, что обычно, при использовании стандартной конфигурации Prometheus, вы прописываете таргеты для каждого мониторинг-ресурса отдельно, используя IP-адрес и имя. Но представьте инфраструктуру с более чем 150 скейл сетами и 25 виртуальных машин в каждом. Изменения и поддержка такой конфигурации в актуальном состоянии может показаться сложной задачей, если еще и учесть масштабируемость данного ресурса.

Помимо прочего, в Prometheus используется свой язык запросов PromQL, который позволяет кастомизировать запросы для последующего вывода только необходимой информации.

Вот краткий список основных преимущества Prometheus:

• Open-Source продукт;
• Поддержка быстрого и надежного деплоймента через контейнерную инфраструктуру;
• Автоматическое обнаружение Azure ресурсов;
• Embedded TSDB;
• PromQL;

Windows Exporter и мониторинг микросервисов

Windows Exporter — инструмент, разработанный сообществом Prometheus и предназначений для сбора информации о системе.

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

Так мы получаем информацию по таким метрикам системы, как сервисы, CPU, память, операции ввода-вывода, сети, диски, активные подключения и многое другое.

Самое важное в этом списке — вывод информации по процессам, который позволяет активно мониторить состояние микросервисов и очень гибко настроить оповещения в случае возникновения каких-либо системных инцидентов.

Настройка деплоймента конфигураций системы и установка Windows Exporter

Для этого мы используем Terraform, PowerShell DSC и Chocolatey. Пару слов о каждом инструменте:

• Terraform — «Infrastructure as a code» инструмент для создания, управления и конфигурации облачной инфраструктуры, в нашем случае в Azure.
• PowerShell DSC — это встроенная в Windows платформа управления конфигурациями, основанная на открытых стандартах.
• Chocolatey (choco) — по-моему, самый известный менеджер пакетов для Windows.

Мы подключаем PowerShell DSC в виде расширения виртуальной машины, где описана желаемая конфигурация системы, в том числе, и установка Windows Exporter’а с помощью choco. Операцию подключения мы применяем с помощью Terraform. Использование Infrastructure as Code сильно играет на руку, поскольку применять данную конфигурацию приходится более чем на 150 скейл сетах.

Важно также упомянуть, что нам пришлось частично переписать базовую конфигурацию choco и использовать локальный репозиторий для хранения и управления всеми пакетами этого инструмента. Это было сделано, чтобы обойти стандартное ограничение choco на одновременную выгрузку большого количества пакетов Windows Exporter’а с официального репозитория.

Использование Terraform, PowerShell DSC и Chocolatey позволяет гибко и эффективно управлять всей инфраструктурой и ресурсами Azure. Данный подход также реализует концепцию непрерывного управления конфигурацией для всех скейл сетов. При этом мы избавляемся от всех несогласованных конфигураций, и получаем полностью консистентное окружение, что так важно при использовании методологии DevOps.

Как выглядит мониторинг наглядно?

С левой стороны представлен кластер Service Fabric в виде пунктира, который состоит из ряда скейл сетов. На каждом скейл сете установлен и запущен Windows Exporter, а также микросервисы приложений.

Также имеется по два блока с правой стороны, первый — сервер Prometheus с TSDB, второй — сервер Grafana с подключенными источниками данных. В этом примере источником данных выступает сервер Prometheus.

Как происходит взаимодействие Windows Exporter’а с Prometheus? Exporter запущен как Windows — сервис c предварительно заданными параметрами, такими как список собираемых метрик, открытый TCP (порт сервиса по умолчанию 9128) и т.д. Prometheus считывает и забирает (scrape) публикуемые exporter’ом данные по HTTP с определенными временными интервалами. Они могут составлять, например, 5,10,15 секунд. Меньший интервал даст более детальную картину происходящего, но в то же время значительно увеличит нагрузку и размер базы данных. Этот момент стоит учесть во время проектирования системы с учетом retention policy.

Стоит также учесть возможность изолирования системы мониторинга в отдельную сеть, что предоставит повышенную безопасность путем более гибкого контроля доступов системы к источникам данных и к самой системе в целом.

Отдельное внимание также стоит уделить Grafana, которая использует базу данных Prometheus как источник для построения и визуализации всей собранной информации.

Настройка «непрерывной доставки» системы мониторинга

Для этого мы используем репозиторий, TeamCity и Ansible:

• TeamCity — билд-сервер для обеспечения непрерывных интеграций и развертывания.
• Ansible — agentless cистема управления конфигурациями.

Для настройки пайплайна мы использовали репозиторий с Ansible-плейбуками, в которых описывается детальный процесс установки и настройки Prometheus в виде Docker контейнера. TeamCity, который мы используем в качестве основного инструмента для непрерывной интеграции, в данном примере используется для запуска билд конфигураций. А именно для проверки более актуальных плейбуков в репозитории, их выгрузки и передачи в работу Ansible. Ansible выступает в роли инструмента для сборки Prometheus или Grafana-контейнеров. Стоит также упомянуть, что Ansible может быть сконфигурирован и как отдельный инстанс, так и в виде TeamCity-плагина. Возможен любой вариант.

Таким вот нехитрым образом можно реализовать свой пайплайн автоматизации процесса деплоя или обновление системы мониторинга. В итоге мы значительно экономим время: на один из процессов уходит менее 20 секунд.

Что в результате мы получили?

Благодаря данному подходу конфигурирования Grafana и Prometheus, мы получаем все желаемые метрики по всем окружениям Service Fabric-кластера, скейл сетам и микросервисам.

Мы отслеживаем около 370 микросервисов в реальном времени в каждом окружении, от разработки до продакшена. У нас появилось реальное представление происходящего в удобном для нас виде, с дополнительной кастомизацией и интеграцией в виде бонуса.

Мы не беспокоимся о постоянном отслеживании изменений, связанных с масштабированием скейл сетов и обновлении конфигурации Prometheus и Grafana. Поскольку этот подход реализует динамическое исключение старых скейл сетов и мониторинг исключительно актуальных.

Также, использование единой PowerShell DSC конфигурации, исключает неконсистентность всех окружений и гибкий сетап приложений с использованием локального репозитория. Поэтому сетап Windows Exporter’а и сбор метрик по всем микросервисам на новых скейл сетах полностью автоматизирован и происходит без каких-либо дополнительных манипуляций с нашей стороны.

Кроме того, у нас есть отлично настроенный алертинг, и мы получаем оповещения о большом количестве событий по многим ресурсам Microsoft Azure.

Надеюсь, что смог максимально детально раскрыть главный смысл использования описанных инструментов и технологий.