Spec-Zone.ru › Spring Boot

Функции, готовые к использованию в производстве

Spring Boot включает ряд дополнительных функций, которые помогут вам отслеживать и управлять вашим приложением при его развертывании в производстве. Вы можете управлять и отслеживать приложение, используя HTTP-точки доступа или JMX. Аудит, проверка работоспособности и сбор метрик также могут быть автоматически применены к вашему приложению.

1. Включение функций, готовых к использованию в производстве

Модуль spring-boot-actuator предоставляет все функции Spring Boot, готовые к использованию в производстве. Рекомендуемый способ включения функций — добавление зависимости от “Starter”.

Определение актуатора

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

Для добавления актуатора в проект на основе Maven добавьте следующую зависимость “Starter”:

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

Для Gradle используйте следующее объявление:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
}

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

Конечные точки Actuator позволяют отслеживать и взаимодействовать с вашим приложением. Spring Boot включает несколько встроенных конечных точек и позволяет добавлять свои собственные. Например, конечная точка health предоставляет основную информацию о работоспособности приложения.

Вы можете включить или отключить каждую отдельную конечную точку и опубликовать их (сделать их удаленно доступными) по HTTP или JMX. Конечная точка считается доступной, когда она включена и опубликована. Встроенные конечные точки настраиваются автоматически только при их доступности. Большинство приложений выбирают публикацию по HTTP, где идентификатор конечной точки и префикс /actuator сопоставляются с URL-адресом. Например, по умолчанию конечная точка health сопоставляется с /actuator/health.

Для получения дополнительной информации о конечных точках Actuator и форматах запросов и ответов см. отдельную документацию API (HTML или PDF).

Доступны следующие технологически независимые конечные точки:

ID Описание

auditevents

Отображает информацию об аудиторных событиях для текущего приложения. Требует bean AuditEventRepository.

beans

Отображает полный список всех Spring bean в вашем приложении.

caches

Отображает доступные кэши.

conditions

Показ условий, которые были проверены в классах конфигурации и автоконфигурации, и причин, по которым они соответствуют или не соответствуют.

configprops

Отображает сводный список всех @ConfigurationProperties.

env

Отображает свойства из ConfigurableEnvironment Spring.

flyway

Отображает все примененные миграции базы данных Flyway. Требует один или несколько bean Flyway.

health

Отображает информацию о работоспособности приложения.

httpexchanges

Отображает информацию о HTTP обмене (по умолчанию последние 100 HTTP запросов-ответов). Требует bean HttpExchangeRepository.

info

Отображает произвольную информацию об приложении.

integrationgraph

Отображает граф Spring Integration. Требуется зависимость от spring-integration-core.

loggers

Отображает и изменяет конфигурацию логгеров в приложении.

liquibase

Отображает все примененные миграции базы данных Liquibase. Требует один или несколько bean Liquibase.

metrics

Отображает информацию «метрики» для текущего приложения.

mappings

Отображает сводный список всех @RequestMapping путей.

quartz

Отображает информацию о задачах планировщика Quartz.

scheduledtasks

Отображает запланированные задачи в вашем приложении.

sessions

Позволяет извлекать и удалять пользовательские сессии из хранилища сессий Spring Session. Требуется приложение на основе сервлетов, использующее Spring Session.

shutdown

Позволяет плавно завершить работу приложения. Работает только при использовании упаковки jar. Отключен по умолчанию.

startup

Отображает данные о шагах запуска, собранные ApplicationStartup. Требуется настройка SpringApplication с BufferingApplicationStartup.

threaddump

Выполняет дамп потоков.

Если ваше приложение является веб-приложением (Spring MVC, Spring WebFlux или Jersey), вы можете использовать следующие дополнительные конечные точки:

ID Описание

heapdump

Возвращает файл дампа кучи. В JVM HotSpot возвращается файл в формате HPROF. В JVM OpenJ9 возвращается файл в формате PHD.

logfile

Возвращает содержимое файла журнала (если установлено свойство logging.file.name или logging.file.path). Поддерживает использование HTTP заголовка Range для получения части содержимого файла журнала.

prometheus

Отображает метрики в формате, который может быть собран сервером Prometheus. Требуется зависимость от micrometer-registry-prometheus.

2.1. Включение конечных точек

По умолчанию все конечные точки, кроме shutdown, включены. Для настройки включения конечной точки используйте свойство management.endpoint.<id>.enabled. Следующий пример включает конечную точку shutdown:

Свойства
management.endpoint.shutdown.enabled=true
Yaml
management:
  endpoint:
    shutdown:
      enabled: true

Если вы предпочитаете, чтобы включение конечных точек было выборочным (opt-in), а не по умолчанию (opt-out), установите свойство management.endpoints.enabled-by-default в false и используйте отдельные свойства конечных точек enabled для повторного включения. Следующий пример включает конечную точку info и отключает все остальные конечные точки:

Свойства
management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=true
Yaml
management:
  endpoints:
    enabled-by-default: false
  endpoint:
    info:
      enabled: true
Отключенные конечные точки полностью удаляются из контекста приложения. Если вы хотите изменить только технологии, через которые доступна конечная точка, используйте свойства include и exclude вместо этого.

2.2. Предоставление доступа к конечным точкам

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

Чтобы изменить доступные конечные точки, используйте следующие свойства, специфичные для технологий: include и exclude.

Свойство Значение по умолчанию

management.endpoints.jmx.exposure.exclude

management.endpoints.jmx.exposure.include

health

management.endpoints.web.exposure.exclude

management.endpoints.web.exposure.include

health

Свойство include перечисляет идентификаторы конечных точек, которые должны предоставляться. Свойство exclude перечисляет идентификаторы конечных точек, которые не должны предоставляться. Свойство exclude имеет приоритет над свойством include. Оба свойства include и exclude можно настроить, указав список идентификаторов конечных точек.

Например, чтобы предоставить доступ только к конечным точкам health и info через JMX, используйте следующее свойство:

Свойства
management.endpoints.jmx.exposure.include=health,info
Yaml
management:
  endpoints:
    jmx:
      exposure:
        include: "health,info"

* можно использовать для выбора всех конечных точек. Например, чтобы предоставить доступ ко всем конечным точкам через HTTP, за исключением конечных точек env и beans, используйте следующие свойства:

Свойства
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env,beans
Yaml
management:
  endpoints:
    web:
      exposure:
        include: "*"
        exclude: "env,beans"
* имеет специальное значение в YAML, поэтому убедитесь, что вы добавили кавычки, если хотите включить (или исключить) все конечные точки.
Если ваше приложение доступно публично, настоятельно рекомендуем также защитить конечные точки.
Если необходимо реализовать собственную стратегию предоставления доступа к конечным точкам, можно зарегистрировать bean EndpointFilter.

2.3. Безопасность

В целях безопасности по умолчанию доступна только конечная точка /health через HTTP. Для настройки доступных конечных точек используйте свойство management.endpoints.web.exposure.include.

Перед настройкой management.endpoints.web.exposure.include, убедитесь, что предоставляемые актуаторы не содержат конфиденциальной информации, защищены брандмауэром или защищены чем-то вроде Spring Security.

Если Spring Security присутствует в classpath и нет других bean SecurityFilterChain, все актуаторы, кроме /health, защищены с помощью автоматической настройки Spring Boot. Если вы определите свой bean SecurityFilterChain, автоматическая настройка Spring Boot отключается, и вы получите полный контроль над правилами доступа к актуаторам.

Если требуется настроить пользовательскую безопасность для HTTP-конечных точек (например, разрешить доступ только пользователям с определённой ролью), Spring Boot предоставляет удобные объекты RequestMatcher, которые можно использовать совместно с Spring Security.

Типичная конфигурация Spring Security может выглядеть примерно так:

Java
import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

import static org.springframework.security.config.Customizer.withDefaults;

@Configuration(proxyBeanMethods = false)
public class MySecurityConfiguration {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.securityMatcher(EndpointRequest.toAnyEndpoint());
        http.authorizeHttpRequests((requests) -> requests.anyRequest().hasRole("ENDPOINT_ADMIN"));
        http.httpBasic(withDefaults());
        return http.build();
    }

}
Kotlin
import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.security.config.Customizer.withDefaults
import org.springframework.security.config.annotation.web.builders.HttpSecurity
import org.springframework.security.web.SecurityFilterChain

@Configuration(proxyBeanMethods = false)
class MySecurityConfiguration {

    @Bean
    fun securityFilterChain(http: HttpSecurity): SecurityFilterChain {
        http.securityMatcher(EndpointRequest.toAnyEndpoint()).authorizeHttpRequests { requests ->
            requests.anyRequest().hasRole("ENDPOINT_ADMIN")
        }
        http.httpBasic(withDefaults())
        return http.build()
    }

}

В приведенном примере используется EndpointRequest.toAnyEndpoint() для соответствия запроса любой конечной точке и гарантирует, что все имеют роль ENDPOINT_ADMIN. На объекте EndpointRequest доступны и другие методы сопоставления. Подробности см. в документации API (HTML или PDF).

Если приложения развернуты за брандмауэром, предпочтительнее, чтобы ко всем конечным точкам актуаторов можно было получить доступ без необходимости авторизации. Это можно сделать, изменив свойство management.endpoints.web.exposure.include следующим образом:

Свойства
management.endpoints.web.exposure.include=*
Yaml
management:
  endpoints:
    web:
      exposure:
        include: "*"

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

Java
import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration(proxyBeanMethods = false)
public class MySecurityConfiguration {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.securityMatcher(EndpointRequest.toAnyEndpoint());
        http.authorizeHttpRequests((requests) -> requests.anyRequest().permitAll());
        return http.build();
    }

}
Kotlin
import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.security.config.annotation.web.builders.HttpSecurity
import org.springframework.security.web.SecurityFilterChain

@Configuration(proxyBeanMethods = false)
class MySecurityConfiguration {

    @Bean
    fun securityFilterChain(http: HttpSecurity): SecurityFilterChain {
        http.securityMatcher(EndpointRequest.toAnyEndpoint()).authorizeHttpRequests { requests ->
            requests.anyRequest().permitAll()
        }
        return http.build()
    }

}
В обоих приведенных примерах конфигурация применяется только к конечным точкам актуатора. Поскольку конфигурация безопасности Spring Boot полностью отключается при наличии любого bean SecurityFilterChain, необходимо настроить дополнительный bean SecurityFilterChain с правилами, которые применяются к остальной части приложения.

2.3.1. Защита от межсайтовых поддельных запросов (CSRF)

Поскольку Spring Boot полагается на значения по умолчанию Spring Security, защита от CSRF включена по умолчанию. Это означает, что для конечных точек актуаторов, требующих POST (конечные точки остановки и логгеров), PUT или DELETE, будет возвращаться ошибка 403 (запрещено), когда используется конфигурация безопасности по умолчанию.

Рекомендуется полностью отключить защиту от CSRF только если вы создаете сервис, который используется не веб-клиентами.

Дополнительную информацию о защите от CSRF можно найти в Руководстве по Spring Security.

2.4. Настройка конечных точек

Конечные точки автоматически кэшируют ответы для операций чтения, которые не принимают параметров. Чтобы настроить время, в течение которого конечная точка кэширует ответ, используйте свойство cache.time-to-live данной конечной точки. В следующем примере время жизни кэша конечной точки beans устанавливается в 10 секунд:

Свойства
management.endpoint.beans.cache.time-to-live=10s
Yaml
management:
  endpoint:
    beans:
      cache:
        time-to-live: "10s"
Префикс management.endpoint.<name> однозначно идентифицирует конфигурируемую конечную точку.

2.5. Гипермедиа для веб-конечных точек актуатора

Добавлена страница «обнаружения» со ссылками на все конечные точки. Страница «обнаружения» доступна по адресу /actuator по умолчанию.

Чтобы отключить страницу «обнаружения», добавьте следующее свойство в свойства вашего приложения:

Свойства
management.endpoints.web.discovery.enabled=false
Yaml
management:
  endpoints:
    web:
      discovery:
        enabled: false

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

2.6. Поддержка CORS

Обмен ресурсами с разных доменов (CORS) — это спецификация W3C, которая позволяет гибко определять, какие запросы с разных доменов разрешены. Если вы используете Spring MVC или Spring WebFlux, вы можете настроить веб-точки доступа Actuator для поддержки таких сценариев.

Поддержка CORS по умолчанию отключена и включается только после настройки свойства management.endpoints.web.cors.allowed-origins. Следующая конфигурация разрешает GET и POST вызовы с домена example.com.

Свойства
management.endpoints.web.cors.allowed-origins=https://example.com
management.endpoints.web.cors.allowed-methods=GET,POST
Yaml
management:
  endpoints:
    web:
      cors:
        allowed-origins: "https://example.com"
        allowed-methods: "GET,POST"
Смотрите CorsEndpointProperties для полного списка опций.

2.7. Реализация пользовательских конечных точек

Если вы добавите @Bean с аннотацией @Endpoint, все методы, помеченные аннотациями @ReadOperation, @WriteOperation, или @DeleteOperation, будут автоматически доступны через JMX и, в веб-приложении, также через HTTP. Конечные точки могут быть доступны через HTTP с использованием Jersey, Spring MVC или Spring WebFlux. Если доступны как Jersey, так и Spring MVC, используется Spring MVC.

Следующий пример демонстрирует операцию чтения, возвращающую пользовательский объект:

Java
@ReadOperation
public CustomData getData() {
    return new CustomData("test", 5);
}
Kotlin
@ReadOperation
fun getData(): CustomData {
    return CustomData("test", 5)
}

Вы также можете создавать технологически-специфичные конечные точки, используя @JmxEndpoint или @WebEndpoint. Эти конечные точки ограничены соответствующими технологиями. Например, @WebEndpoint доступна только через HTTP, а не через JMX.

Вы можете создавать технологически-специфичные расширения, используя @EndpointWebExtension и @EndpointJmxExtension. Эти аннотации позволяют вам предоставлять технологически-специфические операции для дополнения существующей конечной точки.

Наконец, если вам нужен доступ к функциональности, специфичной для веб-фреймворка, вы можете реализовать конечные точки сервлетов или Spring @Controller и @RestController, но в этом случае они не будут доступны через JMX или при использовании другого веб-фреймворка.

2.7.1. Получение ввода

Операции на конечной точке получают входные данные через свои параметры. При экспонировании через веб, значения этих параметров берутся из параметров запроса URL и из тела запроса JSON. При экспонировании через JMX, параметры сопоставляются с параметрами операций MBean. Параметры по умолчанию обязательны. Они могут быть сделаны необязательными, добавив аннотацию @javax.annotation.Nullable или @org.springframework.lang.Nullable.

