Anton Sidorov homepage

Bookmark this to keep an eye on my project updates!

Follow me on GitHub

OpenTelemetry (OTel) Protocol (OTLP)

Концепция OpenTelemetry (OTel) объединила OpenTracing + OpenCensus.

Зачем

  • Слабая связность средств инструментирования (логи, метрики, трассировки) и сервера сбора данных Observability
  • Vendor Lock исключить
  • Receivers - Input Data Collector Data Collector
    • Metric
    • Trace
    • OTEL Instrumentation Library, Agent, 2 modes of operation:
      • you can either use the OpenTelemetry API to manually instrument the telemetry collection from your application
      • or you can use automatic instrumentation techniques that have already been implemented for some languages. OTEL Agent
  • Data OTEL Collector
  • Exporters - SDK realize
  • Roadmap Spec
    • Receivers
    • Exporters
    • OTLP
      • Tracing: Stable
      • Metrics: Stable
      • Logs: Stable

Термины

Архитектура

Based on the Specification, the APIs and SDKs are implemented. There’s a noteworthy distinction between the two:

  • APIs consist of all the abstractions used for instrumentation, clearly decoupled from their actual implementations. The APIs do not contain the working functionality (they are only there to define what is going to be collected).
  • An important part of the SDK is the exporters. After collecting the telemetry signals from your application,
    • either directly (using the manual instrumentation approach)
    • or indirectly (using the auto-instrumentation), you have to actually emit them. To do that, you have to use an SDK exporter and configure it to send data to a particular destination.
    • Such a destination can be
      • a telemetry backend of your choice (such as Prometheus, New Relic or Jaeger)
      • or an OpenTelemetry collector.
    • SDKs consist of all the parts that actually implement the APIs and provide the working functionality for collecting and exporting all the signal data.

scheme

Reference

OTEL Collector

  • You can export the signals
    • directly to the backend
    • of your choice directly from the OpenTelemetry exporter in your application.
  • The goal here is to unify the process of telemetry data processing so that you don’t have to set up communication with multiple telemetry tools separately. You just configure one collector that is able to communicate with all the tools, and run it alongside your application (eg. in a docker container).
  • provides you with some extra functionality you normally might not have, such as retrying, batching or encryption.

Logs

Receive from:

  • stduot, file logs schema
  • FluentBit schema
  • Direct schema
  • New First-Party Application Logs schema

OTLP - OpenTelemetry (OTel) Protocol

  • OTLP defines the encoding of telemetry data and the protocol used to exchange data between the client and the server.
  • This specification defines how OTLP is implemented over gRPC and HTTP 1.1 transports and specifies Protocol Buffers schema that is used for the payloads.
  • OTLP is a request/response style protocols: the clients send requests, the server replies with corresponding responses. This document defines one requests and response type: Export.
  • All server components MUST support the following transport compression options:
    • No compression, denotated by none.
    • Gzip compression, denoted by gzip.

Технологии