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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мониторинг Kubernetes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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