Вы можете сопоставить каждую корневую свойство в теле запроса JSON с параметром конечной точки. Рассмотрим следующее тело запроса JSON:

{
    "name": "test",
    "counter": 42
}

Вы можете использовать это для вызова операции записи, принимающей параметры String name и int counter, как показано в следующем примере:

Java
@WriteOperation
public void updateData(String name, int counter) {
    // injects "test" and 42
}
Kotlin
@WriteOperation
fun updateData(name: String?, counter: Int) {
    // injects "test" and 42
}
Поскольку конечные точки технологически независимы, в сигнатуре метода могут быть указаны только простые типы. В частности, объявление единственного параметра с типом CustomData, определяющим свойства name и counter, не поддерживается.
Чтобы входные данные могли быть сопоставлены с параметрами метода операции, код Java, реализующий конечную точку, должен быть скомпилирован с -parameters, а код Kotlin, реализующий конечную точку, должен быть скомпилирован с -java-parameters. Это произойдет автоматически, если вы используете плагин Spring Boot для Gradle или Maven и spring-boot-starter-parent.
Преобразование типов ввода

Параметры, передаваемые методам операций конечной точки, при необходимости автоматически преобразуются в требуемый тип. Перед вызовом метода операции, ввод, полученный через JMX или HTTP, преобразуется в требуемые типы, используя экземпляр ApplicationConversionService, а также любые Converter или GenericConverter бин, квалифицированные с @EndpointConverter.

2.7.2. Пользовательские веб-конечные точки

Операции над @Endpoint, @WebEndpoint, или @EndpointWebExtension автоматически экспонируются через HTTP с использованием Jersey, Spring MVC или Spring WebFlux. Если доступны как Jersey, так и Spring MVC, используется Spring MVC.

Предикаты запросов веб-конечных точек

Для каждой операции на веб-конечной точке автоматически генерируется предикат запроса.

Путь

Путь предиката определяется идентификатором конечной точки и базовым путем веб-конечных точек. Базовый путь по умолчанию — /actuator. Например, конечная точка с идентификатором sessions использует /actuator/sessions в качестве пути в предикате.

Вы можете дополнительно настроить путь, добавив аннотацию @Selector к одному или нескольким параметрам метода операции. Такой параметр добавляется в предикат пути как переменная пути. Значение переменной передаётся в метод операции при вызове операции конечной точки. Если вы хотите захватить все оставшиеся элементы пути, добавьте @Selector(Match=ALL_REMAINING) к последнему параметру и сделайте его типом, совместимым с преобразованием с String[].

Метод HTTP

Метод HTTP предиката определяется типом операции, как показано в следующей таблице:

Операция Метод HTTP

@ReadOperation

GET

@WriteOperation

POST

@DeleteOperation

DELETE
Consumes

Для @WriteOperation (HTTP POST) использующего тело запроса, consumes часть предиката — application/vnd.spring-boot.actuator.v2+json, application/json. Для всех остальных операций consumes часть предиката пустая.

Produces

Часть produces предиката может быть определена атрибутом produces аннотаций @DeleteOperation, @ReadOperation, и @WriteOperation. Атрибут необязателен. Если он не используется, часть produces предиката определяется автоматически.

Если метод операции возвращает void или Void, часть produces предиката пустая. Если метод операции возвращает org.springframework.core.io.Resource, часть produces предиката — application/octet-stream. Для всех остальных операций часть produces предиката — application/vnd.spring-boot.actuator.v2+json, application/json.

Статус ответа веб-конечной точки

Статус ответа по умолчанию для операции конечной точки зависит от типа операции (чтение, запись или удаление) и того, возвращает ли операция какое-либо значение.

Если операция @ReadOperation возвращает значение, статус ответа будет 200 (OK). Если она не возвращает значение, статус ответа будет 404 (Не найдено).

Если операция @WriteOperation или @DeleteOperation возвращает значение, статус ответа будет 200 (OK). Если она не возвращает значение, статус ответа будет 204 (Без содержимого).

Если операция вызывается без обязательного параметра или с параметром, который нельзя преобразовать в требуемый тип, метод операции не вызывается, и статус ответа будет 400 (Ошибка запроса).

Веб-конечные точки и запросы диапазона

Вы можете использовать запрос диапазона HTTP для запроса части HTTP-ресурса. При использовании Spring MVC или Spring WebFlux операции, возвращающие org.springframework.core.io.Resource, автоматически поддерживают запросы диапазона.

Запросы диапазона не поддерживаются при использовании Jersey.
Безопасность веб-конечной точки

Операция на веб-конечной точке или расширении веб-конечной точки может получить текущий java.security.Principal или org.springframework.boot.actuate.endpoint.SecurityContext в качестве параметра метода. Первый обычно используется совместно с @Nullable для предоставления различного поведения для авторизованных и неавторизованных пользователей. Второй обычно используется для выполнения проверок авторизации с помощью своего метода isUserInRole(String).

2.7.3. Конечные точки сервлетов

Сервлет может быть экспонирован как конечная точка путём реализации класса, помеченного аннотацией @ServletEndpoint, который также реализует Supplier<EndpointServlet>. Сервлет-конечные точки обеспечивают более глубокую интеграцию с контейнером сервлетов, но за счёт портативности. Они предназначены для экспонирования существующего сервлета как конечной точки. Для новых конечных точек аннотации @Endpoint и @WebEndpoint следует предпочесть, когда это возможно.

2.7.4. Конечные точки контроллера

Вы можете использовать @ControllerEndpoint и @RestControllerEndpoint для реализации конечной точки, доступной только в Spring MVC или Spring WebFlux. Методы отображаются с помощью стандартных аннотаций Spring MVC и Spring WebFlux, таких как @RequestMapping и @GetMapping, используя идентификатор конечной точки в качестве префикса для пути. Конечные точки контроллера обеспечивают более глубокую интеграцию с веб-фреймворками Spring, но ценой портативности. Аннотации @Endpoint и @WebEndpoint следует предпочитать, когда это возможно.

2.8. Информация о состоянии

Вы можете использовать информацию о состоянии, чтобы проверить состояние вашего работающего приложения. Она часто используется средствами мониторинга для оповещения, когда система в производстве выходит из строя. Информация, экспонируемая конечной точкой health, зависит от свойств management.endpoint.health.show-details и management.endpoint.health.show-components, которые можно настроить одним из следующих значений:

Имя Описание

never

Подробности никогда не отображаются.

when-authorized

Подробности отображаются только авторизованным пользователям. Авторизованные роли могут быть настроены с помощью management.endpoint.health.roles.

always

Подробности отображаются всем пользователям.

Значение по умолчанию — never. Пользователь считается авторизованным, когда он находится в одной или нескольких ролях конечной точки. Если для конечной точки не настроены роли (по умолчанию), все аутентифицированные пользователи считаются авторизованными. Вы можете настроить роли, используя свойство management.endpoint.health.roles.

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

Информация о состоянии собирается из содержимого HealthContributorRegistry (по умолчанию, все HealthContributor экземпляры, определенные в ApplicationContext). Spring Boot включает в себя ряд автоматически настроенных HealthContributors, и вы также можете написать свои собственные.

Контрибьютор HealthContributor может быть либо HealthIndicator, либо CompositeHealthContributor. HealthIndicator предоставляет фактическую информацию о состоянии, включая Status. CompositeHealthContributor предоставляет композицию других HealthContributors. Вместе контрибьюторы образуют древовидную структуру для представления общего состояния системы.

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

Вы можете использовать HealthContributorRegistry для регистрации и отмены регистрации индикаторов состояния во время выполнения.

2.8.1. Автоматически настраиваемые HealthIndicators

При необходимости Spring Boot автоматически настраивает HealthIndicators перечисленные в следующей таблице. Вы также можете включить или отключить выбранные индикаторы, настроив management.health.key.enabled, с key перечисленными в следующей таблице:

Ключ Имя Описание

cassandra

CassandraDriverHealthIndicator

Проверяет, запущена ли база данных Cassandra.

couchbase

CouchbaseHealthIndicator

Проверяет, запущен ли кластер Couchbase.

db

DataSourceHealthIndicator

Проверяет, можно ли получить соединение с DataSource.

diskspace

DiskSpaceHealthIndicator

Проверяет на наличие низкого свободного места на диске.

elasticsearch

ElasticsearchRestHealthIndicator

Проверяет, запущен ли кластер Elasticsearch.

hazelcast

HazelcastHealthIndicator

Проверяет, запущен ли сервер Hazelcast.

influxdb

InfluxDbHealthIndicator

Проверяет, запущен ли сервер InfluxDB.

jms

JmsHealthIndicator

Проверяет, запущен ли брокер JMS.

ldap

LdapHealthIndicator

Проверяет, запущен ли сервер LDAP.

mail

MailHealthIndicator

Проверяет, запущен ли почтовый сервер.

mongo

MongoHealthIndicator

Проверяет, запущена ли база данных Mongo.

neo4j

Neo4jHealthIndicator

Проверяет, запущена ли база данных Neo4j.

ping

PingHealthIndicator

Всегда отвечает с UP.

rabbit

RabbitHealthIndicator

Проверяет, запущен ли сервер Rabbit.

redis

RedisHealthIndicator

Проверяет, запущен ли сервер Redis.
Их всех можно отключить, установив свойство management.health.defaults.enabled.

Доступны дополнительные HealthIndicators, но по умолчанию они не включены:

Ключ Имя Описание

livenessstate

LivenessStateHealthIndicator

Предоставляет состояние доступности приложения «Liveness».

readinessstate

ReadinessStateHealthIndicator

Предоставляет состояние доступности приложения «Readiness».

2.8.2. Написание пользовательских индикаторов состояния

Для предоставления пользовательской информации о состоянии вы можете зарегистрировать компоненты Spring, реализующие интерфейс HealthIndicator. Вам необходимо предоставить реализацию метода health() и вернуть ответ Health. Ответ Health должен включать статус и может необязательно содержать дополнительную информацию для отображения. Следующий код показывает пример реализации HealthIndicator:

Java
import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class MyHealthIndicator implements HealthIndicator {

    @Override
    public Health health() {
        int errorCode = check();
        if (errorCode != 0) {
            return Health.down().withDetail("Error Code", errorCode).build();
        }
        return Health.up().build();
    }

    private int check() {
        // perform some specific health check
        return ...
    }

}
Kotlin
import org.springframework.boot.actuate.health.Health
import org.springframework.boot.actuate.health.HealthIndicator
import org.springframework.stereotype.Component

@Component
class MyHealthIndicator : HealthIndicator {

    override fun health(): Health {
        val errorCode = check()
        if (errorCode != 0) {
            return Health.down().withDetail("Error Code", errorCode).build()
        }
        return Health.up().build()
    }

    private fun check(): Int {
        // perform some specific health check
        return  ...
    }

}
Идентификатор данного HealthIndicator — имя компонента без суффикса HealthIndicator, если он есть. В предыдущем примере информация о состоянии доступна в записи с именем my.
Индикаторы состояния обычно вызываются по HTTP и должны ответить до истечения срока ожидания подключения. Spring Boot будет выводить сообщение об ошибке для любого индикатора состояния, который отвечает дольше 10 секунд. Если вы хотите настроить этот порог, вы можете использовать свойство management.endpoint.health.logging.slow-indicator-threshold.

В дополнение к предопределённым типам Status Spring Boot, Health может возвращать пользовательский Status, представляющий новое состояние системы. В таких случаях вам также необходимо предоставить пользовательскую реализацию интерфейса StatusAggregator или настроить стандартную реализацию, используя конфигурационное свойство management.endpoint.health.status.order.

Например, предположим, что в одной из ваших реализаций HealthIndicator используется новый Status с кодом FATAL. Чтобы настроить порядок важности, добавьте следующее свойство в свои свойства приложения:

Свойства
management.endpoint.health.status.order=fatal,down,out-of-service,unknown,up
Yaml
management:
  endpoint:
    health:
      status:
        order: "fatal,down,out-of-service,unknown,up"

Код HTTP-статуса в ответе отражает общее состояние здоровья. По умолчанию OUT_OF_SERVICE и DOWN сопоставляются со значением 503. Любые несопоставленные статусы состояния, включая UP, сопоставляются со значением 200. Возможно, вам также потребуется зарегистрировать пользовательские сопоставления статусов, если вы обращаетесь к точке входа состояния по HTTP. Настройка пользовательского сопоставления отключает значения по умолчанию для DOWN и OUT_OF_SERVICE. Если вы хотите сохранить значения по умолчанию, вы должны явно настроить их, наряду с любыми пользовательскими сопоставлениями. Например, следующее свойство сопоставляет FATAL со значением 503 (отказ в обслуживании) и сохраняет значения по умолчанию для DOWN и OUT_OF_SERVICE:

Свойства
management.endpoint.health.status.http-mapping.down=503
management.endpoint.health.status.http-mapping.fatal=503
management.endpoint.health.status.http-mapping.out-of-service=503
Yaml
management:
  endpoint:
    health:
      status:
        http-mapping:
          down: 503
          fatal: 503
          out-of-service: 503
Если вам нужен больший контроль, вы можете определить собственный компонент HttpCodeStatusMapper bean.

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

Статус Сопоставление

DOWN

SERVICE_UNAVAILABLE (503)

OUT_OF_SERVICE

SERVICE_UNAVAILABLE (503)

UP

Сопоставление по умолчанию отсутствует, поэтому HTTP-статус — 200

UNKNOWN

Сопоставление по умолчанию отсутствует, поэтому HTTP-статус — 200

2.8.3. Реактивные индикаторы состояния

Для реактивных приложений, таких как те, которые используют Spring WebFlux, ReactiveHealthContributor предоставляет асинхронный интерфейс для получения состояния приложения. Аналогично традиционному HealthContributor, информация о состоянии собирается из содержимого ReactiveHealthContributorRegistry (по умолчанию, все HealthContributor и ReactiveHealthContributor экземпляры, определённые в вашем ApplicationContext). Стандартные HealthContributors проверки, не выполняемые с реактивным API, выполняются на эластичном планировщике.

В реактивном приложении вы должны использовать ReactiveHealthContributorRegistry для регистрации и отмены регистрации индикаторов состояния во время выполнения. Если вам нужно зарегистрировать обычный HealthContributor, вы должны обернуть его в ReactiveHealthContributor#adapt.

