Usage attribution helps you understand and allocate your Observe usage across teams, environments, and services. With this feature, you can answer questions such as:

• Which teams are responsible for the most log or metric volume?
• How much data does each environment or service contribute?
• Are there spikes in ingest tied to specific workloads?

Before this feature, many customers built custom solutions to achieve charge-back or show-back models internally. These often relied on naming conventions (such as datastream token names) or manually built dashboards. Usage attribution brings this into the product natively, with support for standardized resource attributes like:

• deployment.environment.name
• service.name
• team.name

See Auto-discovered attributes for a full list of auto-discovered attributes.

Limitations

The following limitations are known at this time:

• Anything collected through the Observe Agent running on a host with the following configuration will automatically add the attributes below to its data:
  YAML

  resource_attributes:
    deployment.environment.name: prod
    service.name: recommendation
    team.name: ai

• Data collected by filedrop or poller is not yet covered by usage attribution.

Where can I find usage attribution?

Access the Usage Attribution page using any of the following methods:

• In the left navigation rail, select Data & integrations > Usage attribution.
• In the left navigation rail, hover on your user name, then select Manage account, then click Usage attribution.
• Use to the following URL, replacing ${observe_tenant} with your observe tenant ID:

https://${observe_tenant}.observeinc.com/settings/usage-attribution

Recommended approach

Use the Add Data for Kubernetes and Add Data for Host (Linux, Windows, and macOS) flows with the Observe Agent. These automatically set default annotations and collect them as resource attributes. You can then slice and dice your usage by:

• deployment.environment.name
• service.name
• team.name

This approach is simpler and more reliable than building ad-hoc models based on token names or dashboards.

Add team.name in Kubernetes

You can add a team.name annotation to any Kubernetes workload. For example, if the recommendation Deployment is owned by the ai team:

1. Patch the Deployment’s pod template (so new pods get the annotation):

kubectl -n default patch deployment recommendation \\
--type='merge' \\
-p '{"spec":{"template":{"metadata":{"annotations":{"resource.opentelemetry.io/team.name":"ai"}}}}}'

2. Roll the Deployment so pods pick it up:

kubectl -n default rollout restart deployment recommendation
kubectl -n default rollout status  deployment recommendation

3. Verify the annotation on a new pod:

# List the new pod(s)
kubectl -n default get pods

# Check the annotation
kubectl -n default get pod <pod-name> -o yaml | grep 'resource.opentelemetry.io/team.name'

After applying this change, the attribute will be available in Observe, allowing you to break down usage by team in Usage Attribution.