Java Blog

Если вы разрабатываете веб-приложение, Spring Boot Actuator автоматически настраивает все включенные конечные точки для показа через HTTP. Соглашение по умолчанию заключается в использовании идентификатора конечной точки с префиксом /actuator в качестве пути URL. Например, health показывается как /actuator/health. Actuator изначально поддерживается Spring MVC, Spring WebFlux и Jersey. Если доступны как Jersey, так и Spring MVC, будет использоваться Spring MVC. Jackson является обязательной зависимостью для получения правильных ответов JSON. Настройка путей конечных точек управления Иногда полезно настроить префикс для конечных точек управления (management endpoints). Например, ваше приложение может уже использовать /actuator для других целей. Вы можете использовать свойство management.endpoints.web.base-path, чтобы изменить префикс для конечной точки management, как показано в следующем примере: management.endpoints.web.base-path=/manage В предыдущем примере application.prop

Информация о приложении предоставляет различную информацию, собранную из всех компонентов InfoContributor, определенных в вашем ApplicationContext. Spring Boot включает в себя несколько автоматически настраиваемых компонентов InfoContributor, и вы можете написать свой собственный. Автоконфигурированные InfoContributors Следующие компоненты InfoContributor автоматически настраиваются Spring Boot, когда это необходимо: Название Описание EnvironmentInfoContributor Предоставляет любой ключ из Environment под info ключом. GitInfoContributor Предоставляет информацию о git, если файл git.properties доступен. BuildInfoContributor Предоставляет информацию о сборке, если доступен файл META-INF/build-info.properties. Их можно отключить, установив свойство management.info.defaults.enabled. Настраиваемая информация о приложении Вы можете настроить данные, предоставляемые конечной точкой info, установив info.* свойства Spring. Все свойства среды под info ключом выставляются а

Иногда полезно разбить показатели работоспособности на группы, которые можно использовать для разных целей. Например, если вы развертываете свое приложение в Kubernetes, вам может потребоваться разные набор индикаторов работоспособности для ваших проб “liveness” и “readiness”. Для создания группы индикаторов работоспособности вы можете использовать свойство management.endpoint.health.group.<name> и указать список идентификаторов индикаторов работоспособности, которые нужно включить или исключить. Например, чтобы создать группу, включающую только индикаторы базы данных, вы можете определить следующее: management.endpoint.health.group.custom.include=db Затем вы можете проверить результат, сделав запрос по localhost:8080/actuator/health/custom. По умолчанию группы наследуют те же параметры StatusAggregator и HttpCodeStatusMapper, что и health системы, однако они также могут быть определены для каждой группы. Также возможно переопределить свойства show-details и roles, если

Для реактивных приложений, таких как использующие Spring WebFlux, ReactiveHealthContributor предоставляет неблокирующий контракт для получения работоспособности приложения. Подобно традиционному HealthContributor, информация о работоспособности собирается из содержимого ReactiveHealthContributorRegistry (по умолчанию все экземпляры HealthContributor и ReactiveHealthContributor, определенные в ApplicationContext). Обычные HealthContributors, которые не проверяют реактивный API, выполняются в эластичном планировщике. В реактивном приложении ReactiveHealthContributorRegistry следует использовать для регистрации и отмены регистрации индикаторов состояния во время выполнения. Если вам нужно зарегистрировать обычного HealthContributor, вам следует обернуть его с помощью ReactiveHealthContributor#adapt. Чтобы предоставить пользовательскую информацию о работоспособности из реактивного API, вы можете зарегистрировать компоненты Spring, которые реализуют интерфейс ReactiveHealthIndicator. В сл

Чтобы предоставить пользовательскую информацию о работоспособности (health), вы можете зарегистрировать компоненты Spring, которые реализуют интерфейс HealthIndicator. Вам необходимо предоставить реализацию метода health() и вернуть ответ Health. Ответ о работоспособности должен включать статус и при желании может включать дополнительные сведения, которые будут отображаться. В следующем коде показан пример реализации HealthIndicator: 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(); } } Идентификато