Для предоставления пользовательской информации о состоянии из реактивного API вы можете зарегистрировать компоненты Spring, реализующие интерфейс ReactiveHealthIndicator. Следующий код показывает пример реализации ReactiveHealthIndicator:

Java
import reactor.core.publisher.Mono;

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.ReactiveHealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class MyReactiveHealthIndicator implements ReactiveHealthIndicator {

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

    private Mono<Health> doHealthCheck() {
        // perform some specific health check
        return ...
    }

}
Kotlin
import org.springframework.boot.actuate.health.Health
import org.springframework.boot.actuate.health.ReactiveHealthIndicator
import org.springframework.stereotype.Component
import reactor.core.publisher.Mono

@Component
class MyReactiveHealthIndicator : ReactiveHealthIndicator {

    override fun health(): Mono<Health> {
        return doHealthCheck()!!.onErrorResume { exception: Throwable? ->
            Mono.just(Health.Builder().down(exception).build())
        }
    }

    private fun doHealthCheck(): Mono<Health>? {
        // perform some specific health check
        return  ...
    }

}
Чтобы автоматически обработать ошибку, рассмотрите возможность расширения от AbstractReactiveHealthIndicator.

2.8.4. Автонастроенные реактивные индикаторы состояния

При необходимости Spring Boot автоматически настраивает следующие:

Ключ Имя Описание

cassandra

CassandraDriverReactiveHealthIndicator

Проверяет, доступна ли база данных Cassandra.

couchbase

CouchbaseReactiveHealthIndicator

Проверяет, доступен ли кластер Couchbase.

elasticsearch

ElasticsearchReactiveHealthIndicator

Проверяет, доступен ли кластер Elasticsearch.

mongo

MongoReactiveHealthIndicator

Проверяет, доступна ли база данных Mongo.

neo4j

Neo4jReactiveHealthIndicator

Проверяет, доступна ли база данных Neo4j.

redis

RedisReactiveHealthIndicator

Проверяет, доступен ли сервер Redis.
При необходимости реактивные индикаторы заменяют стандартные. Кроме того, любые HealthIndicator , которые не обрабатываются явно, автоматически оборачиваются.

2.8.5. Группы состояния

Иногда полезно группировать индикаторы состояния для различных целей.

Для создания группы индикаторов состояния можно использовать свойство management.endpoint.health.group.<name> и указать список идентификаторов индикаторов состояния для включения или исключения. Например, для создания группы, включающей только индикаторы баз данных, можно определить следующее:

Свойства
management.endpoint.health.group.custom.include=db
Yaml
management:
  endpoint:
    health:
      group:
        custom:
          include: "db"

Затем можно проверить результат, обратившись по адресу localhost:8080/actuator/health/custom.

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

Свойства
management.endpoint.health.group.custom.exclude=db
Yaml
management:
  endpoint:
    health:
      group:
        custom:
          exclude: "db"

По умолчанию, запуск завершится неудачей, если группа состояния включает или исключает индикатор состояния, которого нет. Чтобы отключить это поведение, установите management.endpoint.health.validate-group-membership в false.

По умолчанию, группы наследуют те же настройки StatusAggregator и HttpCodeStatusMapper , что и общесистемное состояние. Однако, вы также можете определить их на уровне группы. Также можно переопределить свойства show-details и roles при необходимости:

Свойства
management.endpoint.health.group.custom.show-details=when-authorized
management.endpoint.health.group.custom.roles=admin
management.endpoint.health.group.custom.status.order=fatal,up
management.endpoint.health.group.custom.status.http-mapping.fatal=500
management.endpoint.health.group.custom.status.http-mapping.out-of-service=500
Yaml
management:
  endpoint:
    health:
      group:
        custom:
          show-details: "when-authorized"
          roles: "admin"
          status:
            order: "fatal,up"
            http-mapping:
              fatal: 500
              out-of-service: 500
Можно использовать @Qualifier("groupname") , если необходимо зарегистрировать пользовательские StatusAggregator или HttpCodeStatusMapper компоненты для использования в группе.

Группа состояния также может включать/исключать CompositeHealthContributor . Вы также можете включить/исключить только определенный компонент CompositeHealthContributor. Это можно сделать, используя полное имя компонента следующим образом:

management.endpoint.health.group.custom.include="test/primary"
management.endpoint.health.group.custom.exclude="test/primary/b"

В приведенном выше примере группа custom будет включать HealthContributor с именем primary, который является компонентом составного test . Здесь primary сам является составным, и HealthContributor с именем b будет исключен из группы custom.

Группы состояния могут быть доступны по дополнительным путям на основном или управляющем порту. Это полезно в облачных средах, таких как Kubernetes, где часто используется отдельный управляющий порт для конечных точек актуатора по соображениям безопасности. Наличие отдельного порта может привести к ненадежным проверкам состояния, поскольку основное приложение может работать некорректно, даже если проверка состояния успешна. Группу состояния можно настроить с дополнительным путём следующим образом:

management.endpoint.health.group.live.additional-path="server:/healthz"

Это сделает группу состояний live доступной на основном порту сервера по адресу /healthz . Префикс обязателен и должен быть либо server: (представляет основной порт сервера), либо management: (представляет управляющий порт, если он настроен). Путь должен быть единственным сегментом пути.

2.8.6. Состояние источника данных

Индикатор состояния DataSource отображает состояние как стандартных источников данных, так и компонентов-источников данных маршрутизации. Состояние маршрутизируемого источника данных включает состояние каждого из его целевых источников данных. В ответе конечной точки состояния каждый из целевых источников маршрутизируемого источника данных называется с использованием его ключа маршрутизации. Если вы предпочитаете не включать маршрутизируемые источники данных в вывод индикатора, установите management.health.db.ignore-routing-data-sources в true.

2.9. Зонды Kubernetes

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

По умолчанию Spring Boot управляет состоянием доступности приложения Состояние доступности приложения. При развертывании в среде Kubernetes, Actuator собирает информацию о «жизнеспособности» и «готовности» из интерфейса ApplicationAvailability и использует эту информацию в специализированных показателях состояния: LivenessStateHealthIndicator и ReadinessStateHealthIndicator. Эти индикаторы отображаются на глобальном концевой точке состояния ("/actuator/health"). Они также доступны как отдельные HTTP зонды, используя группы состояния: "/actuator/health/liveness" и "/actuator/health/readiness".

Затем вы можете настроить свою инфраструктуру Kubernetes с помощью следующей информации об конечных точках:

livenessProbe:
  httpGet:
    path: "/actuator/health/liveness"
    port: <actuator-port>
  failureThreshold: ...
  periodSeconds: ...

readinessProbe:
  httpGet:
    path: "/actuator/health/readiness"
    port: <actuator-port>
  failureThreshold: ...
  periodSeconds: ...
<actuator-port> должен быть установлен на порт, на котором доступны конечные точки Actuator. Это может быть основной порт веб-сервера или отдельный порт управления, если была установлена свойство "management.server.port" .

Эти группы состояния автоматически активируются только если приложение работает в среде Kubernetes. Вы можете включить их в любой среде, используя свойство конфигурации management.endpoint.health.probes.enabled.

Если запуск приложения занимает больше времени, чем настроенный период жизнеспособности, Kubernetes указывает на "startupProbe" как возможное решение. В целом, "startupProbe" необязательно, поскольку "readinessProbe" терпит неудачу, пока не завершатся все задачи запуска. Это означает, что ваше приложение не будет получать трафик, пока не будет готово. Однако, если ваш запуск занимает много времени, рассмотрите использование "startupProbe" чтобы убедиться, что Kubernetes не завершит ваше приложение во время запуска. См. раздел, описывающий поведение зондов во время жизненного цикла приложения.

Если ваши конечные точки Actuator развернуты в отдельном контексте управления, они не используют ту же веб-инфраструктуру (порт, пулы подключений, компоненты фреймворка), что и основное приложение. В этом случае проверка зонда может быть успешной, даже если основное приложение работает неправильно (например, не может принимать новые подключения). По этой причине рекомендуется сделать группы состояния liveness и readiness доступными на основном порте сервера. Это можно сделать, установив следующее свойство:

management.endpoint.health.probes.add-additional-paths=true

Это сделает группу liveness доступной по адресу /livez и группу readiness доступной по адресу /readyz на основном порте сервера. Пути можно настроить с помощью свойства additional-path каждой группы, см. группы состояния для подробностей.

2.9.1. Проверка внешнего состояния с помощью зондов Kubernetes

Actuator настраивает зонды «жизнеспособности» и «готовности» как группы состояния. Это означает, что для них доступны все возможности функции групп состояния. Например, вы можете настроить дополнительные индикаторы состояния:

Свойства
management.endpoint.health.group.readiness.include=readinessState,customCheck
Yaml
management:
  endpoint:
    health:
      group:
        readiness:
          include: "readinessState,customCheck"

По умолчанию Spring Boot не добавляет другие индикаторы состояния в эти группы.

Зонд «жизнеспособности» не должен зависеть от проверок внешних систем. Если состояние жизнеспособности приложения нарушено, Kubernetes пытается решить эту проблему, перезапустив экземпляр приложения. Это означает, что если внешняя система (например, база данных, веб-API или внешний кэш) выходит из строя, Kubernetes может перезапустить все экземпляры приложения и вызвать цепную реакцию сбоев.

Что касается зонда «готовности», выбор проверки внешних систем должен быть сделан разработчиками приложения со всей ответственностью. По этой причине Spring Boot не включает никаких дополнительных проверок состояния в зонд «готовности». Если состояние готовности экземпляра приложения не готово, Kubernetes не направляет трафик на этот экземпляр. Некоторые внешние системы могут не быть общими для экземпляров приложения, в этом случае они могут быть включены в зонд готовности. Другие внешние системы могут быть некритичными для приложения (у приложения могут быть предохранители и обходные пути), в этом случае их определенно не следует включать. К сожалению, внешняя система, которая общая для всех экземпляров приложения, является распространённой, и вам нужно принять решение: включить её в зонд готовности и ожидать, что приложение будет выведено из работы, когда внешний сервис недоступен, или исключить её и иметь дело с ошибками на более высоком уровне стека, возможно, используя предохранитель в вызывающей стороне.

Если все экземпляры приложения не готовы, служба Kubernetes с type=ClusterIP или NodePort не принимает никаких входящих подключений. Нет ответа с HTTP ошибкой (503 и т.д.), так как нет подключения. Служба с type=LoadBalancer может или не может принимать подключения, в зависимости от провайдера. Сервис с явным ingress также отвечает способом, зависящим от реализации - служба ingress сама должна решить, как обработать «отказ в подключении» от нижележащего уровня. HTTP 503 весьма вероятен в случае как балансировщика нагрузки, так и ingress.

Также, если приложение использует автоматическое масштабирование Kubernetes horizontal-pod-autoscaling, его реакция на вывод приложений из балансировщика может отличаться в зависимости от конфигурации его автомасштабирования.

2.9.2. Жизненный цикл приложения и состояния зондирования

Важным аспектом поддержки зондирования Kubernetes является его согласованность с жизненным циклом приложения. Существует существенная разница между AvailabilityState (внутреннее состояние приложения в памяти) и фактическим зондированием (которое отображает это состояние). В зависимости от фазы жизненного цикла приложения, зондирование может быть недоступно.

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

В следующих таблицах показаны AvailabilityState и состояние HTTP-соединений на разных этапах.

При запуске приложения Spring Boot:

Фаза запуска LivenessState ReadinessState HTTP-сервер Примечания

Запуск

BROKEN

REFUSING_TRAFFIC

Не запущен

Kubernetes проверяет зондирование "liveness" и перезапускает приложение, если оно занимает слишком много времени.

Запущен

CORRECT

REFUSING_TRAFFIC

Отклоняет запросы

Контекст приложения обновлен. Приложение выполняет задачи запуска и еще не принимает трафик.

Готов

CORRECT

ACCEPTING_TRAFFIC

Принимает запросы

Задачи запуска завершены. Приложение принимает трафик.

При завершении работы приложения Spring Boot:

Фаза завершения Состояние Liveness Состояние Readiness HTTP-сервер Примечания

Выполнение

CORRECT

ACCEPTING_TRAFFIC

Принимает запросы

Завершение запрошено.

Плавное завершение

CORRECT

REFUSING_TRAFFIC

Новые запросы отклоняются

Если включено, процессы плавного завершения обрабатывают входящие запросы.

Завершение

Н/Д

Н/Д

Сервер остановлен

Контекст приложения закрыт, и приложение остановлено.
Смотрите раздел жизненного цикла контейнера Kubernetes для получения дополнительной информации о развертывании Kubernetes.

2.10. Информация о приложении

Информация о приложении предоставляет различные данные, собранные от всех InfoContributor бинов, определённых в вашем ApplicationContext. Spring Boot включает в себя ряд автоматически настроенных InfoContributor бинов, и вы можете написать свои собственные.

2.10.1. Автоматически настроенные InfoContributors

По возможности Spring автоматически настраивает следующие InfoContributor бины:

ID Имя Описание Предварительные условия

build

BuildInfoContributor

Отображает информацию о сборке.

Ресурс META-INF/build-info.properties.

env

EnvironmentInfoContributor

Отображает любую переменную из Environment, имя которой начинается с info..

Нет.

git

GitInfoContributor

Отображает информацию из Git.

Ресурс git.properties.

java

JavaInfoContributor

Отображает информацию о среде выполнения Java.

Нет.

os

OsInfoContributor

Отображает информацию об операционной системе.

Нет.

Включённость отдельных участников контролируется свойством management.info.<id>.enabled . Разные участники имеют разные значения по умолчанию для этого свойства, в зависимости от их предварительных условий и характера отображаемой информации.

Участники env, java, и os по умолчанию отключены, так как у них нет предварительных условий, указывающих на их включение. Каждый из них можно включить, установив свойство management.info.<id>.enabled в true.

Участники build и git включены по умолчанию. Каждый из них можно отключить, установив свойство management.info.<id>.enabled в значение false. Также, чтобы отключить всех участников, обычно включённых по умолчанию, установите свойство management.info.defaults.enabled в значение false.

2.10.2. Кастомная информация о приложении

Когда включён участник env, вы можете настроить данные, отображаемые конечной точкой info, установив свойства Spring. Все свойства Environment под ключом info автоматически отображаются. Например, вы можете добавить следующие настройки в файл application.properties:

Свойства
info.app.encoding=UTF-8
info.app.java.source=17
info.app.java.target=17
Yaml
info:
  app:
    encoding: "UTF-8"
    java:
      source: "17"
      target: "17"

