Пока на этой неделе, когда что-то пошло неправильно на этом блоге свидетельство жило в docker логи на сервере, что означает это эффективно жило нигде. Пользователь мог попасть ошибка, рассказать мне об это, и мой инструмент отладки был прокручивание выход терминала ищущий временную метку что примерно совпадает с их сообщением. Время чтоб это исправить.
Идея простая: каждый раз когда сервис пишет ответ ошибки, оно также пишет строку в таблицу error_log. Путь, статус, код ошибки, сообщение, id запроса, пользователь если был. Панель admin получает вкладку логи что читает из обоих сервисов и объединяет их в один список я могу фильтровать. Пользователь говорит «это сломалось около восьми», я фильтрую в тот период и вижу ровно что их запрос попал.
Первое дизайн решение что вышло неправильно: я только логировал 5xx ошибки, на теории что 4xx означает пользователь сделал что-то неправильное и 5xx означает я сделал. Но 4xx ответы часто сноска. Куча 413s означает кто-то постоянно ударяет потолок загрузки я установил слишком низко. Поток 429s означает либо атаку либо баг разрешений. Так сетка расширилась в 5xx плюс припасённые несколько: 403, 413 и 429. Не каждый 404 от бота сканирующего wordpress.php, это будет просто шум с счётом базы данных.
Тонкий баг в середине этого один был об контексте. Очевидный код пропускает контекст запроса в вставку базы данных. Но к времени ответ ошибки написан, тот запрос в основном закончен, и его контекст может уже быть отменён, что убивает вставку. Строка логи об отказе получается потеряна потому что отказ случился. Исправление это дать вставке это собственный отделённый контекст с коротким временем ожидания:
ctx, cancel := context.WithTimeout(context.Background(), errorLogInsertTimeout)
defer cancel()
if err := q.InsertErrorLog(ctx, db.InsertErrorLogParams{ ... }); err != nil {
log.Printf("error_log insert failed: %v", err)
}И заметь что случается когда вставка сама провалится: простая строка логи, ничего больше. Одна вещь регистратор ошибок должен никогда не делать это производить ответ ошибки самого, потому что та ошибка получилась бы логирована, что могла провалиться, что получилась бы логирована. Я читал достаточно постмортемов чтоб быть правильно напуганным того цикла.
Вкладка также получила кнопку удалить за строку и очистить-всё, потому что логи ты не можешь очистить просто становится стеной старого шума ты перестаёшь читать. Строки старше 90 дней подметают себя с событиями аналитики, таже уборщица, таже расписание.
Это двухтабличный лог ошибок с объединением в браузере грандиозная платформа наблюдаемости. Нет. Есть правильный централизованный сервис логирования набросанный за v2, с партионированием и повторная попытка когда сеть падает. Но это дизайн за позже. То что я нуждался в этой неделе это остановить отладку через docker логи, и та проблема сейчас решена с двумя таблицами и одной вкладкой admin.