Set up on Grafana Labs

GET hardware requirements

Thu, 24 Jul 2025 15:08:34 +0000

GET hardware requirements

This page outlines the current hardware requirements for running Grafana Enterprise Traces (GET). Grafana Labs reserves the right to mark a support issue as ‘unresolvable’ if these requirements are not followed. Refer to the Grafana Labs Enterprise Support SLA for more details.

Note
As of February 2025, you must run GET on the managed Kubernetes services offered by AWS (Amazon Elastic Kubernetes Service), GCP (Google Kubernetes Engine), or Azure (Azure Kubernetes Service). Additionally, you must use the managed object storage services offered by AWS (S3), GCP (GCS), or Azure (Blob Storage).

No other deployment modes are supported.

CPU and memory

Deploy on machines with a 1:4 ratio of CPU to memory. For every CPU core, you should have 4GB of memory. Grafana Labs recommends deploying onto machines with at least 16 CPU cores and 64GB of memory. All the nodes in the Kubernetes cluster running GET should be of the same type.

Network

All components require fast network access. Nodes the software runs on should be connected by 10 gigabit/second or faster network connection speed.

Storage

GET requires fast storage to run. Any storage solutions you use have to have adequate performance. Object storage (for example AWS S3 buckets, Google Cloud GCS or Microsoft Azure Storage) buckets or blobs are used to persist trace data for the required retention period. Your object storage should be large enough to contain 30 days worth of data, the default block retention for GET.

However, various components of GET (for example, the ingester) also require fast, persistent block storage to be available to the host machine. For example, in the case of the ingester component, all incoming data is sent to a write-ahead log (WAL) to aggregate trace data into blocks before storing them in object storage, and to help withstand unexpected node termination.

For every deployment, you need both object and block storage. Block storage must be memory-state storage, like SSD or NVMEs. Hard drive (platter-based) disk storage is not supported.

The supported configurations for AWS, GCP, and Azure are in the following sections.

Block storage

Platform	Storage type	Configuration option
Amazon Web Services	Block	`gp3` General Purpose SSD EBS volumes
Google Cloud Platform	Block	`pd-ssd` SSD persistent storage
Microsoft Azure	Block	`Premium SSD` SSD persistent storage

Object storage

GET requires object storage for configuration storage, as well as long-term data storage. Amazon AWS S3, GCP GCS, and Azure Blob storage are the only supported object stores for running GET.

Platform	Storage type	Configuration option	Comments
Amazon Web Services	Object	S3 Standard	S3 object storage service using the Standard storage class.
Google Cloud Platform	Object	STANDARD	GCS object storage service using the STANDARD storage class in both regional and dual regional storage locations.
Microsoft Azure	Object	Standard performance with LRS replication	Blob Storage object storage service with Standard performance and replication type Locally Redundant Storage (LRS)

Deploy GET with Helm

Wed, 10 Jun 2026 16:15:01 +0000

Deploy GET with Helm

The Helm charts for Grafana Enterprise Traces (GET) and Grafana Tempo allow you to configure, install, and upgrade Grafana Tempo or Grafana Enterprise Traces within a Kubernetes cluster.

Warning
Grafana Enterprise Metrics (GEM), Grafana Enterprise Logs (GEL), and Grafana Enterprise Traces (GET) have entered Long-Term Support (LTS):

GEM LTS version is 2.17.

GEL LTS version is 3.6.

GET LTS version is 2.8.

Existing customers will continue to receive support, bug fixes, and security fixes, but no new features, through Feb. 1, 2029, when GEM, GEL, and GET will reach End-of-Life (EOL).

If you have questions, contact your account manager.

The recommended method for installing GET is to use the tempo-distributed Helm chart, which deploys Tempo or GET in microservices mode.

Get started with Grafana Enterprise Traces using the Helm chart

Note
Monitoring with Grafana Cloud is required for all GET installations. Professional services will assist you in configuring monitoring for your GET installation.

The tempo-distributed Helm chart allows you to configure, install, and upgrade Grafana Enterprise Traces (GET) within a Kubernetes cluster. Using this procedure, you need to:

Create a custom namespace within your Kubernetes cluster
Install Helm and the Grafana helm-charts repository
Configure a storage option for traces
Install GET using Helm
Install the GET license
Create an additional storage bucket for the admin resources
Disable the gateway used in open source Tempo
Enable the enterpriseGateway, which is activated when you specify Enterprise

To learn more about Helm, read the Helm documentation.

GET is based on Grafana Tempo 2.8. The Helm chart used in this document is based on the tempo-distributed Helm chart for Tempo 2.8, version 1.48.1.

Before you begin

These instructions are common across any flavor of Kubernetes. This procedure assumes you know how to install, configure, and operate a Kubernetes cluster and that you have an understanding of what the kubectl command does.

Warning
This procedure is primarily aimed at local or development setups. Multiple components, including MinIO and ingress-nginx, are deprecated and shouldn’t be used in production environments.

Hardware requirements

Ensure your environment meets the following hardware requirements:

A single Kubernetes node with a minimum of 9 cores and 32 GB RAM

Software requirements

Ensure you have the following software installed:

Kubernetes 1.29 or later (refer to Kubernetes installation documentation)
The kubectl command for your version of Kubernetes
Helm 3 or later (refer to Helm installation documentation)
An enterprise license

