Ответ
В инфраструктуре на основе контейнеров и оркестраторов я настраиваю несколько уровней проверок для обеспечения отказоустойчивости.
В контексте Kubernetes:
- Liveness Probe — проверяет, «живо» ли приложение внутри контейнера. Если проверка падает, kubelet перезапускает контейнер. Я настраиваю её для критичных сервисов, например, проверяя внутренний эндпоинт
/healthz:livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 10 - Readiness Probe — определяет, готов ли контейнер принимать трафик. Провал проверки исключает под из списка целей Service. Это важно для сервисов с долгой инициализацией (например, загрузка кэша):
readinessProbe: tcpSocket: port: 9300 timeoutSeconds: 2 - Startup Probe — используется для «тяжелых» приложений с долгим стартом, чтобы liveness-проверка не убивала их преждевременно.
В мониторинге (Prometheus, Nagios):
- Blackbox probing — внешние проверки доступности сервиса (HTTP, TCP, ICMP) с точки зрения пользователя. Настраивал через Prometheus Blackbox Exporter для проверки SSL-сертификатов и времени ответа сайта.
- Custom script checks — сложные сценарии, например, скрипт на bash или Python, который проверяет не только доступность базы данных, но и наличие свободного места в табличном пространстве или репликационный лаг. Результат таких проверок экспортируется как метрика или алерт.