Сегодня я расскажу, что из себя представляет Instana, и чем эта система мониторинга (СМ) отличается от других.
Система состоит из Instana Backend (сервер с веб-интерфейсом и хранилищем собранных данными) и Instana Agent (агент, который устанавливается на целевые хосты для мониторинга приложений). В качестве БД для хранения данных по метрикам используется Cassandra. Кроме On-premise установки, есть облачная версия. Обзор посвящен опыту использования первого варианта.
Установка
Технические детали и ссылки на документацию — под спойлером.
Подготовка
Перед началом установки необходимо убедиться, что у вас открыт доступ к репозиториям Instana, так как большинство компонентов загружают необходимые пакеты и артефакты при запуске. Это касается и агента Instana. Его дистрибутив содержит только ядро агента: во время установки агент обнаруживает компоненты на целевом сервере и скачивает пакеты, необходимые для мониторинга этих компонентов. Вы можете использовать ваш внутренний репозиторий в режиме прокси (например, Sonartype Nexus).
Выберите операционку — на данный момент для установки бэкенд-сервера поддерживаются:
- SLES: >= 12
- Ubuntu: >= 16.04
- Debian: >= 8
- RedHat Enterprise Linux >= 7.2
- CentOS >= 7
Требования к версиям ОС обусловлены тем, что ПО Instana работает на Docker >= 1.10.
ПО платное, поэтому вам также понадобится ключ активации для Backend и Agent.
Установка Backend
Мы используем CentOS 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:
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 (не JRE !). Переменная среды JAVA_HOME должна содержать корректный путь к установленному JDK.
Заходим в веб-интерфейс Instana Backend и скачиваем дистрибутив под нужную операционку:
Также можно скачать дистрибутивы напрямую на сайте вендора.
Например, на Linux установка агента заключается в копировании и распаковке архива. Перед запуском необходимо поправить конфиг агента и указать данные вашего репозитория. Теперь можно запустить агента:
<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 Чтобы все хосты у вас на карте были разбиты на зоны (как на картинке ниже), искались по тегам, необходимо внести правки в конфиг агента на хосте и перезапустить агента. Всё это подробно описано в документации. Кстати, для начала можно установить агента на сам сервер Backend Instana.
Агента также можно установить в контейнере.
Использование
Несмотря на то, что интерфейс системы очень интуитивный, советую прочитать соответствующую документацию, встречаются неочевидные моменты.
Например, чтобы посмотреть подробности того или иного параметра необходимо кликнуть на нем (для меня строка таблицы была неочевидным местом клика):
Откроется соответствующий график:
Инфраструктурная карта (Infrastructure Map):
Можно включить отображение значений системной метрики (ЦПУ, память) прямо на карте:
В новой версии добавилась таблица сравнения. Она позволяет сразу увидеть текущее значение основных системных метрик по всем хостам. К тому же можно быстро выделить нужные хосты и проанализировать произвольную метрику на сводном графике:
Карта приложения (Application Map):
В новой версии добавилась таблица сравнения для компонентов приложения, где также можно выбрать компоненты и проанализировать их на сводном графике:
Все транзакции доступны для анализа в Trace view, где таблица сортируется по любому столбцу (можно, например, быстро найти самую длительную транзакцию):
Из любого представления вы можете открыть дашборд, в котором найдете графики и значения метрик по хосту и компонентам на нем:
Есть поиск по именам хостов, компонентам, трассировке, тегам, зонам — поддерживаются маски (*) и объединения (AND/OR):
Отличительной особенностью, которой на данный момент нет ни у одной другой СМ, является работа с историческими данными в режиме Timeshift. При прокрутке шкалы времени (Timeline) видим не только все события за прошедшее время, но и как выглядела карта (физическая/логическая) в прошлом. Например, видно что на сервере перестал работать Tomcat, как это повлияло на взаимодействия компонентов приложения, как раньше выглядела инфраструктурная карта и карта компонентов приложения. В таком же ключе можно смотреть транзакции (вкладка Application → Trace).
В новой версии бэкенда все события собраны в отдельной вкладке Incidents, где можно отсортировать таблицу по столбцам и анализировать детали:
По ссылкам в деталях можно сразу перейти на подробный дашборд соответствующего компонента.
В отличие от классического инфраструктурного мониторинга (доступность хоста, уровень утилизации ЦПУ, доступность HTTP-страницы и т.п.), мониторинг приложений предъявляет более серьезные требования к частоте и детализации (гранулярности) собираемых данных. Чем чаще получаем значение той или иной метрики, тем лучше, особенно это касается транзакционного мониторинга. Это связано с тем, что проблемы при работе приложения могут быть очень непродолжительными, а последствия при этом вполне ощутимыми. Для сравнения графики с различной гранулярностью (1 минута vs 5 секунд):
Сразу понятно, что недостаточно подробные данные в ряде случаев не позволят обнаружить проблему. Данная система позволяет собирать данные с частотой вплоть до 1 секунды. Для уменьшения объема исторических данных они агрегируются относительно давности — чем дальше, тем ниже гранулярность: 1 секунда (live-данные хранятся 10 минут) → 5 секунд (хранятся 1 день) → 1 минута (хранятся 31 день) → 5 минут (хранятся 3 месяца) → 1 час (хранятся 1 год, но можно увеличить).
Очень полезен автоматический поиск (Automatic Discovering) компонентов: если на хосте установлен агент Instana, в СМ автоматически появятся все известные ей компоненты и сервисы. Это особенно важно, когда ваше приложение построено на микросервисах:
Список поддерживаемых технологий включает практически всё, что сейчас популярно. Естественно, можно смотреть транзакции и анализировать работу приложения на уровне вызова метода (в документации есть подробности механизма трассировки).
Важный критерий при выборе СМ для нас — поддержка Scala, это редкость для СМ приложений. Может показаться, что для СМ достаточно поддержки Java — и глубокий мониторинг приложения (инструментирование) в кармане. Но на поверку оказывается, что это не так: без поддержки Scala на мониторинге будет видна трассировка только одного вызова JVM. Поэтому даже самые известные игроки на рынке APM на сегодняшний день отстают в этом плане.
Система видит изменения компонентов по принципу дельты:
Кроме того система способна в онлайн-режиме отображать состояние взаимодействия между компонентами (частота перемещения точек на связях показывает насколько быстро идет обмен данными):
Для оповещения «из коробки» доступны следующие варианты интеграций:
- OpsGenie
- PagerDuty
- Slack
- Webhook
Продукт активно развивается, но уже сейчас выглядит удобным инструментом для поиска проблем с приложением как на стадии тестирования/отладки, так и для оперативного мониторинга.
Ссылки
В статье использованы материалы:
ссылка на оригинал статьи https://habrahabr.ru/post/317254/
Добавить комментарий