Additional requirements

Verify that you have:

Access to the Kubernetes cluster.
Enabled persistent storage in the Kubernetes cluster, which has a default storage class setup.
Access to a local storage option (like MinIO) or a storage bucket like Amazon S3, Azure Blob Storage, or Google Cloud Platform. Refer to the Optional: Other storage options section for more information.
DNS service works in the Kubernetes cluster. Refer to Debugging DNS resolution in the Kubernetes documentation.
Optional: Set up an ingress controller in the Kubernetes cluster, for example ingress-nginx.

Note
If you want to access GET from outside of the Kubernetes cluster, you may need an ingress. Ingress-related procedures are optional.

Note that ingress-nginx is being retired and should not be used in production environments.

Create a custom namespace and add the Helm repository

Using a custom namespace solves problems later on because you don’t have to overwrite the default namespace.

Create a unique Kubernetes namespace, for example, enterprise-traces:
shell
```
kubectl create namespace enterprise-traces
```
For more details, see the Kubernetes documentation about Creating a namespace.

Set up a Helm repository using the following commands:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

Set Helm chart values

The Helm chart includes a file called values.yaml, which contains default configuration options. In this procedure, you create a local file called custom.yaml in a working directory.

When you use Helm to deploy the chart, you can specify that Helm uses your custom.yaml to augment the default values.yaml file. The custom.yaml file sets the storage and traces options, enables the gateway, and sets the cluster to main. The traces section configures the distributor’s receiver protocols.

After creating the file, you have the option to make changes in that file as needed for your deployment environment.

To customize your Helm chart values:

Create a custom.yaml file in your working directory.
From the examples below, copy and paste Helm chart values into your file.
Save your custom.yaml file.
For simple deployments, use the default storage and minio sections. The Helm chart deploys MinIO. GET uses it to store traces and other information. Further down this page are instructions for customizing your trace storage configuration options.
Set your custom.yaml values to configure the receivers on the Tempo distributor.
Save the changes to your file.

Grafana Enterprise Traces helm chart values

The values in the example below provide configuration values for GET. These values include an additional admin bucket and specify a license. The enterpriseGateway is automatically enabled as part of enabling the chart for installation of GET.

GET requires multitenancy. It’s enabled by setting multitenancyEnabled: true in the values file. For more information, refer to Set up GET tenants.

# Specify the global domain for the cluster (in this case just local cluster mDNS)
global:
  clusterDomain: "cluster.local"

# Enable the Helm chart for GET installation
# Configure the Helm chart for a Grafana Enterprise Traces installation.
# We set the latest GET version as the image tag (2.8.4).
enterprise:
  enabled: true
  image:
    tag: v2.8.4

# Enable multitenancy for GET (required)
multitenancyEnabled: true

# MinIO storage configuration
# The installs a separate MinIO service/deployment into the same cluster and namespace as the GET install.
# Note: MinIO should not be used for production environments.
minio:
  enabled: true
  mode: standalone
  rootUser: grafana-tempo
  rootPassword: supersecret
  buckets:
    # Bucket for traces storage if enterprise.enabled is true - requires license. This is where all trace span information is stored.
    - name: enterprise-traces
      policy: none
      purge: false
    # Admin client bucket if enterprise.enabled is true - requires license. This is where tenant and administration information is stored.
    - name: enterprise-traces-admin
      policy: none
      purge: false
  # Changed the mc (the MinIO CLI client) config path to '/tmp' from '/etc' as '/etc' is only writable by root and OpenShift will not permit this.
  configPathmc: "/tmp/minio/mc/"
storage:
  # Specifies traces storage location.
  # Uses the MinIO bucket configured for trace storage.
  trace:
    backend: s3
    s3:
      access_key: "grafana-tempo"
      secret_key: "supersecret"
      bucket: "enterprise-traces"
      endpoint: "tempo-minio:9000"
      insecure: true
  # Specifies administration data storage location.
  # Uses the MinIO bucket configured for admin storage.
  admin:
    backend: s3
    s3:
      access_key_id: "grafana-tempo"
      secret_access_key: "supersecret"
      bucket_name: "enterprise-traces-admin"
      endpoint: "tempo-minio:9000"
      insecure: true

# Specifies which trace protocols to accept by the gateway.
# Note: GET's Enterprise gateway will only accept OTLP over gRPC or HTTP.
traces:
  otlp:
    http:
      enabled: true
    grpc:
      enabled: true

# Configure the distributor component to log all received spans.
distributor:
  config:
    log_received_spans:
      enabled: true

# Specify the license. This is the base64 license text you have received from your Grafana Labs representative.
license:
  contents: |
    LICENSEGOESHERE

Enterprise image version

If you require a different version of GET from the default in the Helm chart, update the enterprise configuration section in the custom.yaml values file with the required image version.

This example uses an older image tag of v2.8.0.

You can check for the latest version number by referencing the GET 2.8 release notes.

enterprise:
  enabled: true
  image:
    tag: v2.8.0

Enterprise license configuration

You need to configure a license by either

adding the license to the custom.yaml file or
by using a secret that contains the license.

Only use one of these options.

Note
Refer to the Obtain a GET license to learn how to obtain a license.

Using the first option, you can specify the license text in the custom.yaml values file created in the license: section.

