Hello, explorers of the Observability world! Today, we’re going to delve into ‘Resource’, one of OpenTelemetry’s very important fundamental concepts, in an easy and detailed way.
Collecting data is important, but knowing where that data came from is even more crucial. That’s exactly the role ‘Resource’ plays! π
[image 1 β download failed]
π·οΈ What is a Resource?
Simply put, a Resource is a set of attributes that describe the entity producing telemetry data.
Does that sound a bit difficult? Let’s use a simple analogy. It’s like writing the sender’s name, address, and contact information when we send a package. π¦ You need this information to know where the package came from, right?
Similarly, when data like application logs, metrics, and traces are generated, ‘Resource’ is the ‘information tag’ that tells us which service, which environment, and which version created this data.
- Entity producing data: This could be your microservice, a specific server, a container, or an individual process. π’
- Attributes: These are specific pieces of information structured as ‘Key-Value’ pairs. (e.g., service.name = user-api)
π§ What information does a Resource contain?
A Resource can have various attributes that identify the entity. The most common examples include:
- service.name: The logical name of the service (e.g., payment-service, frontend-web)
- service.version: The version of the service (e.g., 1.0.5, v2.1-beta)
- deployment.environment: The deployment environment (e.g., production, staging, development)
- host.name: The name of the host (e.g., server-prod-01)
- cloud.provider: The cloud provider (e.g., aws, gcp, azure)
In addition to these, a wide variety of standard attributes are defined, allowing you to describe your environment in great detail.
β¨ Why is Resource so important?
The most powerful feature of a Resource is that “once defined, it applies commonly to all data generated by that entity”.
(Image: OpenTelemetry Official Documentation)
Let’s assume we’ve set service.name, service.version, and deployment.environment as Resources for a service called ‘user-api’.
- When this service processes an API request, a Span is generated. β‘οΈ These 3 Resource attributes are automatically included in this Span.
- The current memory usage Metric for this service is collected. β‘οΈ These 3 Resource attributes are also automatically included in this Metric.
- An error occurs, and a Log is recorded. β‘οΈ These 3 Resource attributes are also automatically included in this Log.
Because consistent identification information is assigned to all data in this way, we can perform powerful analyses such as: π
- “Filter and view all logs generated in the production environment”
- “Check if the error rate is particularly high only in version v2.1-beta of the payment-service”
- “Analyze the CPU usage and response time of a specific host (server-prod-01) together”
Thus, Resource provides the context that ties disparate data together, playing a crucial role in tracking and understanding problems in complex systems.
Today, we learned about the ‘Resource’ concept in OpenTelemetry. The first step to properly building Observability is clearly knowing where the data you are looking at comes from. When applying OpenTelemetry to your system, don’t forget to configure your Resources! π
Leave a Reply