Click on theClick to subscribe to the column of Cloud Recommendation Guru, get the official recommended boutique content, learn technology not lost!

As distributed applications become more and more common, they need to rely on strong observability facilities to provide monitoring assurance, and strong observability facilities need to rely on high-quality telemetry data. Many open source or commercial vendors offer telemetry data monitoring and acquisition solutions. However, in the absence of a unified standard, the telemetry data collected is not compatible, and the maintenance of monitoring clients also brings heavy burden to users.

Opentelemetry solves all of these problems by providing developers with a unified, third-party telemetry data acquisition solution.

origin

Opentelemetry comes from the merger of Two open source communities, OpenTracing and OpenCensus. Initiated by Ben Sigelman in 2016, OpenTracing aims to solve the problems of repeated development monitoring client of open source Tracing, inconsistent data model, and high cost of compatibility of Tracing back end. OpenCensus is an open source monitoring client toolkit combining Tracing and Metrics based on Google’s internal practices.

Since the influence of the two open source communities is not small, the existence of two or more Tracing standards is contrary to the purpose of community establishment. The two open source communities clicked and formed OpenTelemetry.

Why is it needed

From the perspective of users, access to the Tracing monitoring client has certain intrusion to the business code. Once one vendor’s monitoring client is connected, it is difficult to switch to another vendor’s monitoring client. From the perspective of Tracing server suppliers, the server should not only process the data of its own Tracing client, but also be compatible with the data generated by other vendors’ Tracing clients, so the maintenance cost is getting higher and higher. Opentelemetry’s value becomes even more obvious as distributed applications become more prevalent, as mentioned at the beginning of this article.

Opentelemetry project composition

Opentelemetry project is divided into four parts

• Cross-language specification specification
• Collector, a tool for collecting, converting, and forwarding telemetry data
• Monitor client API & SDK for each language
• Automatic monitoring client with third-party libraries Instrumentation & Contrib

Cross-language specification specification

The specification covers a wide range of topics. There are specifications for the internal implementation of the telemetry client and protocol specifications for the communication between the telemetry client and the outside world.

Code repository: OpentElemety-Specification

The internal implementation of the telemetry client required specifications, such as basic monitoring client architecture, design principles, telemetry signals (Traces/ Metrics/ Logs) and auxiliary objects (Baggage/ Context/ Propagator) concepts and model definitions, The realization of telemetry client needs to achieve the design of classes and functions. This part of this article is not to do in detail, can be in the specification/overview. The md and the corresponding object folders below datamodel. Md/API. The md/SDK. Md can refer to.

OpenTelemetry Protocol (OTLP) is the Protocol specification for telemetry client and external communication. OTLP is Opentelemetry’s native telemetry signal transmission protocol. Although the components in Opentelemetry’s project support the implementation of Zipkin V2 or Jaeger Thrift protocol formats, they are provided in the form of third-party contribution libraries. Only OTLP is the official native supported format for Opentelemetry.

The OTLP data model definition is based on ProtoBuf. If you want to implement a back-end service that can collect OTLP telemetry data, you need to know about it. For this, you can refer to the code repository:

Code repository: OpentElemety-Proto

Collector, a tool for collecting, converting, and forwarding telemetry data

There is a principle in the Tracing practice that the telemetry data collection process needs to be orthogonal to the business logic processing. This means that the process of telemetry data collection and delivery to the telemetry back-end service does not occupy the channel/thread of the business logic and minimizes the monitoring of the client’s impact on the original business logic. Collector is a product of the practice based on this principle.

Code repository: OpentElemety-collector

At the architectural level, the Collector has two modes. One is to deploy the Collector on the same host as the application (such as K8S ‘DaemonSet) or on the same Pod as the application (such as K8S’ Sidecar). The telemetry data collected by the application is directly transmitted to the Collector over the loopback network. This mode is collectively called Agent mode.

Another pattern is to treat the Collector as a standalone middleware to which the application passes telemetry data collected. This pattern is called the Gateway pattern.

The two modes can be used independently or in combination, as long as the data protocol format of the data egress is consistent with that of the data entrance.

