Observability для микросервисных приложений в Kubernetes

Любая распределенная система, например включающая несколько микросервисов со своими источниками данных (и особенно запущенная внутри сложной системы оркестрации, которая сама по сути является распределенным приложением), обладает множеством точек отказа и по мере ее масштабирования и развития становится все сложнее обнаружить проблемы в функционировании (например, долгий ответ одного из микросервисов), которые приводят к общей потере производительности и даже отказам при высокой нагрузке (или при других неудачных стечениях обстоятельств). И даже если обнаружить сам факт наличия проблемы еще возможно через метрики систем мониторинга, наиболее часто для этого используются замеры задержки ответа, интенсивности запросов, операционные метрики насыщенности сервиса (например, отношение одновременно обрабатываемых запросов к лимиту или замеры процессорного время и/или зарезервированной памяти), то выяснить истинную причину возникновения отклонения уже не так просто (например, это может быть неудачная настройка кэшей запросов базы данных или достижения лимита подключений из-за того, что приложение не использует пул и т.д.). Чтобы решить эту задачу используются сочетания инструментов (мониторинг, отслеживание распределенных операций и логирование), которые объединяются в общем подходе Observability. В этой статье мы рассмотрим несколько стеков и инструментов для наблюдения за приложениями в Kubernetes.

Прежде всего обозначим, что подход Observability не является новым и он подразумевает возможность анализа потенциальных внутренних причин событий, обнаруживаемых через внешнее наблюдение за системой. Это означает, что инструментам мониторинга неизвестны подробности взаимодействия микросервисов, но вся информация и выводы делаются на основе временных замеров (в distributed tracing), оценки операционных метрик различных компонентов системы (мониторинг) и соотнесение событий с информацией из логов компонентов (например, обнаружения информации об ошибках, в том числе стеков исключений). По отдельности для каждой из задач есть доступные инструменты (в том числе с открытым исходным кодом) и наиболее часто можно встретить решения:

• мониторинг - Prometheus для накопления данных (использует модель exporter для получения данных из различных приложений, включая базы данных, веб-серверы, серверы приложений и т.д.) и Grafana для визуализации метрик (либо telegraf + influxdb + chronograf или любые другие сочетания инструментов).

• логирование - часто используется стек ELK (ElasticSearch для хранения индексов и поиска по сообщениям, Logstash для извлечения логов из файлов, вывода Docker Engine и др. и дальнейшего извлечения метаданных из сообщений, Kibana - web-интерфейс для удобного поиска по сообщениям, создания информационных панелей и др. В Kubernetes Logstash часто заменяется Fluentd или Filebeat. Также можно использовать Grafana Loki, который также умеет работать с логами и соотносить их по временным меткам с событиями на графике по данным системы мониторинга.

• отслеживание распределенных запросов (distributed tracing) - часто совмещается с API Gateway, который выступает в роли посредника во взаимодействии всех микросервисов, при этом для отслеживания используются дополнительные заголовки с уникальным идентификатором исходного запроса. Здесь может использоваться SigNoz (который также умеет объединять метрики и журналы и выступать в роли инструмента для Observability), Jaeger или Zipkin. Также существует инструмент Grafana Tempo, которая совместима по протоколу с Jaeger и Zipkin и может получать информацию от их агентских библиотек.

Для обеспечения совместимости между инструментами сейчас стал доступен протокол OpenTelemetry, независимый от конкретного поставщика, но при этом обеспечивающий унифицированный механизм обмена данными о логах, метриках и наблюдении за распределенными системами и являющийся основой для реализации Observability. Список поставщиков, которые поддерживают OpenTelemetry уже сейчас включает Grafana Labs и SigNoz и постепенно растет. Также сейчас стало доступным наблюдение за метриками Kubernetes с использованием плагина для containerd, которые можно включить флагом:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletTracing: true
tracing:
  samplingRatePerMillion: 1000000

Для Kubernetes существует несколько решений, обеспечивающих мониторинг за всеми составляющими observability:

• KubeSphere - основан на модели подключаемых компонентов (поддерживает взаимодействие с системами сбора логов (например, ElasticSearch), событий обнаружения аномалий или проблем), позволяет разворачивать системы и компоненты (вместе с необходимым мониторингом) из магазина приложений (например, можно установить Nginx, MySQL, RabbitMQ, MongoDB, PostgreSQL и др.). Также может взаимодействовать с метриками, получаемыми от контроллера кластера Kubernetes. Для установки на Kubernetes используется оператор, который разворачивается из одного yaml-файла. Дальнейшее конфигурирование выполняется с помощью CRD, которые поддерживаются оператором.

• Pixie - sandbox-проект CNCF, позволяет быстро интегрироваться в существующие приложения и предоставляет удобную визуализацию взаимосвязей между сервисами (интегрируется в сетевой стек через использование eBPF). Для развертывания и конфигурации использует утилиту командной строки px, поддерживает работу с логами, данными мониторинга и распределенного отслеживания.

• SigNoz - благодаря поддержке OpenTelemetry этот инструмент также может быть использован для обеспечения Observability. В Kubernetes можно установить SigNoz с использованием Helm.

Также для целей Observability можно использовать инструменты Grafana Labs (Grafana + Loki + Tempo), поскольку они дают возможность навигации между событиями на линии времени, однако все же сейчас возможностей инструмента может оказаться недостаточно для поиска причины исходной проблемы. Аналогично инструменты ElasticSearch + Kibana сейчас также позиционируются как observability, построенной вокруг анализа логов с возможностью визуализации метрик и данных замеров распределенного выполнения (через OpenTelemetry и протоколы Jaeger или Prometheus).

Кстати, прямо сейчас в OTUS заканчивается набор на новый поток курса "Observability: мониторинг, логирование, трейсинг". Если вы заинтересованы в обучении, узнать о курсе можно по ссылке ниже.

• Узнать подробнее о курсе