#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"
если на вашем локальном диске достаточно места.