OpenTracing
The hyperlink login is visible.
OpenTracing has developed a platform-agnostic and vendor-agnostic Trace protocol, allowing developers to easily add or replace implementations of distributed tracing systems. In November 2016, the CNCF Technical Committee voted to accept OpenTracing as a hosted project, which is the third project of the CNCF, the first is Kubernetes, and the second is Prometheus, which shows that the CNCF attaches great importance to the observability behind OpenTracing. For example, the famous Zipkin and Jaeger both follow the OpenTracing protocol.
OpenCensus
The hyperlink login is visible.
You may be thinking, now that OpenTracing is here, what is OpenCensus going to do with the fun? Sorry, you should know that the initiator of OpenCensus is Google, which is the first company to propose the concept of Tracing, and OpenCensus is the community version of Google Dapper. The biggest difference between OpenCensus and OpenTracing is that in addition to Tracing, it also includes metrics, so that basic metric monitoring can also be done on OpenCensus. Another difference is that OpenCensus is not a simple specification, he also does everything including data collection agents and collectors. OpenCensus also has a large following, and the biggest news recently is that Microsoft has also announced that it has joined, and OpenCensus can be described as a tiger with wings.
What is OpenTelemetry?
The hyperlink login is visible.
OpenTelemetry merges the OpenTracing and OpenCensus projects, providing a set of APIs and libraries to standardize the acquisition and transmission of telemetry data. OpenTelemetry provides a secure, vendor-neutral tool that allows data to be sent to different backends as needed.
The OpenTelemetry project consists of the following components:
- Drive the use of consistent specifications across all projects
- Specification-based, with APIs for interfaces and implementations
- SDKs (implementations of APIs) in different languages, such as Java, Python, Go, Erlang, etc
- Exporters: Data can be sent to a backend of your choice
- Collectors: Vendor-neutral implementation for processing and exporting telemetry data
Opentelemetry terminology:
Traces: Records the request activity through a distributed system, and a trace is a directed acyclic graph of spans
Spans: A trace represents a named, time-based operation. Spans nest to form trace trees. Each trace contains a root span that describes the end-to-end latency, and its suboperations may also have one or more subspans.
Metrics: The raw metric data captured at runtime about the service. metric instruments defined by Opentelemetry. Observer supports data acquisition through asynchronous APIs, with one data at each acquisition interval.
Context: A span contains a span context, which is a globally unique identifier that represents the unique request to which each span belongs, as well as the data required to transfer trace information across service boundaries. OpenTelemetry also supports correlation context, which can contain user-defined attributes. The correlation context is not required, and the component can choose not to carry and store that information.
Context propagation: Indicates the passing of contextual information between different services, usually via HTTP header. Context propagation is one of the key features of the Opentelemetry system. In addition to tracing, there are some interesting uses like, performing A/B testing. OpenTelemetry supports context propagation for multiple protocols to avoid possible problems, but it is important to note that it is best to use a single approach in your own application.
Benefits of OpenTelemetry:
By merging OpenTracing and OpenCensus into one open standard, OpenTelemetry provides the following conveniences:
Easy to choose: Instead of having to choose between the two standards, OpenTelemetry is compatible with both OpenTracing and OpenCensus.
Cross-platform: OpenTelemetry supports various languages and backends. It represents a vendor-neutral way to capture and transmit telemetry data to the backend without changing existing tools.
Simplified observability: As OpenTelemetry puts it, "high-quality telemetry requires high-quality telemetry". I would like to see more vendors switch to OpenTelemetry because it is more convenient and only needs to test a single standard.
|
Posted on 1/19/2021 1:36:29 PM
|
|
|
|
