Сегодня я расскажу, что из себя представляет Instana, и чем эта система мониторинга (СМ) отличается от других.
Система состоит из Instana Backend (сервер с веб-интерфейсом и хранилищем собранных данными) и Instana Agent (агент, который устанавливается на целевые хосты для мониторинга приложений). В качестве БД для хранения данных по метрикам используется Cassandra. Кроме On-premise установки, есть облачная версия. Обзор посвящен опыту использования первого варианта.
Технические детали и ссылки на документацию — под спойлером.
Несмотря на то, что интерфейс системы очень интуитивный, советую прочитать соответствующую документацию, встречаются неочевидные моменты.
Например, чтобы посмотреть подробности того или иного параметра необходимо кликнуть на нем (для меня строка таблицы была неочевидным местом клика):
Откроется соответствующий график:
Инфраструктурная карта (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 на сегодняшний день отстают в этом плане.
Система видит изменения компонентов по принципу дельты:
Кроме того система способна в онлайн-режиме отображать состояние взаимодействия между компонентами (частота перемещения точек на связях показывает насколько быстро идет обмен данными):
Для оповещения «из коробки» доступны следующие варианты интеграций:
Продукт активно развивается, но уже сейчас выглядит удобным инструментом для поиска проблем с приложением как на стадии тестирования/отладки, так и для оперативного мониторинга.
В статье использованы материалы:
Установка
Технические детали и ссылки на документацию — под спойлером.
Подробности установки
Перед началом установки необходимо убедиться, что у вас открыт доступ к репозиториям Instana, так как большинство компонентов загружают необходимые пакеты и артефакты при запуске. Это касается и агента Instana. Его дистрибутив содержит только ядро агента: во время установки агент обнаруживает компоненты на целевом сервере и скачивает пакеты, необходимые для мониторинга этих компонентов. Вы можете использовать ваш внутренний репозиторий в режиме прокси (например, Sonartype Nexus).
Выберите операционку — на данный момент для установки бэкенд-сервера поддерживаются:
Требования к версиям ОС обусловлены тем, что ПО Instana работает на Docker >= 1.10.
ПО платное, поэтому вам также понадобится ключ активации для Backend и Agent.
Мы используем CentOS 7, установка прошла четко по инструкции.
Добавляем запись о репозитории (используется логин/пароль, выделенный вендором):
После чего запускаем установку пакета через yum:
После окончания установки не торопитесь запускать, сперва надо скопировать и поправить конфиг для Instana Backend:
Нам понадобилось закомментировать строчку в /etc/sudoers с помощью команды visudo, чтобы произвести запуск из под root с помощью sudo:
Логинимся в репозиторий Instana:
Добавляем запуск бэкенда в автозагрузку:
Всё, теперь можно запускать:
После этого начнут загружаться необходимые пакеты из репозитория, это займет время. В конце должна появиться радостная надпись:
На данный момент поддерживаются следующие операционки:
Для запуска агента необходимо установить JDK 8 (не JRE !). Переменная среды JAVA_HOME должна содержать корректный путь к установленному JDK.
Заходим в веб-интерфейс Instana Backend и скачиваем дистрибутив под нужную операционку:
Также можно скачать дистрибутивы напрямую на сайте вендора.
Например, на Linux установка агента заключается в копировании и распаковке архива. Перед запуском необходимо поправить конфиг агента и указать данные вашего репозитория. Теперь можно запустить агента:
После запуска можно проверить статус агента командой:
При необходимости остановить агента можно командой:
Текущий лог агента лежит здесь:
Чтобы все хосты у вас на карте были разбиты на зоны (как на картинке ниже), искались по тегам, необходимо внести правки в конфиг агента на хосте и перезапустить агента. Всё это подробно описано в документации. Кстати, для начала можно установить агента на сам сервер Backend Instana.
Агента также можно установить в контейнере.
Подготовка
Перед началом установки необходимо убедиться, что у вас открыт доступ к репозиториям 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
Продукт активно развивается, но уже сейчас выглядит удобным инструментом для поиска проблем с приложением как на стадии тестирования/отладки, так и для оперативного мониторинга.
Ссылки
В статье использованы материалы:
Поделиться с друзьями
Комментарии (21)
r_j
09.12.2016 16:49в самом низу страницы есть некий множитель (1 SIM = $0.0001), насколько я понимаю суть которого — это кол-во обработанных системой данных (SIM = Software Instance Minute).
osigida
09.12.2016 19:49Я так и не понял чем же она отличается от других, и кто они, эти, другие.
r_j
09.12.2016 22:17Чем отличается:
… Отличительной особенностью, которой на данный момент нет ни у одной другой СМ, является работа с историческими данными в режиме Timeshift...
… Данная система позволяет собирать данные с частотой вплоть до 1 секунды...
… автоматический поиск (Automatic Discovering) компонентов: если на хосте установлен агент Instana, в СМ автоматически появятся все известные ей компоненты и сервисы. Это особенно важно, когда ваше приложение построено на микросервисах...
… Важный критерий при выборе СМ для нас — поддержка Scala, это редкость для СМ приложений...
Другие:
даже самые известные игроки на рынке APM на сегодняшний день отстают в этом плане
Ну т.е. HP APM, IBM Tivoli, CA APM, AppDynamics,…
Отмечу, что это именно обзор системы (которую сейчас только пилотим), а не сравнение со всеми основными игроками рынка.
Ipeacocks
10.12.2016 15:01Я не очень внимательно читал конечно, но можете ли вы привести описание простой кастомной проверки для этой мониторинговой системы (примером проверку, что какой-то процесс запущен) и как собрать матрики для отображения графиков?
r_j
11.12.2016 22:01Все метрики, алерты и их логика — зашиты в ПО бэкенда. Добавить самостоятельно свою метрику или переопределить имеющуюся — пока нельзя.
В документации на данный момент есть только список сенсоров и метрик. Все дашборды и «вьюшки» в системе идут «из коробки», создать кастомные дашборды нельзя.
Замысел создателей системы таков, что после установки агента на интересующий хост, автоматически на физическую и логическую карту бэкенда добавляется соответствующий объект со всеми компонентами, которые агент обнаружил на этом хосте. С этого момента все указанные выше метрики собираются и доступны для анализа, в числе которых транзакции приложения. Т.е. все работает сразу «из коробки», если нужно добавить что-то исключительное – необходимо обращаться к вендору.Ipeacocks
13.12.2016 01:04>> Т.е. все работает сразу «из коробки», если нужно добавить что-то исключительное – необходимо обращаться к вендору.
Но это в конечном счете будет стоить очень прилично.
devpreview
Система мониторинга без исходников? Нууу не знаааюю…
r_j
Да, это не Open Source. Но кое-что есть на Github (агент + некоторые сенсоры).
devpreview
У меня всегда в процессе эксплуатации мониторинг превращался в какого-то монстра, которого и трогать-то страшно (это шутка, конечно, но стружки много было). Т.ч. я не представляю как можно использовать, например, SaaS мониторинг (ну разве на случай «совсем всё сломалось» — для оперативного разбора ситуации). Собственно, в ТКСе то как Instana используется?
Справедливости ради, из универсальных систем мониторинга я работал только с Nagios'ом (давно) и Zabbix'ом (сейчас).
RPG18
В понедельник olegbunin выложил Monitoring driven эксплуатация.
r_j
Instana пока на этапе пилотного проекта. Планируется использовать для оперативного мониторинга продуктива, разбора полетов и, скорее всего, отладки приложения в тестовой среде.
RPG18
По моему это тренд, тот же okmeter.io SaaS решение.
r_j
Да, это тренд для всего ИТ, т.к. заказчику очень нравится отсутствие необходимости поднимать/сопровождать инфраструктуру для чего бы то ни было, да и сам софт.
osigida
Eсли важен опен соурс, посмотрите на pinpoint.
Он конечно не так красив и не так много чего (все еще) умеет, но зато бесплатен