Вместо жёсткого кодирования этих значений, вы также можете расширить свойства info во время сборки.

Предполагая, что вы используете Maven, вы можете переписать предыдущий пример следующим образом:

Свойства
info.app.encoding=@project.build.sourceEncoding@
info.app.java.source=@java.version@
info.app.java.target=@java.version@
Yaml
info:
  app:
    encoding: "@project.build.sourceEncoding@"
    java:
      source: "@java.version@"
      target: "@java.version@"

2.10.3. Информация о коммите Git

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

Бин GitProperties автоматически настраивается, если файл git.properties доступен в корневом каталоге classpath. Подробнее см. "как сгенерировать информацию о Git".

По умолчанию конечная точка отображает свойства git.branch, git.commit.id, и git.commit.time, если они присутствуют. Если вы не хотите видеть эти свойства в ответе конечной точки, их нужно исключить из файла git.properties. Для отображения полной информации о Git (т.е. всего содержимого git.properties) используйте свойство management.info.git.mode, как показано ниже:

Свойства
management.info.git.mode=full
Yaml
management:
  info:
    git:
      mode: "full"

Чтобы полностью отключить информацию о коммите Git из конечной точки info, установите свойство management.info.git.enabled в значение false, как показано ниже:

Свойства
management.info.git.enabled=false
Yaml
management:
  info:
    git:
      enabled: false

2.10.4. Информация о сборке

Если доступен бин BuildProperties, конечная точка info также может публиковать информацию о вашей сборке. Это происходит, если файл META-INF/build-info.properties доступен в classpath.

Плагины Maven и Gradle могут генерировать этот файл. Подробнее см. "как сгенерировать информацию о сборке".

2.10.5. Информация о Java

Конечная точка info публикует информацию о вашей среде выполнения Java, см. JavaInfo для получения дополнительной информации.

2.10.6. Информация об ОС

Конечная точка info публикует информацию о вашей операционной системе, см. OsInfo для получения дополнительной информации.

2.10.7. Создание собственных InfoContributors

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

Следующий пример вносит запись example с одним значением:

Java
import java.util.Collections;

import org.springframework.boot.actuate.info.Info;
import org.springframework.boot.actuate.info.InfoContributor;
import org.springframework.stereotype.Component;

@Component
public class MyInfoContributor implements InfoContributor {

    @Override
    public void contribute(Info.Builder builder) {
        builder.withDetail("example", Collections.singletonMap("key", "value"));
    }

}
Kotlin
import org.springframework.boot.actuate.info.Info
import org.springframework.boot.actuate.info.InfoContributor
import org.springframework.stereotype.Component
import java.util.Collections

@Component
class MyInfoContributor : InfoContributor {

    override fun contribute(builder: Info.Builder) {
        builder.withDetail("example", Collections.singletonMap("key", "value"))
    }

}

Если вы обратитесь к конечной точке info, вы увидите ответ, содержащий следующую дополнительную запись:

{
    "example": {
        "key" : "value"
    }
}

3. Мониторинг и управление через HTTP

Если вы разрабатываете веб-приложение, Spring Boot Actuator автоматически настраивает все включенные конечные точки для экспонирования через HTTP. По умолчанию используется id конечной точки с префиксом /actuator в качестве пути URL. Например, health экспонируется как /actuator/health.

Actuator поддерживается по умолчанию с Spring MVC, Spring WebFlux и Jersey. Если доступны как Jersey, так и Spring MVC, используется Spring MVC.
Jackson является необходимой зависимостью для получения корректных ответов JSON, как описано в документации API (HTML или PDF).

3.1. Настройка путей конечных точек управления

Иногда полезно настроить префикс для конечных точек управления. Например, ваше приложение может уже использовать /actuator для другой цели. Вы можете использовать свойство management.endpoints.web.base-path для изменения префикса вашей конечной точки управления, как показано в следующем примере:

Свойства
management.endpoints.web.base-path=/manage
Yaml
management:
  endpoints:
    web:
      base-path: "/manage"

Предыдущий application.properties пример изменяет конечную точку с /actuator/{id} на /manage/{id} (например, /manage/info).

Если порт управления не был настроен для экспонирования конечных точек с использованием другого порта HTTP, management.endpoints.web.base-path относит к server.servlet.context-path (для приложений веб-сервлетов) или spring.webflux.base-path (для реактивных веб-приложений). Если management.server.port настроен, management.endpoints.web.base-path относится к management.server.base-path.

Если вы хотите сопоставить конечные точки с другим путем, вы можете использовать свойство management.endpoints.web.path-mapping.

Следующий пример пересопоставляет /actuator/health на /healthcheck:

Свойства
management.endpoints.web.base-path=/
management.endpoints.web.path-mapping.health=healthcheck
Yaml
management:
  endpoints:
    web:
      base-path: "/"
      path-mapping:
        health: "healthcheck"

3.2. Настройка порта сервера управления

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

Вы можете установить свойство management.server.port для изменения порта HTTP, как показано в следующем примере:

Свойства
management.server.port=8081
Yaml
management:
  server:
    port: 8081
В Cloud Foundry по умолчанию приложения получают запросы только на порту 8080 для маршрутизации HTTP и TCP. Если вы хотите использовать пользовательский порт управления в Cloud Foundry, вам нужно явно настроить маршруты приложения для перенаправления трафика на пользовательский порт.

3.3. Настройка SSL для сервера управления

При настройке на использование пользовательского порта вы также можете настроить сервер управления с собственным SSL, используя различные свойства management.server.ssl.*. Например, это позволяет серверу управления быть доступным через HTTP, в то время как основное приложение использует HTTPS, как показано в следующих настройках свойств:

Свойства
server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:store.jks
server.ssl.key-password=secret
management.server.port=8080
management.server.ssl.enabled=false
Yaml
server:
  port: 8443
  ssl:
    enabled: true
    key-store: "classpath:store.jks"
    key-password: "secret"
management:
  server:
    port: 8080
    ssl:
      enabled: false

В качестве альтернативы, и основной сервер, и сервер управления могут использовать SSL, но с различными хранилищами ключей, как показано ниже:

Свойства
server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:main.jks
server.ssl.key-password=secret
management.server.port=8080
management.server.ssl.enabled=true
management.server.ssl.key-store=classpath:management.jks
management.server.ssl.key-password=secret
Yaml
server:
  port: 8443
  ssl:
    enabled: true
    key-store: "classpath:main.jks"
    key-password: "secret"
management:
  server:
    port: 8080
    ssl:
      enabled: true
      key-store: "classpath:management.jks"
      key-password: "secret"

3.4. Настройка адреса сервера управления

Вы можете настроить адрес, на котором доступны конечные точки управления, задав свойство management.server.address. Это может быть полезно, если вы хотите прослушивать только внутреннюю или обслуживающую сеть или принимать подключения только от localhost.

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

В следующем примере application.properties не разрешает удаленные подключения к управлению:

Свойства
management.server.port=8081
management.server.address=127.0.0.1
Yaml
management:
  server:
    port: 8081
    address: "127.0.0.1"

3.5. Отключение конечных точек HTTP

Если вы не хотите экспонировать конечные точки через HTTP, вы можете установить порт управления на -1, как показано в следующем примере:

Свойства
management.server.port=-1
Yaml
management:
  server:
    port: -1

Это также можно сделать, используя свойство management.endpoints.web.exposure.exclude, как показано в следующем примере:

Свойства
management.endpoints.web.exposure.exclude=*
Yaml
management:
  endpoints:
    web:
      exposure:
        exclude: "*"

4. Мониторинг и управление через JMX

Java Management Extensions (JMX) обеспечивают стандартный механизм для мониторинга и управления приложениями. По умолчанию эта функция отключена. Вы можете включить её, установив свойство конфигурации spring.jmx.enabled в значение true. Spring Boot экспонирует подходящий MBeanServer в качестве бин с идентификатором mbeanServer. Любые ваши бины, аннотированные аннотациями Spring JMX (@ManagedResource, @ManagedAttribute, или @ManagedOperation ), будут доступны для него.

Если ваша платформа предоставляет стандартный MBeanServer, Spring Boot использует его и по умолчанию использует VM MBeanServer, если это необходимо. В случае неудачи создаётся новый MBeanServer.

См. класс JmxAutoConfiguration для получения более подробной информации.

По умолчанию Spring Boot также экспонирует конечные точки управления в качестве MBeans JMX под доменом org.springframework.boot. Чтобы полностью контролировать регистрацию конечных точек в домене JMX, рассмотрите возможность регистрации собственной реализации EndpointObjectNameFactory.

4.1. Настройка имён MBean

Имя MBean обычно генерируется из id конечной точки. Например, конечная точка health экспонируется как org.springframework.boot:type=Endpoint,name=Health.

Если ваше приложение содержит более одного Spring ApplicationContext, могут возникнуть конфликты имён. Чтобы решить эту проблему, вы можете установить свойство spring.jmx.unique-names в значение true, чтобы имена MBean всегда были уникальными.

Вы также можете настроить домен JMX, под которым экспонируются конечные точки. В следующих настройках показан пример их выполнения в application.properties:

Свойства
spring.jmx.unique-names=true
management.endpoints.jmx.domain=com.example.myapp
Yaml
spring:
  jmx:
    unique-names: true
management:
  endpoints:
    jmx:
      domain: "com.example.myapp"

4.2. Отключение конечных точек JMX

Если вы не хотите экспонировать конечные точки через JMX, вы можете установить свойство management.endpoints.jmx.exposure.exclude в значение *, как показано в следующем примере:

Свойства
management.endpoints.jmx.exposure.exclude=*
Yaml
management:
  endpoints:
    jmx:
      exposure:
        exclude: "*"

5. Наблюдаемость

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

Для метрик и трассировок Spring Boot использует Наблюдение Micrometer. Чтобы создать собственные наблюдения (которые приведут к метрикам и трассировкам), вы можете ввести ObservationRegistry. 

import io.micrometer.observation.Observation;
import io.micrometer.observation.ObservationRegistry;

import org.springframework.stereotype.Component;

@Component
public class MyCustomObservation {

    private final ObservationRegistry observationRegistry;

    public MyCustomObservation(ObservationRegistry observationRegistry) {
        this.observationRegistry = observationRegistry;
    }

    public void doSomething() {
        Observation.createNotStarted("doSomething", this.observationRegistry)
            .lowCardinalityKeyValue("locale", "en-US")
            .highCardinalityKeyValue("userId", "42")
            .observe(() -> {
                // Execute business logic here
            });
    }

}
Метки с низкой кардинальностью будут добавлены к метрикам и трассировкам, в то время как метки с высокой кардинальностью будут добавлены только к трассировкам.

Компоненты типа ObservationPredicate, GlobalObservationConvention и ObservationHandler будут автоматически зарегистрированы в ObservationRegistry. Вы также можете зарегистрировать любое количество компонентов ObservationRegistryCustomizer для дальнейшей настройки реестра.

Для получения дополнительной информации см. документацию по наблюдениям Micrometer.

Наблюдаемость для JDBC и R2DBC может быть настроена с помощью отдельных проектов. Для JDBC проект Datasource Micrometer предоставляет стартовый набор Spring Boot, который автоматически создаёт наблюдения при вызове JDBC-операций. Подробнее читайте в справочной документации. Для R2DBC Автоконфигурация Spring Boot для наблюдений R2DBC создаёт наблюдения для вызовов запросов R2DBC.

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

6. Логгеры

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

  • TRACE

  • DEBUG

  • INFO

  • WARN

  • ERROR

  • FATAL

  • OFF

  • null

null означает, что нет явной конфигурации.

6.1. Настройка логгера

Чтобы настроить данный логгер, POST частичную сущность в URI ресурса, как показано в следующем примере:

{
    "configuredLevel": "DEBUG"
}
Чтобы «сбросить» конкретный уровень логгера (и использовать вместо него значения по умолчанию), вы можете передать значение null в качестве configuredLevel.

7. Метрики

Spring Boot Actuator предоставляет управление зависимостями и автоконфигурацию для Micrometer, фасада прикладных метрик, поддерживающего многочисленные системы мониторинга, включая:

  • AppOptics

  • Atlas

  • Datadog

  • Dynatrace

  • Elastic

  • Ganglia

  • Graphite

  • Humio

  • Influx

  • JMX

  • KairosDB

  • New Relic

  • OpenTelemetry

  • Prometheus

  • SignalFx

  • Простой (в памяти)

  • Stackdriver

  • StatsD

  • Wavefront

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

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

Spring Boot автоматически настраивает составной MeterRegistry и добавляет реестр в составной для каждой поддерживаемой реализации, которую находит в пути к классам. Наличие зависимости от micrometer-registry-{system} в пути к классам во время выполнения достаточно для того, чтобы Spring Boot настраивал реестр.

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

Свойства
management.datadog.metrics.export.enabled=false
Yaml
management:
  datadog:
    metrics:
      export:
        enabled: false

Вы также можете отключить все реестры, если не указано иное свойством конкретного реестра, как показано в следующем примере:

Свойства
management.defaults.metrics.export.enabled=false
Yaml
management:
  defaults:
    metrics:
      export:
        enabled: false

Spring Boot также добавляет все автоматически настроенные реестры в глобальный статический составной реестр в классе Metrics, если вы не скажете ему этого не делать:

Свойства
management.metrics.use-global-registry=false
Yaml
management:
  metrics:
    use-global-registry: false

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

Java
import io.micrometer.core.instrument.MeterRegistry;

import org.springframework.boot.actuate.autoconfigure.metrics.MeterRegistryCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyMeterRegistryConfiguration {

    @Bean
    public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
        return (registry) -> registry.config().commonTags("region", "us-east-1");
    }

}
Kotlin
import io.micrometer.core.instrument.MeterRegistry
import org.springframework.boot.actuate.autoconfigure.metrics.MeterRegistryCustomizer
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyMeterRegistryConfiguration {

    @Bean
    fun metricsCommonTags(): MeterRegistryCustomizer<MeterRegistry> {
        return MeterRegistryCustomizer { registry ->
            registry.config().commonTags("region", "us-east-1")
        }
    }

}

Вы можете применить настройки к конкретным реализациям реестра, указав более конкретный тип:

Java
import io.micrometer.core.instrument.Meter;
import io.micrometer.core.instrument.config.NamingConvention;
import io.micrometer.graphite.GraphiteMeterRegistry;