Opentelemetry Architecture

In the Collector internal design, a set of data inflow, processing, and outflow process is called pipeline. A pipeline consists of three components, which are receiver/ processor/ exporter.

• receiver

  • Responsible for monitoring and receiving telemetry data according to the corresponding protocol format and transferring the data to one or more processors

• processor

  • Responsible for telemetry data processing, such as discarding data, adding information, transferring batch processing, and passing data to the next processor or to one or more exporters

• exporter

  • Responsible for sending data to the next receiver (typically a telemetry back end), MY friend can define a way to fetch telemetry data from multiple processors at the same time

Collector Pipeline

As you can see from the design above, in addition to providing the capability to make telemetry data collection orthogonal to business logic processing, the Collector acts as an adapter for telemetry data to connect to the telemetry back end. The Collector can receive otLP, Zipkin, Jaeger and other data in any format and forward the data in any format. It all depends on whether the formats you need input or output have receiver and EXPORTER implementations. Otlp-related implementations are all in the OpentElemety-Collector repository. For protocol implementations other than OTLP, refer to the code repository below.

Code repository: opentElemetyr-collector-contrib

Monitor client API & SDK for each language

Opentelemetry provides a basic monitoring client API & SDK package for each language. These packages are generally based on the suggestions and definitions in opentElemetry – Specification and the characteristics of the language itself to achieve the basic capability of collecting telemetry data on the client. Such as metadata transfer between services and processes, Trace addition monitoring and data export, creation, use and data export of Metrics indicators, etc. The following is a table of code repositories for each language monitor client API & SDK package.

As planned for the Opentelemetry project, most components will complete Tracing support in the first half of 2021. At the current point in time (December 2021), C++/.NET/Golang/Java/Javascript/Python/Ruby monitoring client support for Tracing has entered a Stable state. Tracing support for the Erlang/Rust/Swift monitoring client is in the Beta phase.

The Opentelemetry project plans to support Mertics later. Expect to have Metrics support in most components by the second half of 2021. As it stands, Metrics support is still in the Alpha phase of the language client packages. Support for Logs is scheduled to begin in 2022.

Instrumentation & Contrib

If you simply use the monitor client API & SDK package, a number of operations will require changes to the application code. For example, adding Tracing monitoring points, recording field information, and boxing and unboxing metadata between processes/services. This approach is code intrusive, not easy to decouple, and the operation cost is high, increasing the user threshold. At this point, you can take advantage of common component design patterns or language features to lower the barriers to use.

Leveraging common component design patterns, such as the Gin component in Golang, implements the Middleware chain of responsibility design pattern. We can quote github.com/gin-gonic/g… Library to create an Otelgin.Middleware and manually add it to the Middleware chain for quick Gin monitoring.

Using language features, such as Java’s ability to use Java Agent and ByteBuddy bytecode weaving technology, find corresponding classes and methods before Java application starts, modify bytecode injection monitoring, and realize automatic monitoring of specified classes.

In theory, fast monitoring relies on the client API & SDK, while automatic monitoring relies on fast monitoring. But the practice did not follow the theory. For example, the Java language uses Java Agent and ByteBuddy technology to implement automatic monitoring of specified open source components, so there is no separate fast monitoring (there is a separate monitoring in OpenTracing).

conclusion

Opentelemetry’s mission is to enable effective observability facilities by collecting high quality, wide range, and portable telemetry data. It does not provide a complete observability solution by itself, but provides a unified telemetry data acquisition solution. If it is necessary to build a complete set of observable facilities, corresponding monitoring backends are also needed for data persistence and data query, such as Tracing back end Zipkin/Jaeger/Tempo /, Metrics back end Prometheus, logs back end Loki, etc.

Excellent articles recommended by Zhou Dongke in the past:Tracing the Past Life of link Tracing

“Cloud recommendation” is Tencent cloud plus community high-quality content column. Yunjianguan specially invites the top performers in the industry, focusing on the landing of cutting-edge technology and theoretical practice, to continue to interpret hot technologies in the cloud era and explore new opportunities for industry development.Click one button to subscribe, we will regularly push high-quality content for you.