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

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

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

Если компания предоставляет SLA клиентам, обычно при прописывании SLO берутся в расчет установленные показатели SLA. Так как в случае не достижения SLO это напрямую отразиться на SLA, что приведет к определенным последствиям для бизнеса в лице нарушения договорных обязательств перед клиентами или даже штрафам.

В концепции SLI и SLO присутствует индикатор ErrorBudget или, как его иногда называют, право на ошибку. ErrorBudgetэто степень невыполнения наших SLO. Например, если наш SLO учитывает доступность, то error budget это максимальное время, в течение которого наша система может быть недоступной без последствий для нас и нашей команды.

Использование данного показателя упрощает командам процесс контроля времени недоступности приложений/сервисов посредством ввода наглядного индикатора. Устанавливая ErrorBudget, мы ставим для себя цель не выйти за рамки разрешенного нам самим downtime.

Например, если в качестве SLI для одного из наших приложений у нас указана метрика Availability, а в качестве SLO для этого SLI мы указали значение 99,95% в месяц, то наш ErrorBudget за месяц (30 дней) составит 21 минуту 54 секунды. Конкретную цифру ErrorBudget можно не рассчитывать самостоятельно, а воспользоваться готовым калькулятором.

Для анализа текущего положения дел с ErrorBudget с учетом установленного SLO/SLA и среднего показателя Availability на момент расчета, можно использовать вот такой калькулятор.

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

7 последовательных шагов по имплементации SLO

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

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

3. Определяем текущее распределение значений выбранных метрик.
   
   Если вы используете промышленное APM решение, то скорей всего вам уже доступно определение baseline метрик. Например, мы видим, что у транзакции чекаута время исполнения по 90-му перцентилю равняется 110 мс за последние две недели.

4. Определяем SLO, учитывая нормальное поведение выбранных метрик или данных по baseline и устанавливаем Error Budget.

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

   Например, можно установить порог 110 мс по 90-му перцентилю и SLO в 95%. Это будет означать, что мы допускаем 5% времени, в которое время исполнения транзакции по 90-му перцентилю будет выше 110 мс.

5. Прописываем процедуру действий на случай истощения Error Budget

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

   1. Оповещение при превышении Error Budget

   2. Повышение приоритета для команд разработки и DevOps у работ по восстановлению доступности сервиса перед работами по выкатке новых фич на определенный период времени.

   3. Lessons learned, post mortem и другие документы фиксация причин превышения Error Budget в каждом конкретном случае в базу знаний и работа над ошибками.

6. Отслеживаем выполнение установленных нами SLO для соответствующих SLIs во времени.

7. Оцениваем результаты внедрения SLI SLO, как и с любым процессом, следующим логике Plan-Do-Check-Act. Лучше начать с небольшого количества SLO, определить достижимые цели, научиться отслеживать показатели и проводить улучшения постепенно.

А теперь давайте посмотрим, как концепция SLI SLO реализована в инструменте Instana.

Реализация концепции SLO и SLI в Instana

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

ВInstanaопределитьпутипользователяпоприложениюможно с помощьюфункцииApplicationPerspective.Подробнее отом,какещеиспользоватьApplicationPerspective, можно прочитать в нашем посте-Observabilityсистема для микросервисов на примереInstana, часть 1

Для созданияApplicationPerspective перейдем винтерфейсеInstanaкразделуApplication,кликнемнаNewApplicationPerspective.

Впоявившемся окне будутпредложены вариантыApplicationPerspective. Выбрав acriticaluserjourney, мыукажем, какие сервисы иэндпоинтывходятв путь пользователя.А если говоритьпроще то мы определили какие сервисы иэндпоинтывходятв одну из бизнес-транзакций, по которойнеобходимоопределитьSLO.

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

Конфигурация SLI

Создадим новыйкастомныйдашборд.

На которомдобавим SLO виджети выберем созданноеранееApplicationPerspective.

КликнувнаManageSLIперейдемк списку всех доступных индикаторов для выбранногоApplicationPerspective.

ВыбравCreateSLI,мы перейдемксозданиюSLI.

Для создания индикатора:

1. Укажем имя индикатора.

2. Определим тип индикатора:Time-BasedилиEvent-Based.

