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

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

05.09.2024

Sentry та обмеження обсягу

Почалося все просто з того, що я перевіряв, як працює інтеграція slog з Sentry з вчора. Нічого тут складного немає. Береш ключ з проєкту. Запускаєш з ним локальний скрипт. Скрипт надсилає помилку в Sentry. От тільки… ні. Чомусь не надсилає.

Звісно, спочатку намагався знайти, що роблю не так. Фільтри, налаштування… Ніби все працює. Навіть sentry.CaptureMessage повертає якийсь ідентифікатор. Але на сайті порожньо.

Точніше ні. На сайті були свіжі випадки якоїсь іншої помилки. Тож Sentry живий. Такого я раніше не бачив. Від розпачу вирішив виправити ту іншу помилку, бо обсяг був немаленький.

Поки шукав, звідки вона взялася (а справа була на стейджингу), помітив, що помилка належить до релізу за травень. Такого старого коду просто не могло бути — але десь він був запущений. Та сипав помилками.

Урок: додавайте до помилок достатньо метаданих, щоб відстежити її до сервісу. Мені довелося шукати в декількох кластерах ECS, бо відома був тільки IP адреса зі спільної для них мережі. Така задача простіше з AWS CLI та jq.

Все одно не відразу знайшов, бо та IP адреса належала вже зупиненій задачі. Яка з травня висіла в очікування зупинки. Поки не знаю, чому, але моя ставка на багах ECS. Задачу вдалося зупинити через примусову зупинку машини EC2. Взагалі я трохи в шоку, бо в теорії така “зомбі” могла б накоїти гірших наслідків. Доведеться придумати, як за цим спостерігати.

Помилка зникла. Можна було повернутись до перевірки інтеграції та… о диво, вона запрацювала! Виявилось, що стара помилка вичерпувала rate limit проєкту, тому нова й не могла проскочити. Урок 2: треба дуже уважно ставитись до обмежень обсягу в Sentry, бо якщо вони вичерпуються постійно — навіть чимсь неважливим — то є реальний шанс не побачити нову помилку, навіть критичну. Плюс один показник, за яким потрібно стежити.