import org.springframework.boot.actuate.autoconfigure.metrics.MeterRegistryCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyMeterRegistryConfiguration {

    @Bean
    public MeterRegistryCustomizer<GraphiteMeterRegistry> graphiteMetricsNamingConvention() {
        return (registry) -> registry.config().namingConvention(this::name);
    }

    private String name(String name, Meter.Type type, String baseUnit) {
        return ...
    }

}
Kotlin
import io.micrometer.core.instrument.Meter
import io.micrometer.core.instrument.config.NamingConvention
import io.micrometer.graphite.GraphiteMeterRegistry
import org.springframework.boot.actuate.autoconfigure.metrics.MeterRegistryCustomizer
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyMeterRegistryConfiguration {

    @Bean
    fun graphiteMetricsNamingConvention(): MeterRegistryCustomizer<GraphiteMeterRegistry> {
        return MeterRegistryCustomizer { registry: GraphiteMeterRegistry ->
            registry.config().namingConvention(this::name)
        }
    }

    private fun name(name: String, type: Meter.Type, baseUnit: String?): String {
        return  ...
    }

}

Spring Boot также настраивает встроенную инструментировку, которую вы можете контролировать с помощью конфигурации или специальных аннотаций.

7.2. Поддерживаемые системы мониторинга

В этом разделе кратко описаны каждая из поддерживаемых систем мониторинга.

7.2.1. AppOptics

По умолчанию регистр AppOptics периодически отправляет метрики в api.appoptics.com/v1/measurements. Для экспорта метрик в SaaS-сервис AppOptics необходимо предоставить свой токен API:

Свойства
management.appoptics.metrics.export.api-token=YOUR_TOKEN
Yaml
management:
  appoptics:
    metrics:
      export:
        api-token: "YOUR_TOKEN"

7.2.2. Atlas

По умолчанию метрики экспортируются в Atlas, работающий на вашем локальном компьютере. Вы можете указать расположение сервера Atlas:

Свойства
management.atlas.metrics.export.uri=https://atlas.example.com:7101/api/v1/publish
Yaml
management:
  atlas:
    metrics:
      export:
        uri: "https://atlas.example.com:7101/api/v1/publish"

7.2.3. Datadog

Регистр Datadog периодически отправляет метрики в datadoghq. Для экспорта метрик в Datadog необходимо указать ваш API-ключ:

Свойства
management.datadog.metrics.export.api-key=YOUR_KEY
Yaml
management:
  datadog:
    metrics:
      export:
        api-key: "YOUR_KEY"

Если вы дополнительно укажете ключ приложения (необязательно), то также будут экспортированы метаданные, такие как описания метров, типы и базовые единицы:

Свойства
management.datadog.metrics.export.api-key=YOUR_API_KEY
management.datadog.metrics.export.application-key=YOUR_APPLICATION_KEY
Yaml
management:
  datadog:
    metrics:
      export:
        api-key: "YOUR_API_KEY"
        application-key: "YOUR_APPLICATION_KEY"

По умолчанию метрики отправляются на сайт Datadog в США site (api.datadoghq.com). Если ваш проект Datadog размещён на одном из других сайтов или вам нужно отправлять метрики через прокси, настройте URI соответственно:

Свойства
management.datadog.metrics.export.uri=https://api.datadoghq.eu
Yaml
management:
  datadog:
    metrics:
      export:
        uri: "https://api.datadoghq.eu"

Вы также можете изменить интервал, с которым метрики отправляются в Datadog:

Свойства
management.datadog.metrics.export.step=30s
Yaml
management:
  datadog:
    metrics:
      export:
        step: "30s"

7.2.4. Dynatrace

Dynatrace предлагает два API для приема метрик, оба из которых реализованы для Micrometer. Документацию Dynatrace по приему метрик Micrometer вы можете найти здесь. Параметры конфигурации в пространстве имен v1 применяются только при экспорте в API v1 временных рядов. Параметры конфигурации в пространстве имен v2 применяются только при экспорте в API v2 метрик. Обратите внимание, что эта интеграция может экспортировать только в версию API v1 или v2 в один момент, при этом v2 предпочтительнее. Если device-id (необходим для v1, но не используется в v2) установлен в пространстве имен v1, метрики экспортируются на конечную точку v1. В противном случае предполагается v2.

API v2

API v2 можно использовать двумя способами.

Автоконфигурация

Автоконфигурация Dynatrace доступна для хостов, которые отслеживаются OneAgent или оператором Dynatrace для Kubernetes.

Локальный OneAgent: Если на хосте запущен OneAgent, метрики автоматически экспортируются на локальную конечную точку приема OneAgent. Конечная точка приема передает метрики на бэкенд Dynatrace.

Оператор Dynatrace для Kubernetes: При работе в Kubernetes с установленным оператором Dynatrace регистр автоматически получит URI вашей конечной точки и токен API из оператора.

Это стандартное поведение и не требует специальной настройки помимо зависимости от io.micrometer:micrometer-registry-dynatrace.

Ручная настройка

Если автоматическая настройка недоступна, требуется конечная точка API v2 метрик и токен API. Токен API должен иметь разрешение «Принимать метрики» (metrics.ingest). Рекомендуется ограничить область действия токена только этим разрешением. Вы должны убедиться, что URI конечной точки содержит путь (например, /api/v2/metrics/ingest):

URL конечной точки приема API метрик v2 отличается в зависимости от вашего варианта развертывания:

  • SaaS: https://{your-environment-id}.live.dynatrace.com/api/v2/metrics/ingest

  • Развертывания в облаке: https://{your-domain}/e/{your-environment-id}/api/v2/metrics/ingest

Пример ниже настраивает экспорт метрик с использованием идентификатора среды example:

Свойства
management.dynatrace.metrics.export.uri=https://example.live.dynatrace.com/api/v2/metrics/ingest
management.dynatrace.metrics.export.api-token=YOUR_TOKEN
Yaml
management:
  dynatrace:
    metrics:
      export:
        uri: "https://example.live.dynatrace.com/api/v2/metrics/ingest"
        api-token: "YOUR_TOKEN"

При использовании API v2 Dynatrace доступны следующие необязательные функции (более подробную информацию можно найти в документации Dynatrace):

  • Префикс ключа метрики: Устанавливает префикс, который добавляется ко всем ключам экспортируемых метрик.

  • Обогащение данными Dynatrace: Если работает OneAgent или оператор Dynatrace, обогащайте метрики дополнительными метаданными (например, о хосте, процессе или под).

  • Стандартные измерения: Укажите пары «ключ-значение», которые добавляются ко всем экспортируемым метрикам. Если метки с одинаковым ключом указаны с помощью Micrometer, они перезаписывают стандартные измерения.

  • Использование инструментов Dynatrace Summary: В некоторых случаях регистр Micrometer Dynatrace создавал метрики, которые отклонялись. В Micrometer 1.9.x это было исправлено путем введения инструментов Dynatrace-специфических суммарных значений. Установка этого переключателя в false заставляет Micrometer вернуться к поведению, которое было по умолчанию до 1.9.x. Его следует использовать только при возникновении проблем при миграции с Micrometer 1.8.x на 1.9.x.

Можно не указывать URI и токен API, как показано в следующем примере. В этом случае используется автоматически настроенная конечная точка:

Свойства
management.dynatrace.metrics.export.v2.metric-key-prefix=your.key.prefix
management.dynatrace.metrics.export.v2.enrich-with-dynatrace-metadata=true
management.dynatrace.metrics.export.v2.default-dimensions.key1=value1
management.dynatrace.metrics.export.v2.default-dimensions.key2=value2
management.dynatrace.metrics.export.v2.use-dynatrace-summary-instruments=true
Yaml
management:
  dynatrace:
    metrics:
      export:
        # Specify uri and api-token here if not using the local OneAgent endpoint.
        v2:
          metric-key-prefix: "your.key.prefix"
          enrich-with-dynatrace-metadata: true
          default-dimensions:
            key1: "value1"
            key2: "value2"
          use-dynatrace-summary-instruments: true # (default: true)
API v1 (Устаревший)

Регистр метрик API v1 Dynatrace периодически отправляет метрики по указанному URI с использованием API v1 временных рядов. Для обратной совместимости с существующими настройками, когда device-id установлено (необходимо для v1, но не используется в v2), метрики экспортируются на конечную точку Timeseries v1. Для экспорта метрик в Dynatrace необходимо указать ваш токен API, идентификатор устройства и URI:

Свойства
management.dynatrace.metrics.export.uri=https://{your-environment-id}.live.dynatrace.com
management.dynatrace.metrics.export.api-token=YOUR_TOKEN
management.dynatrace.metrics.export.v1.device-id=YOUR_DEVICE_ID
Yaml
management:
  dynatrace:
    metrics:
      export:
        uri: "https://{your-environment-id}.live.dynatrace.com"
        api-token: "YOUR_TOKEN"
        v1:
          device-id: "YOUR_DEVICE_ID"

Для API v1 необходимо указать базовый URI среды без пути, так как путь к конечной точке v1 добавляется автоматически.

Настройки, независимые от версии

В дополнение к конечной точке API и токену, вы также можете изменить интервал, с которым метрики отправляются в Dynatrace. Стандартный интервал экспорта составляет 60s. Следующий пример устанавливает интервал экспорта в 30 секунд:

Свойства
management.dynatrace.metrics.export.step=30s
Yaml
management:
  dynatrace:
    metrics:
      export:
        step: "30s"

Дополнительную информацию о настройке экспортера Dynatrace для Micrometer можно найти в документации Micrometer и документации Dynatrace.

7.2.5. Elastic

По умолчанию метрики экспортируются в Elastic, запущенный на вашем локальном компьютере. Вы можете указать расположение сервера Elastic, используя следующее свойство:

Свойства
management.elastic.metrics.export.host=https://elastic.example.com:8086
Yaml
management:
  elastic:
    metrics:
      export:
        host: "https://elastic.example.com:8086"

7.2.6. Ganglia

По умолчанию метрики экспортируются в Ganglia, запущенный на вашем локальном компьютере. Вы можете указать хост и порт сервера Ganglia, как показано в примере ниже:

Свойства
management.ganglia.metrics.export.host=ganglia.example.com
management.ganglia.metrics.export.port=9649
Yaml
management:
  ganglia:
    metrics:
      export:
        host: "ganglia.example.com"
        port: 9649

7.2.7. Graphite

По умолчанию метрики экспортируются в Graphite, запущенный на вашем локальном компьютере. Вы можете указать хост и порт сервера Graphite, как показано в примере ниже:

Свойства
management.graphite.metrics.export.host=graphite.example.com
management.graphite.metrics.export.port=9004
Yaml
management:
  graphite:
    metrics:
      export:
         host: "graphite.example.com"
         port: 9004

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

Чтобы контролировать это поведение, определите свой GraphiteMeterRegistry и предоставьте собственный HierarchicalNameMapper. Автонастроенные GraphiteConfig и Clock бины предоставляются, если вы не определите свои собственные:

Java
import io.micrometer.core.instrument.Clock;
import io.micrometer.core.instrument.Meter;
import io.micrometer.core.instrument.config.NamingConvention;
import io.micrometer.core.instrument.util.HierarchicalNameMapper;
import io.micrometer.graphite.GraphiteConfig;
import io.micrometer.graphite.GraphiteMeterRegistry;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyGraphiteConfiguration {

    @Bean
    public GraphiteMeterRegistry graphiteMeterRegistry(GraphiteConfig config, Clock clock) {
        return new GraphiteMeterRegistry(config, clock, this::toHierarchicalName);
    }

    private String toHierarchicalName(Meter.Id id, NamingConvention convention) {
        return ...
    }

}
Kotlin
import io.micrometer.core.instrument.Clock
import io.micrometer.core.instrument.Meter
import io.micrometer.core.instrument.config.NamingConvention
import io.micrometer.core.instrument.util.HierarchicalNameMapper
import io.micrometer.graphite.GraphiteConfig
import io.micrometer.graphite.GraphiteMeterRegistry
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyGraphiteConfiguration {

    @Bean
    fun graphiteMeterRegistry(config: GraphiteConfig, clock: Clock): GraphiteMeterRegistry {
        return GraphiteMeterRegistry(config, clock, this::toHierarchicalName)
    }
    private fun toHierarchicalName(id: Meter.Id, convention: NamingConvention): String {
        return  ...
    }

}

7.2.8. Humio

По умолчанию регистр Humio периодически отправляет метрики на cloud.humio.com. Чтобы экспортировать метрики в SaaS Humio, необходимо предоставить свой токен API:

Свойства
management.humio.metrics.export.api-token=YOUR_TOKEN
Yaml
management:
  humio:
    metrics:
      export:
        api-token: "YOUR_TOKEN"

Также следует настроить один или несколько тегов для идентификации источника данных, в который отправляются метрики:

Свойства
management.humio.metrics.export.tags.alpha=a
management.humio.metrics.export.tags.bravo=b
Yaml
management:
  humio:
    metrics:
      export:
        tags:
          alpha: "a"
          bravo: "b"

7.2.9. Influx

По умолчанию метрики экспортируются в экземпляр Influx v1, запущенный на вашем локальном компьютере, с конфигурацией по умолчанию. Чтобы экспортировать метрики в InfluxDB v2, настройте org, bucket, и параметры аутентификации token для записи метрик. Вы можете указать расположение сервера Influx для использования, используя:

Свойства
management.influx.metrics.export.uri=https://influx.example.com:8086
Yaml
management:
  influx:
    metrics:
      export:
        uri: "https://influx.example.com:8086"

7.2.10. JMX

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

Свойства
management.jmx.metrics.export.domain=com.example.app.metrics
Yaml
management:
  jmx:
    metrics:
      export:
        domain: "com.example.app.metrics"

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

Чтобы контролировать это поведение, определите свой JmxMeterRegistry и предоставьте собственный HierarchicalNameMapper. Автонастроенные JmxConfig и Clock бины предоставляются, если вы не определите свои собственные:

Java
import io.micrometer.core.instrument.Clock;
import io.micrometer.core.instrument.Meter;
import io.micrometer.core.instrument.config.NamingConvention;
import io.micrometer.core.instrument.util.HierarchicalNameMapper;
import io.micrometer.jmx.JmxConfig;
import io.micrometer.jmx.JmxMeterRegistry;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyJmxConfiguration {

    @Bean
    public JmxMeterRegistry jmxMeterRegistry(JmxConfig config, Clock clock) {
        return new JmxMeterRegistry(config, clock, this::toHierarchicalName);
    }

    private String toHierarchicalName(Meter.Id id, NamingConvention convention) {
        return ...
    }

}
Kotlin
import io.micrometer.core.instrument.Clock
import io.micrometer.core.instrument.Meter
import io.micrometer.core.instrument.config.NamingConvention
import io.micrometer.core.instrument.util.HierarchicalNameMapper
import io.micrometer.jmx.JmxConfig
import io.micrometer.jmx.JmxMeterRegistry
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyJmxConfiguration {

    @Bean
    fun jmxMeterRegistry(config: JmxConfig, clock: Clock): JmxMeterRegistry {
        return JmxMeterRegistry(config, clock, this::toHierarchicalName)
    }

    private fun toHierarchicalName(id: Meter.Id, convention: NamingConvention): String {
        return  ...
    }

}

