Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

14.10.2024

gin / slog / sentry

Промучився з нібито простою задачею про моніторинг gin - вебсервера на Go.

Для журналювання в slog є slog-gin. Для збору помилок - sentry-go/gin. Для перекидання помилок з журналу в Sentry - slog-sentry - нещодавно вже про це писав. Ніби всі потреби покриті.

Тепер. Помилок є два різновиди: окрім непередбачених панік в Gin можна завжди ввічливо зареєструвати помилку через виклик ctx.Error(). Тут починається… slog-sentry збирає тільки паніки. А slog-gin - тільки “ввічливі” помилки. Ба більше, помилок за один запит може бути декілька, тому slog-gin показує “агреговану” помилку, яка навіть з однією виглядатиме як Error #1: some error, що мене бісить. Також він чомусь не проставляє в журнал атрибут err, а тільки показує помилку як текст.

Виходить, slog-sentry з slog-gin не дружить (хоч і написаний одним автором!) Бо в Sentry потрапить ото агреговане повідомлення про помилки, а сама помилка (чи помилки) - ні — бо вони беруться з err. Якщо додати обидві інтеграції - slog-gin та sentry-gin - то буде не так, як в коді, що не стосується Gin. А окрім того, жодна ще не дивиться на обидві категорії помилок, тож доведеться розвʼязати це два рази окремо.

Можна не інтегруватися з Gin, а надсилати помилки напряму. Тоді все добре (бо вже налаштовано для решти проєкту.) Але ж так ми не отримаємо контексту вебзапиту - IP, URL, та все інше.

Скоріше за все, адаптую інтеграцію slog-gin, щоб вона генерувала структури, потрібні slog-sentry. Та додам обробник, щоб паніки перетворювались в “ввічливі” помилки. Чому все повинно бути так складно?