Hello everyone! Today, we’re going to explore the core components of OpenTelemetry, which has become an essential element in cloud-native environments. These concepts are crucial for looking inside complex systems and quickly identifying the root cause of problems, so please pay close attention! ๐
๐ป SDK (Software Development Kit)
The first friend we’ll get to know is the SDK.
You can easily think of an SDK as a library ๐ฆ that you install directly into the application code you’ve developed. The main mission of this library is to generate ๐ various data, known as telemetry data (trace information, metrics, logs), that occurs within the application.
Its biggest characteristic is that it is dependent on the programming language. For example,
- For applications built with Java, use the Java SDK!
- For applications built with Python, use the Python SDK!
- You must use a dedicated SDK appropriate for each language, such as Go, .NET, etc.
It’s like using a translator appropriate for each country’s language, isn’t it? ๐ฃ๏ธ
๐ก Collector
Next up is the versatile worker that collects and processes data, the Collector.
Unlike the SDK, the Collector is an independent program that is not tied to a specific programming language. It plays the role of gathering scattered telemetry data from various places into one location.
Its main functions are as follows:
- Receive: Receives data from various sources (application SDKs, other Collectors, etc.).
- Process: Performs processing tasks such as filtering unnecessary data or enriching data. โ๏ธ
- Export: Safely exports the processed data to its final destination (e.g., Jaeger, Prometheus, Splunk, etc.). ๐ค
Thanks to the Collector, data pipelines can be managed flexibly and scalably.
๐ฎ OTLP (OpenTelemetry Protocol)
The third protagonist is OTLP.
OTLP is a standard communication protocol ๐ค that defines how telemetry data is exchanged. When data generated by an SDK is sent to a Collector, or from a Collector to another system, it follows the common agreement of OTLP.
Because OTLP is not bound by specific languages or platforms, it enables seamless data exchange ๐ even between systems composed of different technology stacks. In other words, it’s like a standardized postal system that helps data not get lost.
๐ท๏ธ Semantic Conventions
Finally, the concept we’ll introduce is Semantic Conventions.
Also known as ‘semantic rules,’ this is a specification (rule) ๐ that standardizes the names of attributes included in telemetry data.
For example, if one system records the URL of an HTTP request as http.url and another system records it as url.path, analyzing the data would be very confusing. ๐คฏ
Semantic Conventions prevent this confusion by providing rules that unify names and formats, such as “Let’s call the URL of an HTTP request http.url!” This ensures data consistency and allows anyone to easily understand and analyze the data. โ
โจ In Summary
We’ve looked at the core components of OpenTelemetry so far.
- SDK: Language-specific library for generating data at the code level
- Collector: Independent agent for collecting, processing, and forwarding data
- OTLP: Standard protocol for data transmission
- Semantic Conventions: Naming rules for data consistency
These elements work organically together to enhance the observability of complex systems. A good understanding of these concepts will greatly help you diagnose system problems more quickly and accurately!
Leave a Reply