Обзор системы мониторинга приложений Instana

Сегодня я расскажу, что из себя представляет Instana ^[1], и чем эта система мониторинга (СМ) отличается от других.

Система состоит из Instana Backend (сервер с веб-интерфейсом и хранилищем собранных данными) и Instana Agent (агент, который устанавливается на целевые хосты для мониторинга приложений). В качестве БД для хранения данных по метрикам используется Cassandra ^[2]. Кроме On-premise установки, есть облачная версия. Обзор посвящен опыту использования первого варианта.

Установка

Технические детали и ссылки на документацию — под спойлером.

Подробности установки

Подготовка

Перед началом установки необходимо убедиться, что у вас открыт доступ к репозиториям Instana ^[3], так как большинство компонентов загружают необходимые пакеты и артефакты при запуске. Это касается и агента Instana. Его дистрибутив содержит только ядро агента: во время установки агент обнаруживает компоненты на целевом сервере и скачивает пакеты, необходимые для мониторинга этих компонентов. Вы можете использовать ваш внутренний репозиторий в режиме прокси (например, Sonartype Nexus ^[4]).

Выберите операционку — на данный момент для установки бэкенд-сервера поддерживаются:

• SLES: >= 12
• Ubuntu: >= 16.04
• Debian: >= 8
• RedHat Enterprise Linux >= 7.2
• CentOS >= 7

Требования к версиям ОС обусловлены тем, что ПО Instana работает на Docker ^[5] >= 1.10.
ПО платное, поэтому вам также понадобится ключ активации для Backend и Agent ^[6].

Установка Backend

Мы используем CentOS 7, установка прошла четко по инструкции ^[7].

Добавляем запись о репозитории (используется логин/пароль, выделенный вендором):

sudo tee /etc/yum.repos.d/instana.repo <<-EOF
[instanarepo]
name=Instana Repository
baseurl=https://<user>:<password>@package-repository.instana.io/backend/rhel7
enabled=1
gpgcheck=1
gpgkey=https://<user>:<password>@package-repository.instana.io/instana.gpg
EOF

После чего запускаем установку пакета через yum:

yum install instana-backend

После окончания установки не торопитесь запускать, сперва надо скопировать и поправить конфиг для Instana Backend ^[8]:

cd /etc/instana-backend
cp instana.settings.template instana.settings

Нам понадобилось закомментировать строчку в /etc/sudoers с помощью команды visudo, чтобы произвести запуск из под root с помощью sudo:

#Defaults	requiretty

Логинимся в репозиторий Instana:

docker login -u ”$INSTANA_REPO_USER”  -p “$INSTANA_REPO_PASSWORD” registry-
public.instana.io

Добавляем запуск бэкенда в автозагрузку:

systemctl enable instana-backend.service

Всё, теперь можно запускать:

systemctl start instana-backend

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

All done :)

Установка агента

На данный момент поддерживаются следующие операционки:

• Linux 32 / 64 bit
• Windows 32 / 64 bit
• Mac OS 64 bit

Для запуска агента необходимо установить JDK 8 ^[9] (не JRE !). Переменная среды JAVA_HOME должна содержать корректный путь к установленному JDK.

Заходим в веб-интерфейс Instana Backend и скачиваем дистрибутив под нужную операционку:

Также можно скачать дистрибутивы напрямую на сайте вендора ^[10].

Например, на Linux установка агента заключается в копировании и распаковке архива. Перед запуском необходимо поправить конфиг агента ^[11] и указать данные вашего репозитория. Теперь можно запустить агента:

<instana-agent-install-dir>/instana-agent/bin/start

После запуска можно проверить статус агента командой:

<instana-agent-install-dir>/instana-agent/bin/status

При необходимости остановить агента можно командой:

<instana-agent-install-dir>/instana-agent/bin/stop

Текущий лог агента лежит здесь:

<instana-agent-install-dir>/instana-agent/data/log/agent.log

Чтобы все хосты у вас на карте были разбиты на зоны (как на картинке ниже), искались по тегам, необходимо внести правки в конфиг агента на хосте и перезапустить агента. Всё это подробно описано в документации ^[12]. Кстати, для начала можно установить агента на сам сервер Backend Instana.