При необходимости Spring Boot автоматически настраивает следующие HealthIndicators: Имя Описание CassandraHealthIndicator Проверяет, что база данных Cassandra работает. CouchbaseHealthIndicator Проверяет, что кластер Couchbase работает. DiskSpaceHealthIndicator Проверяет, мало ли места на диске. DataSourceHealthIndicator Проверяет, что соединение с DataSource может быть получено. ElasticSearchRestHealthContributorAutoConfiguration Проверяет, работает ли кластер Elasticsearch. HazelcastHealthIndicator Проверяет, работает ли сервер Hazelcast. InfluxDbHealthIndicator Проверяет, работает ли сервер InfluxDB. JmsHealthIndicator Проверяет, работает ли JMS-брокер. LdapHealthIndicator Проверяет, работает ли сервер LDAP. MailHealthIndicator Проверяет, что почтовый сервер работает. MongoHealthIndicator Проверяет, что база данных Mongo работает. Neo4jHealthIndicator Проверяет, что база данных Neo4j работает. PingHealthIndicator Всегда отвеча

Вы можете использовать информацию о работоспособности (health), чтобы проверить состояние вашего работающего приложения. Он часто используется программным обеспечением для мониторинга, чтобы предупредить кого-либо, когда производственная система выходит из строя. Информация, предоставляемая конечной точкой health, зависит от свойств management.endpoint.health.show-details и management.endpoint.health.show-components, для которых можно настроить одно из следующих значений: Имя Описание never Подробности никогда не показываются. when-authorized Подробности показываются только авторизованным пользователям. Авторизованные роли можно настроить с помощью management.endpoint.health.roles. always Подробности показаны всем пользователям. Значением по умолчанию является never. Пользователь считается авторизованным, когда он выполняет одну или несколько ролей конечной точки. Если конечная точка не имеет настроенных ролей (по умолчанию), все аутентифицированные пользователи счи

Пользовательские веб конечные точки Операции над @Endpoint, @WebEndpoint или @EndpointWebExtension автоматически предоставляются через HTTP с использованием Jersey, Spring MVC или Spring WebFlux. Если доступны как Jersey, так и Spring MVC, будет использоваться Spring MVC. Предикаты запроса веб конечной точки Предикат запроса генерируется автоматически для каждой операции в конечной точке, доступной через веб. Путь Путь предиката определяется идентификатором конечной точки и базовым путем открытых конечных точек. Базовый путь по умолчанию - /actuator. Например, конечная точка с идентификаторами sessions будет использовать /actuator/sessions в качестве своего пути в предикате. Путь может быть дополнительно настроен путем аннотирования одного или нескольких параметров метода операции с помощью @Selector. Такой параметр добавляется к предикату пути как переменная пути. Значение переменной передается в метод операции при вызове операции конечной точки. Если вы хотите захватить все ост

Операции на конечной точке получают ввод через свои параметры. При отображении через веб значения этих параметров берутся из параметров URL-адреса запроса и из JSON тела запроса. При отображении через JMX параметры сопоставляются с параметрами операций MBean. Параметры обязательны по умолчанию. Их можно сделать необязательными, пометив их @org.springframework.lang.Nullable. Каждое корневое свойство в JSON теле запроса может быть сопоставлено с параметром конечной точки. Рассмотрим следующее JSON тело запроса: { "name": "test", "counter": 42 } Это можно использовать для вызова операции записи, которая принимает параметры String name и int counter. Поскольку конечные точки не зависят от технологии, в сигнатуре метода могут быть указаны только простые типы. В частности, объявление одного параметра с пользовательским типом, определяющим имя и свойства счетчика, не поддерживается. Чтобы разрешить сопоставление ввода с параметрами метода операц

Если вы добавляете @Bean, аннотированный @Endpoint, любые методы, аннотированные @ReadOperation, @WriteOperation или @DeleteOperation, автоматически отображаются через JMX и, в веб-приложении, также через HTTP. Конечные точки могут быть открыты через HTTP с использованием Jersey, Spring MVC или Spring WebFlux. Если доступны как Jersey, так и Spring MVC, будет использоваться Spring MVC. Вы также можете написать специфичные для технологии конечные точки, используя @JmxEndpoint или @WebEndpoint. Эти конечные точки ограничены соответствующими технологиями. Например, @WebEndpoint предоставляется только через HTTP, а не через JMX. Вы можете написать специфичные для технологии расширения, используя @EndpointWebExtension и @EndpointJmxExtension. Эти аннотации позволяют вам выполнять специфические для технологии операции для расширения существующей конечной точки. Наконец, если вам нужен доступ к функциям, специфичным для веб-фреймворка, вы можете реализовать конечные точки Servlet или Sprin

Конечные точки автоматически кэшируют ответы на операции чтения, которые не принимают никаких параметров. Чтобы настроить время, в течение которого конечная точка будет кэшировать ответ, используйте ее свойство cache.time-to-live. В следующем примере время жизни кэша конечной точки beans устанавливается равным 10 секундам: application.properties management.endpoint.beans.cache.time-to-live=10s Префикс management.endpoint.<name> используется для однозначной идентификации настраиваемой конечной точки. При выполнении аутентифицированного HTTP-запроса Principal рассматривается как входная информация для конечной точки, и поэтому ответ не будет кэшироваться. Hypermedia для конечных точек Actuator Web Добавлена ​​«страница обнаружения» (“discovery page”) со ссылками на все конечные точки. «Страница обнаружения» по умолчанию доступна в /actuator. Когда настраиваемый путь контекста управления настроен, «страница обнаружения» автоматически перемещается из /actuator в корень кон

Вы должны позаботиться о защите конечных точек HTTP так же, как и любого другого конфиденциального URL. Если Spring Security присутствует, конечные точки защищены по умолчанию с использованием стратегии согласования содержимого Spring Security. Если вы хотите настроить пользовательскую безопасность для конечных точек HTTP, например, разрешить доступ к ним только пользователям с определенной ролью, Spring Boot предоставляет несколько удобных объектов RequestMatcher, которые можно использовать в сочетании с Spring Security. Типичная конфигурация Spring Security может выглядеть примерно так: @Configuration(proxyBeanMethods = false) public class ActuatorSecurity extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.requestMatcher(EndpointRequest.toAnyEndpoint()).authorizeRequests((requests) -> requests.anyRequest().hasRole("ENDPOINT_ADMIN")); http.httpBasic(); } }

Поскольку конечные точки могут содержать конфиденциальную информацию, необходимо тщательно продумать, когда их следует раскрывать. В следующей таблице показано открытие по умолчанию для встроенных конечных точек: ID JMX Web auditevents Да Нет beans Да Нет caches Да Нет conditions Да Нет configprops Да Нет env Да Нет flyway Да Нет health Да Да heapdump Не применимо Нет httptrace Да Нет info Да Да integrationgraph Да Нет jolokia Не применимо Нет logfile Не применимо Нет loggers Да Нет liquibase Да Нет metrics Да Нет mappings Да Нет prometheus Не применимо Нет scheduledtasks Да Нет sessions Да Нет shutdown Да Нет threaddump Да Нет Чтобы изменить конечные точки, используйте следующие специальные свойства include и exclude: Свойство Значение по умолчанию management.endpoints.jmx.exposure.exclude management.endpoints.jmx.exposure.include * management.endp

По умолчанию все конечные точки, кроме shutdown, включены. Чтобы настроить включение конечной точки, используйте ее свойство management.endpoint.<id>.enabled. В следующем примере включается конечная точка shutdown: management.endpoint.shutdown.enabled=true Если вы предпочитаете, чтобы включение конечной точки было включением, а не выключением, установите для свойства management.endpoints.enabled-by-default значение false и используйте отдельные свойства конечных точек с enabled для возврата. В следующем примере включается info конечная точка и отключаются все остальные конечные точки: management.endpoints.enabled-by-default=false management.endpoint.info.enabled=true Отключенные конечные точки полностью удаляются из контекста приложения. Если вы хотите изменить только те технологии, которые используются в конечной точке, используйте вместо этого свойства include и exclude. Читайте также: Spring Boot Actuator: функции готовности к производственной работе Spring

