SNAMP

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

Метрики, события и проверки состояния используются для контроля работоспособности сервисов в ИТ-инфраструктуре. Сбор данных производится в реальном времени. Собранная информация может визуализироваться в виде графиков, служить для оповещений и автоматического выполнения обслуживающих действий. Для важных метрик можно настроить наблюдатель (watcher), который определяет допустимые значения и условия для срабатывания. Если значение выходит за пределы, наблюдатель может вызвать триггер — например, выполненный вручную скрипт на одном из поддерживаемых языков, например Groovy. Триггером может быть обслуживающее действие (перезапуск узла), либо отправка уведомления (например, по электронной почте).

Также возможно расширение существующих средств мониторинга, используемых в организации. SNAMP способен собирать телеметрию и предоставлять её внешним программам по поддерживаемым протоколам. Например, данные, собранные по JMX, можно экспонировать через SNMP и анализировать средствами управления сетью вроде Nagios.

Трассировка позволяет выявлять коммуникационные пути между сервисами и собирать ключевые метрики: время отклика, число запросов в секунду, доступность, масштабируемость и др. Эти данные помогают локализовать проблемы с задержками, производительностью и определить узкие места. Также маршруты запросов могут отображаться на графе в веб-консоли, что даёт наглядную картину ИТ-ландшафта в режиме реального времени.

Для передачи нужной информации в SNAMP приложения должны быть инструментированы. Библиотеки для этого доступны в репозитории Maven Central^[2] c groupID io.snamp.instrumentation. Поддерживаются и сторонние реализации:

• OpenZipkin^[3]
• Apache HTrace^[4]

Менеджер эластичности — компонент SNAMP, отвечающий за автоматическое выделение и освобождение узлов кластера. Его поведение регулируется политиками масштабирования. В рамках одного кластера может быть несколько таких политик. Принятие решений основано на нечёткой логике: каждая политика имеет свой вес голоса, и процесс голосования запускается периодически. Результат голосования — увеличение, уменьшение размера кластера или отсутствие изменений. Политика может базироваться на результатах проверки состояния, пользовательском скрипте или диапазоне значений метрики. Благодаря гибкости процесса можно реализовать разные стратегии масштабирования:

• Все из — все политики должны проголосовать за изменение размера кластера
• Любая из — достаточно одного голоса политика
• Большинство — решение принимается большинством политик

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

Менеджер эластичности использует выбранную платформу управления кластером или облаком для команд на выделение и удаление узлов. Это могут быть OpenStack, Kubernetes, VMware ESXi.

Веб-консоль предназначена для визуализации метрик в виде графиков, отображения маршрутов взаимодействия сервисов и мониторинга кластера. Использование веб-консоли — опционально, поскольку SNAMP поддерживает интеграцию со сторонними инструментами, например с Grafana^[5].

Платформа SNAMP состоит из следующих основных компонентов:

• Resource Connector^[6] — обеспечивает связь между SNAMP и сервисом в инфраструктуре, инкапсулирует протокол и предоставляет телеметрию в едином виде. Например, JMX Connector позволяет управлять Java-приложениями через JMX.
• Gateway^[7] — публикация данных от всех коннекторов во внешний мир по выбранному протоколу (например, через SNMP).
• Supervisor^[8] — управляет группой ресурсов, предоставляет мониторинг состояния, управление эластичностью, автоматическое обнаружение ресурсов.

Сочетание различных шлюзов и коннекторов позволяет преобразовывать телеметрию между протоколами. Каждый компонент можно дорабатывать с помощью скриптов на Groovy. Также можно создавать собственные компоненты на любом языке для JVM.

• Интеграция со сторонними инструментами визуализации и мониторинга: Grafana^[5], Nagios, SSH
• Сбор телеметрии по следующим протоколам и технологиям: Spring Actuator, OpenZipkin spans (от Kafka и HTTP), HTTP, JMX, Modbus, rsh, стандартный вывод терминальных приложений, SSH
• Передача телеметрии по: XMPP (чат-бот), SNMPv2/SNMPv3, HTTP, NRDP, NSCA^[9], syslog, стриминг данных в InfluxDB
• Управление эластичностью поддерживает OpenStack Senlin^[10].
• Cкрипты на Groovy

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

• Мониторинг и визуализация: Nagios, Grafana^[5]
• Сквозная трассировка: OpenZipkin^[3]
• Автоматическое масштабирование: AWS обеспечивает автоскейлинг^[11] для ресурсов EC2, OpenStack Heat

Jolokia^[12] предоставляет мост JMX-to-HTTP и может работать внутри отдельной Java-программы, Java EE-сервера приложений или среды OSGi.