---
title: "Configure Application Observability metrics | Grafana Cloud documentation"
description: "Learn how to manage Application Observability metrics in the knowledge graph"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Configure Application Observability metrics

You can manage how Application Observability metrics are generated for the knowledge graph.

## Metrics generation

Enable or disable metrics generation for the default provisioned Traces data source for the stack.

## Beyla

Beyla can generate its own span metrics and service graph metrics. When used together with Grafana Cloud metrics generation, this can lead to duplicate series, which can display erroneous data in Application Observability. You can choose one of the following options to set it up properly:

- Grafana Cloud Tempo generates span metrics from all traces, except those containing the following resource attribute. This option excludes traces that have the `span.metrics.skip=true` resource attribute.
- Grafana Cloud Tempo disregards the deduplication resource attribute when generating metrics from spans. Selecting this option can cause duplicate metrics to be generated.

This configuration exists so that you can use Beyla metrics generation simultaneously with Grafana Cloud metrics generation.

## Before you begin

Ensure the following:

- You are familiar with your metrics coming into Grafana Cloud, including the source environment and clusters
- You have Grafana Cloud Admin permissions

### Enable metrics generation

1. Sign into Grafana Cloud and click **Observability > Configuration**.
2. Click **Connect knowledge graph**.
3. Click **Enable metric generation**.
4. Click **Activate**.

### Configure metrics duplication options

1. Sign into Grafana Cloud and click **Observability > Configuration**.
2. Click **Connect knowledge graph**.
3. Click **Duplication Options**.
4. Select how you want the knowledge graph to manage span metrics.
5. Click **OK**.

## Troubleshoot missing or incomplete span and service graph metrics

Span metrics power the Service Overview dashboards, and service graph metrics power the service relationship and dependency maps. The Instrumentation Quality report flags a service when these metrics are missing or incomplete. Use the message shown in the report to identify which case applies:

- **No span or service graph metrics were found.** Metrics generation isn’t producing data for this service. Enable it as described in [Enable metrics generation](#enable-metrics-generation), and confirm the service is sending traces. If you use Beyla, confirm it is configured to generate the metrics.
- **Metrics are present but the environment label is empty.** The metrics exist but the deployment environment isn’t set. The knowledge graph populates environment from the [`deployment.environment.name`](https://opentelemetry.io/docs/specs/semconv/registry/attributes/deployment/#deployment-environment-name) or `deployment.environment` OpenTelemetry resource attribute. Set one of these attributes in your instrumentation. If neither is set, the service appears under environment “unknown”.
- **Metrics are present but the namespace label is empty.** The metrics exist but the service namespace isn’t set. Set the `service.namespace` resource attribute in your instrumentation. For Kubernetes workloads, also set the `k8s.namespace.name` attribute. Refer to [Add missing Kubernetes attributes](/docs/grafana-cloud/knowledge-graph/troubleshoot-infra-apps/explore-entity-catalog/instrumentation-quality/#add-missing-kubernetes-attributes).

## How OpenTelemetry services are scoped

The knowledge graph identifies each OpenTelemetry service by the combination of:

- `deployment.environment.name` (or `deployment.environment`)
- `service.namespace`
- `service.name`

This means a service running across multiple Kubernetes clusters under the same deployment environment appears as a single entity, with metrics aggregated across all clusters. You can filter and drill down by individual cluster using `k8s_cluster_name` as a secondary filter in the Service Overview.

The knowledge graph links OpenTelemetry services to their underlying Kubernetes workloads through a `RUNS_ON` relationship. This connection enables alert propagation from workload-level resource alerts to the application service.