Как посмотреть саму ошибку и её контекст

Анализ ошибок в DevOps-практике

Для эффективного анализа ошибок и их контекста в DevOps-среде существует целый арсенал инструментов и методик, которые я применяю в зависимости от ситуации.

Уровни наблюдения и соответствующие инструменты

1. Уровень приложения (логирование)

# Просмотр логов в реальном времени
tail -f /var/log/application.log
tail -f /var/log/nginx/error.log

# Поиск ошибок с контекстом
grep -n -B 5 -A 5 "ERROR\|Exception\|FATAL" /path/to/logfile.log

# Использование journald (systemd)
journalctl -u service-name --since "10 minutes ago" -f
journalctl -u nginx --no-pager -n 50

2. Уровень инфраструктуры и контейнеров

# Docker контейнеры
docker logs --tail 100 --timestamps container_name
docker logs -f container_id

# Kubernetes
kubectl logs deployment/app-name --tail=50 -f
kubectl logs -l app=myapp --all-containers=true --tail=100
kubectl describe pod pod-name  # показывает события и состояние

3. Мониторинг и алертинг

# Проверка метрик в Prometheus
rate(http_requests_total{status=~"5.."}[5m])

# Просмотр алертов
kubectl get events --sort-by='.lastTimestamp'

Ключевые подходы к анализу контекста

Сбор полного контекста ошибки:

• Трассировка стека (stack trace) - самый ценный источник информации
• Идентификаторы корреляции (correlation IDs) для отслеживания запроса через микросервисы
• Метки времени и временные метки для построения временной линии событий
• Параметры окружения (версии ПО, переменные окружения, конфигурация)

Структурированное логирование - обязательная практика:

{
  "timestamp": "2023-12-20T10:30:00Z",
  "level": "ERROR",
  "correlation_id": "abc-123-def",
  "service": "payment-service",
  "error_type": "DatabaseConnectionError",
  "message": "Failed to connect to database",
  "context": {
    "database_host": "db.production.internal",
    "attempt": 3,
    "user_id": "user-456"
  },
  "stack_trace": "..."
}

Практические шаги при инциденте

1. Сбор первичной информации:

   • Время возникновения ошибки
   • Частота и паттерн возникновения
   • Условия воспроизведения

2. Анализ зависимостей:

   # Проверка сетевой связности
   curl -v https://api.service.com/health
   nc -zv database-host 5432
   
   # Проверка ресурсов
   df -h  # дисковое пространство
   free -m  # оперативная память
   top -n 1  # нагрузка CPU
   

3. Использование APM-инструментов:

   • Distributed tracing (Jaeger, Zipkin)
   • Метрики производительности (Prometheus, Grafana)
   • Профилирование (pprof для Go, async-profiler для Java)

Расширенный анализ с примерами

Пример анализа ошибки базы данных:

-- Проверка блокировок в PostgreSQL
SELECT 
  pid, 
  query, 
  age(clock_timestamp(), query_start), 
  wait_event_type,
  wait_event
FROM pg_stat_activity 
WHERE state = 'active';

Анализ сетевых проблем:

# tcpdump для анализа сетевого трафика
tcpdump -i any port 443 -w capture.pcap
tcpdump -nn -v -i eth0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

# Проверка DNS
dig +trace api.service.com
nslookup problematic-host

Рекомендации по настройке наблюдаемости

1. Централизованное логирование: ELK Stack (Elasticsearch, Logstash, Kibana) или Loki
2. Метрики: Prometheus с правильными labels для фильтрации
3. Трассировка: внедрение OpenTelemetry стандарта
4. Dashboard-ы в Grafana с ключевыми метриками ошибок:
   • Error rates по сервисам
   • Latency percentiles (p95, p99)
   • Saturation ресурсов

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