Перейти на PRO

Ваш сервис отдает ошибку 500. Опишите по шагам, как вы будете искать причину проблемы.

Тип вопроса: Общие Backend Вероятность: 23% Категория: Golang Разработчик

Ответ

Мой план действий будет выглядеть следующим образом, двигаясь от общего к частному:

  1. Анализ системы мониторинга и алертов (первые 30 секунд):

    • Проверяю дашборды в Grafana/Prometheus. Ищу аномалии: всплеск CPU/Memory, количество ошибок (error rate), задержки (latency).
    • Смотрю, не сработали ли алерты в Alertmanager или PagerDuty. Это поможет понять масштаб проблемы: она затрагивает всех пользователей или это единичный случай.

  2. Распределенная трассировка (Jaeger/Zipkin):

    • Это самый эффективный инструмент в микросервисной архитектуре. Я найду проблемный запрос по trace_id (если он есть) и посмотрю весь его путь по сервисам.
    • Трассировка сразу покажет, какой именно сервис вернул ошибку, сколько времени занял каждый вызов и где произошел сбой (например, долгий ответ от базы данных или ошибка в другом сервисе).

  3. Проверка логов конкретного сервиса:

    • Если трассировка указала на мой сервис, я иду в систему логирования (ELK Stack, Loki, Graylog).
    • Ищу по request_id или trace_id логи, связанные с проблемным запросом. Ищу сообщения об ошибках, паники (panics) и их стектрейсы.

  4. Проверка состояния зависимостей:

    • Если в логах ошибка связана с внешней системой (база данных, кэш, другой API), я проверяю ее состояние: доступность, нагрузку, логи.

  5. Воспроизведение ошибки:

    • Пытаюсь воспроизвести ошибку в тестовом (staging) или локальном окружении, используя те же входные данные и заголовки, что и в проблемном запросе.

  6. Анализ последних изменений:

    • Если причина все еще не ясна, я проверяю последние коммиты и деплои. Возможно, проблема связана с недавними изменениями в коде или конфигурации.

Превентивные меры в коде: Чтобы упростить отладку в будущем, я всегда использую middleware для обработки паник и логирования.

// Middleware для восстановления после паники и логирования
func PanicRecovery(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                // Логируем стектрейс для детального анализа
                log.Printf("PANIC: %vn%s", err, debug.Stack())

                // Не отдаем клиенту детали, чтобы избежать утечки информации
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

Ответ 18+ 🔞

Ага, щас я тебе расскажу, как я обычно разбираюсь, когда всё горит синим пламенем. Сядь, пристегнись, а то сейчас будет резкий старт.

Ну вот, допустим, прилетает алерт — «всё упало, пользователи орут». Первым делом, ёпта, я не бегу в код, как угорелый. Это путь в никуда, чистая трата времени. Вместо этого я делаю вот что.

Первые 30 секунд — оцениваю масштаб пиздеца. Захожу в Grafana, смотрю на графики. CPU зашкаливает? Память упёрлась в потолок? Количество ошибок взлетело до небес? Это даёт понять, локальный это косяк или система уже накрылась медным тазом. Параллельно гляжу в Alertmanager — может, там уже целый хор алертов орет, и мой сервис просто жертва обстоятельств.

Дальше — самое мощное оружие: трассировка. В микросервисах без Jaeger или Zipkin ты просто слепой. Находишь trace_id проблемного запроса (если его нет — это отдельный пиздец, но об этом позже) и смотришь, где он запнулся. Вот тут-то и открывается картина: «Ага, сука, сервис «Платежи» ответил за 10 секунд, а должен за 200 мс!» или «О, бля, вызов к базе данных вообще завис!». Трассировка сразу выводит на главного подозреваемого.

Если виновник — мой сервис, иду в логи. ELK, Loki — неважно. Ищу по тому же trace_id или request_id. Там уже должна быть вся подноготная: стектрейс паники, сообщение об ошибке «connection refused», или, что хуже, нихуя нет — значит, логирование настроено криво, и это уже второй косяк.

Проверяю, не сдохли ли соседи. Часто проблема не в тебе, а в том, кого ты дергаешь. База данных, кэш, внешний API. Глянул на их мониторинг — и всё становится ясно. «А, так Redis кластер в ребуте! Ну тогда понятно, почему всё легло».

Пытаюсь воспроизвести. Беру те же параметры запроса и гоняю его на staging или локально. Если воспроизводится — уже полдела сделано. Можно дебажить.

И, наконец, смотрю, что недавно меняли. Гитхаб, история деплоев. Очень часто оказывается, что «ой, мы два часа назад залили фичу, и она, блядь, при определенных условиях начинает жрать память как не в себя». Совпадение? Не думаю.

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

// Middleware для восстановления после паники и логирования
func PanicRecovery(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                // Логируем стектрейс для детального анализа
                log.Printf("PANIC: %vn%s", err, debug.Stack())

                // Не отдаем клиенту детали, чтобы избежать утечки информации
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

Эта хитрая жопа ловит любой неожиданный пиздец в твоём коде, логирует его со всеми подробностями (стектрейс — наше всё!), а пользователю отдает просто 500-ю ошибку, без внутренностей. И тебя не разбудят из-за какой-нибудь мелочи, которую можно разобрать утром за кофе. Волшебство, ебать!

© ХакСобесов, 2026
support@hacksobesov.com