license:
  contents: |
    LICENSEGOESHERE

If you don’t want to specify the license in the custom.yaml file, you can reference a secret that contains the license content.

Create the secret.

kubectl -n enterprise-traces create secret generic get-license --from-file=license.jwt

Configure the custom.yaml that you created to reference the secret.
YAML
```
license:
  external: true
  secretName: get-license
```

Set your storage option

Before you run the Helm chart, you need to configure where to store trace data.

The storage block defined in the values.yaml file configures the storage that Tempo uses for trace storage.

The procedure below configures MinIO as the local storage option managed by the Helm chart. However, you can use another storage provider. Refer to the Optional: Other storage options section.

Note
The MinIO installation included with this Helm chart is for demonstration purposes only. As of October 2025, MinIO no longer provides or supports precompiled Docker images. This chart uses an unsupported version of MinIO.

This configuration sets up a maximum storage size of 5GiB. This MinIO installation isn’t suitable for production environments and should only be used for example purposes. For production, use performant, Enterprise-grade object storage.

The Helm chart values provided include the basic MinIO setup values. If you need to customize them, the steps below walk you through which sections to update. If you don’t need to change the values, you can skip this section.

Optional: Update the configuration options in custom.yaml for your configuration if required.

storage:
  trace:
    backend: s3
    s3:
      access_key: "grafana-tempo"
      secret_key: "supersecret"
      bucket: "tempo-traces"
      endpoint: "tempo-minio:9000"
      insecure: true

Specify an additional bucket for admin resources:

storage:
  admin:
    backend: s3
    s3:
      access_key_id: "grafana-tempo"
      secret_access_key: "supersecret"
      bucket_name: "enterprise-traces-admin"
      endpoint: "tempo-minio:9000"
      insecure: true

Optional: If you need to change the defaults for MinIO, locate the MinIO section and change the relevant fields. Ensure that you update any trace or admin storage sections appropriately.
YAML
```
minio:
  enabled: true
  mode: standalone
  rootUser: minio
  rootPassword: minio123
```

Optional: Other storage options

You can enable persistent storage in the Kubernetes cluster, which has a default storage class setup. To change the default, refer to the StorageClass using Kubernetes documentation.

This Helm chart guide defaults to using MinIO as a simple solution to get you started. However, you can use a storage bucket like Amazon S3, Azure Blob Storage, or Google Cloud Platform.

Each storage provider has a different configuration stanza. You need to update your configuration based on your storage provider. Refer to the storage configuration block in the Grafana Tempo documentation for information on storage options.

Update the storage configuration options based upon your requirements:

Amazon S3 configuration documentation. The Amazon S3 example is identical to the MinIO configuration, except the two last options, endpoint and insecure, are dropped.
Azure Blob Storage configuration documentation
Google Cloud Storage configuration documentation

Azure with the `local_blocks` and `metrics-generator` processors

By default, the metrics-generator doesn’t require a backend connection unless you’ve enabled the local_blocks processor. The local_blocks processor is used for generating metrics from traces, which is required for TraceQL metrics. When this configuration is set, the metrics-generator produces blocks and flushes them into a backend storage.

In this case, list the generator in the env var expansion configuration so the STORAGE_ACCOUNT_ACCESS_KEY has the secret value.

You can use this configuration example with Helm charts, like tempo-distributed. Replace any values in all caps with the values for your Helm deployment.

generator:
  extraArgs:
    - "-config.expand-env=true"
  extraEnv:
    - name: <STORAGE_ACCOUNT_ACCESS_KEY>
      valueFrom:
        secretKeyRef:
          name: <TEMPO-TRACES-STG-KEY>
          key: <TEMPO-TRACES-KEY>

For more information about the local_blocks processor, refer to Enable TraceQL metrics queries.

Set traces receivers

The Helm chart values in your custom.yaml file are configured to use OTLP. If you are using other receivers, then you need to configure them.

You can configure Tempo to receive data from OTLP, Jaeger, Zipkin, Kafka, and OpenCensus. The following example enables OTLP on the distributor. For other options, refer to the distributor documentation

The example used in this procedure has OTLP enabled.

Enable any other protocols based on your requirements.

traces:
  otlp:
    grpc:
      enabled: true
    http:
      enabled: true

Enterprise Gateway is enabled by default, which only receives traces in OTLP gRPC and HTTP protocols.

Optional: Add custom configurations

There are many configuration options available in the tempo-distributed Helm chart. This procedure only covers the minimum configuration required to launch GET in a basic deployment.

You can add values to your custom.yaml file to set custom configuration options that override the defaults present in the Helm chart. The tempo-distributed Helm chart’s README contains a list of available options. The values.yaml files provides the defaults for the Helm chart.

Use the following command to see all of the configurable parameters for the tempo-distributed Helm chart:

helm show values grafana/tempo-distributed

Add the configuration sections to the custom.yaml file. Include this file when you install or upgrade the Helm chart.

Optional: Configure an ingress

An ingress lets you externally access a Kubernetes cluster. Replace <ingress-host> with a suitable hostname that DNS can resolve to the external IP address of the Kubernetes cluster. For more information, refer to Ingress.

Note
If you are using a Linux system and it’s not possible for you set up local DNS resolution, use the --add-host=<ingress-host>:<kubernetes-cluster-external-address> command-line flag to define the <ingress-host> local address for the Docker commands in the examples that follow.

Open your custom.yaml or create a YAML file of Helm values called custom.yaml.

Add the following configuration to the file:

nginx:
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - host: <ingress-host>
        paths:
          - path: /
            pathType: Prefix
    tls: {} # empty, disabled.

Save the changes.

Optional: Configure TLS with Helm

GET can be configured to communicate between the components using Transport Layer Security, or TLS.

To configure TLS with the Helm chart, you must have a TLS key-pair and CA certificate stored in a Kubernetes secret.

For instructions, refer to Configure TLS with Helm.

Optional: Use global or per-tenant overrides

The tempo-distributed Helm chart provides a module for users to set global or per-tenant override settings:

Global overrides come under the overrides property, which pertain to the standard overrides
Per-tenant overrides come under the per_tenant_overrides property, and allow specific tenants to alter configuration associated with them as per tenant-specific runtime overrides. The Helm chart generates a /runtime/overrides.yaml configuration file for all per-tenant configuration.

These overrides correlate to the standard (global) and tenant-specific (per_tenant_overide_config) overrides in GET configuration. For more information about overrides, refer to the Overrides configuration documentation.

The following example configuration sets some global configuration options, as well as a set of options for a specific tenant:

overrides:
  defaults:
    ingestion:
      rate_limit_bytes: 5 * 1000 * 1000
      burst_size_bytes: 5 * 1000 * 1000
      max_traces_per_user: 1000
    global:
      max_bytes_per_trace: 10 * 1000 * 1000

    metrics_generator:
      processors: ["service-graphs", "span-metrics"]

per_tenant_overrides:
  "1234":
    ingestion:
      rate_limit_bytes: 2 * 1000 * 1000
      burst_size_bytes: 2 * 1000 * 1000
      max_traces_per_user: 400
    global:
      max_bytes_per_trace: 5 * 1000 * 1000

This configuration:

Enables the Span Metrics and Service Graph metrics-generator processors for all tenants.
An ingestion rate and burst size limit of 5MB/s, a maximum trace size of 10MB and a maximum of 1000 live traces in an ingester for all tenants.
Overrides the 1234 tenant with a rate and burst size limit of 2MB/s, a maximum trace size of 5MB and a maximum of 400 live traces in an ingester.

Note
Runtime configurations should include all options for a specific tenant.

Install GET using the Helm chart

Use the following command to install GET using the configuration options you’ve specified in the custom.yaml file:

helm -n enterprise-traces install tempo grafana/tempo-distributed --version 1.48.1 -f custom.yaml

The output of the command contains the write and read URLs necessary for the following steps. If you update your values.yaml or custom.yaml, run the same helm install command and replace install with upgrade.

Check the statuses of the GET pods:

kubectl -n enterprise-traces get pods

Wait until all of the pods have a status of Running or Completed, which might take a few minutes.

The output results look similar to this:

❯ k get pods
NAME                                        READY   STATUS      RESTARTS      AGE
tempo-admin-api-7c59c75f6c-wvj75            1/1     Running     0             86m
tempo-compactor-75777b5d8c-5f44z            1/1     Running     0             86m
tempo-distributor-94fd965f4-prkz6           1/1     Running     0             86m
tempo-enterprise-gateway-6d7f78cf97-dhz9b   1/1     Running     0             86m
tempo-ingester-0                            1/1     Running     0             86m
tempo-ingester-1                            1/1     Running     1 (86m ago)   86m
tempo-ingester-2                            1/1     Running     1 (86m ago)   86m
tempo-memcached-0                           1/1     Running     0             86m
tempo-minio-6c4b66cb77-wjfpf                1/1     Running     0             86m
tempo-querier-6cb474546-cwlkz               1/1     Running     0             86m
tempo-query-frontend-6d6566cbf7-pcwg6       1/1     Running     0             86m
tempo-tokengen-job-58jhs                    0/1     Completed   0             86m

Note that the tempo-tokengen-job has emitted a log message containing the initial admin token.

Retrieve the token with this command:

kubectl -n enterprise-traces get pods | awk '/.*-tokengen-job-.*/ {print $1}' | xargs -I {} kubectl -n enterprise-traces logs {} | awk '/Token:\s*/ {print $2}'

To get the logs for the tokengen Pod, you can use:

kubectl -n enterprise-traces get pods | awk '/.*-tokengen-job-.*/ {print $1}' | xargs -I {} kubectl -n enterprise-traces logs {}

Test your installation

The next step is to test your installation by sending trace data to Grafana. You can use the Set up a test application for a Tempo cluster document for step-by-step instructions.

If you already have Grafana available, you can add a Tempo data source using the URL fitting to your environment. For example: http://tempo-query-frontend.enterprise-traces.svc.cluster.local:3100

You may need to install the Enterprise Traces plugin in your Grafana Enterprise instance to allow configuration of tenants, tokens, and access policies. After creating a user and access policy using the plugin, you can configure a data source to point at http://tempo-enterprise-gateway.enterprise-traces.svc.cluster.local:3100.

Set up metamonitoring

