{"id":60154,"date":"2022-11-24T14:40:40","date_gmt":"2022-11-24T06:40:40","guid":{"rendered":"https:\/\/version-2.com\/?p=60154"},"modified":"2023-02-22T14:31:42","modified_gmt":"2023-02-22T06:31:42","slug":"opentelemetry-a-modern-observability-standard","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2022\/11\/opentelemetry-a-modern-observability-standard\/","title":{"rendered":"OpenTelemetry: A modern observability standard"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
In the first part of our blog series about observability, we covered the basic principles of observability and explained how it differs from the classical monitoring term. In this article, we\u2019ll discuss OpenTelemetry and its instrumentation approaches.\u00a0<\/div><\/div><\/div>
\"\"<\/div>

\"Blog<\/p><\/div><\/div>

OpenTelemetry<\/b><\/h2>

Please check out our first article on observability<\/a> to gain a fuller context for the topic we\u2019re about to discuss. OpenTelemetry is currently the most actively developed standard in the field of observability. It is being adopted as the Cloud Native Computing Foundation incubating project. Born primarily as a merging of former OpenTracing and OpenCensus standards, OpenTelemetry continues to gain popularity, with its supporters including representatives of Google, Microsoft, and Uber.<\/p>

The goal of the OpenTelemetry project is to introduce a standardized open solution for any development team to enable a proper observability layer in its project. OpenTelemetry provides a standard protocol description for metrics, tracing, and logging collection. It also collects APIs under its nest instrumentation for different target languages and data infrastructure components.<\/p>

Below is a visualization of the overall scope of OpenTelemetry (credits to CNCF):<\/p>

The development of specifications and all related implementations is being run in an open way in Github<\/a>, so anyone involved can propose changes.<\/p>

Different instrumentation implementations for different languages are in development. The current state of readiness can always be found on a related page of official documentation (for example, PHP<\/a>).<\/p>

Logs<\/b><\/h2>

<\/p>

Logs are the oldest and best-known type of telemetry signals, and they have a significant legacy. Log collection and storage is a well-understood task, with many solutions being established and widely adopted to carry it out. For example, the infamous ELK<\/a> (or EFK) stack, Splunk, and Grafana Labs recently introduced the Loki<\/a> project, a lighter alternative to ElasticSearch.<\/p>

The main problem is that logs are not integrated with other telemetry signals \u2013 no solutions offer an option to correlate a log record with a relative metric or trace. Having the opportunity to do this can form a very powerful introspection framework.<\/p>

OpenTelemetry specifications try to solve this problem with a logging format standard proposal. It allows correlating logs via execution context metadata, timing, or a log emitter source.<\/p>

However, right now the standard is at an experimental stage and under heavy development, so we won’t focus on it here. The current specifications can be found here<\/a>.<\/p>

Metrics<\/b><\/h2>

As discussed previously, metrics are numeric data aggregates representing the software system’s performance. Through aggregation, we can develop a combination of measurements into exact statistics during a time window.<\/p>

The OpenTelemetry metrics system is flexible. It was designed to be like this to cover the existing metric systems without any loss of functionality. As a result, a move to OpenTelemetry is less painful than other alternatives.<\/p>

The OpenTelemetry standard defines three metrics models:<\/p>