Guide to add Resource Attributes
Resource attributes provide contextual information about the source of your logs, such as service name, environment, hostname, and deployment details. These attributes enable better filtering, grouping, and correlation of logs in SigNoz. You can set resource attributes at different levels in your observability stack.
Setting Resource Attributes at the Collector Level
The OpenTelemetry Collector provides several processors to add or modify resource attributes for incoming log data.
Using Resource Processor
The resource processor allows you to add, modify, or delete resource attributes. This configuration adds static resource attributes to all logs processed by the collector:
processors:
resource:
attributes:
- key: service.name
value: "my-log-service"
action: upsert
- key: deployment.environment
value: "production"
action: insert
- key: host.name
from_attribute: "hostname"
action: upsert
service:
pipelines:
logs:
receivers: [otlp]
processors: [resource, batch]
exporters: [otlp]
This configuration adds a service name and environment to all logs, and copies the hostname from an existing attribute. The action
parameter determines how the attribute is handled (insert, update, or upsert).
Using Resource Detection Processor
The resource detection processor automatically detects resource information from the host environment. This processor can detect attributes like hostname, OS information, cloud provider details, and Kubernetes metadata:
processors:
resourcedetection:
detectors: [env, host, system, docker, k8snode]
system:
hostname_sources: ["os"]
timeout: 5s
service:
pipelines:
logs:
receivers: [otlp]
processors: [resourcedetection, batch]
exporters: [otlp]
This processor automatically adds resource attributes by detecting information from the environment, host system, Docker containers, and Kubernetes nodes. The timeout
parameter controls how long the processor waits for detection to complete.
Setting Resource Attributes at the SDK Level
You can configure resource attributes directly in your application code using OpenTelemetry SDKs. This approach gives you fine-grained control over the attributes for each service.
import { Resource } from '@opentelemetry/resources';
import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions';
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPLogExporter } from '@opentelemetry/exporter-logs-otlp-http';
// Create a resource with custom attributes
const resource = new Resource({
[SemanticResourceAttributes.SERVICE_NAME]: 'my-log-service',
[SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
[SemanticResourceAttributes.DEPLOYMENT_ENVIRONMENT]: 'production',
'custom.team': 'backend-team',
'custom.region': 'us-west-2'
});
// Initialize the SDK with the resource
const sdk = new NodeSDK({
resource: resource,
logRecordProcessor: new BatchLogRecordProcessor(
new OTLPLogExporter({
url: 'http://localhost:4318/v1/logs',
})
),
});
sdk.start();
This configuration creates a resource with both standard semantic conventions (service name, version, environment) and custom attributes (team, region). These attributes will be attached to all logs generated by this service.
Using Environment Variables
You can set resource attributes using environment variables, which is particularly useful for containerized deployments and CI/CD pipelines:
Multiple attributes in single line
# Set multiple resource attributes in a single environment variable
export OTEL_RESOURCE_ATTRIBUTES="service.name=my-log-service,service.version=1.0.0,deployment.environment=production,custom.team=backend"
Single attribute
# Set service name separately
export OTEL_SERVICE_NAME="my-log-service"
These environment variables are automatically picked up by OpenTelemetry SDKs and applied to all telemetry data, including logs. This approach is ideal for deployment scenarios where you want to configure resource attributes without modifying code.
Using Kubernetes
The K8s infra chart enables a lot of these resource attributes by default. You can find the complete list of attributes here.
Last updated: July 18, 2025
Edit on GitHub