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

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

Мыпрошли этот путь больше года назад, когда изучали инструменты, которые стоит использовать вне стандартной связки Prometheus + Grafana. Обзор получился объемным, поэтому разбили надве части.

Архитектура и установка агентов

Архитектурно продукт Instana состоит изсервера иагентов, собирающих данные. Устанавливается один агент нахост, который контролирует сам хост, все контейнеры иприложения, работающие нахосте. Основные данные, которые собирает продукт это метрики приложений иинфраструктурных компонентов (прокси-серверы, СУБД, кэш, очереди итд), трейсы приложений, логи иошибки приложений. Поддерживается 200+ технологий для сбора данных. Помимо этого, впродукте присутствуют модули EUM End User Monitoring для сбора данных производительности сконечных пользователей, взаимодействующих сприложениями через веб-браузеры инативные мобильные приложения для iOS иAndroid.

Сервер Instana backend, накоторый агенты отсылают данные, предоставляется помодели SaaS, атакже доступен вварианте on-premise для компаний, нежелающих использовать облачную модель размещения.

Мониторинг микросервисных приложений начинается сустановки агента Instana. Агент устанавливаются одной командой. Вразделе установки мывыбираем нужную нам платформу, идалее генерируется скрипт для его установки. Среди поддерживаемых агентом платформ есть Linux, Unix, Windows, Kubernetes всех мастей иоблачные среды AWS, Azure иGoogle Cloud.

Мастер выбора платформы и варианта установки агента

Наскриншоте представлен один извариантов установки агента вKubernetes кластер helm chart. Также можно установить агента спомощью Kubernetes Operator или daemonset.yaml. После того, как агенты установятся внаш кластер, мысможем посмотреть накарту нашей инфраструктуры вInstana.

Первое знакомство с продуктом Infrastructure Map

Карта объектов инфраструктуры

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

Каждая башня нанашей карте инфраструктуры представляет хост, вданном случае, ноду Kubernetes кластера. Аналогично будут представлены просто машины, неотносящиеся ккластеру. Внутри каждой башни мывидим этажи или, как ихназывают всамой Instana, коробки отпиццы это текомпоненты, которые были автоматически обнаружены намашине контейнеры, приложения, базы данных, прокси серверы, очереди, балансировщики, процессы итд.

Внашем случае мывидим, что агент обнаружил Docker контейнеры, Node.JS приложения, MongoDB, SpringBoot Java приложения иеще много других компонентов.

Свойства выбранного Node.JS приложения на карте инфраструктуры

Выбрав одну из коробок от пиццы мы получаем сводную информацию об этом компоненте. Выбрав Node.JS приложение shop-frontend мы видим версию приложения, ID процесса, аргументы запуска и другую информацию. Для детального анализа компонента по клику доступен дашборд с инфраструктурными метриками, но мы поговорим об этом позже. Также мы видим полную инфраструктурную географию этого компонента указание на детали расположения компонента в инфраструктуре. В нашем случае Node.JS приложение связано с процессом node, процесс находится в контейнере, контейнер в k8s поде, под находится на ноде k8s, а нода k8s обслуживается хостом. Для каждого из этих уровней доступны свои собственные дашборды и соответствующие метрики.

Свойства выбранного Docker контейнера на карте инфраструктуры

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

Карта инфраструктуры с контейнерами, сгруппированными по Kubernetes namespace

Автоматический распределенный трейсинг гетерогенных приложений

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

С точки зрения трейсинга продукт поддерживает следующие языки разработки и технологии:

Технологии, поддерживаемые в Instana с точки зрения трейсинга

Давайте посмотрим на обнаруженные сервисы в нашем случае. Сервис в данном контексте это https/grpc сервисы приложения, база данных, очередь сообщений, CLI скрипт, кэш и другие системы.

Для этого перейдем в раздел Applications на вкладку Services где мы видим все наши сервисы и их основную информацию - имя и тип сервиса, количество обнаруженных endpoints и ключевые метрики - количество вызовов, время исполнения и процент ошибок.

