Как узнаёшь, что контейнер упал?

В продакшн-среде я настраиваю многоуровневый мониторинг, чтобы сразу видеть проблемы с контейнерами.

1. Оркестратор (Kubernetes):

• Статус Pod'а: Первичный источник. Постоянно проверяю через kubectl get pods или дашборд (Lens, Octant). Состояния CrashLoopBackOff, Error или Completed (для job'ов) сигнализируют о падении.

  kubectl get pods --field-selector=status.phase!=Running

• События (Events): K8s генерирует события при смене состояния. Смотрю их для понимания причины (OOMKilled, FailedPostStartHook).

  kubectl describe pod <pod-name> | grep -A 10 Events
  kubectl get events --sort-by='.lastTimestamp' --watch

• Liveness-пробы: Настраиваю их для критичных сервисов. Если проба fails, kubelet убивает и перезапускает контейнер. Это видно в событиях и метриках рестартов.

2. Система мониторинга (Prometheus):

• Метрики из kube-state-metrics: Отслеживаю kube_pod_container_status_restarts_total и kube_pod_status_phase. Настраиваю алерты в Alertmanager при резком росте рестартов или переходе Pod'а в нерабочее состояние.
• Метрики приложения: Интегрирую бизнес-метрики (число ошибок, latency). Их обнуление тоже может быть признаком падения.

3. Централизованное логирование (Loki/ELK):

• Настраиваю сбор логов всех контейнеров. Внезапное прекращение потока логов от конкретного сервиса — явный сигнал о его падении. После восстановления смотрю логи предыдущего экземпляра контейнера (kubectl logs --previous).

4. Инфраструктурные алерты:

• Использую Blackbox Exporter для проверки доступности эндпоинта сервиса снаружи (HTTP, TCP пробы).

Таким образом, я не "узнаю" о падении вручную — система алертинга сама присылает уведомление в Slack/Telegram/PagerDuty, когда срабатывает одно из условий выше.