Vendor-нейтральность, eBPF-инструментирование, Operator и OTel в браузере и serverless

Команда использует Collector от vendor-дистрибутива с проприетарными процессорами. Они считают себя OTel-нейтральными, потому что приложение отправляет OTLP. Через год миграция к новому вендору требует переписать не только конфигурацию Collector, но и логику обработки, существующую только в дистрибутиве старого вендора. Vendor-нейтральность была незаметно разрушена.

Ловушка vendor-нейтральности

Многие вендоры поставляют “OTel-совместимые” Collector-дистрибутивы — Datadog Agent, Splunk OTel Collector, New Relic distro — включающие проприетарные процессоры и экспортёры. Использование одного из них допустимо, но с двумя оговорками, часто создающими незаметный lock-in.

(1) Проприетарные процессоры: если вы полагаетесь на процессор, существующий только в дистрибутиве vendor-X (например, специфичная для вендора маршрутизация по стоимости, RUM-коррелятор вендора), ваш конфиг Collector больше не переносим. Переход к vendor-Y означает переписывание этого процессора — он не существует в upstream.

(2) Edge OTLP: контракт, определяющий vendor-нейтральность — “отправляет ли edge приложения OTLP?” Если код приложения вызывает vendor-SDK напрямую (dd-trace, New Relic agent) и данные в формате вендора на границе приложения, вы не vendor-нейтральны, даже если в середине есть Collector — потому что стоимость миграции живёт в коде приложения, в каждом сервисе.

Позиция Honeycomb: vendor-дистрибутивы допустимы для удобства на уровне сбора, но если инструментирование приложения специфично для вендора, вы столкнётесь со стоимостью миграции инструментирования в следующий раз.

Аудит переносимости: проводить ежеквартально. Grep кода приложения на импорты vendor-SDK. Проверять YAML Collector на имена процессоров, существующих только в дистрибутиве вендора. Проверять соответствие Semantic Conventions по сервисам. Vendor-нейтральность — не бинарное состояние, это позиция, поддерживаемая дисциплиной.

OTel и вопрос wide-events

Стабильная модель данных OTel по-прежнему трёхпилонная — трассировки, метрики, логи как отдельные API и типы OTLP-сообщений. Но индустрия движется к более унифицированной модели. Хранилище wide-events (Honeycomb, ClickHouse) может принимать OTel-логи (с прикреплённым trace context) и обрабатывать их как единый поток. Будущая работа OTel — сигнал Profiles, обсуждения wide-event корреляции в рабочей группе по спецификации — движется к более унифицированной модели данных.

Для senior-команд в 2026 году это означает: принятие OTel сейчас прямо совместимо как с бэкендами 1.0 (разделёнными по пилонам), так и с бэкендами 2.0 (wide-event). Смена бэкенда позже — это изменение конфигурации Collector, а не переписывание инструментирования.

eBPF-авто-инструментирование: путь без кода

Растущий класс OTel-совместимого инструментирования работает в ядре через eBPF — Grafana Beyla, Pixie, Datadog USM. Эти инструменты подключают kernel-пробы, наблюдающие системные вызовы, HTTP-трафик на сокетах и gRPC RPC без изменений кода или библиотек приложения.

Что видит eBPF: HTTP + gRPC + вызовы DB-сокетов, задержку, статус-коды. Идентичность сервиса из cgroup (service.name определяется из имени процесса или метки cgroup). OTel-образные спаны с атрибутами Semantic Conventions.

Что eBPF не может видеть: бизнес-атрибуты — customer.segment, feature_flag, batch_size — потому что они живут внутри приложения, а не в системном вызове. Атрибуция медленных хвостов конкретной логике приложения сложнее.

Паттерн на практике: eBPF для широты (бесплатное покрытие каждого сервиса, включая бинарники вендоров, которые нельзя изменить), SDK-инструментирование для глубины (бизнес-спаны и атрибуты). Оба отправляют OTLP в один Collector, оба используют Semantic Conventions, оба отображаются в тех же дашбордах.

OTel Operator: инструментирование как ответственность платформы

OTel Operator (Kubernetes Operator под зонтом CNCF) управляет развёртыванием Collector декларативно.

CRD OpenTelemetryCollector: определяет спецификации агентского и шлюзового Collector в YAML. Operator создаёт DaemonSet, Deployment и Services из CRD; обновление CRD запускает rolling restart без простоев.

CRD Instrumentation: конфигурирует инъекцию авто-инструментирования через аннотации на podах. Пример:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: my-instrumentation
spec:
  exporter:
    endpoint: http://otel-collector:4317
  propagators: [tracecontext, baggage]
  sampler:
    type: parentbased_traceidratio
    argument: "0.25"
  java:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest
  nodejs:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:latest

Pod с аннотацией instrumentation.opentelemetry.io/inject-java: "true" получает Java Agent, инжектируемый через initContainer при старте — никаких изменений Dockerfile или кода.

Стратегическая ценность: инструментирование становится ответственностью платформенной команды, а не ответственностью на уровне каждого сервиса. Новый сервис с правильной аннотацией получает полное авто-инструментирование без изменений Dockerfile или кода. Зрелые платформы делают это поведением по умолчанию; отказ требует явной аннотации.

Браузер и serverless: OTel/HTTP и ограничения холодного старта

Браузер: OTel JavaScript SDK поддерживает браузерную среду через @opentelemetry/sdk-trace-web — инструментируя fetch, XMLHttpRequest, загрузку документа, взаимодействия пользователя. Браузеры отправляют OTLP/HTTP (не gRPC; gRPC несовместим с браузером) на эндпоинт Collector, настроенный с CORS. Получаемые браузерные спаны присоединяются к серверной трассировке через заголовок W3C traceparent, распространяемый на исходящих запросах — настоящие сквозные трассировки от клика пользователя до запроса в БД.

Lambda: стоимость холодного старта инициализации OTel SDK значительна (50-200 мс для полного Lambda-инструментирования). Стандартный подход использует AWS OTel Lambda Layer — слой инициализирует SDK в runtime extension и амортизирует стоимость старта по вызовам.

Cloudflare Workers / Vercel Edge: поддержка OTel ещё развивается, с ограничениями на распространение async-context в модели V8-изолятов.