PrepBro
← Назад к вопросам

Куда смотреть, чтобы определить причину падения микросервиса?

2.8 Senior🔥 191 комментариев
#DevOps и инфраструктура#Архитектура и паттерны

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI22 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Системный подход к диагностике падения микросервиса

Когда микросервис падает, нужна методичная диагностика. За 10+ лет я выработал проверенный checklist, начиная с фундамента.

1. Логи приложения — первое место

Это источник истины. Смотрим:

# Типичные признаки в логах
DEBUG, INFO, WARNING, ERROR, CRITICAL

# Последний ERROR или CRITICAL перед падением
# Traceback с точной строкой кода
# Время возникновения (с миллисекундами)

Используй:

  • ELK stack (Elasticsearch + Logstash + Kibana) — центральное хранилище логов
  • Datadog, New Relic — готовые решения с фильтрацией и поиском
  • tail -f локально для быстрой проверки: tail -f /var/log/app.log
# Команда для поиска ошибок
grep "ERROR\|CRITICAL" /var/log/app.log | tail -100

2. Системные ресурсы

Много падений — от нехватки памяти, CPU или дискового пространства:

# Проверяем память
free -h
top -b -n 1 | head -20

# Проверяем CPU
mpstat -P ALL 1

# Проверяем диск
df -h
du -sh /*

OOM killer в Linux — убивает процессы при нехватке памяти. Признаки в логах:

killed (oom-kill)
Out of memory

3. Зависимости и внешние сервисы

Микросервис зависит от других сервисов:

# Проверяем доступность зависимостей
import requests

try:
    response = requests.get('http://dependency-service:8000/health', timeout=5)
    print(f"Status: {response.status_code}")
except requests.ConnectionError:
    print("Сервис недоступен")
except requests.Timeout:
    print("Timeout при подключении")

Что проверить:

  • База данных (PostgreSQL, MySQL) — доступность и производительность
  • Redis/Memcached — fallen cache
  • Message queues (RabbitMQ, Kafka) — заполнение очередей
  • HTTP зависимости — network timeouts, 5xx ошибки

4. Мониторинг и метрики

Prometheus + Grafana показывают историю:

# Пример инструментации
from prometheus_client import Counter, Histogram

request_count = Counter('requests_total', 'Total requests')
request_duration = Histogram('request_duration_seconds', 'Request latency')

@app.get("/api/users")
def get_users():
    request_count.inc()
    with request_duration.time():
        # бизнес логика
        pass

На что смотреть:

  • Spike в error rate
  • Spike в latency
  • Memory leak — рост памяти без снижения
  • Request queue depth

5. Сетевые проблемы

# Проверяем сетевые соединения
ss -tuln
netstat -an | grep ESTABLISHED | wc -l

# Проверяем DNS
dig service-name
nslookup service-name

# Проверяем маршруты
route -n
traceroute remote-service

Частые проблемы:

  • DNS resolution timeout
  • Connection refused (сервис не слушает порт)
  • Too many open files (file descriptor limit)

6. Docker/Kubernetes вопросы

# Если в Docker
docker logs container-id
docker stats container-id

# Если в Kubernetes
kubectl logs pod-name -n namespace
kubectl describe pod pod-name
kubectl top nodes
kubectl top pods

Health checks:

  • Liveness probe — падает, если сервис зависает
  • Readiness probe — исключает из балансировщика при проблемах

7. Код и конфигурация

# Проверяем последний деплой
# git log --oneline -10
# Что изменилось в последних коммитах?

# Проверяем конфигурацию
# Environment variables корректны?
# API keys активны?
# Database connection string правильный?

8. Слои диагностики (порядок важен)

  1. Приложение — логи, исключения, трейсы
  2. ОС — память, CPU, процессы
  3. Сетевой слой — соединения, DNS, маршруты
  4. Зависимости — БД, кеш, очереди
  5. Контейнеризация — Docker/K8s логи и метрики
  6. Инфраструктура — load balancer логи, firewall rules

Практический пример

# Скрипт для быстрой диагностики
import subprocess
import psutil

print("=== ДИАГНОСТИКА МИКРОСЕРВИСА ===")

# Память
mem = psutil.virtual_memory()
print(f"Память: {mem.percent}% ({mem.available / (1024**3):.1f}GB свободно)")

# Процессы Python
for proc in psutil.process_iter(['pid', 'name', 'memory_percent', 'cpu_percent']):
    if 'python' in proc.name():
        print(f"Python процесс {proc.pid}: {proc.memory_percent():.1f}% RAM")

# Последние логи
subprocess.run(['tail', '-20', '/var/log/app.log'])

Итог

Диагностика микросервиса — это не случайное гадание. Это систематический процесс: логи → ресурсы → зависимости → метрики → инфраструктура. Начни с логов и работай вниз по списку, пока не найдёшь корень проблемы. В 90% случаев ответ в логах или ресурсах.

Куда смотреть, чтобы определить причину падения микросервиса? | PrepBro