# Побудувала власний моніторинг помилок та трасування OpenTelemetry замість покупних — очищення payload, виявлення сплесків і регресій, символікацію та синтетичний heartbeat — за 11 операторськими поданнями. 2025 **Ситуація.** Різниця між платформою, яка піднята, і платформою, яка працює, полягає в тому, чи хтось про це дізнається. Помилка, на яку користувач наштовхнувся об одинадцятій вечора, на сторінці, яку ніхто не тестує, лишається невидимою, доки щось не піде й не збере її. Звична відповідь — купити хостований трекер помилок, і це хороша відповідь, — а ще вона означає, що власні помилки платформи, стектрейси й контекст користувача їдуть до третьої сторони. **Завдання.** Помилки й трейси треба було збирати, групувати й робити придатними до дії так, щоб нутрощі платформи не залишали платформу. **Дія.** Побудовано дві частини. OpenTelemetry відповідає за трасування через OTLP, тож повільний запит можна простежити наскрізь через фронтенд, API та базу даних, а не здогадуватися про нього. Поруч стоїть власний пайплайн помилок — сервіс errmon і сервіс ingest, — який санітизує payload перед збереженням, групує помилки у повторювані проблеми замість плаского списку, виявляє сплески й регресії з періодом очікування, щоб один невдалий деплой не смикнув когось сорок разів, перетворює мінімізовані стектрейси фронтенду назад на читабельний код і запускає синтетичний heartbeat, щоб довести, що сам пайплайн живий. Усе це осідає в базі даних як події помилок, групи помилок, inbox, латентність API та семпли стеків, а назовні виходить через 11 операторських подань, зокрема одне для service level objectives. **Результат.** Помилки перетворюються на чергу, яку хтось може розібрати, а регресія оголошує про себе сама, замість того щоб її знайшов користувач. Побудувати замість купити коштувало реального часу й означає, що це ще одна річ на підтримці, — куплений трекер працював би вже того ж дня по обіді. Натомість це дало те, що нічого чутливого не виїжджає назовні, а правила сповіщень підігнані під цю платформу, а не під якусь загальну. --- - Роль: Інженер з надійності (SRE) - Категорії: [Backend‑розробка](https://platform.engineer.company/uk/categories/backend/), [DevOps](https://platform.engineer.company/uk/categories/devops/), [Інфраструктура](https://platform.engineer.company/uk/categories/infrastructure/), [Надійність і резервне копіювання](https://platform.engineer.company/uk/categories/reliability/), [Моніторинг та observability](https://platform.engineer.company/uk/categories/observability/), [Безпека](https://platform.engineer.company/uk/categories/security/) - Послуги: [Backend- та API‑розробка](https://platform.engineer.company/uk/services/backend-development/), [DevOps та автоматизація CI/CD](https://platform.engineer.company/uk/services/devops-cicd/), [Надійність та моніторинг (SRE)](https://platform.engineer.company/uk/services/site-reliability/)