Конечные точки actuator'а позволяют вам контролировать и взаимодействовать с вашим приложением. Spring Boot включает в себя ряд встроенных конечных точек и позволяет добавлять свои собственные. Например, конечная точка health предоставляет базовую информацию о работоспособности приложений. Каждая отдельная конечная точка может быть включена или отключена. Это контролирует, создана ли конечная точка и существует ли ее компонент в контексте приложения. Чтобы быть доступной удаленно, конечная точка также должна быть доступна через JMX или HTTP. Большинство приложений выбирают HTTP, где идентификатор конечной точки вместе с префиксом /actuator сопоставляется с URL-адресом. Например, по умолчанию конечная точка health сопоставлена ​​с /actuator/health. Доступны следующие независимые от технологии конечные точки: ID Описание auditevents Предоставляет информацию о событиях аудита для текущего приложения. Требуется компонент AuditEventRepository. beans Отображает полный спис

Spring Boot включает в себя ряд дополнительных функций, которые помогут вам контролировать и управлять приложением, когда вы запускаете его в производство. Вы можете управлять своим приложением и контролировать его, используя конечные точки HTTP или JMX. Аудит, исправность и сбор метрик также могут автоматически применяться к вашему приложению. Включение функций готовности к производственной работе Модуль spring-boot-actuator предоставляет все Spring Boot функции готовности к производственной работе. Самый простой способ включить эти функции - добавить зависимость стартера spring-boot-starter-actuator. Определение Actuator Actuator - это производственный термин, который относится к механическому устройству для перемещения или управления чем-либо. Actuator'ы могут генерировать большое количество движения от небольшого изменения. Чтобы добавить actuator в проект на основе Maven, добавьте следующую зависимость стартера: <dependencies> <dependency> <

Kotlin API: runApplication Spring Boot предоставляет идиоматический способ запуска приложения с помощью runApplication<MyApplication>(*args), как показано в следующем примере: import org.springframework.boot.autoconfigure.SpringBootApplication import org.springframework.boot.runApplication @SpringBootApplication class MyApplication fun main(args: Array<String>) { runApplication<MyApplication>(*args) } Это замена для SpringApplication.run(MyApplication::class.java, *args). Это также позволяет настраивать приложение, как показано в следующем примере: runApplication<MyApplication>(*args) { setBannerMode(OFF) } Kotlin API: расширения Расширения Kotlin предоставляют возможность расширять существующие классы дополнительными функциями. Spring Boot Kotlin API использует эти расширения для добавления новых специфичных для Kotlin удобств в существующие API. Предусмотрены расширения TestRestTemplate, аналогичные тем, которые предоставляются Sprin

Kotlin - это статически типизированный язык, предназначенный для JVM (и других платформ), который позволяет писать лаконичный и элегантный код, обеспечивая при этом совместимость с существующими библиотеками, написанными на Java. Spring Boot обеспечивает поддержку Kotlin, используя поддержку других проектов Spring, таких как Spring Framework, Spring Data и Reactor. Требования Spring Boot поддерживает Kotlin 1.3.x. Чтобы использовать Kotlin, в пути к классам должны присутствовать org.jetbrains.kotlin:kotlin-stdlib и org.jetbrains.kotlin:kotlin-reflect. Варианты kotlin-stdlib kotlin-stdlib-jdk7 и kotlin-stdlib-jdk8 также могут быть использованы. Так как классы Kotlin по умолчанию являются окончательными, вы, вероятно, захотите настроить плагин kotlin-spring, чтобы автоматически открывать классы, аннотированные Spring, чтобы их можно было проксировать. Модуль Jackson Kotlin необходим для сериализации/десериализации данных JSON в Kotlin. Он автоматически регистрируется при обнаружении

Полная версия Spring Boot для библиотеки может содержать следующие компоненты: Модуль autoconfigure, который содержит код автоконфигурации. Модуль starter, который обеспечивает зависимость для модуля автоматической настройки, а также библиотеки и любые дополнительные зависимости, которые обычно полезны. Короче говоря, добавление стартера должно обеспечить все необходимое для начала использования этой библиотеки. Вы можете объединить код автоконфигурации и управление зависимостями в одном модуле, если вам не нужно разделять эти две проблемы. Именование Вы должны убедиться, что предоставили правильное пространство имен для своего стартера. Не начинайте имена модулей со spring-boot, даже если вы используете другой Maven groupId. В будущем возможна официальная поддержка для вещи, которую вы автоматически настраиваете. Как правило, вы должны назвать комбинированный модуль как стартер. Например, предположим, что вы создаете стартер для "acme" назовите модуль автоконфигураци

