Почему не просто Spring Boot Admin?

Spring Boot Admin (SBA) — часто первый инструмент, к которому приходят команды, когда нужно централизованное решение для дебага, тестирования и мониторинга Spring Boot-развёртываний. На этой странице описано, как Axelix соотносится с SBA: какие задачи он закрывает и как два продукта сравниваются по возможностям и по эксплуатации.

Если вы выбираете между инструментами, прочитайте эту страницу вместе со справочником "Возможностей" и разделом "Мотивация" — там разобраны повседневные проблемы, на которые ориентирован Axelix.

Создан инженерами, которые много лет работали с SBA

Прежде всего, Spring Boot Admin — зрелый и широко распространённый проект. Он собирает health, metrics, loggers, данные environment и другие поверхности Actuator в одном UI и много лет развивается под эгидой Codecentric.

Люди, которые проектируют и разрабатывают ядро Axelix, долго эксплуатировали Spring Boot Admin в реальных средах. Этот опыт определяет продукт: болевые точки ниже — не теоретическое сравнение по чек-листу, а повторяющиеся потребности, которые стандартный Actuator (а значит и SBA) не закрывал в типичных энтерпрайз-установках.

Причина 1: SBA ограничен Actuator; а Axelix идёт дальше

Spring Boot Admin работает поверх встроенных endpoint'ов Spring Boot/Cloud Actuator-а. Всё, что отдаёт Actuator, SBA может показать; всё, чего Actuator не умеет, SBA тоже не сделает без доработок в каждом управляемом приложении.

Эта граница важна при тестировании, отладке и в итоге в production-эксплуатации. В корпоративных парках Spring Boot регулярно нужно:

включать и отключать кэши в runtime, а не только очищать записи;
запускать, перенастраивать, включать и отключать задачи с @Scheduled без передеплоя;
видеть, какой SQL выполнялся внутри какого метода с @Transactional, с таймингами по каждому вызову, без развёртывания полноценного APM;
разбираться, почему существует тот или иной bean (зависимости, origin, qualifiers) и почему auto-configuration пошла по конкретному пути.

Такие сценарии требуют кода в мониторируемом приложении: своих endpoint'ов, перехватчиков, расширенных отчётов.

Axelix поставляет эту логику в Spring Boot Starter в виде отдельных Actuator endpoint'ов axelix-*, к которым обращаются Master и UI. Это кстати одна из главных причин появления проекта Axelix: Spring Boot Admin просто не давал той глубины операционной работы, которая нужна при отладке живых сервисов в сложных развёртываниях.

Конкретные примеры такой отладки — в разделе Мотивация.

Причина 2: Axelix готов к установке; SBA нужно собирать самим

Второе крупное отличие — как вы запускаете и развертываете у себя решение.

Spring Boot Admin обычно встраивают в приложение, которое нужно написать самостоятельно, или выкладывают отдельным сервисом, который вы сами упаковываете, сопровождаете, патчите там зависимости и т.д. У SBA upstream-проекта нет официального Docker-образа или Helm-чарта от авторов SBA. Подключение OIDC/OAuth2, корпоративного LDAP или детальной авторизации чаще всего означает свою конфигурацию Spring Security поверх вашего развёртывания. Ещё раз - вы будете вынуждены писать это сами и тратить на это время.

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

автономный JAR с встроенным UI и MCP сервером — см. Настройка Master;
официальный Docker-образ и примеры Docker Compose в том же руководстве;
официальный Helm-чарт на Artifact Hub (исходники: github.com/axelixlabs/helm-charts).

Аутентификация встроена: для простых установок — локальная база пользователей, для production — OAuth2/OIDC (Keycloak, Auth0, Okta, Google и другие провайдеры) с сопоставлением ролей — см. Аутентификация. Управляемые приложения защищены JWT между Master и starter; authorities на уровне операций (например, CACHES_TOGGLE, SCHEDULED_TASKS_MODIFY) ограничивают опасные действия в UI и через MCP.