3. Определимграницыдлявызовов:InboundCallsилиAllCalls.

   1. Inboundcalls:ВсевходящиевызовыврамкахсервисоввходящихвApplicationPerspective.

   2. Allcalls:ВсевходящиевызовыврамкахApplicationPerspectiveиисходящиевызовыизApplication Perspective.

4. Укажем необходимую конфигурацию в зависимости отвыбранноготипа индикатора.

5. СохранимSLIкликнув наCreate.

Time Based SLI

Time-Based индикаторосновываетсяназначенияхвыбраннойметрики (временного ряда). Среди доступных метрик:

• Latency времяисполнения вызовов;

• CallCount количество вызовов;

• Error Rate процент ошибок;

• ErroneousCallsколичество вызовов,содержащихошибку.

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

В процессе установки SLI мы:

• Определяем область действия этого индикатора - можем выбратькакконкретный сервис,так и использоваться все сервисы входящие вApplicationPerspective. Для более детального определения можем указать конкретныйэндпоинтсервиса.

• Выбираемметрику,которая войдет вSLI. Этоможетбыть-Latency, CallCount, ErrorRate, ErroneousCalls.

• Определяем, как будем агрегировать значение метрики: по перцентилям (90, 50, 99ит.д.), по среднему значению, по минимальному или максимальному значению.

• Определяем пороговое значение метрики.

После того, как мы указали метрику и ее пороговое значение,SLIрассчитаетсяпо формуле:

SLI = (1 - #minutes_where_threshold_is_violated / #minutes_in_time_window) * 100%

Посмотрим на примернастройки Time-Basedиндикатора.

Все вызовы сервисаproto.groupдолжныисполнятьсяв среднем не более чем за 25мс.

Event-Based SLI

Event-Based индикатор основывается на хороших и плохих событиях.

Хорошие события- этонабор вызовов, которые указывают на положительное качество работы сервиса, например, 2ххHTTPстатус коды.

Плохие события это набор вызовов, которые указывают на отрицательное качество работы сервиса, например, 5ххHTTPстатус коды.

В ходе настройки Event-Based SLI мы:

• С помощью фильтров определим, какие вызовы указывают наположительное качество работы сервиса;

• С помощью фильтров, определим, какие вызовы указывают наотрицательное качество работы сервиса.

SLIв таком случае рассчитывается по формуле:

SLI= #good_events/ (#good_events+ #bad_events) * 100%

Рассмотрим примернастройки Event-Basedиндикатора.

Мы определили, что хорошие события это все вызовы с 2ххHTTPстатус кодом, а плохие - все вызовы с 5ххHTTPстатус кодом.

SLO отчет

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

На представленном примеревиджетаRobotShopSLO.Мыиспользуемметрику времени исполнения транзакции добавлении товара в корзину, как ключевой индикаторSLI, значение метрики должно не превышать 20мс.

SLOрассматриваем за выбранный промежуток времени 24часа,и намдоступно72 минуты на простой нашего сервиса(ErrorBudget).Надашбордевышемы видим,чтоSLOнарушался 116минутза выбранный промежуток времени, нашErrorBudgetпревышенна44минуты.

Еще пример SLO отчета для Event-Based SLI:

КонфигурацияSLOвиджета

В этом разделе мы расскажем, как создатьSLOWidgetдля любогоApplicationPerspective.

Перейдемна свойкастомныйдашборди добавимSLO виджет, просто кликнув на AddWidget:

В открывшемся окне перейдем на вкладкуSLO и для настройки сделаем следующее:

1. Укажем имя виджета.

2. ВыберемApplicationPerspective/критически важный пользовательскийпуть,по которому нужно задатьSLO

3. Выберем заранее созданный целевой индикаторSLIдля выбранногоApplicationPerspective.

4. Определим цельSLOкоторую нужно достичь

5. Выберемвременной период,за которыйбудетрассчитыватьсяSLO:

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

      

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

   3. FixedtimeintervalSLOбудетрассчитываться за фиксированный период времени с определенной датой начала и длительностью. Например, ежемесячно начиная с2020-01-01.

6. Убедимся, что мы заполнили все необходимые поля конфигурации.Нажав на Highlightmissingconfiguration нам подсветятся все не заполненные поля.

7. Сохраним виджет, нажав на Create

Итоги

Мы настроили SLI и SLO для сервисов, начали с выбора критичного пути пользователя по сайту, определили какие метрики использовать для SLI, указали error budget и настроили виджет, визуализирующий текущий статус SLO. Метрики приложений мы собрали автоматически, путем установки агента, реализующего инструментацию приложений - метрики не потребовалось описывать вручную.

Подробнее про основные возможности observability системы Instana можно почитать в нашем обзоре продукта.

Также приглашаем на наш вебинар, посвященный использованию Instana для мониторинга Kubernetes и снижения MTTR.

Всем привет! Запоследние пять лет мыдостаточно часто сталкивались сзапросами намониторинг Java приложений. Собрав основные моменты помониторингу Java, мырешили написать данный пост.

Сегодня мысвами рассмотрим, что такое full-stack мониторинг ичем онотличается отпривычного уху понятию мониторинга, нюансы full-stack мониторинга для Java исложности мониторинга микросервисных приложений наJava. Расскажем, как мыреализуем full-stack мониторинг спомощью open-source стандартов иплатной платформы.

Full-stack мониторинг

Давайте определимся, что мы называем full-stack мониторингом?

Full-stack мониторинг это подход вмониторинге производительности приложений, который подразумевает под собой мониторинг всего стека, что включает всебя:

• Мониторинг приложений сбор метрик приложения, сбор трейсов транзакций, обеспечение видимости науровне кода ит.д.

• Мониторинг инфраструктуры метрики хостов, процессов, контейнеров ит.д.

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

Основное отличие full-stack мониторинга от привычного мониторинга заключается в том, что, применяя full-stack мониторинг, мы получаем реальное представление о том, как себя "чувствует наше приложение и как его работа влияет на пользовательский опыт, так как видим не просто метрики приложения, а влияние всех инфраструктурных компонентов на приложение и то, как это сказывается на опыте наших пользователей.

Зачастую под full-stack мониторингом подразумевают продукт/решение, который предоставляет единый сервис для сбора, хранения и анализа собираемых данных с приложения, инфраструктуры и пользователей. Но в нашей статье мы поговорим именно про подход и расскажем про использование как open-source стандартов, так и платной платформы для реализации full-stack мониторинга Java.

По результатам нашего опыта можем сказать, что применение full-stack подхода к мониторингу позволяет заметно ускорить процесс root cause анализа инцидентов и действительно снизить MTTR.

Нюансы full-stack мониторинга Java

Чтобы понимать что нужно мониторить в Java приложениях, давайте для начала разберемся что собой представляет Java. Во-первых, Java это приложения, написанные не только на языке программирования Java, но и на других языках, которые основываются на Java Kotlin, Scala, JRuby, и другие.

Во-вторых, Java это еще и среда для чтения, понимания и выполнения байт-кода Java. Приложения, написанные на Java языке или на языках, базирующихся на Java, компилируются в байткод и запускаются в определенной среде исполнения JVM (Java Virtual Machine).

Поэтому нам нужно мониторить как само приложение на Java, так и среду, в которой оно запускается.

В целом full-stack мониторинг Java будет выглядеть следующим образом:

1. Сбор Java и JVM метрик.

2. Сбор распределенных трассировок транзакций.

3. Профилирование Java кода.

4. Мониторинг конечных пользователей.

Давайте подробнее пройдемся по всем компонентам full-stack мониторинга Java.

Сбор метрик Java и Java Virtual Machine

Под сбором метрик Java подразумевается сбор уникальных метрик с используемых фреймворков Java (SpringBoot, DropWizzard и т.д.) и applications серверов (JBoss/Wildfly, Websphere и т.д.), например:

• количество HTTP Requests для SpringBoot Framework;

• количество WebDeployments и количество их активных сессий для JBoss;

• количество запросов и среднее время отклика servlets для Websphere.

Получить метрики Java Virtual Machine (JVM) можно с помощью имеющейся у Java технологии JMX (Java Management Extensions), которая представляет информацию о состоянии самой JVM, garbage collection и других внутренних элементов.

Какие метрики JVM нас интересуют в первую очередь:

• Memory Usage
  Общий объем памяти, используемый самой JVM.
  Получим из java.lang.Runtime#totalMemory

• Threads
  Количество тредов, находящихся в статусах: new, runnable, timed-waiting, waiting или blocked.

  • Текущие идентификаторы тредов получим из java.lang.management.ThreadMXBean#getAllThreadIds

  • Статус тредов получим из ThreadMXBean#getThreadInfo

• Heap Memory
Общее использование heap memory самой JVM.

  • Текущее значение получим из java.lang.Runtime#totalMemory-java.lang.Runtime#freeMemory

  • Максимальное значение получим из java.lang.Runtime#maxMemory

• Memory Pools
  Использование memory pools

  • Информацию о пуле получим из ManagementFactory#getMemoryPoolMXBeans

  • Значение использования памяти пулом получим из java.lang.management.MemoryUsage

  • Максимальное значение получим из getMax, начальное значение получим изgetInit, и текущее значение получим изgetUsage.

• Garbage Collection
  Значение garbage collection и время его выполнения

  • Информацию о garbage collection получим из ManagementFactory#getGarbageCollectorMXBeans

  • Значение для каждого коллектора получим из java.lang.management.GarbageCollectorMXBean

  • Garbage collection runtime получим из getCollectionTime

Во время разработки приложений, самыми популярными инструментами для сбора и анализа метрик являются VisualVM и JDK Mission Control.

Помимо стандартного набора метрик, можно описать свои собственные (кастомные) метрики и здесь нам помогут такие инструменты, как DropWizard, Micrometer, StatsD и Prometheus.

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

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

Сбор распределенных трассировок (distributed tracing)

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

Наиболее распространенный путь в получении end-to-end трейсинга это использование open-source стандартов, например, таких как, OpenTelemetry и OpenTracing.

Пример видимости транзакции в одном из самых распространенных open-source инструментов для end-to-end трейсинга Jaeger

Но важно учитывать, что, используя разные open source решения - одно для сбора метрик (например, Prometheus), другое для сбора транзакций (Jaeger, Zipkin и т.п.) мы столкнемся с необходимостью ручной корреляции метрик и трейсов между собой. Связанно это с тем, что все open source решения по-разному записывают и хранят данные. И если инцидент затронул много сервисов, что часто происходит в микросервисных инфраструктурах, то при использовании такой связки, как например Prometheus + Jaeger, процесс root-cause анализа инцидента наоборот может усложниться и в результате увеличиться MTTR.

Поэтому для сбора метрик, транзакций и их корреляции между собой в микросервисных инфраструктур, мы используем готовые продукты для full-stack мониторинга, ниже расскажем про их применение.

Профилирование Java кода

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

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

На нашей практике, для профилирования приложения в основном используются такие инструменты, как VisualVM, jProfiler и JavaMissionControl в сочетании с Flight Recorder.

Мониторинг конечных пользователей (End user мониторинг/Real user мониторинг)

Как мы писали выше, одной из важных частей full-stack мониторинга является мониторинг наших конечных пользователей. Это обусловлено тем, что работа нашего приложения напрямую влияет на пользовательский опыт. Пользователи взаимодействуют с приложением через веб-сайт или мобильное приложение и понимание того какие запросы от пользователей уходят на бэкенд, т.е. запросы к Java приложению, обеспечивают сквозную видимость запроса, от клика пользователя в браузере или мобильном приложение до конкретной транзакции на бэкенде.

Таким образом, мы видим влияние скорости работы и ошибок в Java приложение на пользовательский опыт.

Мы решили сейчас много не писать на тему end user мониторинга так как мы ранее уже достаточно подробно раскрыли эту тему в одном из наших постов:

• End User Monitoring контролируем производительность фронтенда с помощью Instana.

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

Не могли не затронуть, хотя бы вскользь, тему мониторинга микросервисных Java приложений.

Основная сложность мониторинга таких приложений заключается в том, что увеличивается количество подконтрольных компонентов контейнеры, оркестраторы (k8s, docker swarm, openshift и т.д). Контейнеры с приложениями постоянно скейлятся, могут запускать только на короткий срок времени. Все это экспоненциально усложняет процесс мониторинга.

Динамичность микросервисной архитектуры Java приложения приводит нас к тому, что для обеспечения full-stack мониторинга нам необходимо проводить постоянную инвентаризацию инфраструктуры c целью получения актуальных данных о нашей инфраструктуре. Это возможно реализовать с помощью autodiscovery подхода .

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

Визуализация стека компонентов с их ключевыми метриками в продукте Instana

Отсутствие автодискаверинга как неотъемлемой части full-stack мониторинга микросервисных приложениях приводит к тому, что вновь запущенные компоненты, могут быть не замониторены и в результате у нас появятся слепые зоны в инфраструктуре. Мы не будем иметь представления о том, как себя действительно чувствует тот или иной компонент инфраструктуры, не сможем корректно оценить состояние приложения.

Реализовать подход автодискаверинга вручную, достаточно трудоемкий процесс, поэтому в наших проектах мы используем готовое решение Instana.

Full-stack мониторинг как продукт

Выше мы с вами рассмотрели full-stack мониторинг как подход, здесь же мы поговорим о full-tack мониторинге как готовом к использованию продукте.

На рынке существуют различные решения для full-stack мониторинга - Dynatrace, DataDog, New Relic, AppDynamics, Instana и т.д. Но мы расскажем именно про Instana, так она на данный момент объединяет в себе объемный функционал, необходимый для full-stack мониторинга как классических инфраструктур, так и микросервисных и выгодно отличается по цене от конкурентов.

С помощью Instana мы получаем full-stack мониторинг в том числе и для Java приложений без необходимости ручной настройки.

Instana постоянно и автоматически собирает ключевые данные для поддерживаемых технологий, относительно JVM обнаруживает все что находится внутри нее:

• тип JVM;

• версия JVM;

• используемый framework;

• коннекторы к базам данным;

• Upstream и Downstream сервисы;

• и многое другое.

Причем для агента Instana не важно в какой инфраструктуре запущено приложение в Docker, Kubernetes, OpenShift, Linux или Windows. После обнаружения JVM агент подключается к самому процессу и анализирует архитектуру сервиса, какой Framework используется (Spring Boot, DropWizzard и так далее), сервер приложений (Jboss/Wildfly, Websphere, и тд) и коннекторы к базам данных. Далее приложение автоматически инструментируется и агентом начинают собираться ключевые метрики и трейсы приложения. Очень важно, что при этом не требуется перезапуск приложения.

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

Давайте посмотрим на пример топологической модели Spring Boot приложения:

• Sping Boot приложение, это часть ->

• Java процесса, который представляет собой Java приложение, запущенное в ->

• JVM, которая запущена в ->

• Docker контейнере, который запущен в ->

• процессе операционной системы, который запущен на ->

• Linux хосте.

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

Но как мы писали выше, метрик недостаточно для полноценного мониторинга Java приложений. Приложения предоставляют собой сервисы, которые между собой как-то взаимодействуют. Instana обнаруживает все вызовы между сервисами и создает распределенные трейсы, показывая end-to-end карту вызовов.

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

Важной частью мониторинга Java приложений является профилирование кода. У нас могут быть метрики всех компонентов приложения и видимость всех вызовов, и мы можем понять связана ли эта проблема с использованием ресурсов и какой сервис именно пострадал. Но мы не узнаем, какой именно метод в работающем сервисе приложения вызывал проблемы с производительностью. И тут нам поможет постоянно работающий Java профилировщик. Профилировщик покажет точный метод(ы), которые перегружают CPU или имеют большой wait time.

Подводя итоги

Актуальность full-stack мониторинга будет только расти и это обусловлено, в том числе, переходом на микросервисную архитектуру, которая экспоненциально усложняет мониторинг по причине постоянного увеличения подконтрольных компонентов инфраструктуры.

Full-stack мониторинг позволяет охватить весь наш стек приложения, инфраструктуру, пользователей, и значительно ускорить root-cause анализ и снизить MTTR.

Имплементировать full-stack мониторинг возможно и как с помощью подхода сделай сам, используя open source стандарты (Prometheus/statsD для сбора метрик, Jaeger/Zipkin для сбора трейсов, jProfiler/Java VisualVM для профилирования Java кода), так и с помощью готовых продуктов, которых на рынке сейчас уже не мало.

Будем рады, если в комментариях вы поделитесь применяете ли full-stack мониторинг, как мониторите Java приложения и какие используете для этого инструменты?