В данном техническом обзоре мы детально познакомимся с продуктом 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 приложения на карте инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дашборд endpoint KPI
Дашборд endpoint KPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мониторинг Kubernetes

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

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

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

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

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

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

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

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

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

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

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

График количества вызовов, сгруппированных по endpoint name
График количества вызовов, сгруппированных по 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 приложения
Метрики Spring Boot приложения

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

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

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

Метрики JVM
Метрики JVM

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

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

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

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

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

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

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

Раздел 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 для контроля производительности приложений у реальных пользователей в браузерах и в нативных мобильных приложениях.

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