[Администрирование баз данных, Microsoft Azure, DevOps, Kubernetes] Мониторинг Kubernetes с помощью Prometheus и Thanos (перевод)

Автор Сообщение
news_bot ®

Стаж: 6 лет 3 месяца
Сообщений: 27286

Создавать темы news_bot ® написал(а)
05-Ноя-2020 18:32
В преддверии старта профессионального курса «Мониторинг и логирование: Zabbix, Prometheus, ELK», подготовили для вас интересный перевод, а также предлагаем посмотреть демо-урок потеме:«Prometheus как новый виток систем мониторинга».
ВведениеПоздравляем! Вам удалось убедить ваше начальство в миграции приложений на микросервисную архитектуру с использованием контейнеров и Kubernetes.Вы очень довольны и все идет по плану. Вы создаете свой первый кластер Kubernetes (у всех основных облачных провайдеров: Azure, AWS и GCP, — есть простые решения для провиженинга управляемого или неуправляемого Kubernetes), разрабатываете первое контейнерное приложение и развертываете его в кластере. Это было легко, не так ли?Через некоторое время вы понимаете, что все становится немного сложнее: вам нужно развернуть в кластере несколько приложений, поэтому вам нужен Ingress Controller. Далее вы хотите мониторить нагрузку, поэтому вы начинаете искать решения для этого и, к счастью, находите Prometheus. Разворачиваете его, добавляете Grafana и все!Позже вы начинаете задаваться вопросом: "Почему Prometheus работает только с одной репликой"? Что произойдет в случае рестарта контейнера? Что будет при простом обновлении версии? Как долго Prometheus может хранить метрики? Что если кластер развалится? Нужен ли еще один кластер для HA и DR? Как мне получить единое представление метрик со всех серверов Prometheus? Что ж, продолжайте читать, умные люди уже разобрались с этими вопросами.Типичный кластер KubernetesНа диаграмме ниже показано типичное развертывание с использованием Kubernetes.
Типичный кластер 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-запросы (общее количество, задержка, код ответа и т. д.).
  • Количество исходящих соединений (например, с базой данных).
  • Количество потоков.
Сбор метрик, упомянутых выше, позволит вам создавать осмысленные алерты и дашборды, о чем мы кратко поговорим далее. ThanosThanos — это проект с открытым исходным кодом, на основе которого можно построить высокодоступную систему сбора метрик с неограниченным размером хранилища, бесшовно интегрирующуюся с существующими экземплярами 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 подробно расскажут о программе обучения и ответят на интересующие вопросы.

===========
Источник:
habr.com
===========

===========
Автор оригинала: Idan Levin
===========
Похожие новости: Теги для поиска: #_administrirovanie_baz_dannyh (Администрирование баз данных), #_microsoft_azure, #_devops, #_kubernetes, #_kubernetes, #_devops, #_grafana, #_thanos, #_monitoring (мониторинг), #_prometheus, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
)
, #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
, #_microsoft_azure, #_devops, #_kubernetes
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 17-Май 09:31
Часовой пояс: UTC + 5