Какой план действий при поиске причины ошибки 500 от микросервиса?

План диагностики ошибки 500 в микросервисе на Go

Ошибка 500 (Internal Server Error) в микросервисной архитектуре — критическая ситуация, требующая системного подхода. Вот пошаговый план действий, который я применяю в работе с Go-микросервисами.

1. Немедленные действия: изоляция и мониторинг

// Пример кода для быстрой проверки состояния сервиса
func healthCheckHandler(w http.ResponseWriter, r *http.Request) {
    // Проверка зависимостей
    if !checkDatabase() || !checkCache() || !checkExternalAPI() {
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
}

• Активирую Circuit Breaker для изоляции проблемного сервиса
• Проверяю метрики в реальном времени: CPU, память, количество ошибок
• Временное увеличение лимитов rate limiting для предотвращения каскадных отказов
• Уведомляю команду через систему мониторинга (Prometheus/Grafana + алерты)

2. Анализ логов структурированного формата

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc-123-def-456",
  "error": "panic: runtime error: invalid memory address",
  "stack_trace": "...",
  "context": {"user_id": 123, "order_id": "ORD-789"}
}

• Использую централизованный сбор логов (ELK, Loki, Graylog)
• Ищу паттерны ошибок: учащение 500-х ошибок в конкретные периоды
• Анализирую распределенные трейсы (Jaeger, Zipkin) для понимания потока запросов
• Проверяю correlation ID для отслеживания цепочки вызовов

3. Диагностика на уровне приложения Go

// Добавляю детализированное логирование для отладки
func processOrder(ctx context.Context, order Order) error {
    logger := log.WithFields(log.Fields{
        "trace_id": ctx.Value("trace_id"),
        "order_id": order.ID,
    })
    
    logger.Info("Начало обработки заказа")
    defer func() {
        if r := recover(); r != nil {
            logger.Errorf("PANIC восстановлен: %v", r)
            // Отправка метрики для алертинга
            metrics.IncPanicCounter("order_processor")
        }
    }()
    
    // Бизнес-логика
    if err := validateOrder(order); err != nil {
        logger.WithError(err).Warn("Ошибка валидации")
        return err
    }
}

• Проверяю panic recovery в горутинах
• Анализирую утечки памяти через pprof:

go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap

• Ищу дедлоки и race conditions:

go test -race ./...
go run -race main.go

4. Проверка зависимостей и конфигурации

# Пример проблемной конфигурации
database:
  max_connections: 100
  connection_timeout: "5s"  # Слишком мало для пиковой нагрузки
  retry_attempts: 3

• Тестирую подключения к базам данных, кешам, очередям
• Проверяю таймауты и retry политики
• Анализирую лимиты ресурсов (коннекты, память, дескрипторы файлов)
• Проверяю актуальность конфигурации после деплоя

5. Воспроизведение и тестирование

// Написание теста для воспроизведения ошибки
func TestOrderProcessingPanic(t *testing.T) {
    // Создание моков зависимостей
    mockDB := new(MockDatabase)
    mockDB.On("SaveOrder").Return(errors.New("connection timeout"))
    
    service := NewOrderService(mockDB)
    
    // Проверка обработки ошибки
    assert.Panics(t, func() {
        service.Process(testOrder)
    })
}

• Создаю минимальный воспроизводимый пример ошибки
• Запускаю интеграционные тесты с изолированными зависимостями
• Использую нагрузочное тестирование для выявления проблем при масштабировании

6. Постоянные улучшения процесса

• Добавляю метрики для ключевых точек отказа:

var errorCounter = prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Name: "service_errors_total",
        Help: "Total number of errors by type",
    },
    []string{"error_type", "endpoint"},
)

• Внедряю chaos engineering для проверки устойчивости
• Обновляю runbooks и документацию по устранению инцидентов
• Провожу post-mortem анализ с выявлением коренных причин

Ключевые инструменты в стеке Go-разработчика:

• Мониторинг: Prometheus, Grafana, Datadog
• Логирование: Zerolog, Logrus с structured logging
• Трассировка: OpenTelemetry, Jaeger
• Профилирование: pprof, trace, go-torch
• Тестирование: testify, gomock, ginkgo

Важнейший принцип: 500-я ошибка — симптом, а не причина. Поиск должен быть направлен на выявление корневой проблемы в коде, конфигурации, инфраструктуре или взаимодействии сервисов. В микросервисной архитектуре особенно критично учитывать распределенный характер ошибок и cascade failures.