Рубрики
Без рубрики

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

Краткое введение в приводы Spring Boot – использование и расширение существующих, настройка и прокатка ваших собственных.

Автор оригинала: José Carlos Valero Sánchez.

1. Обзор

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

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

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

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

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

  • Что такое Привод?
  • Пружинный ботинок 2.x Привод
  • Пружинный ботинок 1.x Привод

Дальнейшее чтение:

Настройка веб-приложения Spring Boot

Создание пользовательского стартера с помощью Spring Boot

Тестирование в весенней загрузке

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

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

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

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

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

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

2.1. Начало работы

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

В Maven:


    org.springframework.boot
    spring-boot-starter-actuator

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

3. Пружинный ботинок 2.Привод x

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более подробную информацию мы можем найти в официальных документах совершенно новый привод .

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

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

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

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

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

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

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

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

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

Поэтому, если мы отправим запрос 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
}

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

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

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

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

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

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

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

@Component
public class DownstreamServiceHealthIndicator implements ReactiveHealthIndicator {

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

    private Mono 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

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

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

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

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

В этом случае, если мы отправим запрос на /привод/здоровье/обычай , то:

{"status":"UP"}

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

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

Теперь, если мы отправим тот же запрос в /привод/здоровье/обычай, мы увидим более подробную информацию:

{
  "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, если статус custom group |/UP.

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

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

Вместо этого мы должны взаимодействовать с Микрометром напрямую. В Spring Boot 2.0 мы получим боб типа Meter Registry autoconfigured для нас.

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

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

{
  "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 :


    pl.project13.maven
    git-commit-id-plugin

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


    org.springframework.boot
    spring-boot-maven-plugin
    
        
            
                build-info

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

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

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

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

    private Map features = new ConcurrentHashMap<>();

    @ReadOperation
    public Map 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 
    }

}

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

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

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

  • @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,) .
  • В отличие от 1.x, больше нет необходимости расширять данный интерфейс.
  • В отличие от старой модели чтения/записи, теперь мы можем определять операции DELETE с помощью @DeleteOperation .

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

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

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

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

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

    private InfoEndpoint delegate;

    // standard constructor

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

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

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

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

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

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

management.endpoints.web.exposure.include=*

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

management.endpoint.shutdown.enabled=true

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

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

4. Пружинный ботинок 1.Привод x

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3./конечная точка работоспособности

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

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

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

{
    "status" : "UP"
}

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

Некоторая информация, возвращаемая Индикатором работоспособности , является конфиденциальной по своей природе, но мы можем настроить 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.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,
    ...
}

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

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

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

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

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

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

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

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

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

Выход:

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

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

В целях безопасности мы можем предоставить конечные точки привода через нестандартный порт-свойство management.port можно легко использовать для его настройки.

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

Следовательно, мы можем изменить свойство management.address , чтобы ограничить доступ к конечным точкам по сети:

#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

Кроме того, все встроенные конечные точки, кроме /info , по умолчанию чувствительны.

Если приложение использует Spring Security, мы можем защитить эти конечные точки, определив свойства безопасности по умолчанию (имя пользователя, пароль и роль) в файле application.properties :

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

5. Заключение

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

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

Затем мы обсудили привод в более ранней версии Spring Boot 1.

Наконец, мы продемонстрировали, как настроить и расширить привод.

Как всегда, код, используемый в этой статье, можно найти на GitHub как для Spring Boot 2.x , так и для Spring Boot 1.x .

Читайте ещё по теме: