MicroProfile Health API — это базовый API-интерфейс для отчета о состоянии вашего сервиса, основанный на одном или нескольких Health Probe. Это очень полезно в тех случаях, когда какой-либо сервер или контроллер кластера должны решить, следует ли перезапускать ваш экземпляр и когда.
Использовать MicroProfile Health API в вашем приложении так же просто, как реализовать один (или несколько) org.eclipse.microprofile.health.HealthCheck и аннотировать класс с помощью @Health .
Интерфейс HealthCheck имеет один метод, который вы должны реализовать, а именно HealthCheckResponse call() .
Итак, вы решаете, когда этот метод вызывается, если ваш экземпляр здоров.
Ваш ответ ( HealthCheckResponse ) содержит:
- имя для идентификации этого зонда от других зондов.
- флаг ВВЕРХ или ВНИЗ , чтобы указать состояние.
- любые другие метаданные, которые вы хотите включить в пару ключ-значение.
Основной пример.
Допустим, у нас есть приложение, которое использует базу данных, и если соединение с базой данных не работает (или очень медленно), мы должны сообщить, что это приложение не работает:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
@Health @ApplicationScoped public class MembershipHealthCheck implements HealthCheck { @Inject private DataSource datasource; @Override public HealthCheckResponse call() { HealthCheckResponseBuilder responseBuilder = HealthCheckResponse.named("membership"); try { Connection connection = datasource.getConnection(); boolean isValid = connection.isValid(timeout); DatabaseMetaData metaData = connection.getMetaData(); responseBuilder = responseBuilder .withData("databaseProductName", metaData.getDatabaseProductName()) .withData("databaseProductVersion", metaData.getDatabaseProductVersion()) .withData("driverName", metaData.getDriverName()) .withData("driverVersion", metaData.getDriverVersion()) .withData("isValid", isValid); return responseBuilder.state(isValid).build(); } catch(SQLException e) { log.log(Level.SEVERE, null, e); responseBuilder = responseBuilder .withData("exceptionMessage", e.getMessage()); return responseBuilder.down().build(); } } } |
(см. полный пример здесь )
В приведенном выше примере имя проверки работоспособности — «членство» и сообщает UP, если соединение с базой данных может быть установлено в течение определенного времени. Он также включает несколько полей метаданных в базе данных.
/здоровье.
Если вы перейдете к /health на своем сервере, вы увидите агрегированный ответ от всех зондов и общее состояние (ВВЕРХ или ВНИЗ) сервера.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
{ "outcome":"UP", "checks":[ { "name":"membership", "state":"UP", "data":{ "databaseProductVersion":"5.5.5-10.1.35-MariaDB", "databaseProductName":"MySQL", "driverVersion":"mysql-connector-java-8.0.11 (Revision: 6d4eaa273bc181b4cf1c8ad0821a2227f116fedf)", "isValid":"true", "driverName":"MySQL Connector/J" } } ] } |
Если база данных выходит из строя:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
{ "outcome":"DOWN", "checks":[ { "name":"membership", "state":"DOWN", "data":{ "exceptionMessage":"No operations allowed after connection closed." } } ] } |
Создание зондов многократного использования с конфигурацией MicroProfile.
Определенные датчики работоспособности могут быть повторно использованы любым вашим приложением, и вы можете перенести параметры настройки с помощью API-интерфейса Microprofile Config . Например, если нам нужен датчик работоспособности, который проверяет нагрузку на систему, мы можем вывести на внешний уровень, на каком этапе нагрузка на систему должна начать сообщать о сбое.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
@Health @ApplicationScoped public class SystemLoadHealthCheck implements HealthCheck { @Inject @ConfigProperty(name = "health.systemload.max", defaultValue = "0.7") private double max; @Override public HealthCheckResponse call() { OperatingSystemMXBean operatingSystemMXBean = ManagementFactory.getOperatingSystemMXBean(); String arch = operatingSystemMXBean.getArch(); String name = operatingSystemMXBean.getName(); String version = operatingSystemMXBean.getVersion(); int availableProcessors = operatingSystemMXBean.getAvailableProcessors(); double systemLoadAverage = operatingSystemMXBean.getSystemLoadAverage(); double systemLoadAveragePerProcessors = systemLoadAverage / availableProcessors; HealthCheckResponseBuilder responseBuilder = HealthCheckResponse.named("system-load") .withData("name", name) .withData("arch", arch) .withData("version", version) .withData("processors", availableProcessors) .withData("loadAverage", String.valueOf(systemLoadAverage)) .withData("loadAverage per processor", String.valueOf(systemLoadAveragePerProcessors)) .withData("loadAverage max", String.valueOf(max)); if(systemLoadAverage>0){ boolean status = systemLoadAveragePerProcessors < max; return responseBuilder.state(status).build(); }else{ // Load average not available return responseBuilder.up().build(); } } } |
(см. полный пример здесь )
Выше мы теперь можем переопределить загрузку системы по умолчанию 0.7 к нашему собственному значению, изменив health.systemload.max конфигурации health.systemload.max .
Другие примеры могут включать:
- Память кучи
- Не куча памяти
- Число потоков
Используя это в вашем проекте
Вы можете использовать все вышеперечисленное в своем проекте, так как он доступен в maven central и github :
В вашем pom.xml :
|
1
2
3
4
5
|
<dependency> <groupId>com.github.phillip-kruger.microprofile-extensions</groupId> <artifactId>health-ext</artifactId> <version>1.0.9</version> </dependency> |
Совокупный результат /health может выглядеть примерно так:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
{ "outcome":"UP", "checks":[ { "name":"system-load", "state":"UP", "data":{ "name":"Linux", "arch":"amd64", "processors":"8", "loadAverage":"2.03", "version":"4.18.1-arch1-1-ARCH", "loadAverage max":"0.7", "loadAverage per processor":"0.25375" } }, { "name":"membership", "state":"UP", "data":{ "databaseProductVersion":"5.5.5-10.1.35-MariaDB", "databaseProductName":"MySQL", "driverVersion":"mysql-connector-java-8.0.11 (Revision: 6d4eaa273bc181b4cf1c8ad0821a2227f116fedf)", "isValid":"true", "driverName":"MySQL Connector/J" } }, { "name":"non-heap-memory", "state":"UP", "data":{ "max %":"0.9", "max":"-1", "used":"132792064" } }, { "name":"threads", "state":"UP", "data":{ "max thread count":"-1", "daemon thread count":"86", "monitor deadlocked thread count":"0", "thread count":"134", "deadlocked thread count":"0", "started thread count":"138", "peak thread count":"136" } }, { "name":"heap-memory", "state":"UP", "data":{ "max %":"0.9", "max":"14995161088", "used":"207556800" } } ] } |
| Опубликовано на Java Code Geeks с разрешения Филиппа Крюгера, партнера нашей программы JCG . Смотрите оригинальную статью здесь: Многоразовые пробники MicroProfile Health
Мнения, высказанные участниками Java Code Geeks, являются их собственными. |