В преддверии старта профессионального курса «Мониторинг и логирование: Zabbix, Prometheus, ELK», подготовили для вас интересный перевод, а также предлагаем  посмотреть демо-урок по теме: «Prometheus как новый виток систем мониторинга». Поздравляем! Вам удалось убедить ваше начальство в миграции приложений на микросервисную архитектуру с использованием контейнеров и Kubernetes. Вы очень довольны и все идет по плану. Вы создаете свой первый кластер Kubernetes (у всех основных облачных провайдеров: Azure, AWS и GCP, — есть простые решения для провиженинга управляемого или неуправляемого Kubernetes), разрабатываете первое контейнерное приложение и развертываете его в кластере. Это было легко, не так ли? Через некоторое время вы понимаете, что все становится немного сложнее: вам нужно развернуть в кластере несколько приложений, поэтому вам нужен Ingress Controller. Далее вы хотите мониторить нагрузку, поэтому вы начинаете искать решения для этого и, к счастью, находите Prometheus. Разворачиваете его, добавляете Grafana и все! Позже вы начинаете задаваться вопросом: "Почему Prometheus работает только с одной репликой"? Что произойдет в случае рестарта контейнера? Что будет при простом обновлении версии? Как долго Prometheus может хранить метрики? Что если кластер развалится? Нужен ли еще один кластер для HA и DR? Как мне получить единое представление метрик со всех серверов Prometheus?  Что ж, продолжайте читать, умные люди уже разобрались с этими вопросами. На диаграмме ниже показано типичное развертывание с использованием Kubernetes. Развертывание состоит из трех уровней: Виртуальные машины: master-ноды и worker-ноды. Инфраструктурные компоненты Kubernetes. Пользовательские приложения. Внутри кластера компоненты взаимодействуют друг с другом обычно через HTTP(s) (REST или gRPC), но некоторые из них предоставляют доступ к API снаружи (Ingress). Эти API в основном используются для следующего: Управление кластером через Kubernetes API Server. Взаимодействие с пользовательскими приложениями через Ingress Controller. В некоторых сценариях приложения могут отправлять трафик за пределы кластера для использования сторонних сервисов, таких как Azure SQL, Azure Blob или любых других. Мониторинг Kubernetes должен включать в себя все три уровня, упомянутые выше. Виртуальные машины. Для того чтобы убедиться, что виртуальные машины исправны, необходимо собирать следующие метрики: Количество узлов. Утилизация ресурсов на узле (процессор, память, диск, пропускная способность сети). Состояние узла (работает, не работает и т.п.). Количество подов, работающих на каждом узле. Инфраструктура Kubernetes. Для того чтобы убедиться в работоспособности инфраструктуры Kubernetes необходимо собирать следующие метрики: Состояние подов — ready (сколько реплик доступно), status, restarts (количество рестартов), age (сколько времени приложение запущено). Статус развертываний (Deployments) — desired (целевое количество реплик), current (текущее количество реплик), up-to-date (сколько реплик обновлено), available (сколько реплик доступно), age (сколько времени приложение запущено). Статус StatefulSets. Статистика выполнения CronJobs. Использование ресурсов подом (процессор и память). Проверки работоспособности (Health checks). События Kubernetes. Запросы к API-серверу. Статистика Etcd. Статистика смонтированных томов. Пользовательские приложения.  Каждое приложение должно предоставлять собственные метрики, основанные на его функциональности. Однако для большинства приложений есть общие метрики, такие как: HTTP-запросы (общее количество, задержка, код ответа и т. д.). Количество исходящих соединений (например, с базой данных). Количество потоков. Сбор метрик, упомянутых выше, позволит вам создавать осмысленные алерты и дашборды, о чем мы кратко поговорим далее.  Thanos — это проект с открытым исходным кодом, на основе которого можно построить высокодоступную систему сбора метрик с неограниченным размером хранилища, бесшовно интегрирующуюся с существующими экземплярами Prometheus. Для хранения исторических данных Thanos использует формат хранения Prometheus и может хранить метрики в любом объектном хранилище. Кроме того, он обеспечивает global view для всех экземпляров Prometheus. Основные компоненты Thanos: Sidecar. Подключается к Prometheus и использует его для запросов в реальном времени через Query Gateway и/или загружает его данные в облачное хранилище для длительного хранения. Query Gateway. Реализует Prometheus API для агрегирования данных из нижележащих компонент (таких как Sidecar или Store Gateway). Store Gateway. Предоставляет доступ к содержимому облачного хранилища. Compactor. Делает уплотнение и даунсэмплинг (downsampling) данных в облачном хранилище. Receiver. Получает данные из remote-write WAL Prometheus, предоставляет их и/или загружает в облачное хранилище. Ruler. Вычисляет recording rules и alerting rules для данных в Thanos. В этой статье мы сосредоточимся на первых трех компонентах. Мы начнем с развертывания Thanos Sidecar в тех же кластерах Kubernetes, которые мы используем для пользовательских приложений, Prometheus и Grafana. Есть много способов установки Prometheus, но я предпочитаю использовать Prometheus-Operator, который предоставляет настройки для мониторинга сервисов и развертываний Kubernetes, а также для управления экземплярами Prometheus. Самый простой способ установки Prometheus-Operator — это использовать его Helm чарт, у которого есть встроенная поддержка высокой доступности, Thanos Sidecar и множество преднастроенных алертов для мониторинга кластерных виртуальных машин, инфраструктуры Kubernetes и ваших приложений. Перед развертыванием Thanos Sidecar нам нужен Kubernetes Secret с информацией о том, как подключиться к облачному хранилищу.  Для демонстрации я буду использовать Microsoft Azure.  Создайте account для blob-хранилища: Затем создайте папку (она же container) для метрик: Получите ключи от хранилища: Создайте файл с настройками хранилища (thanos-storage-config.yaml): Создайте Kubernetes Secret: Создайте файл prometheus-operator-values.yaml, в котором переопределите настройки по умолчанию для Prometheus-Operator. И деплой: Теперь у вас должен быть высокодоступный Prometheus вместе с Thanos Sidecar, который загружает ваши метрики в Azure Blob Storage с неограниченным сроком хранения. Для того чтобы Thanos Store Gateway предоставить доступ к Thanos Sidecar, нужно выставить его наружу через Ingress. Я использую Nginx Ingress Controller, но вы можете использовать любой другой Ingress Controller, который поддерживает gRPC (возможно, Envoy будет лучшим вариантом). Для защищенного соединения между Thanos Store Gateway и Thanos Sidecar мы будем использовать mutual TLS. То есть клиент будет аутентифицировать сервер и наоборот. Если у вас есть .pfx-файл, то вы можете извлечь из него закрытый, открытый ключ и сертификат с помощью openssl: Создайте из этого два Kubernetes Secrets. Убедитесь, что у вас есть домен, который резолвится в ваш кластер Kubernetes, и создайте два поддомена, которые будут использоваться для маршрутизации к каждому из Thaos SideCar:  Теперь мы можем создать правила Ingress (измените имя хоста): Теперь у нас есть защищенный доступ к Thanos Sidecars снаружи кластера! На диаграмме развертывания Thanos, приведенной выше, вы могли заметить, что я решил развернуть Thanos в отдельном кластере. Это потому что мне нужен выделенный кластер, который можно было бы при необходимости легко воссоздать и предоставить инженерам доступ к нему, а не к продакшену. Для развертывания компонентов Thanos я решил использовать этот Helm чарт (он пока еще не официальный, но следите за обновлениями, когда примут мой PR). Создайте файл thanos-values.yaml, чтобы переопределить настройки чарта по умолчанию.  Поскольку для Thanos Store Gateway требуется доступ к blob-хранилищу, мы также создадим секрет хранилища в этом кластере. Для развертывания этого чарта мы возьмем те же сертификаты, которые использовали ранее. Это команда установит Thanos Query Gateway и Thanos Storage Gateway, настроив их на использование защищенного канала. Чтобы проверить, все ли работает правильно, вы можете перенаправить порт в HTTP-службу Thanos Query Gateway следующим образом: После этого откройте браузер по адресу http://localhost:8080, и вы должны увидеть Thanos UI! Для дашбордов вы можете установить Grafana, используя Helm чарт. Создайте grafana-values.yaml со следующим содержимым: Обратите внимание, что я добавил к нему три дефолтных дашборда. Вы также можете добавить и свои дашборды (самый простой способ — это использовать ConfigMap). Затем деплой: И опять port-forward: И… всё! Вы развернули на основе Prometheus высокодоступное решение для мониторинга с долгосрочным хранилищем и централизованным представлением нескольких кластеров! Эта статья посвящена Prometheus и Thanos, но если вам не нужен global view для нескольких кластеров, то вы можете использовать только Prometheus с долговременным хранилищем. Другим вариантом является Cortex — еще одна платформа с открытым исходным кодом, которая немного сложнее, чем Thanos, и использует другой подход. Интересно развиваться в данном направлении? Запишитесь на бесплатный мастер-класс, в рамках которого эксперты-преподаватели OTUS подробно расскажут о программе обучения и ответят на интересующие вопросы.  CRM/Email-маркетолог