Home  >  Article  >  Web Front-end  >  Basic concepts of Opentelemetry

Basic concepts of Opentelemetry

WBOY
WBOYOriginal
2024-08-19 17:14:33726browse

Opentelemetry

In a world where Distributed Systems and Micro Services are rampant, it has become very difficult to check system operation or track errors. In this environment, many services have to send data in a common format and connect it to analyze the system.

Opentelemetry (hereinafter otel) is a framework created to increase observability in the latest software trends. We provide API, conventions, toolkits, etc.

But even if it is just a single service, it seems to be easier to view logs, and setting it up is not that difficult (as long as you don't do anything strange...), so it's not a bad idea to try it out.

Observability

To understand otel, you need to know Observability.
Although it is difficult to define clearly, I think it can be defined as the ability to answer the question ‘Why did this happen?’

In order to do so, the program must be ‘well instrumented’.

Instrumentation

This is an expression you will encounter a lot when implementing Opentelementry. In Korean, it means 'measurement', but you can think of it as measuring things well and recording them.

For example, there are several signals (also called telemetry data) that are measured, and logs, traces, and metrics belong to these signals. (These signals will appear again later)

Opentelemetry (continued)

Otel is vendor- and tool-agnostic, so it can be used widely. There is no obligation to use observability backends. You can use open sources that meet Otel standards.

To use Otel, you just need to learn a little(?) concepts and API.

Some concepts you need to know about Opentelemetry

You need to learn the elements that make up Otel.

  • Distributed tracing

  • Log, Span, Trace

  • Context propagation

  • Signals

  • Collector

Distributed Tracing

This is to track what happens when a request is made in a distributed system. This is something that Otel takes seriously. Distributed System refers to a system in which one request is completed through A service, B service, and C service.

Log, Span, Trace

Log

Log is the same log that we always take while coding. There is a timestamp so it is written at that time. It helps a lot in interpreting system behavior.

However, it is difficult to understand the code from the log itself. More contextual information needs to be included. Log is more useful when it is related to Span or Trace.

Span

Span is a unit of action. The name of a specific operation, time-related data, and logs included in the span have characteristics called span attributes.

For example, it has properties such as http.request.method and url.path.

Trace

The process from the beginning to completion of a request is called a trace. This Trace may include spans from multiple systems, not just one system.

The very first span is called Root Span.

Usually depicted as a waterfall diagram.

Opentelemetry의 기본 개념

Context propagation

Continues to propagate context information so that related Signals and Traces can be connected.

Propagation serializes and deserializes this context information object, allowing it to move between services and processes. In normal cases, the W3C TraceContext Propagator is used.

Signals

Signal is a collection element of Otel. There are a total of 4: Log, Metric, Trace, and Baggage.

Log

This is the log mentioned above. It contains a message taken at a specific time.

Metric

This is data to measure the numbers that need to be measured in the service. For example, these are things that need to be recorded to measure numbers such as how many times something was called and how full the queue was.

Trace

Same as Trace mentioned above.

Baggage

This is information that is propagated like context through a key value store. It mainly stores additional information such as User ID.

Collector

Opentelemetry의 기본 개념

It is called Opentelemetry Collector. Collector is responsible for receiving telemetry data from the application, processing it, and exporting it to the telemetry storage.

It is okay to send telemetry data directly from the application to the storage without a collector, but it is better to run a collector and leave the processing of the telemetry data to the collector, and the application does its own thing.

There are many advantages to using a collector, such as the ability to vary configurations and span tail filtering in the collector.

The above is the detailed content of Basic concepts of Opentelemetry. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn