Application Observability required metrics and labels
Application Observability uses metrics and labels to present data. This guide provides an overview of how Application Observability functions.
Metric names can differ depending on whether span/service metrics are generated using OTEL connectors on the Alloy/OTEL collector or if these metrics are generated using Tempo. Label names are consistent between the two options.
Application Observability uses the following common labels:
job
: This label identifies services.job
is the concatenation of$service.namespace/$service.name
or just equal toservice.name
when theservice.namespace
attribute is not present.deployment_environment
: This label allows you to filter by environment, for example: “prod”, “dev”, and “ops." You can change the exact name of this label via configuration. We strongly recommend that you use this label on all metrics. It is required for the baselines feature to work.
Span metrics and service graph metrics
Application Observability generates metrics from traces or through Beyla. Regardless of origin, these metrics drive all of the main views in the user interface.
Note
You can use any additional labels not mentioned here for filtering or grouping metrics in the user interface.
Metric name | Mandatory | Description | Mandatory labels | Recommended labels |
---|---|---|---|---|
| yes | This metric stores resource attributes. Service inventory and service metadata are derived from it. | job |
|
OR
OR
OR
OR
OR
| yes | These metrics power RED metric panels and baselines. They are necessary for Application Observability. |
| deployment_environment : Allows filter by environment
|
| no | These metrics indicate service graph request totals. Service maps and inbound/outbound panels won’t work without them. Application Observability also uses them to derive uninstrumented services. You can disable service graph generation to reduce the number of metric series. |
Service graph metrics don’t have |
|
OR
| no | These metrics determine service graph request latency histograms. Service maps and inbound/outbound panels won’t work without them. Application Observability also uses them to derive uninstrumented services. You can disable service graph generation to reduce the number of metric series. |
Service graph metrics don’t have |
|
Host info metrics
Application Observability requires the host info metric to calculate the number of host hours for billing. It should produce a series per host that is sending Application Observability telemetry. You will lose access to Application Observability if no host info metric series are present for the last 30 days.
Metric name | Mandatory | Required labels |
---|---|---|
traces_host_info | yes | grafana_host_id : unique identifier of a host, for example, a k8s node |
Runtime metrics
Application Observability uses runtime metrics to drive runtime dashboards for JVM, .NET, and Golang.
Note
You can use any additional labels not mentioned here for filtering metrics in the user interface.
Metric name | Runtime | Required labels | Recommended labels |
---|---|---|---|
| JVM | job | instance : Correlates CPU/memory usage to a particular instance |
| Golang | job | instance : Correlates CPU/memory usage to a particular instance |
| .NET | job | instance : Correlates CPU/memory usage to a particular instance |