Ещё один важный момент: надёжный, проверенный и поддерживаемый канал аутентификации между Axelix Master и starter'ами уже встроен. С Spring Boot Admin всё это нужно проектировать и реализовывать самим.

Starter по-прежнему добавляется в каждый Spring Boot-сервис, но консоль управления не нужно собирать и защищать с нуля.

Сравнение возможностей (battle card)

Ниже — сравнение типичного поведения Spring Boot Admin 3.x (UI поверх Actuator) с Axelix OSS. Важно понимать, что установки SBA различаются: кто-то добавляет свою безопасность, уведомления или расширения. Теоретически SBA можно допилить или дописать самим (написать код, упаковать, задеплоить и т.д.), но в Axelix эти возможности уже входят.

Область	Spring Boot Admin	Axelix
Поставка
Официальный Docker-образ от сопровождающих проекта	❌ (образ собираете сами)	✅
Официальный Helm-чарт	❌ (только community-чарты)	✅
UI в одном JAR с сервером	Зависит от развёртывания	✅
Безопасность и доступ
Вход через OAuth2 / OIDC	❌ (нужно делать самим)	✅ встроено
Локальные пользователи в консоли	❌	✅
RBAC на уровне операций над инстансом	❌	✅ роли и authorities
JWT-защита Actuator endpoint'ов инстанса	❌	✅ starter + Master
Стандартные поверхности Actuator
Health, info, metrics	✅	✅
Loggers (смена уровней)	✅	✅ (Loggers)
Environment / config properties (чтение)	✅	✅ (Properties, Configuration Properties)
Thread dump, heap dump	✅	✅ (Thread Dump)
Сверх стандартного Actuator
Включение / отключение кэшей в runtime	❌ (только evict/clear через `/actuator/caches`)	✅ (Caches)
Очистка кэшей	✅	✅
Графики hit/miss и оценка числа записей	❌	✅
Список задач с `@Scheduled`	✅ (только чтение через Actuator)	✅
Запуск scheduled-задачи по требованию	❌	✅ (Scheduled Tasks)
Смена cron / fixed delay / fixed rate в runtime	❌	✅
Включение / отключение scheduled-задач в runtime	❌	✅
Мониторинг транзакций (`@Transactional` + timeline SQL)	❌	✅ (Transaction Control)
Расширенные beans (зависимости, origin, qualifiers, proxying)	Частично (Actuator `/beans`)	✅ (Beans)
Источник свойства + ссылки «injected in» / `@ConfigurationProperties`	Частично	✅ (Properties)
Отчёт по условиям auto-configuration	✅	✅ (Conditions)
Группировка metrics с живыми графиками и drill-down по тегам	✅	✅ (Metrics)
Вкл./выкл. GC-лога, trigger GC, скачивание GC-лога	❌	✅ (Garbage Collector)
Опрос thread dump в реальном времени + переключатель contention monitoring	✅	✅ (Thread Dump)
Обнаружение интеграций Feign client	❌	✅ (endpoint `axelix-feign`)
Экспорт состояния приложения в ZIP в один клик	Частично	✅ (Details — Download state)
AI и автоматизация
MCP-сервер (Model Context Protocol) для AI-агентов	❌	✅ (MCP, MCP Tools)
Те же операции в UI и у MCP-клиентов	❌	✅
Обзор парка
Wallboard всех инстансов с health	✅	✅ (Wallboard)
Фильтры по версиям (Spring Boot, Java, Framework, Kotlin)	Частично	✅
Discovery в Kubernetes / Docker Compose	✅ (через Spring Cloud / своё)	✅ (Что такое Master)

См. также

Введение — что такое Axelix.
Мотивация — задачи, ради которых создан Axelix.
Что такое Master — discovery и консоль управления.
Настройка Master — JAR, Docker, Helm, Compose.
Возможности — справочник по экранам управляемых инстансов.