Metamonitoring provides observability for your Tempo deployment by collecting metrics and logs from the Tempo components themselves. This helps you monitor the health and performance of your tracing infrastructure. Setting up metamonitoring for Tempo and GET uses the k8s-monitoring Helm chart. For more information about this Helm chart, refer to the k8s-monitoring README.

Configure metamonitoring

To configure metamonitoring, you need to create a metamonitoring-values.yaml file and use the Kubernetes Monitoring Helm chart.

Create a metamonitoring-values.yaml file for the Kubernetes Monitoring Helm chart configuration. Replace the following values with your monitoring backend details:

tempo: A descriptive name for your cluster and namespace
<url>: Your Prometheus and Loki endpoint URLs
<username>: Your username/instance ID
<password>: Your password/API key

cluster:
  name: tempo # Name of the cluster, this will populate the cluster label

integrations:
  tempo:
    instances:
      - name: "tempo" # This is the name for the instance label that will be reported.
        namespaces:
          - tempo # This is the namespace that will be searched for tempo instances, change this accordingly
        metrics:
          enabled: true
          portName: prom-metrics
        logs:
          enabled: true
        labelSelectors:
          app.kubernetes.io/name: tempo

  alloy:
    name: "alloy-tempo"

destinations:
  - name: "tempo-metrics"
    type: prometheus
    url: "<url>" # Enter Prometheus URL
    auth:
      type: basic
      username: "<username>" # Enter username
      password: "<password>" # Enter password

  - name: "tempo-logs"
    type: loki
    url: "<url>" # Enter Loki URL
    auth:
      type: basic
      username: "<username>" # Enter username
      password: "<password>" # Enter password

alloy-metrics:
  enabled: true

podLogs:
  enabled: true
  gatherMethod: kubernetesApi
  namespaces: [tempo] # Set to namespace
  collector: alloy-singleton

alloy-singleton:
  enabled: true

alloy-metrics:
  enabled: true # This will send Grafana Alloy metrics to ensure the monitoring is working properly.

Install the k8s-monitoring Helm chart:

helm install k8s-monitoring grafana/k8s-monitoring \
  --namespace monitoring \
  --create-namespace \
  -f metamonitoring-values.yaml

Verify the installation:
shell
```
kubectl -n monitoring get pods
```
You should see pods for the k8s-monitoring components running.

Verify metamonitoring in Grafana

Navigate to your Grafana instance.
Check that metrics are being collected:
- Go to Explore > Prometheus.
- Query for Tempo metrics like tempo_build_info or tempo_distributor_spans_received_total.
Check that logs are being collected:
- Go to Explore > Loki
- Filter logs by your cluster name and look for Tempo component logs
Set up Tempo monitoring dashboards:
- For pre-built dashboards and alerts, refer to the Tempo mixin documentation

Your Tempo deployment now includes comprehensive metamonitoring, giving you visibility into the health and performance of your tracing infrastructure.

Next steps

After deploying GET with Helm, you can:

Set up a test application for a Tempo cluster to verify your installation
Set up GET tenants to configure multitenancy
Install the Enterprise Traces plugin in Grafana to manage tenants, tokens, and access policies

Set up the GET plugin for Grafana

Wed, 18 Feb 2026 16:41:26 +0000

Set up the GET plugin for Grafana

The Grafana Enterprise Traces (GET) plugin lets you create new tenants and then use the access page to create new roles to publish traces. These commands are completed using the Grafana user interface in lieu of commands that would normally be completed using the GET CLI.

This procedure explains how to enable and configure the GET plugin.

Before you begin

To configure the GET plugin, you need:

Grafana Enterprise 8.4.0 or higher
GET cluster access token
Microservice deployments require the GET gateway URL, for example: http://tempo-enterprise-gateway.enterprise-traces-test.svc.cluster.local:3200

Refer to Deploy Grafana Enterprise on Kubernetes if you are using Kubernetes. Otherwise, refer to Install Grafana for more information.

Install the plugin in your Grafana Enterprise instance

There are multiple ways to install the plugin to your local Grafana Enterprise instance. For more information, refer to Grafana Enterprise Traces app installation (requires login).

After installing the plugin, you will need to restart the Grafana pod for the plugin to be loaded on startup. If using the “Deploy Grafana Enterprise on Kubernetes” instructions, you will need to access the shell for the Grafana pod that you have just deployed to use the GET plugin installation instructions “Installing on a local Grafana”.

Enable and configure the plugin

To enable and configure the plugin:

Log in to Grafana Enterprise.
From the top-left menu, select Configuration and then select Plugins.
Search for Grafana Enterprise Traces plugin. This option is only available if you have GET and Grafana Enterprise licenses installed.
From the Connection settings tab of the plugin, enable the plugin by clicking on Enable plugin.
Provide the necessary API settings so that the plugin can connect to your cluster:
- Access token: Enter the admin-scoped access token that you generated when setting up your GET cluster. This is available in the logs output (or other configured output) from the tokengen job for the GET installation. The token is prefixed by the text Token:.
- Grafana Enterprise Traces URL: Enter the URL of your GET cluster. For single-process clusters, this is any node in the cluster. For microservice deployments, this URL is the GET gateway (for example, http://tempo-enterprise-gateway.enterprise-traces-test.svc.cluster.local:3200).
Click Test and save configuration.
Navigate to Grafana Enterprise Traces (select the GET, the stylized ‘T’ icon, on the menu bar).
Verify that the plugin loads and can communicate with the GET admin API endpoints. You can test this by selecting the Licenses tab from the GET plugin and ensure that you see something like this:
text
```
Issuer:
https://grafana.com
Issued at:
2026-01-29 13:06:11
Expires:
2026-02-05 13:06:11
Products:
grafana-enterprise-traces
```
Look at the default access policy under the Access Policies tab and ensure that there is a default access policy for the admin scope.

Configure the plugin using provisioning

Alternatively, you can also manage the GET plugin using a plugin configuration. Refer to the plugin configuration documentation for more information.

Example GET plugin configuration file:

apiVersion: 1

apps:
  # <string> the type of app, plugin identifier. Required
  - type: grafana-enterprise-traces-app
    # <integer> Org ID. Default to 1, unless org_name is specified
    org_id: 1
    # <string> Org name. Overrides org_id unless org_id not specified
    org_name: Main Org.
    # <boolean> disable the app. Default to false.
    disabled: false
    # <map> fields that will be converted to json and stored in jsonData.
    jsonData:
      # key/value pairs of string to object
      backendUrl: http://[...]
    # <map> fields that will be converted to json, encrypted and stored in secureJsonData.
    secureJsonData:
      # <string>
      accessToken: [...]

Optional `policiesOnly` field

For a simpler user experience that only shows the Access policies page, you can include the following in the jsonData configuration:

jsonData:
  policiesOnly: true

This simpler mode of operation only gives users access to the ability to create access policies and tokens. It requires setting up the environment to include at least one tenant.

Optional `policiesOnly` field

For a simpler user experience that only shows the “Access policies” page, you can include the following in the jsonData configuration:

jsonData:
  policiesOnly: true

This simpler mode of operation only gives users access to the ability to create access policies and tokens. It requires setting up the environment to include at least one tenant.

Legacy `base64EncodedAccessToken` field

Prior to version 6.0.0 of the plugin, authentication required a base64EncodedAccessToken field. This has been replaced with the simpler accessToken.

The following is provided for troubleshooting purposes, or for users of versions earlier than 6.0.0.

Moving forward, use accessToken in your configuration.

If both base64EncodedAccessToken and accessToken are present in the jsonData, the base64EncodedAccessToken is ignored in versions 6.0.0 and later.

The format of the base64EncodedAccessToken token is a base64-encoded representation of a user-token pair, separated by a colon. For example, $USER:$TOKEN. If you’ve set your GET token as the TOKEN environment variable, and you’ve also set a USER environment variable, then you can generate a compatible base64EncodedAccessToken token in the following format:

#USER INTENTIONALLY LEFT BLANK, INDICATING THE "ADMIN" USER
USER=
TOKEN=exampleTokenForBase64EncodedAccessToken
echo $USER:$TOKEN | tr -d '[:space:]' | base64 -w0

Though $USER is typically blank, you can opt to leave it in the expression to ensure that the : character is present. The following is a more direct way of obtaining the same result:

echo :$TOKEN | tr -d '[:space:]' | base64 -w0

These examples both result in the following base64EncodedAccessToken string:

OmV4YW1wbGVUb2tlbkZvckJhc2U2NEVuY29kZWRBY2Nlc3NUb2tlbgo=

You can apply the encoded token string to the configuration under secureJsonData in your plugin configuration file:

secureJsonData:
  # <string> a base64 encoding of $USER:$TOKEN
  base64EncodedAccessToken: OmV4YW1wbGVUb2tlbkZvckJhc2U2NEVuY29kZWRBY2Nlc3NUb2tlbgo=

Next steps

Now that you have correctly configured the plugin, the next step is to set up a GET tenant and visualize your data.

Limitations

The GET plugin for Grafana allows to manage only 1 GET cluster, and it doesn’t support managing multiple GET clusters with a single GET plugin installation. If you need to manage multiple GET clusters, you should configure 1 GET cluster per Grafana organization.

Set up GET tenants

Fri, 31 Oct 2025 20:36:39 +0000

Set up a tenant in your Grafana Enterprise Traces cluster

Tenants provide a mechanism for trace isolation. Access policies may be set on a per-tenant basis. Authorization of requests is based on specified access policies.

These instructions assume that you have the Grafana Enterprise Traces (GET) plugin installed. Use this plugin to create tenants, access policies, and tokens for your GET cluster. The steps include:

Create a GET tenant.
Create an access policy.
Configure remote-write to your tenant.
Set up your tenant as a Grafana data source.
Visualize your data.

Create a GET tenant

Once a cluster is running, you can create new tenants. To create a GET tenant:

Within Grafana Enterprise, navigate to Apps > Grafana Enterprise Traces > Tenants.
Click on Create tenant.
Choose a name for this tenant. For demonstration purposes, use the name dev-tenant.
Select the cluster.
Click Create tenant.

Create an access policy

Access policies are used to authorize actions and operations by specified tenants. Access policies have a realm, which defines the set of tenants they apply to, and a scope, which defines the set of actions upon which they confer permissions to use.

Grafana Enterprise requires a data source access policy and token to access the traces in the tenant named dev-tenant.

Navigate to Apps > Grafana Enterprise Traces > Access policies.
Click Create access policy.
Choose a name for the policy. For demonstration purposes, use dev-read-write-policy.
Under Scopes, select the toggle next to the question Are you planning on creating a data source that uses this access policy?. This enables the traces:read policy.
Enable the scope traces:write to create an access policy that grants access for both reading and writing trace data (as the previous step toggles the traces:read policy automatically).
Select the tenant dev-tenant.
Click on Create.
From the newly created access policy, click Add token.
Name the token dev-token and click on Create.
In the next window, copy the token by selecting Copy to clipboard.

At this point, you can add a data source to your Grafana Enterprise instance by using the Create a data source option on this dialog or by manually adding one using the procedure below.

Select Create a data source. The data source fields are automatically configured based upon your instance.
Verify the created data source by opening the Configuration option in the Grafana menu and then selecting Data sources.

Set up remote-write to your tenant

To enable writes to your cluster, add a remote-write configuration snippet to the configuration file of an existing Grafana Alloy instance. If you do not have an existing traces collector, refer to Set up with Grafana Alloy. For Kubernetes, refer to the Grafana Alloy Kubernetes quick start guide.

The sample below is an example Alloy configuration below for the Kubernetes Helm chart (the values.yaml manifest):

alloy:
  extraPorts:
    - name: otlp-grpc
      port: 4317
      targetPort: 4317
      protocol: TCP
  configMap:
    create: true
    content: |-
      // Creates a receiver for OTLP gRPC.
      // You can easily add receivers for other protocols by using the correct component
      // from the reference list at: https://grafana.com/docs/alloy/latest/reference/components/
      otelcol.receiver.otlp "otlp_receiver" {
        // Listen on all available bindable addresses on port 4317 (which is the
        // default OTLP gRPC port) for the OTLP protocol.
        grpc {
          endpoint = "0.0.0.0:4317"
        }

        // Output straight to the OTLP gRPC exporter. We would usually do some processing
        // first, most likely batch processing, but for this example we pass it straight
        // through.
        output {
          traces = [
            otelcol.exporter.otlp.get.input,
          ]
        }
      }

      // Define an OTLP gRPC exporter to send all received traces to GET.
      // The unique label 'get' is added to uniquely identify this exporter.
      otelcol.exporter.otlp "get" {
          // Define the client for exporting.
          client {
              // Use Header authentication, defined below.
              auth = otelcol.auth.headers.credentials.handler
              // Send to the locally running Tempo instance, on port 4317 (OTLP gRPC).
              endpoint = "http://get-cluster-tempo-enterprise-gateway.get.svc.cluster.local:3100"
              // Configure TLS settings for communicating with the endpoint.
              tls {
                  // The connection is insecure.
                  insecure = true
                  // Do not verify TLS certificates when connecting.
                  insecure_skip_verify = true
              }
          }
      }

      // A default GET install doesn't expose a TLS-encrypted gateway.
      // Grafana Alloy expects gRPC (HTTP/2) traffic to be TLS-encrypted, and
      // therefore fails if the "basic_auth" authorization block is used. Because of
      // this, use the generic "headers" block to authenticate a GET
      // tenant and token.
      // The authorization must be exposed as a '<tenant>:<writeToken>' pair that
      // has been base64 encrypted.
      otelcol.auth.headers "credentials" {
        header {
          key = "Authorization"
          value = "Basic ZGV2LXRlbmFudDpaR1YyTFhKbFlXUXRkM0pwZEdWeUxYQnZiR2xqZVMxa1pXMXZMWFJ2YTJWdU9qWS9lemR1TVRWaEpEUXZQR012THpRMVN6Z3NKakZiTVE9PQo="
        }
      }

In the above Flow configuration, the token for authentication was generated using the dev-tenant user and writeable token via:

echo 'dev-tenant:ZGV2LXJlYWQtd3JpdGVyLXBvbGljeS1kZW1vLXRva2VuOjY/ezduMTVhJDQvPGMvLzQ1SzgsJjFbMQ==' | base64

Create a Grafana data source

To allow Grafana to read traces from GET, you must create a Tempo data source with the proper credentials.

Navigate to Connections > Data Sources.
Click on Add a data source.
Select Tempo.
Set the URL to http://<get-gateway-host>:<http_listen_port>/<http_api_prefix>, filling in the path to your gateway and the configured HTTP API prefix.
Enable Basic Auth. Use User dev-tenant and the token from your clipboard as the Password.
Click Save & Test.

You should see a message that says Data source is working.

Visualize your data

Once you have created a data source, you can visualize your traces in the Grafana Explore page.

Test your configuration using the Intro to MLTP application

The Intro to MLTP application provides an example five-service application that generates data for Tempo, Mimir, Loki, and Pyroscope. This procedure installs the application on your cluster so you can generate meaningful test data.

Navigate to https://github.com/grafana/intro-to-mltp to get the Kubernetes manifests for the Intro to MLTP application.

Clone the repository using commands similar to the ones below:

  git clone git+ssh://github.com/grafana/intro-to-mltp
  cp intro-to-mltp/k8s/mythical/* ~/tmp/intro-to-mltp-k8s

Change to the cloned repository: cd intro-to-mltp/k8s/mythical
In the mythical-beasts-deployment.yaml manifest, alter each TRACING_COLLECTOR_HOST environment variable instance value to point to the Alloy location. For example, based on an Alloy installation in the default namespace called and with a Helm installation called test:
YAML
```
 	- env:
     ...
     - name: TRACING_COLLECTOR_HOST
       value: test-grafana-alloy.default.svc.cluster.local
```

Deploy the Intro to MLTP application. It deploys into the default namespace.

   kubectl apply -f mythical-beasts-service.yaml,mythical-beasts-persistentvolumeclaim.yaml,mythical-beasts-deployment.yaml

Once the application is deployed, go to Grafana Enterprise and select the Explore menu item.
Select the GET data source from the list of data sources.
Select the Search Query type for the data source.
Select Run query.
Traces from the application are displayed in the traces Explore panel.

Monitor GET using Grafana Cloud

Thu, 24 Jul 2025 15:08:34 +0000

Monitor GET using Grafana Cloud

Note
Monitoring with Grafana Cloud is required for all GET installations. Professional services will assist you in configuring monitoring for your GET installation.

Metamonitoring for GET is handled by the Grafana k8s-monitoring Helm chart (>=v2.1). Using Grafana Alloy to collect metrics and logs.

Before you begin

Helm v3+
Supported Kubernetes cluster: EKS, AKS, and GKE.
Existing GET deployment in Kubernetes.
Grafana Cloud account for metrics/logs storage

Steps

Add the Grafana Helm Chart, or update if already added. This will be using the K8s-Monitoring-Helm and the values.yml file will be to set parameters in the Helm chart.

helm repo add grafana https://grafana.github.io/helm-charts

helm repo update

Generate values.yml.

cluster:
  name: enterprise-traces # Name of the cluster, this will populate the cluster label

integrations:
  tempo:
    instances:
      - name: "enterprise-traces" # This is the name for the instance label that will be reported.
        namespaces:
          - enterprise-traces # This is the namespace that will be searched for tempo instances, change this accordingly
        metrics:
          enabled: true
          portName: prom-metrics
        logs:
          enabled: true
        labelSelectors:
          app.kubernetes.io/name: tempo

  alloy:
    name: "alloy-enterprise"

destinations:
  - name: "enterprise-metrics"
    type: prometheus
    url: "<url>" # URL for prometheus, this can be found under your Grafana Cloud account and should look similiar to "https://prometheus-us-central1.grafana.net/api/prom/push"
    auth:
      type: basic
      username: "<username>" # Username for Grafana Cloud Prometheus 
      password: "<password>" # Password for Grafana Cloud Prometheus

  - name: "enterprise-logs"
    type: loki
    url: "<url>" # URL for loki, this can be found under your grafana cloud account and should look similiar to "https://logs-prod-us-central1.grafana.net/loki/api/v1/push"
    auth:
      type: basic
      username: "<username>" # Username for Grafana Cloud Loki 
      password: "<password>" # Password for Grafana Cloud Loki 

alloy-metrics:
  enabled: true

podLogs:
  enabled: true
  gatherMethod: kubernetesApi
  namespaces: [enterprise-traces] # Set to namespace
  collector: alloy-singleton

alloy-singleton:
  enabled: true

alloy-metrics:
  enabled: true # This will send Grafana Alloy metrics to ensure the monitoring is working properly.

Install the Helm chart using the following command to create a daemonset that grabs Tempo logs:

 helm install k8s-monitoring grafana/k8s-monitoring \
  --namespace monitoring \
  --create-namespace \
  -f values.yml

View Logs and Metrics

Log into Grafana Cloud. Select metrics drilldown and select cluster=<cluster.name> where cluster.name is the name specified in the values.yml. Do the same for logs drilldown.

Set up on Grafana Labs

GET hardware requirements

GET hardware requirements

CPU and memory

Network

Storage

Block storage

Object storage

Deploy GET with Helm

Deploy GET with Helm

Get started with Grafana Enterprise Traces using the Helm chart

Before you begin

Hardware requirements

Software requirements

Additional requirements

Create a custom namespace and add the Helm repository

Set Helm chart values

Grafana Enterprise Traces helm chart values

Enterprise image version

Enterprise license configuration

Set your storage option

Optional: Other storage options

Azure with the local_blocks and metrics-generator processors

Set traces receivers

Optional: Add custom configurations

Optional: Configure an ingress

Optional: Configure TLS with Helm

Optional: Use global or per-tenant overrides

Install GET using the Helm chart

Test your installation

Set up metamonitoring

Configure metamonitoring

Verify metamonitoring in Grafana

Next steps

Set up the GET plugin for Grafana

Set up the GET plugin for Grafana

Before you begin

Install the plugin in your Grafana Enterprise instance

Enable and configure the plugin

Configure the plugin using provisioning

Optional policiesOnly field

Optional policiesOnly field

Legacy base64EncodedAccessToken field

Next steps

Limitations

Set up GET tenants

Set up a tenant in your Grafana Enterprise Traces cluster

Create a GET tenant

Create an access policy

Set up remote-write to your tenant

Create a Grafana data source

Visualize your data

Test your configuration using the Intro to MLTP application

Monitor GET using Grafana Cloud

Monitor GET using Grafana Cloud

Before you begin

Steps

Azure with the `local_blocks` and `metrics-generator` processors

Optional `policiesOnly` field

Optional `policiesOnly` field

Legacy `base64EncodedAccessToken` field