На автоконфигурацию могут влиять многие факторы: конфигурация пользователя (определение @Bean и настройка Environment), оценка состояния (наличие определенной библиотеки) и другие. Конкретно, каждый тест должен создавать четко определенный ApplicationContext, представляющий комбинацию этих настроек. ApplicationContextRunner предоставляет отличный способ достичь этого. ApplicationContextRunner обычно определяется как поле тестового класса для сбора базовой, общей конфигурации. В следующем примере показано, что UserServiceAutoConfiguration всегда вызывается: private final ApplicationContextRunner contextRunner = new ApplicationContextRunner() .withConfiguration(AutoConfigurations.of(UserServiceAutoConfiguration.class)); Если необходимо определить несколько автоконфигураций, нет необходимости упорядочивать их объявления, так как они вызываются в том же порядке, что и при запуске приложения. Каждый тест может использовать runner для представления конкретного варианта испол

Вы почти всегда захотите включить одну или несколько аннотаций @Conditional в свой класс автоконфигурации. Аннотация @ConditionalOnMissingBean - это один из распространенных примеров, который позволяет разработчикам переопределять автоконфигурацию, если они недовольны вашими настройками по умолчанию. Spring Boot включает в себя ряд аннотаций @Conditional, которые вы можете повторно использовать в своем собственном коде, аннотируя классы @Configuration или отдельные методы @Bean. Эти аннотации включают в себя: Class Conditions (Условия класса) Bean Conditions (Условия компонента) Property Conditions (Условия свойства) Resource Conditions (Условия ресурса) Web Application Conditions (Условия веб-приложения) SpEL Expression Conditions (Условия выражения SpEL) Условия класса Аннотации @ConditionalOnClass и @ConditionalOnMissingClass позволяют включать классы @Configuration в зависимости от наличия или отсутствия определенных классов. Из-за того, что метаданные аннотации анализир

Если вы работаете в компании, которая разрабатывает общие библиотеки, или если вы работаете с открытой или коммерческой библиотекой, вы можете разработать собственную автоконфигурацию. Классы автоконфигурации могут быть объединены во внешние jar-файлы и по-прежнему поддерживаться Spring Boot. Автоконфигурирование может быть связано со стартером, который предоставляет код автоконфигурации, а также типичные библиотеки, которые вы будете использовать с ним. Понимание автоматически настроенных компонентов Под капотом автоконфигурация реализована с помощью стандартных классов @Configuration. Дополнительные аннотации @Conditional используются для ограничения необходимости применения автоконфигурации. Обычно классы автоконфигурации используют аннотации @ConditionalOnClass и @ConditionalOnMissingBean. Это гарантирует, что автоконфигурация применяется только тогда, когда соответствующие классы найдены и когда вы не объявили свою собственную @Configuration. Поиск автоконфигурации кандидатов

Spring Boot обеспечивает автоматическую настройку Web Services, поэтому все, что вам нужно сделать, это определить Endpoints. Доступ к функциям Spring Web Services можно легко получить с помощью модуля spring-boot-starter-webservices. Бины SimpleWsdl11Definition и SimpleXsdSchema могут быть автоматически созданы для ваших WSDL и XSD соответственно. Для этого настройте их расположение, как показано в следующем примере: spring.webservices.wsdl-locations=classpath:/wsdl Вызов Web Services с помощью WebServiceTemplate Если вам нужно вызывать удаленные Web Services из вашего приложения, вы можете использовать класс WebServiceTemplate. Поскольку экземпляры WebServiceTemplate часто необходимо настраивать перед использованием, Spring Boot не предоставляет ни одного автоматически настраиваемого компонента WebServiceTemplate. Однако он автоматически настраивает WebServiceTemplateBuilder, который можно использовать для создания экземпляров WebServiceTemplate при необходимости. Следующи