Наблюдаемость больше не является исключительной ответственностью команд надёжности сайтов; от разработчиков всё чаще требуется добавлять traces, logs и metrics в создаваемый ими код, чтобы иметь возможность диагностировать сбои и понимать поведение приложений до и после их выхода в production. В публикации, размещённой в блоге CNCF 25 августа 2026 года, Adriana Villela, руководитель сообщества OpenTelemetry и посол CNCF, и Diana Todea, сертифицированный специалист по документации OpenTelemetry и посол CNCF, предлагают практический путь снижения нагрузки от этой задачи с помощью OpenTelemetry.
Авторы начинают со знакомого разработчикам возражения: добавление Instrumentation означает дополнительный код, который нужно поддерживать, усложнение и вероятность появления ошибок или технического долга. Однако они связывают эти затраты с непосредственными практическими преимуществами, включая сокращение времени исправления ошибок, ускорение завершения и выпуска функций, выявление медленных путей, незаметных повторных попыток и пограничных случаев, а также улучшение понимания распределённых систем. Авторы также считают, что наблюдаемость помогает разбирать приложения, созданные с помощью инструментов искусственного интеллекта, когда их качество неоднородно.
Сначала автоматизация, затем добавление недостающего
Первая рекомендация — использовать Zero-code instrumentation, когда она доступна. Этот механизм добавляет Instrumentation в приложение без изменения исходного кода, перехватывая вызовы распространённых фреймворков и библиотек во время выполнения или компиляции. Согласно материалу, такая поддержка доступна для языков Java, .NET, Python, JavaScript, PHP и Go.
Авторы не считают автоматизацию полноценным решением: она не обязательно знает, что важно в самой логике приложения. Поэтому её следует дополнять Manual instrumentation для добавления traces, metrics, logs, передачи контекста и атрибутов, специфичных для кода. Они также предлагают практиковать Observability-driven development, то есть добавлять наблюдаемость во время написания нового кода, а не возвращаться к этому через несколько дней, когда детали проектирования уже не так хорошо сохраняются в памяти разработчика.
Что стоит измерять?
- Важные рабочие единицы: добавляйте spans для входящих запросов, например HTTP-вызовов, исходящих подключений к базам данных, кэшам, API и очередям, а также для чувствительных к бизнесу операций. Материал предупреждает о создании span для каждого небольшого вызова, поскольку это может породить шум, скрывающий важные сигналы.
- Значимые события: используйте логи, чтобы объяснять, почему произошло определённое событие, уделяя внимание ошибкам, сбоям проверки, путям повторных попыток и альтернативным путям, а также событиям безопасности, таким как сбои аутентификации и отказы в предоставлении прав.
- Время отклика: метрики задержки помогают определить причину, по которой конкретный запрос занимает больше времени, чем обычно, особенно в многоэтапных путях, например при добавлении товара в корзину с последующим оформлением покупки.
- Внутренние фреймворки и библиотеки: Instrumentation фреймворков и библиотек, разработанных самой командой, может обеспечить широкое покрытие, поскольку через них проходят значительные части приложения.
Используйте искусственный интеллект как помощника, а не как замену проверке
Авторы считают, что инструменты программирования с поддержкой искусственного интеллекта могут сократить время изучения интерфейсов различных OpenTelemetry и SDK, а также помочь при работе с устаревшим кодом. Однако для эффективного использования требуется точное руководство. Они предлагают определить роль помощника, цель, расположение кода и используемый язык, требуемые результаты, а также приложить ссылки на документацию или соответствующие примеры кода.
Они также советуют просить агента объяснять свои решения и, по возможности, использовать другого агента в качестве судьи для оспаривания этих решений, а затем повторять попытку и улучшать результаты вместо того, чтобы принимать первое изменение, предложенное инструментом. Эти рекомендации отражают мнение и опыт авторов и не являются гарантией того, что код, созданный искусственным интеллектом, будет правильным или подходящим для приложения.
Локальный путь к пониманию данных измерений
Instrumentation невозможна без средства чтения получаемых данных. В материале объясняется, что OpenTelemetry Collector работает как нейтральный по отношению к поставщикам агент: он принимает traces, logs и metrics из нескольких источников, при необходимости обрабатывает их, а затем отправляет в одно или несколько мест назначения. Он состоит из Receivers для приёма данных, Processors для изменения или скрытия атрибутов либо выборки данных, Exporters для их отправки и Pipelines для определения маршрута каждого типа сигналов, а также Connectors для соединения двух конвейеров.
Для разработки материал предлагает простую конфигурацию, которая принимает данные через OTLP с использованием gRPC или HTTP и экспортирует их в модуль Debug, а также использует SpanMetrics Connector для преобразования длительности span в данные metrics, помогающие отслеживать проблемы с задержкой. Затем рассматриваются три инструмента с открытым исходным кодом, которые можно запускать вместе с Collector и Docker Compose: OTel Desktop Viewer для просмотра traces, otel-tui для просмотра traces, logs и metrics, а также взаимосвязей сервисов через терминальный интерфейс, и OTel Front для отображения тех же трёх типов данных с информационной панелью.
Ограничения, которые необходимо учитывать
Опыт показывает, что эти инструменты не лишены препятствий. Настройка оказалась проще для авторов благодаря их предыдущему опыту работы с OpenTelemetry Collector и Docker, тогда как новички могут столкнуться с большими трудностями. Кроме того, инструменты зависят от сторонних проектов с открытым исходным кодом и не всегда успевают за последними версиями OpenTelemetry API и SDK или обеспечивают полное соответствие функций.
В материале также выделяются более широкие проблемы экосистемы, включая различия в активности рабочих групп для отдельных языков, отсутствие автоматизации для некоторых языков, таких как Rust и Elixir, большое количество вариантов между SDK, eBPF и Instrumentation во время компиляции, а также проблемы стабильности API, обновления зависимостей и высокой Cardinality некоторых атрибутов.
Редакционный комментарий: практическая ценность здесь заключается не в добавлении нового инструмента, а в превращении наблюдаемости из отложенной задачи в часть цикла разработки кода. Руководство определяет точку начала с низкими затратами и одновременно чётко обозначает границы того, чего автоматизация не способна знать. Однако источник не приводит количественного сравнения производительности инструментов и не доказывает, что один путь подходит для всех языков или сред; поэтому к рекомендациям следует относиться как к отправной структуре, проверяя конфигурации и оценивая объём данных, их стоимость и соответствие фактическому приложению.