Агента также можно установить в контейнере ^[13].

Использование

Несмотря на то, что интерфейс системы очень интуитивный, советую прочитать соответствующую документацию ^[14], встречаются неочевидные моменты.

Например, чтобы посмотреть подробности того или иного параметра необходимо кликнуть на нем (для меня строка таблицы была неочевидным местом клика):

Откроется соответствующий график:

Инфраструктурная карта (Infrastructure Map ^[15]):

Можно включить отображение значений системной метрики (ЦПУ, память) прямо на карте:

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

Карта приложения (Application Map ^[16]):

В новой версии добавилась таблица сравнения для компонентов приложения, где также можно выбрать компоненты и проанализировать их на сводном графике:

Все транзакции доступны для анализа в Trace view ^[17], где таблица сортируется по любому столбцу (можно, например, быстро найти самую длительную транзакцию):

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

Есть поиск по именам хостов, компонентам, трассировке, тегам, зонам — поддерживаются маски (*) и объединения (AND/OR):

Отличительной особенностью, которой на данный момент нет ни у одной другой СМ, является работа с историческими данными в режиме Timeshift ^[18]. При прокрутке шкалы времени (Timeline) видим не только все события за прошедшее время, но и как выглядела карта (физическая/логическая) в прошлом. Например, видно что на сервере перестал работать Tomcat, как это повлияло на взаимодействия компонентов приложения, как раньше выглядела инфраструктурная карта и карта компонентов приложения. В таком же ключе можно смотреть транзакции (вкладка Application → Trace ^[17]).

В новой версии бэкенда все события собраны в отдельной вкладке Incidents, где можно отсортировать таблицу по столбцам и анализировать детали:

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

В отличие от классического инфраструктурного мониторинга (доступность хоста, уровень утилизации ЦПУ, доступность HTTP-страницы и т.п.), мониторинг приложений предъявляет более серьезные требования к частоте и детализации (гранулярности) собираемых данных. Чем чаще получаем значение той или иной метрики, тем лучше, особенно это касается транзакционного мониторинга. Это связано с тем, что проблемы при работе приложения могут быть очень непродолжительными, а последствия при этом вполне ощутимыми. Для сравнения графики с различной гранулярностью (1 минута vs 5 секунд):

Сразу понятно, что недостаточно подробные данные в ряде случаев не позволят обнаружить проблему. Данная система позволяет собирать данные с частотой вплоть до 1 секунды ^[19]. Для уменьшения объема исторических данных они агрегируются относительно давности — чем дальше, тем ниже гранулярность: 1 секунда (live-данные хранятся 10 минут) → 5 секунд (хранятся 1 день) → 1 минута (хранятся 31 день) → 5 минут (хранятся 3 месяца) → 1 час (хранятся 1 год, но можно увеличить).

Очень полезен автоматический поиск (Automatic Discovering) компонентов ^[20]: если на хосте установлен агент Instana, в СМ автоматически появятся все известные ей компоненты и сервисы. Это особенно важно, когда ваше приложение построено на микросервисах ^[21]:

Список поддерживаемых технологий ^[22] включает практически всё, что сейчас популярно. Естественно, можно смотреть транзакции ^[17] и анализировать работу приложения на уровне вызова метода (в документации есть подробности механизма трассировки ^[23]).

Важный критерий при выборе СМ для нас — поддержка Scala ^[24], это редкость для СМ приложений. Может показаться, что для СМ достаточно поддержки Java — и глубокий мониторинг приложения (инструментирование ^[25]) в кармане. Но на поверку оказывается, что это не так: без поддержки Scala на мониторинге будет видна трассировка только одного вызова JVM. Поэтому даже самые известные игроки на рынке APM ^[26] на сегодняшний день отстают в этом плане.
Система видит изменения компонентов по принципу дельты ^[20]:

Кроме того система способна в онлайн-режиме отображать состояние взаимодействия между компонентами (частота перемещения точек на связях показывает насколько быстро идет обмен данными):

Автор: Тинькофф Банк

Источник ^[27]