7.2.11. KairosDB

По умолчанию метрики экспортируются в KairosDB, запущенный на вашем локальном компьютере. Вы можете указать расположение сервера KairosDB для использования, используя:

Свойства
management.kairos.metrics.export.uri=https://kairosdb.example.com:8080/api/v1/datapoints
Yaml
management:
  kairos:
    metrics:
      export:
        uri: "https://kairosdb.example.com:8080/api/v1/datapoints"

7.2.12. New Relic

Регистр New Relic периодически отправляет метрики в New Relic. Чтобы экспортировать метрики в New Relic, необходимо предоставить свой API ключ и идентификатор учетной записи:

Свойства
management.newrelic.metrics.export.api-key=YOUR_KEY
management.newrelic.metrics.export.account-id=YOUR_ACCOUNT_ID
Yaml
management:
  newrelic:
    metrics:
      export:
        api-key: "YOUR_KEY"
        account-id: "YOUR_ACCOUNT_ID"

Вы также можете изменить интервал, с которым метрики отправляются в New Relic:

Свойства
management.newrelic.metrics.export.step=30s
Yaml
management:
  newrelic:
    metrics:
      export:
        step: "30s"

По умолчанию метрики публикуются через REST-запросы, но вы также можете использовать API Java Agent, если он находится в вашем классе:

Свойства
management.newrelic.metrics.export.client-provider-type=insights-agent
Yaml
management:
  newrelic:
    metrics:
      export:
        client-provider-type: "insights-agent"

Наконец, вы можете полностью контролировать это, определив свою собственную NewRelicClientProvider bean.

7.2.13. OpenTelemetry

По умолчанию метрики экспортируются в OpenTelemetry, запущенный на вашем локальном компьютере. Вы можете указать расположение конечной точки OpenTelemetry метрик для использования, используя:

Свойства
management.otlp.metrics.export.url=https://otlp.example.com:4318/v1/metrics
Yaml
management:
  otlp:
    metrics:
      export:
        url: "https://otlp.example.com:4318/v1/metrics"

7.2.14. Prometheus

Prometheus ожидает сканирования или опроса отдельных экземпляров приложения для получения метрик. Spring Boot предоставляет конечную точку актуатора по адресу /actuator/prometheus для представления сканирования Prometheus в соответствующем формате.

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

Следующий пример scrape_config добавляется к prometheus.yml. 

scrape_configs:
  - job_name: "spring"
    metrics_path: "/actuator/prometheus"
    static_configs:
      - targets: ["HOST:PORT"]

Примеры Prometheus также поддерживаются. Для активации этой функции должен быть доступен SpanContextSupplier bean. Если вы используете отслеживание Micrometer, то это будет автоматически настроено, но вы всегда можете создать свой собственный, если хотите. Обратитесь к документации Prometheus, так как эту функцию необходимо явно включить в Prometheus, и она поддерживается только в формате OpenMetrics.

Для эфемерных или пакетных задач, которые могут не существовать достаточно долго для сканирования, можно использовать поддержку Prometheus Pushgateway для экспорта метрик в Prometheus. Для включения поддержки Prometheus Pushgateway добавьте следующую зависимость в ваш проект:

<dependency>
    <groupId>io.prometheus</groupId>
    <artifactId>simpleclient_pushgateway</artifactId>
</dependency>

Когда зависимость Prometheus Pushgateway присутствует в классе и свойство management.prometheus.metrics.export.pushgateway.enabled установлено в значение true, PrometheusPushGatewayManager bean настраивается автоматически. Это позволяет управлять отправкой метрик в Prometheus Pushgateway.

Можно настроить PrometheusPushGatewayManager с помощью свойств в management.prometheus.metrics.export.pushgateway. Для расширенной конфигурации можно также предоставить свой собственный PrometheusPushGatewayManager bean.

7.2.15. SignalFx

Регистр SignalFx периодически отправляет метрики в SignalFx. Для экспорта метрик в SignalFx необходимо указать ваш токен доступа:

Свойства
management.signalfx.metrics.export.access-token=YOUR_ACCESS_TOKEN
Yaml
management:
  signalfx:
    metrics:
      export:
        access-token: "YOUR_ACCESS_TOKEN"

Также можно изменить интервал, с которым метрики отправляются в SignalFx:

Свойства
management.signalfx.metrics.export.step=30s
Yaml
management:
  signalfx:
    metrics:
      export:
        step: "30s"

7.2.16. Simple

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

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

Свойства
management.simple.metrics.export.enabled=false
Yaml
management:
  simple:
    metrics:
      export:
        enabled: false

7.2.17. Stackdriver

Регистр Stackdriver периодически отправляет метрики в Stackdriver. Для экспорта метрик в SaaS Stackdriver необходимо указать идентификатор вашего проекта Google Cloud:

Свойства
management.stackdriver.metrics.export.project-id=my-project
Yaml
management:
  stackdriver:
    metrics:
      export:
        project-id: "my-project"

Также можно изменить интервал, с которым метрики отправляются в Stackdriver:

Свойства
management.stackdriver.metrics.export.step=30s
Yaml
management:
  stackdriver:
    metrics:
      export:
        step: "30s"

7.2.18. StatsD

Регистр StatsD активно отправляет метрики по UDP в агент StatsD. По умолчанию метрики экспортируются в StatsD агент, работающий на вашем локальном компьютере. Вы можете указать хост, порт и протокол StatsD агента, используя:

Свойства
management.statsd.metrics.export.host=statsd.example.com
management.statsd.metrics.export.port=9125
management.statsd.metrics.export.protocol=udp
Yaml
management:
  statsd:
    metrics:
      export:
        host: "statsd.example.com"
        port: 9125
        protocol: "udp"

Также можно изменить протокол строк StatsD (по умолчанию Datadog):

Свойства
management.statsd.metrics.export.flavor=etsy
Yaml
management:
  statsd:
    metrics:
      export:
        flavor: "etsy"

7.2.19. Wavefront

Регистр Wavefront периодически отправляет метрики в Wavefront. Если вы экспортируете метрики напрямую в Wavefront, необходимо указать ваш токен API:

Свойства
management.wavefront.api-token=YOUR_API_TOKEN
Yaml
management:
  wavefront:
    api-token: "YOUR_API_TOKEN"

В качестве альтернативы вы можете использовать Wavefront sidecar или внутренний прокси в вашей среде для перенаправления данных метрик на хост API Wavefront:

Свойства
management.wavefront.uri=proxy://localhost:2878
Yaml
management:
  wavefront:
    uri: "proxy://localhost:2878"
Если вы публикуете метрики в Wavefront прокси (как описано в документации Wavefront), хост должен быть в формате proxy://HOST:PORT.

Также можно изменить интервал, с которым метрики отправляются в Wavefront:

Свойства
management.wavefront.metrics.export.step=30s
Yaml
management:
  wavefront:
    metrics:
      export:
        step: "30s"

7.3. Поддерживаемые метрики и метры

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

7.3.1. Метрики JVM

Автоконфигурация включает метрики JVM, используя основные классы Micrometer. Метрики JVM публикуются под именем метра jvm..

Предоставляются следующие метрики JVM:

  • Различные данные о памяти и пулах буферов

  • Статистические данные, связанные с сборкой мусора

  • Использование потоков

  • Количество загруженных и выгруженных классов

  • Информация о версии JVM

  • Время компиляции JIT

7.3.2. Системные метрики

Автоконфигурация включает системные метрики, используя основные классы Micrometer. Системные метрики публикуются под именами метров system., process., и disk..

Предоставляются следующие системные метрики:

  • Метрики процессора

  • Метрики дескрипторов файлов

  • Метрики времени активности (как количество времени работы приложения, так и фиксированная метрика абсолютного начального времени)

  • Доступное дисковое пространство

7.3.3. Метрики запуска приложения

Автоконфигурация предоставляет метрики времени запуска приложения:

  • application.started.time: время, затраченное на запуск приложения.

  • application.ready.time: время, затраченное на подготовку приложения к обработке запросов.

Метрики помечены полным квалифицированным именем класса приложения.

7.3.4. Метрики логгера

Автоконфигурация включает метрики событий для Logback и Log4J2. Подробная информация публикуется под именами метров log4j2.events. или logback.events..

7.3.5. Метрики выполнения и планирования задач

Автоконфигурация включает в себя инструментацию всех доступных ThreadPoolTaskExecutor и ThreadPoolTaskScheduler бинов, при условии, что подлежащий ThreadPoolExecutor доступен. Метрики помечены именем исполнителя, которое получено из имени бина.

7.3.6. Метрики Spring MVC

Автоконфигурация включает в себя инструментацию всех запросов, обрабатываемых контроллерами Spring MVC и функциональными обработчиками. По умолчанию метрики генерируются с именем http.server.requests. Вы можете настроить имя, установив свойство management.observations.http.server.requests.name.

См. документацию по Spring Framework для получения дополнительной информации о производимых наблюдениях.

Для добавления к меткам по умолчанию укажите @Bean, который расширяет DefaultServerRequestObservationConvention из пакета org.springframework.http.server.observation. Для замены меток по умолчанию укажите @Bean, который реализует ServerRequestObservationConvention.

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

По умолчанию обрабатываются все запросы. Для настройки фильтра укажите @Bean, который реализует FilterRegistrationBean<WebMvcMetricsFilter>.

7.3.7. Метрики Spring WebFlux

Автоконфигурация включает инструментацию всех запросов, обрабатываемых контроллерами и функциональными обработчиками Spring WebFlux. По умолчанию метрики генерируются с именем http.server.requests. Вы можете настроить имя, установив свойство management.observations.http.server.requests.name.

См. документацию по Spring Framework для получения дополнительной информации о производимых наблюдениях.

Для добавления к меткам по умолчанию укажите @Bean, который расширяет DefaultServerRequestObservationConvention из пакета org.springframework.http.server.reactive.observation. Для замены меток по умолчанию укажите @Bean, который реализует ServerRequestObservationConvention.

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

7.3.8. Метрики сервера Jersey

Автоконфигурация включает инструментацию всех запросов, обрабатываемых реализацией Jersey JAX-RS. По умолчанию метрики генерируются с именем http.server.requests. Вы можете настроить имя, установив свойство management.observations.http.server.requests.name.

По умолчанию метрики сервера Jersey помечены следующей информацией:

Метка Описание

exception

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

method

Метод запроса (например, GET или POST)

outcome

Результат запроса, основанный на коде состояния ответа. 1xx - INFORMATIONAL, 2xx - SUCCESS, 3xx - REDIRECTION, 4xx - CLIENT_ERROR, и 5xx - SERVER_ERROR.

status

Код HTTP состояния ответа (например, 200 или 500)

uri

Шаблон URI запроса до подстановки переменных, если это возможно (например, /api/person/{id})

Для настройки меток укажите @Bean, который реализует JerseyTagsProvider.

7.3.9. Метрики HTTP-клиентов

Spring Boot Actuator управляет инструментацией как RestTemplate, так и WebClient. Для этого вам нужно внедрить настроенный билдер и использовать его для создания экземпляров:

  • RestTemplateBuilder для RestTemplate

  • WebClient.Builder для WebClient

Вы также можете вручную применить кастомайзеры, ответственные за эту инструментацию, а именно ObservationRestTemplateCustomizer и ObservationWebClientCustomizer.

По умолчанию метрики генерируются с именем http.client.requests. Вы можете настроить имя, установив свойство management.observations.http.client.requests.name.

См. документацию по Spring Framework для получения дополнительной информации о производимых наблюдениях.

Для настройки меток при использовании RestTemplate укажите @Bean, который реализует ClientRequestObservationConvention из пакета org.springframework.http.client.observation. Для настройки меток при использовании WebClient укажите @Bean, который реализует ClientRequestObservationConvention из пакета org.springframework.web.reactive.function.client.

7.3.10. Метрики Tomcat

Автоконфигурация включает инструментацию Tomcat только при включенном MBeanRegistry. По умолчанию MBeanRegistry выключен, но вы можете включить его, установив server.tomcat.mbeanregistry.enabled в значение true.

Метрики Tomcat публикуются под именем метра tomcat..

7.3.11. Метрики кэша

Автоконфигурация позволяет интегрировать все доступные Cache экземпляры при запуске, с метриками, имеющими префикс cache. Инструментация кэша стандартизирована для базового набора метрик. Доступны также дополнительные метрики, специфичные для кэша.

Поддерживаются следующие библиотеки кэширования:

  • Cache2k

  • Caffeine

  • Hazelcast

  • Любое соответствующее JCache (JSR-107) реализация

  • Redis

Метрики помечены именем кэша и именем CacheManager, которое получено из имени компонента.

В реестр добавляются только кэши, настроенные при запуске. Для кэшей, не определённых в конфигурации кэша, таких как кэши, созданные на лету или программно после фазы запуска, требуется явное регистрирование. Для упрощения этого процесса доступен компонент CacheMetricsRegistrar.

7.3.12. Метрики Spring Batch

См. документацию по Spring Batch.

7.3.13. Метрики Spring GraphQL

См. документацию по Spring GraphQL.

7.3.14. Метрики источника данных

Автоконфигурация позволяет интегрировать все доступные объекты DataSource с метриками, имеющими префикс jdbc.connections. Инструментация источника данных приводит к индикаторам, которые представляют собой текущее количество активных, свободных, максимального и минимально допустимого подключений в пуле.

Метрики также помечены именем DataSource, полученным на основе имени компонента.

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

Также доступны метрики, специфичные для Hikari, с префиксом hikaricp. Каждая метрика помечена именем пула (вы можете контролировать его с помощью spring.datasource.name).

7.3.15. Метрики Hibernate

Если org.hibernate.orm:hibernate-micrometer находится в классе, все доступные экземпляры Hibernate EntityManagerFactory с включённой статистикой инструментированы метрикой с именем hibernate.

Метрики также помечены именем EntityManagerFactory, которое получено из имени компонента.

Для включения статистики необходимо установить стандартное свойство JPA hibernate.generate_statistics в значение true. Вы можете включить это для автоматически настроенного EntityManagerFactory:

Свойства
spring.jpa.properties[hibernate.generate_statistics]=true
Yaml
spring:
  jpa:
    properties:
      "[hibernate.generate_statistics]": true

7.3.16. Метрики Spring Data Repository

Автоконфигурация включает инструментацию всех вызовов методов Spring Data Repository. По умолчанию метрики генерируются с именем spring.data.repository.invocations. Вы можете настроить имя, задав свойство management.metrics.data.repository.metric-name.

Аннотация @Timed из пакета io.micrometer.core.annotation поддерживается на интерфейсах и методах Repository. Если вы не хотите регистрировать метрики для всех вызовов Repository, вы можете установить management.metrics.data.repository.autotime.enabled в false и использовать только аннотации @Timed.

Аннотация @Timed с longTask = true позволяет использовать таймер задач со средним временем выполнения для метода. Таймеры задач со средним временем выполнения требуют отдельного имени метрики и могут быть совмещены с таймером задач с коротким временем выполнения.

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

Тег Описание

repository

Простое имя класса исходного Repository.

method

Имя метода Repository который был вызван.

state

Состояние результата (SUCCESS, ERROR, CANCELED, или RUNNING).

exception

Простое имя класса любого исключения, которое было выброшено во время вызова.

Для замены стандартных тегов предоставьте @Bean, который реализует RepositoryTagsProvider.

7.3.17. Метрики RabbitMQ

Автоконфигурация включает инструментацию всех доступных фабрик подключений RabbitMQ с метрикой с именем rabbitmq.

7.3.18. Метрики Spring Integration

Spring Integration автоматически предоставляет поддержку Micrometer всякий раз, когда доступен компонент MeterRegistry . Метрики публикуются под именем счетчика spring.integration..

7.3.19. Метрики Kafka

Автоконфигурация регистрирует MicrometerConsumerListener и MicrometerProducerListener для автоматически настроенных фабрики потребителей и фабрики производителей, соответственно. Также регистрируется KafkaStreamsMicrometerListener для StreamsBuilderFactoryBean. Более подробную информацию см. в разделе Micrometer Native Metrics документации Spring Kafka.

7.3.20. Метрики MongoDB

В этом разделе кратко описываются доступные метрики для MongoDB.

Метрики команд MongoDB

Автоконфигурация регистрирует MongoMetricsCommandListener с автоматически настроенным MongoClient.

Для каждой команды, выданной подключенному драйверу MongoDB, создается метрика таймера с именем mongodb.driver.commands. По умолчанию каждая метрика маркируется следующей информацией:

Тэг Описание

command

Имя выданной команды.

cluster.id

Идентификатор кластера, которому была отправлена команда.

server.address

Адрес сервера, которому была отправлена команда.

status

Результат команды (SUCCESS или FAILED).

Для замены тегов метрик по умолчанию определите bean MongoCommandTagsProvider, как показано в следующем примере:

Java
import io.micrometer.core.instrument.binder.mongodb.MongoCommandTagsProvider;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyCommandTagsProviderConfiguration {

    @Bean
    public MongoCommandTagsProvider customCommandTagsProvider() {
        return new CustomCommandTagsProvider();
    }

}
Kotlin
import io.micrometer.core.instrument.binder.mongodb.MongoCommandTagsProvider
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyCommandTagsProviderConfiguration {

    @Bean
    fun customCommandTagsProvider(): MongoCommandTagsProvider? {
        return CustomCommandTagsProvider()
    }

}

Чтобы отключить автоматически настроенные метрики команд, установите следующую свойство:

Properties
management.metrics.mongo.command.enabled=false
Yaml
management:
  metrics:
    mongo:
      command:
        enabled: false
Метрики пула подключений MongoDB

Автоконфигурация регистрирует MongoMetricsConnectionPoolListener с автоматически настроенным MongoClient.

Для пула подключений создаются следующие метрики типа gauge:

  • mongodb.driver.pool.size отображает текущий размер пула подключений, включая простаивающие и активные члены.

  • mongodb.driver.pool.checkedout отображает количество подключений, которые в настоящее время используются.

  • mongodb.driver.pool.waitqueuesize отображает текущий размер очереди ожидания подключения из пула.

По умолчанию каждая метрика маркируется следующей информацией:

Тэг Описание

cluster.id

Идентификатор кластера, которому соответствует пул подключений.

server.address

Адрес сервера, которому соответствует пул подключений.

Для замены тегов метрик по умолчанию определите bean MongoConnectionPoolTagsProvider:

Java
import io.micrometer.core.instrument.binder.mongodb.MongoConnectionPoolTagsProvider;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyConnectionPoolTagsProviderConfiguration {

    @Bean
    public MongoConnectionPoolTagsProvider customConnectionPoolTagsProvider() {
        return new CustomConnectionPoolTagsProvider();
    }

}
Kotlin
import io.micrometer.core.instrument.binder.mongodb.MongoConnectionPoolTagsProvider
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyConnectionPoolTagsProviderConfiguration {

    @Bean
    fun customConnectionPoolTagsProvider(): MongoConnectionPoolTagsProvider {
        return CustomConnectionPoolTagsProvider()
    }

}

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

Properties
management.metrics.mongo.connectionpool.enabled=false
Yaml
management:
  metrics:
    mongo:
      connectionpool:
        enabled: false

7.3.21. Метрики Jetty

Автоконфигурация связывает метрики для ThreadPool Jetty, используя JettyServerThreadPoolMetrics Micrometer. Метрики для Connector Jetty связываются с помощью JettyConnectionMetrics Micrometer и, когда server.ssl.enabled установлено в true, с помощью JettySslHandshakeMetrics Micrometer.

7.3.22. Поддержка аннотации @Timed

Чтобы использовать @Timed в тех случаях, когда это не поддерживается напрямую Spring Boot, обратитесь к документации Micrometer.

7.3.23. Метрики Redis

Автоконфигурация регистрирует MicrometerCommandLatencyRecorder для автоматически настроенного LettuceConnectionFactory. Более подробная информация представлена в разделе Метрики Micrometer документации Lettuce.

7.4. Регистрация пользовательских метрик

Для регистрации пользовательских метрик введите MeterRegistry в свой компонент:

Java
import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.Tags;

import org.springframework.stereotype.Component;

@Component
public class MyBean {

    private final Dictionary dictionary;

    public MyBean(MeterRegistry registry) {
        this.dictionary = Dictionary.load();
        registry.gauge("dictionary.size", Tags.empty(), this.dictionary.getWords().size());
    }

}
Kotlin
import io.micrometer.core.instrument.MeterRegistry
import io.micrometer.core.instrument.Tags
import org.springframework.stereotype.Component

@Component
class MyBean(registry: MeterRegistry) {

    private val dictionary: Dictionary

    init {
        dictionary = Dictionary.load()
        registry.gauge("dictionary.size", Tags.empty(), dictionary.words.size)
    }

}

Если ваши метрики зависят от других bean, рекомендуется использовать MeterBinder для их регистрации:

Java
import io.micrometer.core.instrument.Gauge;
import io.micrometer.core.instrument.binder.MeterBinder;

import org.springframework.context.annotation.Bean;

public class MyMeterBinderConfiguration {

    @Bean
    public MeterBinder queueSize(Queue queue) {
        return (registry) -> Gauge.builder("queueSize", queue::size).register(registry);
    }

}
Kotlin
import io.micrometer.core.instrument.Gauge
import io.micrometer.core.instrument.binder.MeterBinder
import org.springframework.context.annotation.Bean

class MyMeterBinderConfiguration {

    @Bean
    fun queueSize(queue: Queue): MeterBinder {
        return MeterBinder { registry ->
            Gauge.builder("queueSize", queue::size).register(registry)
        }
    }

}

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

По умолчанию метрики всех bean типа MeterBinder автоматически привязываются к управляемому Spring MeterRegistry.

7.5. Настройка отдельных метрик

Если вам нужно применить настройки к конкретным Meter экземплярам, вы можете использовать интерфейс io.micrometer.core.instrument.config.MeterFilter.

Например, если вы хотите переименовать тег mytag.region на mytag.area для всех идентификаторов счётчиков, начинающихся с com.example, вы можете сделать следующее:

Java
import io.micrometer.core.instrument.config.MeterFilter;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyMetricsFilterConfiguration {

    @Bean
    public MeterFilter renameRegionTagMeterFilter() {
        return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area");
    }

}
Kotlin
import io.micrometer.core.instrument.config.MeterFilter
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration(proxyBeanMethods = false)
class MyMetricsFilterConfiguration {

    @Bean
    fun renameRegionTagMeterFilter(): MeterFilter {
        return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area")
    }

}
По умолчанию все MeterFilter бины автоматически привязаны к управляемому Spring MeterRegistry. Убедитесь, что вы регистрируете свои метрики, используя управляемый Spring MeterRegistry, а не статические методы Metrics. Эти методы используют глобальную регистрацию, которая не управляема Spring.

7.5.1. Общие теги

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

Свойства
management.metrics.tags.region=us-east-1
management.metrics.tags.stack=prod
Yaml
management:
  metrics:
    tags:
      region: "us-east-1"
      stack: "prod"

В приведенном примере к всем счётчикам добавляются теги region и stack со значениями us-east-1 и prod соответственно.

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

7.5.2. Свойства по счётчику

В дополнение к MeterFilter бинам, вы можете применить ограниченный набор настроек на основе каждого счётчика, используя свойства. Настройки по счётчику применяются с помощью PropertiesMeterFilter Spring Boot для всех идентификаторов счётчиков, начинающихся с заданного имени. Следующий пример отфильтровывает все счётчики, имеющие идентификатор, начинающийся с example.remote.

Свойства
management.metrics.enable.example.remote=false
Yaml
management:
  metrics:
    enable:
      example:
        remote: false

Следующие свойства позволяют настраивать метрики по счётчикам:

Таблица 1. Настройки по счётчику
Свойство Описание

management.metrics.enable

Принимать ли счётчики с определёнными идентификаторами. Счётчики, которые не принимаются, отфильтровываются из MeterRegistry.

management.metrics.distribution.percentiles-histogram

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

management.metrics.distribution.minimum-expected-value, management.metrics.distribution.maximum-expected-value

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

management.metrics.distribution.percentiles

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

management.metrics.distribution.expiry, management.metrics.distribution.buffer-length

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

management.metrics.distribution.slo

Опубликовать кумулятивную гистограмму с бинами, определёнными вашими целевыми показателями уровня обслуживания.

Дополнительную информацию о концепциях percentiles-histogram, percentiles и slo см. в разделе “Гистограммы и перцентили” документации Micrometer.

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

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

Перейдя к /actuator/metrics, отобразится список доступных имён метрик. Вы можете углубиться, чтобы просмотреть информацию о конкретной метрике, указав её имя в качестве селектора — например, /actuator/metrics/jvm.memory.max.

Используемое здесь имя должно соответствовать имени, используемому в коде, а не имени после нормализации именования для системы мониторинга, в которую оно отправляется. Другими словами, если jvm.memory.max отображается как jvm_memory_max в Prometheus из-за соглашения об именовании со змейкой, то при инспектировании метрики в конечной точке metrics вы всё равно должны использовать jvm.memory.max в качестве селектора.

Вы также можете добавить любое количество tag=KEY:VALUE параметров запроса в конец URL-адреса, чтобы углубиться в метрику по измерениям — например, /actuator/metrics/jvm.memory.max?tag=area:nonheap.

Отчётные измерения — это сумма статистик всех метрик, соответствующих имени метрики и любым применённым тегам. В предыдущем примере возвращённая статистика Value — это сумма максимальных размеров занимаемой памяти областей «Code Cache», «Compressed Class Space» и «Metaspace» кучи. Если вы хотите увидеть только максимальный размер для «Metaspace», вы можете добавить дополнительный tag=id:Metaspace — то есть /actuator/metrics/jvm.memory.max?tag=area:nonheap&tag=id:Metaspace.

7.7. Интеграция с Micrometer Observation

На DefaultMeterObservationHandler автоматически зарегистрирована ObservationRegistry, которая создаёт метрики для каждой завершённой наблюдения.

8. Отслеживание

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

Чтобы узнать больше о возможностях отслеживания Micrometer, см. его документацию по справке.

8.1. Поддерживаемые инструменты отслеживания

Spring Boot поставляется с автоконфигурацией для следующих инструментов отслеживания:

  • OpenTelemetry с Zipkin, Wavefront или OTLP

  • OpenZipkin Brave с Zipkin или Wavefront

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

Нам нужен пример приложения, который мы можем использовать для начала работы с отслеживанием. В наших целях подойдет простое веб-приложение «Hello World!», о котором рассказывается в разделе «getting-started.html». Мы будем использовать инструмент отслеживания OpenTelemetry с Zipkin в качестве бэкенда трассировки.

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

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@SpringBootApplication
public class MyApplication {

    private static final Log logger = LogFactory.getLog(MyApplication.class);

    @RequestMapping("/")
    String home() {
        logger.info("home() has been called");
        return "Hello World!";
    }

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}
В методе home() добавлена запись в логгер, которая будет важна позже.

Теперь нам нужно добавить следующие зависимости:

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

  • io.micrometer:micrometer-tracing-bridge-otel — связывает API наблюдения Micrometer с OpenTelemetry.

  • io.opentelemetry:opentelemetry-exporter-zipkin — отправляет трассы в Zipkin.

Добавьте следующие свойства приложения:

Свойства
management.tracing.sampling.probability=1.0
Yaml
management:
  tracing:
    sampling:
      probability: 1.0

По умолчанию Spring Boot отбирает только 10% запросов, чтобы избежать перегрузки бэкенда отслеживания. Это свойство переключает его на 100%, так что каждый запрос отправляется в бэкенд отслеживания.

Для сбора и визуализации трасс нам нужен работающий бэкенд отслеживания. Здесь мы используем Zipkin в качестве бэкенда отслеживания. Руководство по быстрой настройке Zipkin содержит инструкции по запуску Zipkin локально.

После запуска Zipkin можно запустить ваше приложение.

Если открыть веб-браузер по адресу localhost:8080, вы должны увидеть следующий вывод:

Hello World!

За кулисами было создано наблюдение для HTTP-запроса, которое в свою очередь передается в OpenTelemetry, который отправляет новую трассу в Zipkin.