Список обнаруженных сервисов

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

Карта взаимодействия сервисов

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

Карта взаимодействия сервисов, выбор сервиса

Управление группами сервисов

С приходом микросервисов стало сложно определять, что именно теперь называть приложением. Ведь в одно приложение могут входить десятки разных сервисов, причем один и тот-же сервис может быть частью двух и более разных приложений. Как раз для логического разделения сервисов на приложения в продукте используется Application Perspective группа логически объединенных по какому-то критерию сервисов.

Группы сервисов - Application Perspective

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

Настройка Application Perspective и критерии объединения сервисов

Например, мы можем сгруппировать сервисы по окружениям - production, stage, dev, test. Можем сгруппировать по Kubernetes namespace или deployments, по тегам, по продукту, команде и так далее. После создания Application Perspective сервисы сгруппируются по указанным параметрам и, в случае появления нового сервиса с параметрами, подходящими под настроенные критерии, сервис автоматически добавится в заданную группу.

По каждому приложению (Application Perspective), которых мы можем создать неограниченное количество, мы получаем готовый дашборд с метриками всех входящих в это приложение сервисов. Это позволяет посмотреть на карту взаимосвязей и метрики именно отфильтрованных сервисов приложения.

Дашборд KPI приложения (группы сервисов)

В Instana Application Perspectives используются для анализа KPI на дашбордах, ролевого управления доступом, алертинга, фильтрации данных на многих экранах. Функционал Application Perspectives позволяет различным командам разработки и эксплуатации эффективно фокусироваться на своих участках и не мешать друг другу.

Анализ KPI сервисов и endpoints

Мы уже увидели карту взаимосвязи сервисов, возможности их группировать, но часто нам нужно проанализировать ключевые метрики производительности одного конкретного сервиса. В Instana для каждого обнаруженного сервиса создается дашборд с ключевыми метриками и данными о связанных объектах инфраструктуры.

Мы переходим на такой дашборд просто выбрав интересующий нас сервис на карте сервисов или в списке. Давайте посмотрим на сервис eum-shop это HTTP сервис Spring Boot приложения.

Дашборд KPI сервиса

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

Список обнаруженных endpoint у сервиса, в данном случае он один

Аналогично представлен дашборд с метриками производительности каждого endpoint для сфокусированного анализа.

Дашборд endpoint KPI

Интеграция с CI/CD маркеры релизов в графиках мониторинга

Когда мы анализируем метрики производительности сервисов и видим деградацию в производительности рост процента ошибок, увеличение времени исполнения важно знать, а не связано ли это с выпуском нового релиза? Для визуализации такой информации предусмотрена возможность сообщать в Instana о том, что был сделан релиз приложения или какого-то одного сервиса, сделав простой вызов к API, например, из CI-пайплайна.

Маркер релиза на дашборде сервиса

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

Список недавних релизов для анализа производительности

Инфраструктурный контекст и взаимосвязь сервисов

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

На вкладке Upstream, мы видим все сервисы, которые вызывают сервис eum-shop, и их ключевые метрики.

Upstream сервисы и их метрики - кто обращается к eum-shop

Аналогично в Downstream мы видим все сервисы, которые вызывает сервис eum-shop, и их ключевые метрики - обычно это не только http сервисы, но и базы данных, кэш, очереди и тд..

Downstream сервисы и их метрики - к кому обращается eum-shop

Instana не только определяет связи сервисов между собой, но и связи с компонентами инфраструктуры. Эта информация доступна по клику кнопки Stack.

Связь сервиса с объектами инфраструктуры

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

Перейдя на вкладку Kubernetes мы увидим сущности Kubernetes, с которыми связан наш сервис pod, Kubernetes service, namespace, deployment, node.

Связь сервиса с объектами Kubernetes

