Приходит разработчик и говорит, что приложение недоступно, что будешь смотреть

«Приходит разработчик и говорит, что приложение недоступно, что будешь смотреть» — вопрос из категории Мониторинг и логирование, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Я начну с быстрой проверки по принципу "от внешнего к внутреннему", чтобы локализовать проблему.

  1. Быстрая проверка доступности (L3-L4):

    # Проверяю, отвечает ли хост (ICMP может быть выключен)
    ping <host-ip>
    # Проверяю, открыт ли нужный порт (например, 443 для HTTPS)
    nc -zv <host-ip> 443
  2. Проверка мониторинга (Grafana/Prometheus): Смотрю дашборды:

    • Инфраструктура: Загрузка CPU, память, дисковое I/O и место на диске на нодах, где работает приложение.
    • Сервис: HTTP-коды ответа (5xx ошибки), latency, rate запросов. Резкий рост 5xx или таймаутов — явный индикатор.
    • Оркестратор: Состояние подов в k8s (kubectl get pods -n <namespace>). Ищу пода в статусах CrashLoopBackOff, Pending или Error.
  3. Глубокий анализ проблемного компонента:

    • Если под упал: Смотрю логи пода и события (Events).
      kubectl describe pod <pod-name> -n <namespace> | tail -20
      kubectl logs <pod-name> -n <namespace> --previous # если под перезапускался
    • Если под работает, но отдает ошибки: Смотрю логи самого приложения внутри пода и логи ingress-контроллера (nginx-ingress, traefik), которые часто содержат более точные HTTP-коды и таймауты бэкенда.
      kubectl logs -l app=<app-label> -n <namespace> --tail=50
      kubectl logs -n ingress-nginx deployment/ingress-nginx-controller | grep <app-hostname>
    • Если проблема с сетью или зависимостями: Проверяю доступность внутренних сервисов (БД, кэша, message broker) с помощью утилит внутри пода (kubectl exec).
      kubectl exec -it <pod-name> -n <namespace> -- sh
      # внутри пода
      nc -zv <db-service> 5432
      curl http://internal-api:8080/health
  4. Проверка изменений: Смотрю, не было ли недавних деплоев, изменений в конфигурации (ConfigMap/Secret) или в инфраструктуре (например, обновление нод). История деплоев в ArgoCD или ленты в Kubernetes помогают здесь.

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