Теперь откройте интерфейс Zipkin по адресу localhost:9411 и нажмите кнопку «Запустить запрос», чтобы перечислить все собранные трассы. Вы должны увидеть одну трассу. Нажмите кнопку «Показать», чтобы увидеть подробности этой трассы.

Вы можете включить текущий идентификатор трассы и раздела в журналы, установив свойство logging.pattern.level в значение %5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]

8.3. Распространение трасс

Для автоматического распространения трасс по сети используйте автоматически настроенный RestTemplateBuilder или WebClient.Builder для создания клиента.

Если вы создаете WebClient или RestTemplate без использования автоматически настроенных билдеров, автоматическое распространение трасс не сработает!

8.4. Реализации инструментов отслеживания

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

Все реализации инструментов отслеживания требуют зависимости org.springframework.boot:spring-boot-starter-actuator.

8.4.1. OpenTelemetry с Zipkin

Отслеживание с OpenTelemetry и отчетность в Zipkin требуют следующих зависимостей:

  • io.micrometer:micrometer-tracing-bridge-otel - связывает API наблюдения Micrometer с OpenTelemetry.

  • io.opentelemetry:opentelemetry-exporter-zipkin - отправляет трассы в Zipkin.

Используйте свойства конфигурации management.zipkin.tracing.* для настройки отправки в Zipkin.

8.4.2. OpenTelemetry с Wavefront

Отслеживание с OpenTelemetry и отчетность в Wavefront требуют следующих зависимостей:

  • io.micrometer:micrometer-tracing-bridge-otel - связывает API наблюдения Micrometer с OpenTelemetry.

  • io.micrometer:micrometer-tracing-reporter-wavefront - отправляет трассы в Wavefront.

Используйте свойства конфигурации management.wavefront.* для настройки отправки в Wavefront.

8.4.3. OpenTelemetry с OTLP

Отслеживание с OpenTelemetry и отчетность с использованием OTLP требуют следующих зависимостей:

  • io.micrometer:micrometer-tracing-bridge-otel - связывает API наблюдения Micrometer с OpenTelemetry.

  • io.opentelemetry:opentelemetry-exporter-otlp - отправляет трассы в коллектор, который может принимать OTLP.

Используйте свойства конфигурации management.otlp.tracing.* для настройки отправки с использованием OTLP.

8.4.4. OpenZipkin Brave с Zipkin

Отслеживание с OpenZipkin Brave и отчетность в Zipkin требуют следующих зависимостей:

  • io.micrometer:micrometer-tracing-bridge-brave - связывает API наблюдения Micrometer с Brave.

  • io.zipkin.reporter2:zipkin-reporter-brave - отправляет трассы в Zipkin.

Если ваш проект не использует Spring MVC или Spring WebFlux, также необходима зависимость io.zipkin.reporter2:zipkin-sender-urlconnection .

Используйте свойства конфигурации management.zipkin.tracing.* для настройки отправки в Zipkin.

8.4.5. OpenZipkin Brave с Wavefront

Отслеживание с OpenZipkin Brave и отчетность в Wavefront требуют следующих зависимостей:

  • io.micrometer:micrometer-tracing-bridge-brave - связывает API наблюдения Micrometer с Brave.

  • io.micrometer:micrometer-tracing-reporter-wavefront - отправляет трассы в Wavefront.

Используйте свойства конфигурации management.wavefront.* для настройки отправки в Wavefront.

8.5. Интеграция с Micrometer Observation

На ObservationRegistry автоматически регистрируется TracingAwareMeterObservationHandler, который создаёт разделы для каждого завершенного наблюдения.

8.6. Создание собственных разделов

Вы можете создавать собственные разделы, начав наблюдение. Для этого внедрите ObservationRegistry в ваш компонент:

import io.micrometer.observation.Observation;
import io.micrometer.observation.ObservationRegistry;

import org.springframework.stereotype.Component;

@Component
class CustomObservation {

    private final ObservationRegistry observationRegistry;

    CustomObservation(ObservationRegistry observationRegistry) {
        this.observationRegistry = observationRegistry;
    }

    void someOperation() {
        Observation observation = Observation.createNotStarted("some-operation", this.observationRegistry);
        observation.lowCardinalityKeyValue("some-tag", "some-value");
        observation.observe(() -> {
            // Business logic ...
        });
    }

}

Это создаст наблюдение с именем «some-operation» и меткой «some-tag=some-value».

Если вы хотите создать раздел без создания метрики, вам нужно использовать низкоуровневый API Tracer из Micrometer.

8.7. Багаж

Вы можете создать багаж с помощью API Tracer:

import io.micrometer.tracing.BaggageInScope;
import io.micrometer.tracing.Tracer;

import org.springframework.stereotype.Component;

@Component
class CreatingBaggage {

    private final Tracer tracer;

    CreatingBaggage(Tracer tracer) {
        this.tracer = tracer;
    }

    void doSomething() {
        try (BaggageInScope scope = this.tracer.createBaggageInScope("baggage1", "value1")) {
            // Business logic
        }
    }

}

Этот пример создает багаж с именем baggage1 и значением value1. Багаж автоматически передаётся по сети, если вы используете распространение W3C. Если вы используете распространение B3, багаж не передается автоматически. Для ручного распространения багажа по сети используйте свойство конфигурации management.tracing.baggage.remote-fields (это работает и для W3C). Для приведенного выше примера установка этого свойства в значение baggage1 приводит к HTTP-заголовку baggage1: value1.

Если вы хотите распространить багаж в MDC, используйте свойство конфигурации management.tracing.baggage.correlation.fields . Для примера выше, установка этого свойства в значение baggage1 приводит к записи в MDC с именем baggage1.

9. Аудит

После включения Spring Security, Spring Boot Actuator имеет гибкую систему аудита, которая публикует события (по умолчанию, «успешная авторизация», «ошибка авторизации» и «отказ в доступе»). Эта функция может быть очень полезной для отчетности и для реализации политики блокировки на основе ошибок авторизации.

Вы можете включить аудит, предоставив бин типа AuditEventRepository в конфигурации вашего приложения. Для удобства Spring Boot предлагает InMemoryAuditEventRepository. InMemoryAuditEventRepository обладает ограниченными возможностями, и мы рекомендуем использовать его только для сред разработки. Для производственных сред рекомендуется создать собственное альтернативное реализацию AuditEventRepository.

9.1. Настройка аудита

Чтобы настроить публикуемые события безопасности, вы можете предоставить свои собственные реализации AbstractAuthenticationAuditListener и AbstractAuthorizationAuditListener.

Вы также можете использовать службы аудита для своих бизнес-событий. Для этого либо введите бин AuditEventRepository в свои компоненты и используйте его напрямую, либо опубликуйте AuditApplicationEvent с помощью Spring ApplicationEventPublisher (реализовав ApplicationEventPublisherAware).

10. Запись HTTP-обменов

Вы можете включить запись HTTP-обменов, предоставив бин типа HttpExchangeRepository в конфигурации вашего приложения. Для удобства Spring Boot предлагает InMemoryHttpExchangeRepository, который по умолчанию хранит последние 100 запросов-ответов. InMemoryHttpExchangeRepository имеет ограниченные возможности по сравнению с решениями отслеживания, и мы рекомендуем использовать его только для сред разработки. Для производственных сред рекомендуется использовать готовое к производству решение для отслеживания или наблюдаемости, такое как Zipkin или OpenTelemetry. В качестве альтернативы вы можете создать собственное HttpExchangeRepository.

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

10.1. Настройка записи HTTP-обменов

Чтобы настроить элементы, включаемые в каждую записанную операцию обмена, используйте свойство конфигурации management.httpexchanges.recording.include.

Чтобы полностью отключить запись, установите management.httpexchanges.recording.enabled в false.

11. Мониторинг процессов

В модуле spring-boot вы найдете два класса для создания файлов, которые часто полезны для мониторинга процессов:

  • ApplicationPidFileWriter создает файл, содержащий идентификатор процесса приложения (по умолчанию, в каталоге приложения с именем файла application.pid).

  • WebServerPortFileWriter создает файл (или файлы), содержащие порты работающего веб-сервера (по умолчанию, в каталоге приложения с именем файла application.port).

По умолчанию эти записи не активированы, но вы можете их включить:

  • Настройка конфигурации

  • Включение мониторинга процессов программно

11.1. Расширение конфигурации

В файле META-INF/spring.factories вы можете активировать слушатель (или слушателей), который записывает файл с PID:

org.springframework.context.ApplicationListener=\
org.springframework.boot.context.ApplicationPidFileWriter,\
org.springframework.boot.web.context.WebServerPortFileWriter

11.2. Программное включение мониторинга процессов

Вы также можете активировать слушатель, вызвав метод SpringApplication.addListeners(…​) и передав соответствующий объект Writer. Этот метод также позволяет настроить имя и путь к файлу в конструкторе Writer.

12. Поддержка Cloud Foundry

Модуль Actuator Spring Boot включает дополнительную поддержку, которая активируется при развертывании в совместимом экземпляре Cloud Foundry. Путь /cloudfoundryapplication предоставляет альтернативный защищенный маршрут ко всем бин @Endpoint.

Расширенная поддержка позволяет управлять пользовательскими интерфейсами Cloud Foundry (например, веб-приложением, с помощью которого можно просматривать развернутые приложения) с информацией Spring Boot actuator. Например, страница состояния приложения может включать полную информацию о состоянии вместо стандартного состояния «работает» или «остановлен».

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

12.1. Отключение расширенной поддержки Cloud Foundry Actuator

Если вы хотите полностью отключить конечные точки /cloudfoundryapplication, вы можете добавить следующее свойство в свой файл application.properties:

Свойства
management.cloudfoundry.enabled=false
Yaml
management:
  cloudfoundry:
    enabled: false

12.2. Самозаверяющие сертификаты Cloud Foundry

По умолчанию проверка безопасности для конечных точек /cloudfoundryapplication выполняет SSL-вызовы к различным службам Cloud Foundry. Если службы UAA или Cloud Controller Cloud Foundry используют самозаверяющие сертификаты, вам нужно установить следующее свойство:

Свойства
management.cloudfoundry.skip-ssl-validation=true
Yaml
management:
  cloudfoundry:
    skip-ssl-validation: true

12.3. Настройка пользовательского контекстного пути

Если контекстный путь сервера настроен на значение, отличное от /, конечные точки Cloud Foundry недоступны в корне приложения. Например, если server.servlet.context-path=/app, конечные точки Cloud Foundry доступны по адресу /app/cloudfoundryapplication/*.

Если вы ожидаете, что конечные точки Cloud Foundry всегда будут доступны по адресу /cloudfoundryapplication/*, независимо от контекстного пути сервера, вам необходимо явно настроить это в вашем приложении. Конфигурация отличается в зависимости от используемого веб-сервера. Для Tomcat вы можете добавить следующую конфигурацию:

Java
import java.io.IOException;
import java.util.Collections;

import jakarta.servlet.GenericServlet;
import jakarta.servlet.Servlet;
import jakarta.servlet.ServletContainerInitializer;
import jakarta.servlet.ServletContext;
import jakarta.servlet.ServletException;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import org.apache.catalina.Host;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.startup.Tomcat;

import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory;
import org.springframework.boot.web.servlet.ServletContextInitializer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyCloudFoundryConfiguration {

    @Bean
    public TomcatServletWebServerFactory servletWebServerFactory() {
        return new TomcatServletWebServerFactory() {

            @Override
            protected void prepareContext(Host host, ServletContextInitializer[] initializers) {
                super.prepareContext(host, initializers);
                StandardContext child = new StandardContext();
                child.addLifecycleListener(new Tomcat.FixContextListener());
                child.setPath("/cloudfoundryapplication");
                ServletContainerInitializer initializer = getServletContextInitializer(getContextPath());
                child.addServletContainerInitializer(initializer, Collections.emptySet());
                child.setCrossContext(true);
                host.addChild(child);
            }

        };
    }

    private ServletContainerInitializer getServletContextInitializer(String contextPath) {
        return (classes, context) -> {
            Servlet servlet = new GenericServlet() {

                @Override
                public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException {
                    ServletContext context = req.getServletContext().getContext(contextPath);
                    context.getRequestDispatcher("/cloudfoundryapplication").forward(req, res);
                }

            };
            context.addServlet("cloudfoundry", servlet).addMapping("/*");
        };
    }

}
Kotlin
import jakarta.servlet.GenericServlet
import jakarta.servlet.Servlet
import jakarta.servlet.ServletContainerInitializer
import jakarta.servlet.ServletContext
import jakarta.servlet.ServletException
import jakarta.servlet.ServletRequest
import jakarta.servlet.ServletResponse
import org.apache.catalina.Host
import org.apache.catalina.core.StandardContext
import org.apache.catalina.startup.Tomcat.FixContextListener
import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory
import org.springframework.boot.web.servlet.ServletContextInitializer
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import java.io.IOException
import java.util.Collections.emptySet

@Configuration(proxyBeanMethods = false)
class MyCloudFoundryConfiguration {

    @Bean
    fun servletWebServerFactory(): TomcatServletWebServerFactory {
        return object : TomcatServletWebServerFactory() {

            override fun prepareContext(host: Host, initializers: Array<ServletContextInitializer>) {
                super.prepareContext(host, initializers)
                val child = StandardContext()
                child.addLifecycleListener(FixContextListener())
                child.path = "/cloudfoundryapplication"
                val initializer = getServletContextInitializer(contextPath)
                child.addServletContainerInitializer(initializer, emptySet())
                child.crossContext = true
                host.addChild(child)
            }

        }
    }

    private fun getServletContextInitializer(contextPath: String): ServletContainerInitializer {
        return ServletContainerInitializer { classes: Set<Class<*>?>?, context: ServletContext ->
            val servlet: Servlet = object : GenericServlet() {

                @Throws(ServletException::class, IOException::class)
                override fun service(req: ServletRequest, res: ServletResponse) {
                    val servletContext = req.servletContext.getContext(contextPath)
                    servletContext.getRequestDispatcher("/cloudfoundryapplication").forward(req, res)
                }

            }
            context.addServlet("cloudfoundry", servlet).addMapping("/*")
        }
    }
}

13. Что читать дальше

Возможно, вам следует прочитать об инструментах визуализации данных, таких как Graphite.

В противном случае вы можете продолжить чтение о “вариантах развертывания” или перейти к углубленному изучению плагинов для инструментов сборки Spring Boot.

Copyright © 2012-2023 VMware, Inc.
Licensed under the Apache License, Version 2.0.
https://docs.spring.io/spring-boot/docs/3.1.3/reference/html/actuator.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API