Перейдя на вкладку Application мы увидим группы приложений, в которые входит анализируемый сервис (как мы помним один сервис может входить в несколько приложений) и их сводные KPI.

Связь сервиса с приложениями

Нам доступен drill down на дашборды связанных компонентов для детального анализа их производительности. Давайте проанализируем наш Kubernetes кластер.

Мониторинг Kubernetes

Instana очень тесно интегрируется с Kubernetes и собирает все ключевые метрики и данные нашего кластера. Для анализа Kubernets представлен отдельный дашборд, где мы можем наблюдать метрики всего кластера, по нодам, подам, namespace, deployments, k8s сервисам и так далее.

Дашборд Kubernetes кластера

Перейдя ко вкладке Namespaces мы обнаруживаем список всех Namespace с их основными метриками.Выбрав интересующий нас namespace мы можем более подробно его изучить какие поды, какие сервисы, какие deployments связаны с этим namespace.

Дашборд одного из Kubernetes namespace

Инфраструктурные метрики Kubernetes уже есть в Prometheus + Grafana, но с помощью Instana мы получили связь еще и трейсов с сущностями Kubernetes. C Kubernetes дашборда мы переходим к анализу вызовов, которые были в этом namespace. Кликнув на кнопку Analyze calls мы попадем в новый раздел - раздел Аналитика.

Раздел Аналитика

Раздел Аналитика с группировкой вызовов по Kubernetes Service и KPI

В разделе Аналитика нам сразу доступны данные и метрики всех вызовов, которые были отфильтрованы по нашему namespace robot-shop и сгруппированы по Kubernetes сервисам. В этом разделе доступен анализ всех вызовов, выбор и визуализация метрик, отображение диаграмм для верхнеуровнего анализа. При необходимости можно очень гибко отфильтровать и отсортировать вызовы и трейсы, чтобы найти именно нужный.

Давайте сгруппируем наши вызовы по имени endpoint:

Группировка вызовов по одному из тэгов - названию endpoint

И посмотрим на графике к каким endpoints больше всего идет вызовов.

График количества вызовов, сгруппированных по endpoint name

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

Список вызовов по заданным фильтрам и их длительность

Как мы видим, у нас применился новый фильтр endpoint.name. Но в данном случае нас интересуют только вызовы с ошибкой. Одним кликом мыши добавляем фильтр erroneous = true для получения всех вызовов с ошибкой - Instana записывает каждый вызов и все они доступны для анализа.

Список вызовов, содержащих ошибку и их длительность

Выбрав из списка интересующий нас вызов, мы попадаем на экран детального анализа трейса для анализа причины ошибки.

Детальный анализ трейсов

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

Детальный анализ трейса

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

Дерево вызовов - последовательность спанов в трейсе и их данные

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

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

Связь спана с объектами инфраструктуры

Анализ инфраструктурных метрик

Перейдя к Spring Boot приложению мы попадаем на соответствующий дашборд с метриками Spring Boot. Instana автоматически собирает ключевые метрики с более чем 200 технологий, например, nginx, redis, postgresql, mysql, rabbitmq, elasticsearch, kaffka, Docker, IIS, Tomcat и многих других. Для каждой из технологий доступен автоматически настроенный дашборд.

Метрики Spring Boot приложения

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

Расположение приложения в инфраструктуре

Например, анализируя метрики Spring Boot приложения нам может быть удобно сразу посмотреть метрики JVM, в которой запущено наше приложение информация о threads, heap memory, memory pools, garbage collection и другие:

Метрики JVM

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

Метрики машины

Алертинг и выявление аномалий

Из коробки мы получили более 230 правил для определения состояния здоровья различных компонентов инфраструктуры и обнаружения аномалий в KPI сервисов и endpoints. Для каждого сервиса и каждого endpoint Instana определяет нормальное поведение KPI метрики (baseline) и, в случае отклонения от baseline, мы получим соответствующие оповещение.

Список правил алертинга и выявления аномалий

