OpenTelemetry без привязки к вендору: как отдавать логи, трейсы и метрики в любой бэкенд
OTel-Native by Design – Building Products That Export to Any Observability Stack
Если вы делаете self-hosted софт или SaaS, рано или поздно пользователи попросят отправлять логи, трейсы и метрики в их собственный observability-стек — ради комплаенса, экономии или централизации. Статья разбирает четыре сигнала OTel и два сценария: когда софт развёрнут у клиента (Kuma, Keycloak) и когда платформа работает на вашей инфраструктуре (Cloudflare, Heroku). Главный выбор — между кастомным polling API и push через OTLP.
Вместо того чтобы ждать запроса, ваш сервис (или запущенный вами OpenTelemetry Collector) активно экспортирует логи, трейсы и метрики прямо на настроенный пользователем endpoint по OTLP (через HTTP или gRPC).
- yearesadpeople
Очень досадно, что эта статья написана LLM. Если прочитать, то и посылка, и вывод — это то, к чему привела бы сессия чата, набитая вызовами RAG и MCP. Разочарован руководством OTel: блог обычно — приятное место, где можно почитать о том, что происходит в сообществе.
- ContinuityLab
OTel-native звучит отлично в теории, но каждый вендор всё равно находит способ затащить тебя в свой проприетарный диалект запросов или обложить налогом на хранение, как только ты выходишь на масштаб в продакшене.
- serkan-ozal
Я работаю в мире observability больше 10 лет, и могу сказать, что OTEL — один из самых больших шагов в этой области, даже несмотря на то, что у разных вендоров есть свои заморочки.