Авторы руководства в блоге OpenTelemetry, набора инструментов для сбора телеметрии, рекомендуют отправлять логи, метрики и данные о прохождении запросов прямо в систему наблюдаемости, выбранную пользователем. Для передачи авторы предлагают OTLP, стандартный протокол передачи телеметрии.

Если пользователь запускает продукт у себя, авторы советуют встроить OpenTelemetry в приложение и дать пользователю настроить адрес получателя данных. Для облачной платформы авторы предлагают поручить сбор и пересылку данных из приложений пользователя инфраструктуре самой платформы.

Авторы также советуют дать пользователю выбрать виды телеметрии для отправки, чтобы управлять объёмом данных и расходами.

Проверка утверждений:

  • В блоге OpenTelemetry опубликовано руководство о том, как дать пользователям экспортировать логи, метрики и данные о прохождении запросов в выбранную систему наблюдаемости. (подтверждено самой публикацией: доказательство; «This post outlines how you can design your product so users can export their logs, traces, and metrics to an OTel backend when they want to.»)
  • Авторы рекомендуют отправлять логи, метрики и данные о прохождении запросов прямо на указанный пользователем адрес по протоколу OTLP. (подтверждено самой публикацией: доказательство; «Instead of waiting to be asked, your service (or an OpenTelemetry Collector you run) actively exports logs, traces, and metrics directly to the user’s configured endpoint using OTLP (over HTTP or gRPC).»)
  • Для продукта, который пользователи запускают в своей среде, авторы советуют встроить OpenTelemetry в приложение и дать пользователям настроить адрес получателя телеметрии. (подтверждено самой публикацией: доказательство; «If your users deploy your software into their own environments, the best practice is to ship the application pre-instrumented with OpenTelemetry and expose configuration flags for their OTLP endpoints.»)
  • Для облачной платформы авторы предлагают собирать данные из приложений пользователя и отправлять их силами инфраструктуры платформы. (подтверждено самой публикацией: доказательство; «Here, you add a platform feature, such as “Telemetry Drains” or “Observability Destinations” that lets customers configure where to send telemetry. Your platform collects telemetry from their workload (and from your own services, like routers) and forwards it to the customer’s OTLP endpoint.»)
  • Авторы советуют дать пользователям выбор, какие виды телеметрии отправлять, чтобы управлять объёмом данных и расходами. (подтверждено самой публикацией: доказательство; «To allow users to control export volume, simplify data management, and reduce costs, let users explicitly toggle which signals they want to export — following Heroku’s example.»)

Публикации:

Первоисточники:

оценка 49,7 из 100 · тип: руководство