05.11.2020 12:48
vlstrochkov 2 2600 Источник

В преддверии старта профессионального курса «Мониторинг и логирование: Zabbix, Prometheus, ELK», подготовили для вас интересный перевод, а также предлагаем посмотреть демо-урок по теме: «Prometheus как новый виток систем мониторинга».

Введение

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

Вы очень довольны и все идет по плану. Вы создаете свой первый кластер Kubernetes (у всех основных облачных провайдеров: Azure, AWS и GCP, — есть простые решения для провиженинга управляемого или неуправляемого Kubernetes), разрабатываете первое контейнерное приложение и развертываете его в кластере. Это было легко, не так ли?

Через некоторое время вы понимаете, что все становится немного сложнее: вам нужно развернуть в кластере несколько приложений, поэтому вам нужен Ingress Controller. Далее вы хотите мониторить нагрузку, поэтому вы начинаете искать решения для этого и, к счастью, находите Prometheus. Разворачиваете его, добавляете Grafana и все!

Позже вы начинаете задаваться вопросом: "Почему Prometheus работает только с одной репликой"? Что произойдет в случае рестарта контейнера? Что будет при простом обновлении версии? Как долго Prometheus может хранить метрики? Что если кластер развалится? Нужен ли еще один кластер для HA и DR? Как мне получить единое представление метрик со всех серверов Prometheus? 

Что ж, продолжайте читать, умные люди уже разобрались с этими вопросами.

Типичный кластер Kubernetes

На диаграмме ниже показано типичное развертывание с использованием Kubernetes.

Типичный кластер Kubernetes
Типичный кластер Kubernetes

Развертывание состоит из трех уровней:

  1. Виртуальные машины: master-ноды и worker-ноды.

  2. Инфраструктурные компоненты Kubernetes.

  3. Пользовательские приложения.

Внутри кластера компоненты взаимодействуют друг с другом обычно через HTTP(s) (REST или gRPC), но некоторые из них предоставляют доступ к API снаружи (Ingress). Эти API в основном используются для следующего:

  1. Управление кластером через Kubernetes API Server.

  2. Взаимодействие с пользовательскими приложениями через 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

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

Мы начнем с развертывания Thanos Sidecar в тех же кластерах Kubernetes, которые мы используем для пользовательских приложений, Prometheus и Grafana.

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

Самый простой способ установки Prometheus-Operator — это использовать его Helm чарт, у которого есть встроенная поддержка высокой доступности, Thanos Sidecar и множество преднастроенных алертов для мониторинга кластерных виртуальных машин, инфраструктуры Kubernetes и ваших приложений.

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

Для демонстрации я буду использовать Microsoft Azure.

Создайте account для blob-хранилища:

az storage account create --name <storage_name> --resource-group <resource_group> --location <location> --sku Standard_LRS --encryption blob

Затем создайте папку (она же container) для метрик:

az storage container create --account-name <storage_name> --name thanos

Получите ключи от хранилища:

az storage account keys list -g <resource_group> -n <storage_name>

Создайте файл с настройками хранилища (thanos-storage-config.yaml):

Создайте Kubernetes Secret:

kubectl -n monitoring create secret generic thanos-objstore-config --from-file=thanos.yaml=thanos-storage-config.yaml

Создайте файл prometheus-operator-values.yaml, в котором переопределите настройки по умолчанию для Prometheus-Operator.

И деплой:

helm install --namespace monitoring --name prometheus-operator stable/prometheus-operator -f prometheus-operator-values.yaml

Теперь у вас должен быть высокодоступный 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:

# public key
openssl pkcs12 -in cert.pfx -nocerts -nodes | sed -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' > cert.key
# private key
openssl pkcs12 -in cert.pfx -clcerts -nokeys | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert.cer
# certificate authority (CA)
openssl pkcs12 -in cert.pfx -cacerts -nokeys -chain | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cacerts.cer

Создайте из этого два Kubernetes Secrets.

# a secret to be used for TLS termination
kubectl create secret tls -n monitoring thanos-ingress-secret --key ./cert.key --cert ./cert.cer
# a secret to be used for client authenticating using the same CA
kubectl create secret generic -n monitoring thanos-ca-secret --from-file=ca.crt=./cacerts.cer

Убедитесь, что у вас есть домен, который резолвится в ваш кластер Kubernetes, и создайте два поддомена, которые будут использоваться для маршрутизации к каждому из Thaos SideCar: 

thanos-0.your.domain
thanos-1.your.domain

Теперь мы можем создать правила Ingress (измените имя хоста):

Теперь у нас есть защищенный доступ к Thanos Sidecars снаружи кластера!

Кластер Thanos

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

Для развертывания компонентов Thanos я решил использовать этот Helm чарт (он пока еще не официальный, но следите за обновлениями, когда примут мой PR).

Создайте файл thanos-values.yaml, чтобы переопределить настройки чарта по умолчанию.

Поскольку для Thanos Store Gateway требуется доступ к blob-хранилищу, мы также создадим секрет хранилища в этом кластере.

kubectl -n thanos create secret generic thanos-objstore-config --from-file=thanos.yaml=thanos-storage-config.yaml

Для развертывания этого чарта мы возьмем те же сертификаты, которые использовали ранее.

helm install --name thanos --namespace thanos ./thanos -f thanos-values.yaml --set-file query.tlsClient.cert=cert.cer --set-file query.tlsClient.key=cert.key --set-file query.tlsClient.ca=cacerts.cer --set-file store.tlsServer.cert=cert.cer --set-file store.tlsServer.key=cert.key --set-file store.tlsServer.ca=cacerts.cer

Это команда установит Thanos Query Gateway и Thanos Storage Gateway, настроив их на использование защищенного канала.

Валидация

Чтобы проверить, все ли работает правильно, вы можете перенаправить порт в HTTP-службу Thanos Query Gateway следующим образом:

kubectl -n thanos port-forward svc/thanos-query-http 8080:10902

После этого откройте браузер по адресу http://localhost:8080, и вы должны увидеть Thanos UI!

Grafana

Для дашбордов вы можете установить Grafana, используя Helm чарт.

Создайте grafana-values.yaml со следующим содержимым:

Обратите внимание, что я добавил к нему три дефолтных дашборда. Вы также можете добавить и свои дашборды (самый простой способ — это использовать ConfigMap).

Затем деплой:

helm install --name grafana --namespace thanos stable/grafana -f grafana-values.yaml

И опять port-forward:

kubectl -n thanos port-forward svc/grafana 8080:80

И… всё! Вы развернули на основе Prometheus высокодоступное решение для мониторинга с долгосрочным хранилищем и централизованным представлением нескольких кластеров!

Другие варианты

Эта статья посвящена Prometheus и Thanos, но если вам не нужен global view для нескольких кластеров, то вы можете использовать только Prometheus с долговременным хранилищем.

Другим вариантом является Cortex — еще одна платформа с открытым исходным кодом, которая немного сложнее, чем Thanos, и использует другой подход.

Интересно развиваться в данном направлении? Запишитесь на бесплатный мастер-класс, в рамках которого эксперты-преподаватели OTUS подробно расскажут о программе обучения и ответят на интересующие вопросы.