Можно добавлять свои собственные правила. В качестве критерия могут быть метрики объектов инфраструктуры, Kubernetes, приложений и сервисов, пользовательского опыта.

Все что относится к результатам мониторинга состояния здоровья, мы можем увидеть в разделе Events.

Раздел Events - сработавшие правила

В Instana существует несколько типов событий:

• Changes изменения компонентов инфраструктуры. Мы видим события онлайн/офлайн компонентов (включение и отключение процессов, контейнеров и тд), были ли изменения в конфигурации компонента.

• Issue сработало правило определения состояния здоровья. Правила могут быть как встроенные, так и созданные самостоятельно.

• Incidents события самого высокого уровня, которые открываются, когда проблемой затронуты наши конечные пользователи или возникла критичная проблема в нашей инфраструктуре. В инцидент объединяются и коррелируются все сопутствующие события на основе анализа графа связей сервисов и компонентов инфраструктуры.

Перейдя ко вкладке Incidents мы увидим все инциденты.

Инциденты

И кликнув на один из них, мы сможем детально его проанализировать.

Детали одного из инцидентов

Что мы видим в инциденте? Время начала и завершения инцидента, сколько событий с ним связано (15), сколько было затронуто компонентов инфраструктуры и сервисов (5) и сами события. Давайте разберемся, с чего начался наш инцидент.

Детали одного из событий в инциденте

Началось все с того, что на сервисе catalogue-demo резко увеличилось количество вызовов с ошибками. В деталях события мы получили говорящую подсказку This can be a sign of a problem on one side of the connection. На графике метрики рейт ошибочных вызовов, которая связана с этим событием, мы видим, что у нас 60% вызовов вдруг стали содержать ошибки. Прямо отсюда мы можем перейти к анализу вызовов в разделе Аналитика, где будут автоматически применены все фильтры, связанные с этим событием вызовы будут отфильтрованы по сервису catalogue-demo и добавлен фильтр erroneous.

Что случилось дальше? За счет того, что Instana определила взаимосвязи сервисов и компонентов инфраструктуры, мы можем увидеть, как проблема на одном сервисе, затронула другие сервисы. Мы видим список других сервисов и компонентов инфраструктуры и их проблемы на одних резко уменьшилось количество вызовов, на других также увеличился процент ошибок, на третьих увеличилось среднее время транзакций.

Список событий в инциденте и его причина

В расследуемом инциденте есть событие Abnormal termination процесса базы данных MySQL. Собственно это и есть причина нашего инцидента.

На этот инцидент мы получили одно оповещение от Instana, так как продукт понял, что эти проблемы связаны, вместо получения на каждое событие по каждому из 5 сервисов отдельного алерта. Такая автоматическая группировка помогла нам избежать шума в оповещениях.

С точки зрения каналов оповещения, то есть того, куда мы можем получать алерты, помимо самого интерфейса продукта, доступны следующие варианты:

Список каналов для отсылки оповещений

Что мы получили в итоге

Подведем промежуточные итоги первой части обзора. С помощью Instana мы смогли:

• наблюдать всегда актуальную картину нашей инфраструктуры и взаимосвязи всех микросервисов между собой;

• без каких-либо усилий по настройке собрать и использовать метрики со всех компонентов, таких как JVM, Node JS приложение, Nginx, Redis, Postgresql, сами Docker контейнеры, кластер и все сущности Kubernetes;

• автоматически получить распределенный трейсинг для PHP, Python, Node JS, Java и других сервисов;

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

Микросервисное приложение, которое использовалось в этом обзоре, вы можете запустить самостоятельно: https://github.com/instana/robot-shop

Для изучения продукта Instana на собственной инфраструктуре доступен бесплатный триальный период: https://www.instana.com/trial/

В следующей части обзора Instana мы рассмотрим функционал End User Monitoring для контроля производительности приложений у реальных пользователей в браузерах и в нативных мобильных приложениях.

Спасибо за внимание.