company_banner

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

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


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


Для оповещения «из коробки» доступны следующие варианты интеграций:

  • Email
  • OpsGenie
  • PagerDuty
  • Slack
  • Webhook

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

Ссылки


В статье использованы материалы:

Tinkoff.ru
210.62
IT’s Tinkoff.ru — просто о сложном
Support the author
Share post

Comments 21

    0
    Система мониторинга без исходников? Нууу не знаааюю…
      0
      Да, это не Open Source. Но кое-что есть на Github (агент + некоторые сенсоры).
        +1
        У меня всегда в процессе эксплуатации мониторинг превращался в какого-то монстра, которого и трогать-то страшно (это шутка, конечно, но стружки много было). Т.ч. я не представляю как можно использовать, например, SaaS мониторинг (ну разве на случай «совсем всё сломалось» — для оперативного разбора ситуации). Собственно, в ТКСе то как Instana используется?

        Справедливости ради, из универсальных систем мониторинга я работал только с Nagios'ом (давно) и Zabbix'ом (сейчас).
          0
          Т.ч. я не представляю как можно использовать, например, SaaS мониторинг (ну разве на случай «совсем всё сломалось» — для оперативного разбора ситуации).

          В понедельник olegbunin выложил Monitoring driven эксплуатация.

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

          По моему это тренд, тот же okmeter.io SaaS решение.

            0
            Да, это тренд для всего ИТ, т.к. заказчику очень нравится отсутствие необходимости поднимать/сопровождать инфраструктуру для чего бы то ни было, да и сам софт.
            0
            Eсли важен опен соурс, посмотрите на pinpoint.
            Он конечно не так красив и не так много чего (все еще) умеет, но зато бесплатен
            +2
            Жаль, что платная. Причем на сколько именно платная можно узнать только по запросу.
              0
              промахнулся, ответ ниже
              0
              в самом низу страницы есть некий множитель (1 SIM = $0.0001), насколько я понимаю суть которого — это кол-во обработанных системой данных (SIM = Software Instance Minute).
                0
                Я так и не понял чем же она отличается от других, и кто они, эти, другие.
                  0
                  Чем отличается:
                  … Отличительной особенностью, которой на данный момент нет ни у одной другой СМ, является работа с историческими данными в режиме Timeshift...

                  … Данная система позволяет собирать данные с частотой вплоть до 1 секунды...

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

                  … Важный критерий при выборе СМ для нас — поддержка Scala, это редкость для СМ приложений...


                  Другие:
                  даже самые известные игроки на рынке APM на сегодняшний день отстают в этом плане

                  Ну т.е. HP APM, IBM Tivoli, CA APM, AppDynamics,…

                  Отмечу, что это именно обзор системы (которую сейчас только пилотим), а не сравнение со всеми основными игроками рынка.
                  0
                  Я видел инстану еще в бете, в Мюнхене. Кажется тут ее и разрабатывают. Похоже, что за последние пол года они сильно продвинулись.
                    0
                    Разработка идет достаточно быстро (во время пилота уже обновили бэкенд и агент). Планов у них на след. год очень много.
                    0
                    Я не очень внимательно читал конечно, но можете ли вы привести описание простой кастомной проверки для этой мониторинговой системы (примером проверку, что какой-то процесс запущен) и как собрать матрики для отображения графиков?
                      0
                      Все метрики, алерты и их логика — зашиты в ПО бэкенда. Добавить самостоятельно свою метрику или переопределить имеющуюся — пока нельзя.
                      В документации на данный момент есть только список сенсоров и метрик. Все дашборды и «вьюшки» в системе идут «из коробки», создать кастомные дашборды нельзя.

                      Замысел создателей системы таков, что после установки агента на интересующий хост, автоматически на физическую и логическую карту бэкенда добавляется соответствующий объект со всеми компонентами, которые агент обнаружил на этом хосте. С этого момента все указанные выше метрики собираются и доступны для анализа, в числе которых транзакции приложения. Т.е. все работает сразу «из коробки», если нужно добавить что-то исключительное – необходимо обращаться к вендору.
                        0
                        >> Т.е. все работает сразу «из коробки», если нужно добавить что-то исключительное – необходимо обращаться к вендору.

                        Но это в конечном счете будет стоить очень прилично.
                      0
                      Пишем сами для своего заббикса сами. От заббикса уже осталось только название… работает…

                      PS: Процессинг карт. Oracle, хосты к МПС, транзакционный обмен, эвайсы.
                        0
                        Круто! Я бы почитал статью об этом.
                          0
                          Поделитесь наработками?

                        Only users with full accounts can post comments. Log in, please.