Обновить

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

Не очень в темя я честно говоря но както дико убивать приложение по глухому зависанию или по зависанию ввода/вывода и делать вид что так и надо просто вести статистику делать рестарты и более ничего. Наверное так можно делать по таймаутам клиентской стороны или БД но во втором случае всё равно желательно понять что это за запрос вызвал таймаут. А зависание это инцидент это надо както решать ладно ещё единичные случаи а если массово то это криво написанное приложение то есть там где то явная ошибка и эта кривизна однажды может вылезти таким боком что мало никому не покажется...

Ну так а что делать, пока это решается? В этом и смысл Liveness, чтобы жить хоть как-то, пока инженеры разбираются в проблеме.

А ещё предусмотреть, что на дев-площадке разработчик может дебаггером зайти. Это вообще минут на 5-10 суммарно нужно timeout+threshold настраивать.

Совпадают ли эндпоинты liveness и readiness? Если да — у вас нет ни того, ни другого, у вас одна проба с неопределённой семантикой.

Нужно пояснить, что для большинства сервисов liveness и readiness пробы будут идентичны по смыслу. Возьмите любой stateless http сервис. Так что это скорее исключение, нежели правило.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации