• Perfetto и его функции обсуждаются как мощный инструмент для анализа производительности, включая поддержку SQL-запросов и визуализацию трассировок.
• Участники делятся опытом использования Perfetto для различных задач, включая генерацию трассировок из SQL-запросов и встроенный в другие инструменты.
• Обсуждаются ограничения и проблемы, такие как производительность при работе с большими трассировками, и отсутствие встроенной поддержки для встроенного UI в другие инструменты.
• Участники также обсуждают возможность встроить UI в другие инструменты и обратную связь с командой разработки Perfetto.

OpenTelemetry Collector: что это, когда нужен и когда нет

Практическое руководство по OpenTelemetry Collector: что делает, как работает, архитектурные паттерны и как решить, нужен ли он вам для производительности, контроля, безопасности и экономии.

Нужен ли вам OpenTelemetry Collector? Для небольших проектов — возможно нет. Для production-среды с множеством сервисов, где важны стоимость, производительность и безопасность — почти наверняка да.

Краткое определение

OpenTelemetry Collector — это нейтральный к вендорам, расширяемый конвейер телеметрии, который принимает, обрабатывает и экспортирует данные (трейсы, метрики, логи) из ваших приложений в одно или несколько хранилищ.

Он позволяет:

• Очищать данные (удалять чувствительные поля, добавлять контекст)
• Пакетировать отправки и повторять при сбоях
• Применять умное семплирование (сохранять ошибки и редкие медленные трейсы)
• Сглаживать различия между версиями SDK
• Маршрутизировать данные в разные хранилища
• Служить защитным барьером между приложениями и интернетом
• Снижать затраты, отсеивая малополезную телеметрию

Архитектура

Без Collector (прямой экспорт)

Каждый сервис отправляет телеметрию напрямую в бэкенд:

Плюсы:

• Проще (меньше компонентов)
• Меньше операционных затрат
• Подходит для маленьких приложений / POC

Минусы:

• Каждый сервис сам handles retries, auth, backpressure
• Сложно менять экспортеры
• Нет централизованного семплирования / очистки / маршрутизации
• Риск misconfigurations
• Выше стоимость исходящего трафика при отправке в несколько систем

С центральным Collector

Все приложения отправляют данные в центральный Collector, который затем экспортирует:

Плюсы:

• Централизованная конфигурация: семплирование, очистка, обогащение
• Один канал исходящего трафика с пакетированием и retry
• Развязывает жизненный цикл приложения от изменений вендоров
• Меньше нагрузки на приложения
• Безопасность: приложения не выходят в интернет напрямую

• Рекомендуется использовать коллектор OpenTelemetry для упрощения архитектуры, локальной отладки и управления аутентификацией
• Предлагается декаплеить коллектор от потребителей трассировок через брокеры сообщений (Kafka/NATS) для надежности и масштабируемости
• Коллектор рассматривается как защитный шлюз (read-only) между приложениями и базой данных для безопасности
• Отмечается сложность освоения OpenTelemetry, но подчеркивается его ценность как стандарта для интероперабельности
• Указывается полезность OTEL даже для монолитов благодаря возможностям корреляции и вложенных спэнов
• Обсуждаются альтернативы (Vector vs OTEL) и необходимость улучшения документации и примеров
• Упоминается использование коллектора для валидации и тестирования с помощью AI-агентов