Побудувала власні моніторинг помилок і трасування

Ситуація. Платформа, яка просто доступна, відрізняється від платформи, яка справді працює, тим, чи дізнається хтось про збій. Помилка, на яку користувач наштовхнувся об одинадцятій вечора на сторінці, яку ніхто не тестує, лишається невидимою, якщо ніщо цілеспрямовано її не збирає. Звичне рішення — купити хмарний трекер помилок, і рішення це добре, — але тоді власні помилки платформи, стектрейси й контекст користувачів ідуть до третьої сторони.

Завдання. Помилки й трейси треба було збирати, групувати й перетворювати на те, з чим можна працювати, — і так, щоб нутрощі платформи не виходили за її межі.

Дія. Побудовано дві частини. OpenTelemetry відповідає за трасування через OTLP, тож повільний запит можна простежити через фронтенд, API та базу даних, а не вгадувати, де він гальмує. Поруч працює власний пайплайн помилок — сервіс errmon і сервіс ingest, — який очищує вміст повідомлень перед збереженням, групує помилки в повторювані проблеми замість плаского списку, виявляє сплески й регресії з паузою між сповіщеннями, щоб через одне невдале розгортання чергового не піднімали сорок разів, відновлює з мінімізованих стектрейсів фронтенду читабельний код і надсилає синтетичний heartbeat, який доводить, що сам пайплайн живий. Усе це осідає в базі даних як події помилок, групи помилок, скринька вхідних, затримки API та зразки стеків, а показується в 11 операторських поданнях, зокрема в одному для цілей рівня обслуговування.

Результат. Помилки складаються в чергу, яку можна послідовно розібрати, а регресія сама дає про себе знати, а не чекає, поки на неї наткнеться користувач. Будувати, а не купувати, коштувало чималого часу, і тепер це ще одна річ, яку треба підтримувати, — куплений трекер запрацював би того ж дня. Натомість нічого чутливого не виходить назовні, а правила сповіщень підігнано під цю платформу, а не під якусь абстрактну.