Skip to content
Osuite Osuite Docs

Resource attributes reference

A resource attribute describes where a piece of telemetry came from — which service, which environment, which host or pod. OpenTelemetry attaches these attributes to every span, log record, and metric, and Osuite reads them to group signals into entities and to power filtering across the UI. This page lists the attributes Osuite surfaces and how they map to the product.

For the underlying model — how shared resource attributes let Osuite correlate the three signals — see Concepts.

service.name

Section titled “service.name”

service.name is the identity of a service. Osuite uses it to group all telemetry from one service under a single entity in APM, and to link a service’s traces, logs, and metrics together.

Set it with the standard OpenTelemetry variable:

Terminal window
OTEL_SERVICE_NAME="checkout"

Every service should set a stable, unique service.name. Telemetry without one is hard to attribute and will not line up across signals.

service.environment

Section titled “service.environment”

service.environment is the attribute Osuite uses to separate environments such as prod, staging, and dev. Osuite groups and filters all telemetry by its value.

Terminal window
OTEL_RESOURCE_ATTRIBUTES="service.environment=prod"

Two points matter here:

  • It is Osuite-specific. Osuite reads service.environment, not the OpenTelemetry semantic-convention attribute deployment.environment. Use this exact key.
  • It should be set on every service. Telemetry without service.environment is not grouped into an environment.

This attribute is described in more depth, alongside the correlation model, in Concepts.

Setting resource attributes

Section titled “Setting resource attributes”

Any resource attribute can be set through the standard OpenTelemetry environment variables:

  • OTEL_SERVICE_NAME — shorthand for service.name.
  • OTEL_RESOURCE_ATTRIBUTES — a comma-separated list of key=value pairs for any other attribute.
Terminal window
OTEL_SERVICE_NAME="checkout"
OTEL_RESOURCE_ATTRIBUTES="service.environment=prod,service.version=1.4.2"

When the OpenTelemetry Collector or the osuite-k8s Helm chart sits between your workloads and Osuite, it can attach or enrich attributes on the way through — see the Kubernetes attributes below.

Kubernetes attributes

Section titled “Kubernetes attributes”

The osuite-k8s Helm chart attaches infrastructure attributes so telemetry lines up with the cluster it came from.

  • cluster and environment — set from the chart’s cluster and environment values, so you can scope dashboards and queries to a specific cluster. These surface on queries as resource.cluster and resource.environment.
  • k8s.namespace.name, k8s.pod.name, and the owning workload (deployment, statefulset, or daemonset) — added by the chart’s k8sattributes processor. service.name is derived from the owning workload, so container logs and metrics line up with the same service in APM. See Container logs.

How attributes map to the UI

Section titled “How attributes map to the UI”

Resource attributes are how you slice telemetry in Osuite. The same attribute keys appear as filter and group-by dimensions across the product:

  • In APM, services are listed by service.name and can be scoped by service.environment.
  • In Logs and Dashboards → Explore metrics, attributes are available as filters — for example filtering logs by resource.service.name or Kubernetes events by resource.k8s.namespace.name.
  • In the CLI, attributes are referenced with their fully qualified path in filter expressions, such as resource.service.name__is=checkout.