Все мы читали хайповые статьи про OpenTelemetry как серебряную пулю для трейсинга в распределённых системах. Но давайте честно — после третьего прод-инцидента, когда SPAN_ID тупо не сходится между сервисами из-за кривого propagation context, я начинаю думать, что мы сами себе создаём проблемы.
Первая боль — это стандартизация семантики. OpenTelemetry даёт гибкость, но на практике каждый второй разработчик пишет кастомные атрибуты, которые потом не агрегируются в единую картину. У нас в проде было 5 разных имен для HTTP-метода: 'http.method', 'method', 'http_method', 'request_method' и 'verb'. И это не шутка — пришлось писать костыльный адаптер для Jaeger.
Вторая грабля — производительность. Когда ты вставляешь OpenTelemetry SDK в каждый микросервис на Go, не забывай про CPU overhead. Особенно если у тебя high-throughput система на Kafka с миллионами сообщений в минуту. Я лично видел, как span экспортёр съедал 15% CPU на поде просто из-за того, что default exporter работал в синхронном режиме.
Третье — это ротация и retention. Все хотят трейсинг 'на годы вперёд', но никто не хочет платить за S3 или ClickHouse. В итоге получаем лимит в 7 дней, а когда прилетает инцидент — трейсы уже протухли. Или хуже — пишем в локальный файл и теряем при рестарте пода.
Лично я пришёл к выводу: OpenTelemetry — это отличный инструмент для стандартизации сбора, но не для хранения и анализа. Лучше собрать метрики через Prometheus + VictoriaMetrics, а трейсы хранить только для критических эндпоинтов с sampling rate 1-5%. Всё остальное — только логи с structured logging и корреляцией через correlation ID.
Что вы думаете? У кого-то был успешный опыт с full OpenTelemetry на production с retention >30 дней? Или все тоже в итоге скатились к гибридному подходу, как я?
👍 1💡 1
Ох, милок, ну ты прямо в самое яблочко попал... А вот в моё время мы вообще никаких трейсингов не знали — написал на ассемблере пару INT 3, и вся отладка готова, никаких тебе CPU overhead'ов 🤭. Но если серьёзно, то про гибридный подход ты верно подметил. У нас тоже была эпопея с OpenTelemetry: натянули на всё, что шевелится, а потом полгода чинили propagation контекста через AMQP — в RabbitMQ этот ваш traceparent в заголовках терялся, как ключи от квартиры у пенсионера.
А по поводу retention — я вообще предлагаю старый добрый файл на диске с ротацией через logrotate, как в ламповые времена. Но тут молодёжь не понимает романтики: «нам же нужен дашборд в Grafana!». Если уж совсем по-человечески, то мы остановились на схеме: Prometheus для метрик (ибо он хотя бы не жрёт процессор на пустом месте), а трейсы — только для error-сценариев с динамическим семплингом. И да, correlation ID в каждом логе — это база, без неё ты как в тёмном лесу с фонариком без батареек.
👍 1
Ну давай разберем твой «ламповый» подход с logrotate для трейсинга. Ты предлагаешь вернуться к файлам на диске — это ровно та же грабля, только в профиль. Когда у тебя 500 подов в Kubernetes, эти файлы ты будешь собирать по одному с каждого пода, как грибы после дождя, а correlation ID в логах работать не будет, если у тебя между сервисами не настроен сквозной propagation, который ты же сам и критикуешь. Да, OpenTelemetry жрет CPU, но alternative — это ручное прописывание correlation ID в каждом хендлере, где разработчики забудут его проставить в 30% случаев. В итоге получаем не 15% CPU, а 2 дня дебага инцидента, потому что лог из сервиса A не стыкуется с логом из сервиса B по таймстемпу.
По существу про retention: твой гибридный подход с Prometheus для метрик — это стандарт, тут без вариантов. Но отказываться от хранения трейсов полностью — значит потерять возможность анализировать редкие баги, которые проявляются раз в месяц. Я бы предложил не «семплинг только ошибок», а динамический семплинг с head-based на уровне 5% для всех запросов плюс tail-based для error-сценариев. Да, это сложнее в настройке, но это единственный способ получить и производительность, и retention >30 дней без переплаты за S3. Мы так сделали на проекте с 200 микросервисами — CPU overhead упал до 3%, а трейсы храним в ClickHouse за копейки. Так что OpenTelemetry не панацея, но и «ламповый файл» — это шаг назад, а не решение.
👍 1
