Привод пружинного ботинка

1. Обзор

В этой статье мы представляем Spring Boot Actuator. Сначала мы рассмотрим основы, а затем подробно обсудим, что доступно в Spring Boot 2.x и 1.x.

Мы узнаем, как использовать, настраивать и расширять этот инструмент мониторинга в Spring Boot 2.x и WebFlux, используя преимущества модели реактивного программирования. Затем мы обсудим, как сделать то же самое с помощью Boot 1.x.

Spring Boot Actuator доступен с апреля 2014 года вместе с первым выпуском Spring Boot.

С выпуском Spring Boot 2 Actuator был переработан, и были добавлены новые захватывающие конечные точки.

Мы разделили это руководство на три основных раздела:

• Что такое актуатор?
• Привод Spring Boot 2.x
• Spring Boot 1.x Актуатор

2. Что такое привод?

По сути, Actuator привносит в наше приложение готовые к работе функции.

Мониторинг нашего приложения, сбор метрик, понимание трафика или состояние нашей базы данных становятся тривиальными с этой зависимостью.

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

Actuator в основном используется для предоставления оперативной информации о запущенном приложении — работоспособности, метриках, информации, дампе, env и т. д. Он использует конечные точки HTTP или JMX-бины, чтобы мы могли взаимодействовать с ним.

Как только эта зависимость находится в пути к классам, несколько конечных точек доступны нам из коробки. Как и в случае с большинством модулей Spring, мы можем легко настроить или расширить его разными способами.

2.1. Начиная

Чтобы включить Spring Boot Actuator, нам просто нужно добавить зависимость spring-boot-actuator в наш менеджер пакетов.

В Мавене:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Обратите внимание, что это остается в силе независимо от версии загрузки, поскольку версии указаны в Спецификации материалов (BOM) Spring Boot.

3. Активатор Spring Boot 2.x

В версии 2.x Actuator сохраняет свою основную цель, но упрощает модель, расширяет возможности и включает лучшие значения по умолчанию.

Во-первых, эта версия становится независимой от технологии. Он также упрощает свою модель безопасности, объединяя ее с моделью приложения.

Среди различных изменений важно иметь в виду, что некоторые из них ломаются. Сюда входят HTTP-запросы и ответы, а также API-интерфейсы Java.

Наконец, последняя версия теперь поддерживает модель CRUD, а не старую модель чтения/записи.

3.1. Технологическая поддержка

В своей второй основной версии Actuator теперь не зависит от технологии, тогда как в 1.x он был привязан к MVC, то есть к Servlet API.

В версии 2.x Actuator определяет свою модель как подключаемую и расширяемую, не полагаясь для этого на MVC.

Следовательно, с этой новой моделью мы можем использовать преимущества MVC, а также WebFlux в качестве базовой веб-технологии.

Кроме того, будущие технологии могут быть добавлены путем внедрения правильных адаптеров.

Наконец, JMX по-прежнему поддерживается для предоставления конечных точек без дополнительного кода.

3.2. Важные изменения

В отличие от предыдущих версий, в Actuator отключено большинство конечных точек.

Таким образом, по умолчанию доступны только два файла: /health и /info .

Если мы хотим включить их все, мы можем установить management.endpoints.web.exposure.include=* . В качестве альтернативы мы можем перечислить конечные точки, которые должны быть включены.

Actuator теперь разделяет конфигурацию безопасности с обычными правилами безопасности приложений, поэтому модель безопасности значительно упрощается.

