---
title: "Monitor the health of your system | Grafana Enterprise Metrics documentation"
description: "Learn how to collect metrics and logs from Grafana Mimir or GEM itself."
---

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

# Monitor the health of your system

You can monitor Grafana Mimir or Grafana Enterprise Metrics by collecting metrics and logs from a Mimir or GEM instance that’s running on a Kubernetes cluster. This process is called *metamonitoring*.

As part of *metamonitoring*, you can create dashboards and receive alerts about the metrics and logs collected from Mimir. To set up these dashboards and alerts, refer to [Installing Grafana Mimir dashboards and alerts](/docs/enterprise-metrics/v2.16.x/manage/monitor/monitor-mimir/installing-dashboards-and-alerts/).

## Configure the Grafana Agent operator via the Helm chart

> Caution
> 
> Grafana Alloy is the new name for our distribution of the OTel collector. Grafana Agent has been deprecated and is in Long-Term Support (LTS) through October 31, 2025. Grafana Agent will reach an End-of-Life (EOL) on November 1, 2025. Read more about why we recommend migrating to [Grafana Alloy](/blog/2024/04/09/grafana-alloy-opentelemetry-collector-with-prometheus-pipelines/).

In the Helm chart, you can configure where to send metrics and logs. You can send metrics to a Prometheus-compatible server and logs to a Loki cluster. The Helm chart can also scrape additional metrics from kube-state-metrics, kubelet, and cAdvisor.

The Helm chart does not collect Prometheus node\_exporter metrics; metrics from node\_exporter must all have an instance label on them that has the same value as the instance label on Mimir metrics. For the list of necessary node\_exporter metrics see the metrics prefixed with `node` in [Grafana Cloud: Self-hosted Grafana Mimir integration](/docs/grafana-cloud/monitor-infrastructure/integrations/integration-reference/integration-mimir/#metrics).

You can configure your collection of metrics and logs by using the [Grafana Agent operator](/docs/agent/latest/operator/). The Helm chart can install and use the Grafana Agent operator.

> **Note:** Before the Helm chart can use the operator, you need to manually install all of the Kubernetes [Custom Resource Definitions (CRDs)](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/) from the [Grafana Agent operator YAML files](https://github.com/grafana/agent/tree/main/operations/agent-static-operator/crds).

It’s best to use the Grafana Agent operator for metrics and logs collection. However, if you prefer not to use it or you already have an existing Grafana Agent that you want to use, see *Collect metrics and logs via Grafana Agent* documentation in Grafana Mimir version 2.5.0.

1. Store credentials in a Secret:
   
   If Prometheus and Loki are running without authentication, then you scan skip this section. Metamonitoring supports multiple ways of authentication for metrics and logs. If you are using a secret such as an API key to authenticate with Prometheus or Loki, then you need to create a Kubernetes Secret with that secret.
   
   This is an example Kubernetes Secret:
   
   YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy
   
   ```yaml
   apiVersion: v1
   kind: Secret
   metadata:
     name: metamonitoring-credentials
   data:
     prometheus-api-key: FAKEACCESSKEY
     loki-api-key: FAKESECRETKEY
   ```
   
   For information about how to create a Kubernetes Secret, see [Creating a Secret](https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret).
2. Configure Helm chart values:
   
   Merge the following YAML configuration into your Helm values file, and replace the values for `url`, `username`, `passwordSecretName` , and `passwordSecretKey` with the details of the Prometheus and Loki clusters, and the Secret that you created. If your Prometheus and Loki servers are running without authentication, then remove the `auth` blocks from the YAML below.
   
   If you already have the Agent operator installed in your Kubernetes cluster, then set `installOperator: false`.
   
   YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy
   
   ```yaml
   metaMonitoring:
     serviceMonitor:
       enabled: true
     grafanaAgent:
       enabled: true
       installOperator: true
   
       logs:
         remote:
           url: "https://example.com/loki/api/v1/push"
           auth:
             username: "12345"
             passwordSecretName: "metamonitoring-credentials"
             passwordSecretKey: "loki-api-key"
   
       metrics:
         remote:
           url: "https://example.com/api/v1/push"
           auth:
             username: "54321"
             passwordSecretName: "metamonitoring-credentials"
             passwordSecretKey: "prometheus-api-key"
   
         scrapeK8s:
           enabled: true
           kubeStateMetrics:
             namespace: kube-system
             labelSelectors:
               app.kubernetes.io/name: kube-state-metrics
   ```

For more information about using using the Helm chart to configure Grafana Mimir, refer to [Run Grafana Mimir in production using the Helm chart](/docs/helm-charts/mimir-distributed/latest/run-production-environment-with-helm/).

### Send metrics back into Mimir or GEM

You can also send the metrics that you collected (metamonitoring metrics) back into Mimir or GEM itself rather than sending them elsewhere.

When you leave the `metamonitoring.grafanaAgent.metrics.remote.url` field empty, then the chart automatically fills in the address of the GEM gateway Service or the Mimir NGINX Service.

If you have deployed Mimir, and `metamonitoring.grafanaAgent.metrics.remote.url` is not set, then the metamonitoring metrics are be sent to the Mimir cluster. You can query these metrics using the HTTP header X-Scope-OrgID: metamonitoring

If you have deployed GEM, then there are two alternatives:

- If are using the `trust` authentication type (`mimir.structuredConfig.auth.type=trust`), then the same instructions apply as for Mimir.
- If you are using the enterprise authentication type (`mimir.structuredConfig.auth.type=enterprise`, which is also the default when `enterprise.enabled=true`), then you also need to provide a Secret with the authentication token for the tenant.The token should be to an access policy with `metrics:write` scope. Assuming you are using the GEM authentication model, the Helm chart values should look like the following example.

YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```yaml
metaMonitoring:
  serviceMonitor:
    enabled: true
  grafanaAgent:
    enabled: true
    installOperator: true

    metrics:
      remote:
        auth:
          username: metamonitoring
          passwordSecretName: gem-tokens
          passwordSecretKey: metamonitoring
```

## Monitor without the Helm chart

To monitor the health of your system without using the Helm chart, see [Collect metrics and logs without the Helm chart](/docs/enterprise-metrics/v2.16.x/manage/monitor/monitor-mimir/collecting-metrics-and-logs/#collect-metrics-and-logs-without-the-helm-chart).

You can also use the self-hosted Grafana Cloud integration to monitor your Mimir system. Refer to [Grafana Cloud: Self-hosted Grafana Mimir integration](/docs/grafana-cloud/monitor-infrastructure/integrations/integration-reference/integration-mimir/) for more information.
