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

#spring-boot #amazon-elb #spring-boot-actuator

#пружинная загрузка #amazon-elb #пружинный загрузочный привод

Вопрос:

Есть ли какой-либо способ поддерживать несколько конечных точек работоспособности в приложении загрузки Spring?

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

Но я хотел бы что-то, что я мог бы вызвать из группы AWS Elastic Load Balancer / AutoScaling. По умолчанию, если экземпляр не проходит проверку работоспособности, ELB / ASG завершит его и заменит новым экземпляром. Проблема в том, что некоторые проверки работоспособности, такие как DataSourceHealthIndicator, будут сообщать о сбое, если база данных не работает, но в остальном мой экземпляр приложения полностью исправен. Если я использую поведение по умолчанию, AWS будет выбрасывать совершенно исправные экземпляры до тех пор, пока база данных не будет восстановлена, и это увеличит мой счет.

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

/health — Общее состояние приложения / ec2Health — игнорирует аспекты, не связанные с экземпляром EC2, такие как сбой базы данных.

Надеюсь, это имеет смысл.

Комментарии:

1. На какой версии spring boot вы работаете? ЕСЛИ вы хотите просто проверить, способно ли приложение отвечать на HTTP-запросы, и ни один из его внешних ресурсов не работает, довольно просто написать собственную проверку работоспособности

Ответ №1:

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

В application.properties вы настраиваете нужные группы:

 management.endpoints.web.path-mapping.health=probes

management.endpoint.health.group.health.include=*
management.endpoint.health.group.health.show-details=never

management.endpoint.health.group.detail.include=*
management.endpoint.health.group.detail.show-details=always

management.endpoint.health.group.other.include=diskSpace,ping
management.endpoint.health.group.other.show-details=always
  

Вывод:

 $ curl http://localhost:8080/actuator/probes
{"status":"UP","groups":["detail","health","other"]}

$ curl http://localhost:8080/actuator/probes/health
{"status":"UP"}

$ curl http://localhost:8080/actuator/probes/detail
{"status":"UP","components":{"diskSpace":{"status":"UP","details":{"total":0,"free":0,"threshold":0,"exists":true}},"ping":{"status":"UP"},"rabbit":{"status":"UP","details":{"version":"3.6.16"}}}}

$ curl http://localhost:8080/actuator/probes/other
{"status":"UP","components":{"diskSpace":{"status":"UP","details":{"total":0,"free":0,"threshold":0,"exists":true}},"ping":{"status":"UP"}}}
  

Комментарии:

1. Получу ли я другой результат УВЕЛИЧЕНИЯ / УМЕНЬШЕНИЯ в зависимости от того, что включено? Это похоже на базовый механизм запроса / фильтрации, а не на то, что будет оценивать работоспособность по-другому.

2. Да, вы получаете разные результаты в зависимости от того, что вы выбираете. Я думаю, что все в вашем выборе должно быть исправным, чтобы вернулся совокупный показатель "UP" . Например, health может быть "DOWN" из-за сбоя базы данных, но other (из моего примера) все равно может вернуться, "UP" если на вашем локальном диске достаточно места.