Поэтому, чтобы настроить правила безопасности Actuator, мы можем просто добавить запись для /actuator/** :

@Bean
public SecurityWebFilterChain securityWebFilterChain(
  ServerHttpSecurity http) {
    return http.authorizeExchange()
      .pathMatchers("/actuator/**").permitAll()
      .anyExchange().authenticated()
      .and().build();
}

Мы можем найти более подробную информацию о новой официальной документации Actuator .

Кроме того, по умолчанию все конечные точки Actuator теперь размещаются по пути / actuator .

Как и в предыдущей версии, мы можем настроить этот путь, используя новое свойство management.endpoints.web.base-path .

3.3. Предопределенные конечные точки

Давайте посмотрим на некоторые доступные конечные точки, большинство из которых уже были доступны в версии 1.x.

Кроме того, некоторые конечные точки были добавлены, некоторые удалены, а некоторые реструктурированы :

• /auditevents перечисляет события, связанные с аудитом безопасности, такие как вход/выход пользователя. Кроме того, мы можем фильтровать по принципалу или типу среди других полей.
• /beans возвращает все доступные bean-компоненты в нашей BeanFactory . В отличие от /auditevents , он не поддерживает фильтрацию.
• /conditions , ранее известный как / autoconfig , создает отчет об условиях автоконфигурации.
• /configprops позволяет нам получить все bean-компоненты @ConfigurationProperties .
• /env возвращает текущие свойства среды. Кроме того, мы можем получить отдельные свойства.
• /flyway предоставляет подробную информацию о миграции базы данных Flyway.
• /health обобщает состояние работоспособности нашего приложения.
• /heapdump создает и возвращает дамп кучи из JVM, используемой нашим приложением.
• /info возвращает общую информацию. Это могут быть пользовательские данные, информация о сборке или сведения о последнем коммите.
• /liquibase ведет себя как / flyway, но для Liquibase.
• /logfile возвращает обычные журналы приложений.
• /loggers позволяет нам запрашивать и изменять уровень ведения журнала нашего приложения.
• /metrics детализирует метрики нашего приложения. Это могут быть как общие показатели, так и пользовательские.
• /prometheus возвращает метрики, подобные предыдущему, но отформатированные для работы с сервером Prometheus.
• /scheduledtasks предоставляет подробную информацию о каждой запланированной задаче в нашем приложении.
• /sessions перечисляет HTTP-сессии, учитывая, что мы используем Spring Session.
• /shutdown выполняет корректное завершение работы приложения.
• /threaddump выводит информацию о потоках базовой JVM.

3.4. Гипермедиа для оконечных устройств актуатора

Spring Boot добавляет конечную точку обнаружения, которая возвращает ссылки на все доступные конечные точки привода. Это облегчит обнаружение конечных точек привода и соответствующих им URL-адресов.

По умолчанию эта конечная точка обнаружения доступна через конечную точку /actuator .

Поэтому, если мы отправим запрос GET на этот URL-адрес, он вернет ссылки на активаторы для различных конечных точек:

{
  "_links": {
    "self": {
      "href": "http://localhost:8080/actuator",
      "templated": false
    },
    "features-arg0": {
      "href": "http://localhost:8080/actuator/features/{arg0}",
      "templated": true
    },
    "features": {
      "href": "http://localhost:8080/actuator/features",
      "templated": false
    },
    "beans": {
      "href": "http://localhost:8080/actuator/beans",
      "templated": false
    },
    "caches-cache": {
      "href": "http://localhost:8080/actuator/caches/{cache}",
      "templated": true
    },
    // truncated
}

Как показано выше, конечная точка /actuator сообщает обо всех доступных конечных точках привода в поле _links .

Более того, если мы настроим собственный базовый путь управления, мы должны использовать этот базовый путь в качестве URL-адреса обнаружения.

Например, если мы установили для management.endpoints.web.base-path значение /mgmt , то мы должны отправить запрос на конечную точку /mgmt , чтобы увидеть список ссылок.

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

3.5. Показатели здоровья

Как и в предыдущей версии, мы можем легко добавлять собственные индикаторы. В отличие от других API, абстракции для создания настраиваемых конечных точек работоспособности остаются неизменными. Однако был добавлен новый интерфейс ReactiveHealthIndicator для реализации реактивных проверок работоспособности.

Давайте взглянем на простую пользовательскую реактивную проверку работоспособности:

@Component
public class DownstreamServiceHealthIndicator implements ReactiveHealthIndicator {

    @Override
    public Mono<Health> health() {
        return checkDownstreamServiceHealth().onErrorResume(
          ex -> Mono.just(new Health.Builder().down(ex).build())
        );
    }

    private Mono<Health> checkDownstreamServiceHealth() {
        // we could use WebClient to check health reactively
        return Mono.just(new Health.Builder().up().build());
    }
}

Удобной особенностью индикаторов здоровья является то, что мы можем агрегировать их как часть иерархии.

Итак, следуя предыдущему примеру, мы могли бы сгруппировать все нижестоящие сервисы в категорию нижестоящих сервисов . Эта категория будет работоспособной, если будет доступна каждая вложенная служба .

Ознакомьтесь с нашей статьей о показателях здоровья для более подробного ознакомления.

3.6. Группы здоровья

Начиная с Spring Boot 2.2, мы можем организовать индикаторы работоспособности в группы и применить одну и ту же конфигурацию ко всем членам группы.

Например, мы можем создать группу здоровья с именем custom , добавив это в наш application.properties :

management.endpoint.health.group.custom.include=diskSpace,ping

Таким образом, настраиваемая группа содержит индикаторы работоспособности diskSpace и ping .

Теперь, если мы вызовем конечную точку /actuator/health , она расскажет нам о новой группе здоровья в ответе JSON:

{"status":"UP","groups":["custom"]}

С группами здоровья мы можем видеть агрегированные результаты нескольких показателей здоровья.

В этом случае, если мы отправим запрос на /actuator/health/custom , то:

{"status":"UP"}

Мы можем настроить группу для отображения более подробной информации через application.properties :

management.endpoint.health.group.custom.show-components=always
management.endpoint.health.group.custom.show-details=always

Теперь, если мы отправим тот же запрос в /actuator/health/custom, мы увидим больше деталей:

{
  "status": "UP",
  "components": {
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 499963170816,
        "free": 91300069376,
        "threshold": 10485760
      }
    },
    "ping": {
      "status": "UP"
    }
  }
}

Также возможно показать эти данные только для авторизованных пользователей:

management.endpoint.health.group.custom.show-components=when_authorized
management.endpoint.health.group.custom.show-details=when_authorized

У нас также может быть пользовательское отображение статуса.

Например, вместо ответа HTTP 200 OK он может вернуть код состояния 207:

management.endpoint.health.group.custom.status.http-mapping.up=207

Здесь мы указываем Spring Boot возвращать код состояния HTTP 207, если статус пользовательской группы — UP.

3.7. Метрики в Spring Boot 2

В Spring Boot 2.0 внутренние метрики были заменены поддержкой Micrometer , так что можно ожидать критических изменений. Если наше приложение использовало службы метрик, такие как GaugeService или CounterService , они больше не будут доступны.

Вместо этого ожидается, что мы будем взаимодействовать с Micrometer напрямую. В Spring Boot 2.0 мы получим bean-компонент типа MeterRegistry , настроенный для нас автоматически.

Кроме того, Micrometer теперь является частью зависимостей Actuator, поэтому мы должны быть в порядке, пока зависимость Actuator находится в пути к классам.

Более того, мы получим совершенно новый ответ от конечной точки /metrics :

{
  "names": [
    "jvm.gc.pause",
    "jvm.buffer.memory.used",
    "jvm.memory.used",
    "jvm.buffer.count",
    // ...
  ]
}

Как мы видим, реальных метрик, как мы получили в 1.x, нет.

Чтобы получить фактическое значение конкретной метрики, теперь мы можем перейти к нужной метрике, например, /actuator/metrics/jvm.gc.pause , и получить подробный ответ:

{
  "name": "jvm.gc.pause",
  "measurements": [
    {
      "statistic": "Count",
      "value": 3.0
    },
    {
      "statistic": "TotalTime",
      "value": 7.9E7
    },
    {
      "statistic": "Max",
      "value": 7.9E7
    }
  ],
  "availableTags": [
    {
      "tag": "cause",
      "values": [
        "Metadata GC Threshold",
        "Allocation Failure"
      ]
    },
    {
      "tag": "action",
      "values": [
        "end of minor GC",
        "end of major GC"
      ]
    }
  ]
}

Теперь метрики гораздо более подробные, включая не только различные значения, но и некоторые связанные метаданные.

3.8. Настройка конечной точки / info

Конечная точка /info остается неизменной. Как и прежде, мы можем добавить детали git, используя соответствующую зависимость Maven или Gradle :

<dependency>
    <groupId>pl.project13.maven</groupId>
    <artifactId>git-commit-id-plugin</artifactId>
</dependency>

Точно так же мы могли бы также включить информацию о сборке, включая имя, группу и версию, используя плагин Maven или Gradle :

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>build-info</goal>
            </goals>
        </execution>
    </executions>
</plugin>

3.9. Создание пользовательской конечной точки

Как мы указывали ранее, мы можем создавать собственные конечные точки. Тем не менее, Spring Boot 2 изменил способ достижения этого, чтобы поддерживать новую парадигму, не зависящую от технологий.

Давайте создадим конечную точку Actuator для запроса, включения и отключения флагов функций в нашем приложении :

@Component
@Endpoint(id = "features")
public class FeaturesEndpoint {

    private Map<String, Feature> features = new ConcurrentHashMap<>();

    @ReadOperation
    public Map<String, Feature> features() {
        return features;
    }

    @ReadOperation
    public Feature feature(@Selector String name) {
        return features.get(name);
    }

    @WriteOperation
    public void configureFeature(@Selector String name, Feature feature) {
        features.put(name, feature);
    }

    @DeleteOperation
    public void deleteFeature(@Selector String name) {
        features.remove(name);
    }

    public static class Feature {
        private Boolean enabled;

        // [...] getters and setters 
    }

}

Чтобы получить конечную точку, нам нужен bean-компонент. В нашем примере мы используем для этого @Component . Кроме того, нам нужно украсить этот компонент @Endpoint .

Путь нашей конечной точки определяется параметром id @Endpoint. В нашем случае он будет направлять запросы в /actuator/features .

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

• @ReadOperation : он будет отображаться в HTTP GET .
• @WriteOperation : он будет отображаться в HTTP POST .
• @DeleteOperation : он будет сопоставлен с HTTP DELETE .

Когда мы запускаем приложение с предыдущей конечной точкой в нашем приложении, Spring Boot зарегистрирует ее.

Быстрый способ проверить это — проверить журналы:

[...].WebFluxEndpointHandlerMapping: Mapped "{[/actuator/features/{name}],
  methods=[GET],
  produces=[application/vnd.spring-boot.actuator.v2+json || application/json]}"
[...].WebFluxEndpointHandlerMapping : Mapped "{[/actuator/features],
  methods=[GET],
  produces=[application/vnd.spring-boot.actuator.v2+json || application/json]}"
[...].WebFluxEndpointHandlerMapping : Mapped "{[/actuator/features/{name}],
  methods=[POST],
  consumes=[application/vnd.spring-boot.actuator.v2+json || application/json]}"
[...].WebFluxEndpointHandlerMapping : Mapped "{[/actuator/features/{name}],
  methods=[DELETE]}"[...]

В предыдущих журналах мы видим, как WebFlux раскрывает нашу новую конечную точку. Если мы переключимся на MVC, он просто делегирует эту технологию без необходимости изменения кода.

Кроме того, у нас есть несколько важных соображений, которые следует учитывать при использовании этого нового подхода:

• Нет никаких зависимостей с MVC.
• Все метаданные, представленные ранее в виде методов ( чувствительные, включенные…), больше не существуют. Однако мы можем включить или отключить конечную точку, используя @Endpoint(id = «features», enableByDefault = false) .
• В отличие от 1.x, больше нет необходимости расширять данный интерфейс.
• В отличие от старой модели чтения/записи, теперь мы можем определять операции DELETE с помощью @DeleteOperation .

3.10. Расширение существующих конечных точек

Давайте представим, что мы хотим убедиться, что производственный экземпляр нашего приложения никогда не будет версией SNAPSHOT .

Мы решили сделать это, изменив код состояния HTTP конечной точки Actuator, которая возвращает эту информацию, т . е. /info . Если бы наше приложение оказалось SNAPSHOT , мы бы получили другой код состояния HTTP .

Мы можем легко расширить поведение предопределенной конечной точки с помощью аннотаций @EndpointExtension или ее более конкретных специализаций @EndpointWebExtension или @EndpointJmxExtension :

@Component
@EndpointWebExtension(endpoint = InfoEndpoint.class)
public class InfoWebEndpointExtension {

    private InfoEndpoint delegate;

    // standard constructor

    @ReadOperation
    public WebEndpointResponse<Map> info() {
        Map<String, Object> info = this.delegate.info();
        Integer status = getStatus(info);
        return new WebEndpointResponse<>(info, status);
    }

    private Integer getStatus(Map<String, Object> info) {
        // return 5xx if this is a snapshot
        return 200;
    }
}

3.11. Включить все конечные точки

Чтобы получить доступ к конечным точкам привода с помощью HTTP, нам нужно включить и открыть их.

По умолчанию все конечные точки, кроме /shutdown , включены. По умолчанию доступны только конечные точки / health и /info .

Нам нужно добавить следующую конфигурацию, чтобы открыть все конечные точки:

management.endpoints.web.exposure.include=*

Чтобы явно включить конкретную конечную точку (например, /shutdown), мы используем:

management.endpoint.shutdown.enabled=true

Чтобы открыть все включенные конечные точки, кроме одной (например, /loggers ), мы используем:

management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=loggers

4. Привод Spring Boot 1.x

В версии 1.x Actuator следует модели чтения/записи, что означает, что мы можем либо читать из него, либо записывать в него.

Например, мы можем получить метрики или работоспособность нашего приложения. В качестве альтернативы мы могли бы изящно завершить наше приложение или изменить конфигурацию ведения журнала.

Чтобы заставить его работать, Actuator требует, чтобы Spring MVC открывал свои конечные точки через HTTP. Другие технологии не поддерживаются.

4.1. Конечные точки

В версии 1.x Actuator предлагает собственную модель безопасности. Он использует преимущества конструкций Spring Security, но его необходимо настраивать независимо от остальной части приложения.

Кроме того, большинство конечных точек являются конфиденциальными — это означает, что они не полностью общедоступны, или большая часть информации будет опущена — в то время как некоторые не являются таковыми, например, /info .

Вот некоторые из наиболее распространенных конечных точек, которые Boot предоставляет по умолчанию:

• /health показывает информацию о работоспособности приложения (простой статус при доступе через неаутентифицированное соединение или полные сведения о сообщении при аутентификации); по умолчанию он не чувствителен.
• /info отображает произвольную информацию о приложении; по умолчанию он не чувствителен.
• /metrics показывает информацию о метриках для текущего приложения; он чувствителен по умолчанию.
• /trace отображает информацию о трассировке (по умолчанию несколько последних HTTP-запросов).

Мы можем найти полный список существующих конечных точек в официальной документации .

4.2. Настройка существующих конечных точек

Мы можем настроить каждую конечную точку со свойствами, используя формат endpoints.[имя конечной точки].[свойство для настройки] .

Доступны три свойства:

• id : по которому эта конечная точка будет доступна через HTTP
• enabled : если правда, то к нему можно получить доступ; иначе не
• чувствительный : если это правда, то требуется авторизация для отображения важной информации по HTTP.

Например, добавление следующих свойств настроит конечную точку / beans :

endpoints.beans.id=springbeans
endpoints.beans.sensitive=false
endpoints.beans.enabled=true

4.3. /здоровье Конечная точка

Конечная точка /health используется для проверки работоспособности или состояния работающего приложения.

Обычно это осуществляется с помощью программного обеспечения для мониторинга, чтобы предупредить нас, если работающий экземпляр выходит из строя или становится неработоспособным по другим причинам, например, из-за проблем с подключением к нашей БД, нехватки места на диске и т. д.

По умолчанию неавторизованные пользователи могут видеть информацию о состоянии только при доступе через HTTP:

{
    "status" : "UP"
}

Эта информация о работоспособности собирается из всех bean-компонентов, реализующих интерфейс HealthIndicator , сконфигурированный в контексте нашего приложения.

Некоторая информация, возвращаемая HealthIndicator , является конфиденциальной по своей природе, но мы можем настроить endpoints.health.sensitive=false для предоставления более подробной информации, такой как место на диске, подключение к брокеру обмена сообщениями, пользовательские проверки и многое другое.

Обратите внимание, что это работает только для версий Spring Boot ниже 1.5.0. Для 1.5.0 и более поздних версий мы также должны отключить безопасность, установив management.security.enabled=false для несанкционированного доступа.

Мы также могли бы реализовать собственный настраиваемый индикатор работоспособности , который может собирать любые настраиваемые данные о работоспособности, характерные для приложения, и автоматически предоставлять их через конечную точку /health :

@Component("myHealthCheck")
public class HealthCheck implements HealthIndicator {
 
    @Override
    public Health health() {
        int errorCode = check(); // perform some specific health check
        if (errorCode != 0) {
            return Health.down()
              .withDetail("Error Code", errorCode).build();
        }
        return Health.up().build();
    }
    
    public int check() {
        // Our logic to check health
        return 0;
    }
}

Вот как будет выглядеть вывод:

{
    "status" : "DOWN",
    "myHealthCheck" : {
        "status" : "DOWN",
        "Error Code" : 1
     },
     "diskSpace" : {
         "status" : "UP",
         "free" : 209047318528,
         "threshold" : 10485760
     }
}

4.4. /info Конечная точка

Мы также можем настроить данные, отображаемые конечной точкой /info :

info.app.name=Spring Sample Application
info.app.description=This is my first spring boot application
info.app.version=1.0.0

И образец вывода:

{
    "app" : {
        "version" : "1.0.0",
        "description" : "This is my first spring boot application",
        "name" : "Spring Sample Application"
    }
}

4.5. /метрики Конечная точка

Конечная точка метрик публикует информацию об ОС и JVM, а также метрики на уровне приложения. После включения мы получаем такую информацию, как память, куча, процессоры, потоки, загруженные классы, выгруженные классы и пулы потоков, а также некоторые метрики HTTP.

Вот как выглядит вывод этой конечной точки из коробки:

{
    "mem" : 193024,
    "mem.free" : 87693,
    "processors" : 4,
    "instance.uptime" : 305027,
    "uptime" : 307077,
    "systemload.average" : 0.11,
    "heap.committed" : 193024,
    "heap.init" : 124928,
    "heap.used" : 105330,
    "heap" : 1764352,
    "threads.peak" : 22,
    "threads.daemon" : 19,
    "threads" : 22,
    "classes" : 5819,
    "classes.loaded" : 5819,
    "classes.unloaded" : 0,
    "gc.ps_scavenge.count" : 7,
    "gc.ps_scavenge.time" : 54,
    "gc.ps_marksweep.count" : 1,
    "gc.ps_marksweep.time" : 44,
    "httpsessions.max" : -1,
    "httpsessions.active" : 0,
    "counter.status.200.root" : 1,
    "gauge.response.root" : 37.0
}

Для сбора пользовательских метрик у нас есть поддержка датчиков (моментальные снимки данных с одним значением) и счетчиков, то есть увеличение/уменьшение показателей.

Давайте реализуем наши собственные метрики в конечной точке /metrics .

Мы настроим процесс входа в систему, чтобы записывать успешные и неудачные попытки входа:

@Service
public class LoginServiceImpl {

    private final CounterService counterService;
    
    public LoginServiceImpl(CounterService counterService) {
        this.counterService = counterService;
    }
    
    public boolean login(String userName, char[] password) {
        boolean success;
        if (userName.equals("admin") && "secret".toCharArray().equals(password)) {
            counterService.increment("counter.login.success");
            success = true;
        }
        else {
            counterService.increment("counter.login.failure");
            success = false;
        }
        return success;
    }
}

Вот как может выглядеть вывод:

{
    ...
    "counter.login.success" : 105,
    "counter.login.failure" : 12,
    ...
}

Обратите внимание, что попытки входа в систему и другие события, связанные с безопасностью, доступны по умолчанию в Actuator как события аудита.

4.6. Создание новой конечной точки

Помимо использования существующих конечных точек, предоставляемых Spring Boot, мы также можем создать совершенно новую.

Во-первых, нам нужно, чтобы новая конечная точка реализовала интерфейс Endpoint<T> :

@Component
public class CustomEndpoint implements Endpoint<List<String>> {
    
    @Override
    public String getId() {
        return "customEndpoint";
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

    @Override
    public boolean isSensitive() {
        return true;
    }

    @Override
    public List<String> invoke() {
        // Custom logic to build the output
        List<String> messages = new ArrayList<String>();
        messages.add("This is message 1");
        messages.add("This is message 2");
        return messages;
    }
}

Чтобы получить доступ к этой новой конечной точке, ее идентификатор используется для ее сопоставления. Другими словами, мы могли бы использовать его, нажимая /customEndpoint .

Выход:

[ "This is message 1", "This is message 2" ]

4.7. Дальнейшая настройка

Из соображений безопасности мы можем сделать так, чтобы конечные точки актуатора отображались через нестандартный порт — для этого можно легко использовать свойство management.port .

Also, as we already mentioned, in 1.x. Actuator configures its own security model based on Spring Security but independent from the rest of the application.

Hence, we can change the management.address property to restrict where the endpoints can be accessed from over the network:

#port used to expose actuator
management.port=8081 

#CIDR allowed to hit actuator
management.address=127.0.0.1 

#Whether security should be enabled or disabled altogether
management.security.enabled=false

Besides, all the built-in endpoints except /info are sensitive by default.

If the application is using Spring Security, we can secure these endpoints by defining the default security properties (username, password, and role) in the application.properties file:

security.user.name=admin
security.user.password=secret
management.security.role=SUPERUSER

5. Conclusion

In this article, we talked about Spring Boot Actuator. We began by defining what Actuator means and what it does for us.

Next, we focused on Actuator for the current Spring Boot version 2.x, discussing how to use it, tweak it, and extend it. We also talked about the important security changes that we can find in this new iteration. We discussed some popular endpoints and how they have changed as well.

Then we discussed Actuator in the earlier Spring Boot 1 version.

Lastly, we demonstrated how to customize and extend Actuator.

As always, the code used in this article can be found over on GitHub for both Spring Boot 2.x and Spring Boot 1.x .