--- title: "Set up Amazon Aurora PostgreSQL | Database Observability documentation" description: "Set up Database Observability for Amazon Aurora PostgreSQL using Grafana Alloy and send telemetry to Grafana Cloud." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt). # Set up Amazon Aurora PostgreSQL Set up Database Observability with Grafana Cloud to collect telemetry from Amazon Aurora PostgreSQL clusters using Grafana Alloy. You configure your Aurora cluster and Alloy to forward telemetry to Grafana Cloud. If you already use the PostgreSQL integration, Database Observability extends it with query-level telemetry collected by the `database_observability.postgres` Alloy component. ## What you’ll achieve In this article, you: - Configure Amazon Aurora PostgreSQL cluster parameter groups for monitoring. - Create monitoring users with required privileges. - Configure Grafana Alloy with the Database Observability components. - Forward telemetry to Grafana Cloud. - Verify that telemetry appears in Database Observability. ## Setup steps Setting up Database Observability for Amazon Aurora PostgreSQL has three steps: 1. [**Set up your database**](#set-up-your-database): Prepare your Aurora cluster so Alloy can collect from it. 2. [**Configure Grafana Alloy**](#configure-grafana-alloy): Configure how Alloy collects telemetry and sends it to Grafana Cloud. Aurora supports a few methods to choose from. 3. [**Verify telemetry in Grafana Cloud**](#verify-telemetry-in-grafana-cloud): Check telemetry status and confirm that query metrics appear in Database Observability. ## Before you begin To complete this setup, you need: - An Amazon Aurora PostgreSQL 14.0 or later cluster. - Permission to modify the Aurora cluster parameter group. - Permission to reboot the Aurora cluster if parameter changes require it. - A PostgreSQL admin user that can create users and grant privileges. - A planned [Grafana Alloy](/docs/grafana-cloud/send-data/alloy/) deployment location with network access to each Aurora instance endpoint. Estimated setup time: 20-40 minutes, excluding any required maintenance window for restarting the cluster. > Note > > Alloy should connect directly to the database host. Avoid connecting Alloy to the database through a load balancer or connection pooler such as PgBouncer as it would limit Alloy’s ability to collect accurate telemetry. ## Set up your database In this step, you’ll prepare your Amazon Aurora PostgreSQL cluster for monitoring by enabling `pg_stat_statements`, creating a monitoring user, and granting the permissions Database Observability needs. Complete this before configuring Alloy. Without it, Alloy can connect to your database, but it won’t be able to collect the telemetry required for Database Observability. ### Configure the DB cluster parameter group Enable `pg_stat_statements` and configure query tracking by adding parameters to your Amazon Aurora PostgreSQL cluster parameter group. These parameters require a cluster restart to take effect. If these values are already enabled on the parameter group attached to your cluster, you don’t need to change them or restart the cluster. If you update any parameter that requires a reboot, plan a maintenance window and wait for the cluster restart to complete before continuing. #### Required parameters Expand table | Parameter | Value | Notes | |-----------------------------|----------------------|------------------| | `shared_preload_libraries` | `pg_stat_statements` | Requires restart | | `pg_stat_statements.track` | `all` | Requires restart | | `track_activity_query_size` | `4096` | Requires restart | #### Use the Amazon RDS console 1. Open the **RDS Console** and navigate to **Parameter groups**. 2. Create a new cluster parameter group or modify an existing one with family `aurora-postgresql14`. 3. Set the parameters listed above. 4. Apply the parameter group to your Aurora cluster. 5. Reboot the cluster to apply changes. For detailed console instructions, refer to [Working with parameter groups](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.html) in the AWS documentation. #### Use Terraform Using Terraform with the `terraform-aws-modules/rds-aurora/aws` module: hcl ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```hcl create_db_cluster_parameter_group = true db_cluster_parameter_group_family = "aurora-postgresql14" db_cluster_parameter_group_name = "-parameter-group" db_cluster_parameter_group_description = "Parameter group with pg_stat_statements for monitoring" db_cluster_parameter_group_parameters = [ { name = "shared_preload_libraries" value = "pg_stat_statements" apply_method = "pending-reboot" }, { name = "pg_stat_statements.track" value = "all" apply_method = "pending-reboot" }, { name = "track_activity_query_size" value = "4096" apply_method = "pending-reboot" }, ] ``` Or using a standalone `aws_rds_cluster_parameter_group` resource: hcl ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```hcl resource "aws_rds_cluster_parameter_group" "aurora_postgres_monitoring" { name = "-parameter-group" family = "aurora-postgresql14" description = "Parameter group with pg_stat_statements for monitoring" parameter { name = "shared_preload_libraries" value = "pg_stat_statements" apply_method = "pending-reboot" } parameter { name = "pg_stat_statements.track" value = "all" apply_method = "pending-reboot" } parameter { name = "track_activity_query_size" value = "4096" apply_method = "pending-reboot" } } ``` Replace *<CLUSTER\_NAME>* with your Aurora cluster name. > Note > > If you already have a parameter group with `rds.logical_replication` enabled, for example, for replication to other services, add the `pg_stat_statements` parameters to that existing group rather than creating a new one. After applying the parameter group to your cluster and restarting, enable the extension in each database you want to monitor: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql CREATE EXTENSION IF NOT EXISTS pg_stat_statements; ``` Verify the extension is installed: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql SELECT * FROM pg_stat_statements LIMIT 1; ``` ### Create a monitoring user and grant required privileges Connect to your Amazon Aurora PostgreSQL cluster as an administrator and create the monitoring user: Create the `db-o11y` user and grant base privileges: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql CREATE USER "db-o11y" WITH PASSWORD ''; GRANT pg_monitor TO "db-o11y"; GRANT pg_read_all_stats TO "db-o11y"; ``` Replace *<DB\_O11Y\_PASSWORD>* with a secure password for the `db-o11y` PostgreSQL user. Alloy must connect as this same user. If you use a name other than `db-o11y`, replace it in every later step, including the disable-tracking SQL. Verify that the user has the correct privileges to query `pg_stat_statements`: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql -- run with the `db-o11y` user SELECT * FROM pg_stat_statements LIMIT 1; ``` #### Disable tracking of monitoring user queries Prevent tracking of queries executed by the monitoring user itself: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql ALTER ROLE "db-o11y" SET pg_stat_statements.track = 'none'; ``` #### Grant object privileges for detailed data To allow collecting schema details and table information, connect to each logical database and grant access to each schema. For example, for a `payments` database: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql -- switch to the 'payments' database \c payments -- grant permissions in the 'public' schema GRANT USAGE ON SCHEMA public TO "db-o11y"; GRANT SELECT ON ALL TABLES IN SCHEMA public TO "db-o11y"; -- grant permissions in the 'tests' schema GRANT USAGE ON SCHEMA tests TO "db-o11y"; GRANT SELECT ON ALL TABLES IN SCHEMA tests TO "db-o11y"; ``` Alternatively, if you’re unsure which specific schemas need access, use the predefined role to grant USAGE and SELECT access to all objects: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql GRANT pg_read_all_data TO "db-o11y"; ``` ### Verify parameter group settings Verify that the parameter settings were applied correctly after restarting: SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql SHOW pg_stat_statements.track; ``` Expected result: Value is `all`. SQL ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```sql SHOW track_activity_query_size; ``` Expected result: Value is `4096`. ### Database setup checkpoint Continue to Alloy configuration only after these conditions are true: - `pg_stat_statements` is in `shared_preload_libraries` and the extension is created (`SELECT * FROM pg_stat_statements LIMIT 1;` runs without error). - `pg_stat_statements.track` is `all` and `track_activity_query_size` is `4096`. - The `db-o11y` monitoring user has the required monitoring and object privileges. - The `db-o11y` monitoring user can connect from the network where Alloy will run. - Any parameter changes that required a reboot have been applied and the cluster restart is complete. After these checks pass, your Aurora cluster is ready for Database Observability. Next, configure Alloy so it can collect telemetry from the Aurora instance endpoints and send it to Grafana Cloud. ## Configure Grafana Alloy After you set up your database, choose how to configure Alloy. **Pick one:** 1. [**Configuration page (recommended)**](#option-1-configure-alloy-from-the-database-observability-configuration-page-recommended): Database Observability generates the Alloy configuration for you. Choose **Fleet Management** or **Manual configuration**, then select **Standalone Alloy** or **Kubernetes Monitoring Helm chart**. Best for most teams. 2. [**Kubernetes Monitoring Helm chart**](#option-2-configure-the-grafana-kubernetes-monitoring-helm-chart-manually): Set `databaseObservability.enabled` in your `values.yaml` yourself. 3. [**Custom configuration file (advanced)**](#option-3-write-a-custom-alloy-configuration-file-advanced): Write the Alloy configuration yourself. Best for full control, custom components or relabeling, or environments the other paths don’t cover. ### Make sure you’re on a supported Alloy version Alloy `1.17.0` or later is required for Database Observability. Find the latest stable version on [Docker Hub](https://hub.docker.com/r/grafana/alloy/tags). To update, refer to the [Alloy release notes](https://github.com/grafana/alloy/releases). > Note > > Grafana Alloy is an open source collector that sends your data to Grafana Cloud. Database Observability needs it to collect metrics and query telemetry from your database. > > If you don’t have it installed, go to **Connections > Collector Setup** in Grafana Cloud, open the **Install** tab, and choose **Alloy**. For more detail, refer to [Get started with Fleet Management and Grafana Alloy](/docs/grafana-cloud/send-data/fleet-management/get-started/alloy/). ### Option 1: Configure Alloy from the Database Observability Configuration page (recommended) Start here for most deployments. The Configuration page (**Configuration** > **Setup**) generates the configuration for you. Choose how to manage the configuration: - **Fleet Management**: Grafana Cloud applies and manages the configuration on enrolled Alloy collectors. Refer to [Introduction to Fleet Management](/docs/grafana-cloud/send-data/fleet-management/introduction/). - **Manual configuration**: Generate the configuration and deploy it yourself with your own tools. Then choose where Alloy runs: **Standalone Alloy** or **Kubernetes Monitoring Helm chart**. Both platforms support Fleet Management and manual configuration. For manual configuration, the wizard generates an Alloy configuration file for standalone Alloy or Helm values for Kubernetes. To start the guided setup flow: 1. Open **Database Observability** in Grafana Cloud. 2. Go to **Configuration**. 3. Open **Setup**. 4. Click **Add database**. 5. Select **PostgreSQL** as the database engine and **Amazon Aurora** as the hosting option. 6. Choose **Fleet Management** or **Manual configuration**, then select **Standalone Alloy** or **Kubernetes Monitoring Helm chart**. For an overview of setup methods and what appears in the **Setup** tab, refer to [Configure Alloy from the Configuration page](/docs/grafana-cloud/monitor-applications/database-observability/configure/fleet-management-integration/). ### Option 2: Configure the Grafana Kubernetes Monitoring Helm chart manually Use this method to write the Kubernetes Monitoring Helm chart values yourself instead of generating them from the Configuration page. Extend your `values.yaml` and set `databaseObservability.enabled` to `true` within the PostgreSQL integration. YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml integrations: collector: alloy-singleton postgresql: instances: - name: jobLabel: integrations/db-o11y exporter: dataSource: host: # Must be specific instance endpoint port: 5432 database: postgres sslmode: require auth: usernameKey: passwordKey: autoDiscovery: enabled: true databaseDenyList: ["rdsadmin"] collectors: statStatements: enabled: true excludeUsers: ["db-o11y", "rdsadmin"] excludeDatabases: ["rdsadmin"] databaseObservability: enabled: true cloudProvider: aws: arn: "" secret: create: false name: namespace: logs: enabled: true labelSelectors: app.kubernetes.io/instance: ``` Replace the placeholders: - `INSTANCE_NAME`: Name for this database instance in Kubernetes. - `INSTANCE_ENDPOINT`: The specific DB instance endpoint. Do not use the cluster (writer), reader, or custom endpoint because these endpoints can route connections to different instances and break metric correlation. - `DB_USERNAME_SECRET_KEY`: Kubernetes secret key that holds the database username, for example, `username`. The value must be the monitoring user you created and granted privileges to, for example, `db-o11y`. That username must match `excludeUsers`. - `DB_PASSWORD_SECRET_KEY`: Kubernetes secret key containing database password. - `AWS_AURORA_INSTANCE_ARN`: The specific Amazon Aurora instance Amazon Resource Name. - `SECRET_NAME`: Name of the Kubernetes secret containing database credentials. - `NAMESPACE`: Kubernetes namespace where the secret exists. To see the full set of values, refer to the k8s-monitoring Helm chart [documentation](https://github.com/grafana/k8s-monitoring-helm/blob/main/charts/k8s-monitoring/charts/feature-integrations/docs/integrations/postgresql.md#database-observability) or the [example configuration](https://github.com/grafana/k8s-monitoring-helm/tree/main/charts/k8s-monitoring/docs/examples/features/database-observability/postgresql). #### Configure AWS Secrets Manager and Kubernetes (optional) If you use AWS Secrets Manager with External Secrets Operator to manage database credentials, configure them as follows. ##### Secret path convention Store monitoring credentials in AWS Secrets Manager at a path following this convention: ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```none /kubernetes/rds//monitoring ``` ##### PostgreSQL secret format Store the secret as JSON with the following format: JSON ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```json { "username": "db-o11y", "password": "", "engine": "postgres", "host": ".rds.amazonaws.com", "port": 5432, "dbClusterIdentifier": "", "database": "postgres" } ``` Replace the placeholders: - `DB_O11Y_PASSWORD`: Password for the `db-o11y` PostgreSQL user. - `INSTANCE_ENDPOINT`: The specific DB instance endpoint. Do not use the cluster (writer), reader, or custom endpoint because these endpoints can route connections to different instances and break metric correlation. - `CLUSTER_NAME`: Aurora cluster name. ##### Create the secret with the AWS CLI Bash ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```bash aws secretsmanager create-secret \ --name "/kubernetes/rds//monitoring" \ --description "Alloy monitoring credentials for Amazon Aurora PostgreSQL cluster" \ --secret-string '{"username":"db-o11y","password":"","engine":"postgres","host":".rds.amazonaws.com","port":5432,"dbClusterIdentifier":"","database":"postgres"}' ``` ##### Kubernetes External Secrets configuration Use the External Secrets Operator to sync the AWS secret into Kubernetes: YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml --- apiVersion: external-secrets.io/v1beta1 kind: SecretStore metadata: name: -db-monitoring-secretstore spec: provider: aws: service: SecretsManager region: --- apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: -db-monitoring-secret spec: refreshInterval: 1h secretStoreRef: kind: SecretStore name: -db-monitoring-secretstore dataFrom: - extract: conversionStrategy: Default decodingStrategy: None key: /kubernetes/rds//monitoring metadataPolicy: None version: AWSCURRENT ``` Replace the placeholders: - `CLUSTER_NAME`: Aurora cluster name. - `AWS_REGION`: AWS region where the secret is stored. ### Option 3: Write a custom Alloy configuration file (advanced) Use this method to write the Alloy configuration yourself instead of generating it from the Configuration page. #### Add the Amazon Aurora PostgreSQL configuration blocks > Note > > For an Aurora cluster, configure Grafana Alloy separately for each DB instance and connect to its **instance endpoint**. Do not use the cluster (writer), reader, or custom endpoint because these endpoints can route connections to different instances. Using instance endpoints ensures metrics and logs are correctly correlated with each instance during role or topology changes. Add these blocks to Alloy for Amazon Aurora PostgreSQL. Replace ``. Create a `local.file` with the data source name string, for example, `"postgresql://:@:/?sslmode=require"`: Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```alloy local.file "postgres_secret_" { filename = "/var/lib/alloy/postgres_secret_" is_secret = true } prometheus.exporter.postgres "postgres_" { data_source_names = [local.file.postgres_secret_.content] enabled_collectors = ["stat_statements"] stat_statements { exclude_users = ["db-o11y", "rdsadmin"] exclude_databases = ["rdsadmin"] } autodiscovery { enabled = true // Exclude the rdsadmin database on Aurora database_denylist = ["rdsadmin"] } } database_observability.postgres "postgres_" { data_source_name = local.file.postgres_secret_.content forward_to = [loki.relabel.database_observability_postgres_.receiver] targets = prometheus.exporter.postgres.postgres_.targets enable_collectors = ["query_details", "query_samples", "schema_details", "explain_plans"] cloud_provider { aws { arn = "" } } } loki.relabel "database_observability_postgres_" { forward_to = [loki.write.grafana_cloud_loki.receiver] rule { target_label = "instance" replacement = "" } } discovery.relabel "database_observability_postgres_" { targets = database_observability.postgres.postgres_.targets rule { target_label = "job" replacement = "integrations/db-o11y" } // OPTIONAL: relabel `instance` to `dsn` before overwriting `instance`; // the `dsn` label is used in the integration with the knowledge graph rule { source_labels = ["instance"] target_label = "dsn" } rule { target_label = "instance" replacement = "" } } prometheus.scrape "database_observability_postgres_" { targets = discovery.relabel.database_observability_postgres_.output forward_to = [prometheus.remote_write.metrics_service.receiver] } ``` Replace the placeholders: - `DB_NAME`: Database name Alloy uses in component identifiers (appears in component names and secret filenames). - `AWS_AURORA_INSTANCE_ARN`: The specific Amazon Aurora instance Amazon Resource Name for cloud provider integration. Do not use the cluster Amazon Resource Name. - `INSTANCE_LABEL`: Value that sets the `instance` label on logs and metrics (optional). - Secret file content example: `"postgresql://:@:/?sslmode=require"`. - `DB_O11Y_USER`: The monitoring user you created and granted privileges to, for example, `db-o11y`. This name must also appear in `exclude_users`. - `DB_O11Y_PASSWORD`: Password for the database user. - `INSTANCE_ENDPOINT`: The specific DB instance endpoint. Do not use the cluster (writer), reader, or custom endpoint because these endpoints can route connections to different instances and break metric correlation. - `DB_PORT`: Database port number (default: `5432`). - `DB_DATABASE`: Logical database name in the DSN (recommend: use `postgres`). Find more about the options supported by the `database_observability.postgres` component in the [reference](/docs/grafana-cloud/send-data/alloy/reference/components/database_observability/database_observability.postgres/) documentation. #### Add processing of PostgreSQL logs (optional) Add processing of PostgreSQL logs to gather detailed metrics about query and server errors. The `logs` collector processes PostgreSQL logs received through the `logs_receiver` entry point. By default it counts server errors. When you enable per-query error processing, it also associates errors with the queries that caused them, which powers the per-query **Errors** views. ##### Configure `log_line_prefix` Configure `log_line_prefix` via your Aurora PostgreSQL DB cluster parameter group: 1. Open the Amazon RDS console → Parameter Groups 2. Create or modify the DB cluster parameter group attached to your cluster 3. Set `log_line_prefix` to: `%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a:` 4. Apply the parameter group to your Aurora cluster > Note > > Ensure [CloudWatch Logs export is enabled](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.CloudWatch.Publishing.html) for the PostgreSQL log on your Aurora cluster. Each instance in the cluster publishes its log to the cluster’s log group as a separate stream. ##### AWS Credentials The `otelcol.receiver.awscloudwatch` component requires AWS credentials. Configure with: - Environment variables: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION` - Docker: Mount `~/.aws` credentials or pass environment variables - Kubernetes: Use [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) or Kubernetes secrets Required IAM permissions: JSON ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "logs:FilterLogEvents", "logs:GetLogEvents", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/rds/cluster/*" // Place your log-group arn(s) here }] } ``` ##### Add logs processing configuration To capture per-query error telemetry, which powers the per-query **Errors** views, add a `logs` block to the `database_observability.postgres` component you defined earlier and set `enable_error_logs_processing` to `true`: Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```alloy logs { enable_error_logs_processing = true } ``` Without this block, log processing still produces the global error rate, but per-query error data isn’t collected. Add the logs processing configuration blocks with [`otelcol.receiver.awscloudwatch`](/docs/grafana-cloud/send-data/alloy/reference/components/otelcol/otelcol.receiver.awscloudwatch/). Add one copy of this pipeline for every Aurora DB instance you monitor. Identify a log stream prefix that matches only each DB instance. Don’t use the raw DB instance identifier when another instance identifier starts with the same value. Replace ``, ``, ``, ``, `` (matching the unique database name used for that instance in the main configuration above), and ``. Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```alloy // Storage for CloudWatch state persistence otelcol.storage.file "cloudwatch_" { directory = "/var/lib/alloy/storage" } // Fetch this DB instance's streams from the shared Aurora log group otelcol.receiver.awscloudwatch "aurora_logs_" { region = "" storage = otelcol.storage.file.cloudwatch_.handler logs { poll_interval = "1m" start_from = "" // Set this as close as possible to the start of the period you want to process groups { named { group_name = "/aws/rds/cluster//postgresql" prefixes = [""] } } } output { logs = [otelcol.processor.transform.aurora_logs_.input] } } // Set labels so the Loki exporter promotes them correctly otelcol.processor.transform "aurora_logs_" { log_statements { context = "log" statements = [ `set(attributes["instance"], "")`, `set(attributes["job"], "integrations/db-o11y")`, `set(attributes["loki.format"], "raw")`, `set(attributes["loki.attribute.labels"], "instance,job")`, ] } output { logs = [otelcol.exporter.loki.aurora_logs_.input] } } // Convert OTLP to Loki format otelcol.exporter.loki "aurora_logs_" { forward_to = [database_observability.postgres.postgres_.logs_receiver] } ``` > Note > > All instances in an Aurora cluster publish to the same `/aws/rds/cluster//postgresql` log group. Aurora appends suffixes such as `.0` and `.1` to each DB instance identifier when naming its streams. Each per-instance receiver must use a distinct `prefixes` value so that no stream matches more than one receiver. Overlapping prefixes ingest logs more than once and attribute them to the wrong instance. > Note > > `otelcol.receiver.awscloudwatch` is an experimental component. To enable and use an experimental component, you must run Alloy with `--stability.level=experimental`. > Note > > **Persistent storage:** The data path (`--storage.path`) must be persisted across restarts to maintain each `otelcol.storage.file` checkpoint. ##### Historical Log Processing The `logs` collector only processes logs with timestamps after the collector’s start time. This prevents re-counting historical logs when the source component replays old entries. **Behavior:** - On startup: Skips logs with timestamps before the collector started - Relies on the source component features to prevent duplicate log ingestion across restarts #### Add Prometheus and Loki write configuration Add the Prometheus remote write and Loki write configuration. From Grafana Cloud, open your stack to get the URLs and generate API tokens: Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```alloy prometheus.remote_write "metrics_service" { endpoint { url = sys.env("GCLOUD_HOSTED_METRICS_URL") basic_auth { password = sys.env("GCLOUD_RW_API_KEY") username = sys.env("GCLOUD_HOSTED_METRICS_ID") } } } loki.write "grafana_cloud_loki" { endpoint { url = sys.env("GCLOUD_HOSTED_LOGS_URL") basic_auth { password = sys.env("GCLOUD_RW_API_KEY") username = sys.env("GCLOUD_HOSTED_LOGS_ID") } } } ``` Replace the placeholders: - `GCLOUD_HOSTED_METRICS_URL`: Your Grafana Cloud Prometheus remote write URL. - `GCLOUD_HOSTED_METRICS_ID`: Your Grafana Cloud Prometheus instance ID (username). - `GCLOUD_HOSTED_LOGS_URL`: Your Grafana Cloud Loki write URL. - `GCLOUD_HOSTED_LOGS_ID`: Your Grafana Cloud Loki instance ID (username). - `GCLOUD_RW_API_KEY`: Grafana Cloud API token with write permissions. ## Verify telemetry in Grafana Cloud After Alloy starts, verify that Database Observability is receiving telemetry. 1. In Grafana Cloud, open **Database Observability**. 2. Go to **Configuration**. 3. Select **Telemetry status**. 4. Select your database instance. 5. Confirm that telemetry status checks pass. 6. Open **Queries overview** and confirm that query metrics appear. After telemetry appears, the database instance should be visible and Queries overview should show query metrics. Additional data such as query samples, wait events, schema details, and explain plans becomes available as Alloy collects it and as the database engine supports it. Telemetry can take a few minutes to appear. For detailed status checks, refer to [Verify telemetry status](/docs/grafana-cloud/monitor-applications/database-observability/configure/verify-telemetry-status/). ## Troubleshoot first-run issues If data doesn’t appear after setup: - If the database instance doesn’t appear in Database Observability, check Alloy connectivity and labels. - If telemetry status checks fail, use the Configuration page to identify the failed requirement. - If query metrics appear but samples, schema details, or explain plans are missing, check database privileges and `pg_stat_statements` settings. - If Alloy can’t connect to the database, check security groups, subnets, DNS, and the monitoring user’s host restrictions. For detailed guidance, refer to [Troubleshoot Alloy](/docs/grafana-cloud/monitor-applications/database-observability/troubleshoot/alloy/) or [Troubleshoot PostgreSQL](/docs/grafana-cloud/monitor-applications/database-observability/troubleshoot/postgres/). ## Next steps - [View query performance](/docs/grafana-cloud/monitor-applications/database-observability/monitor/view-query-performance/) - [Find your application’s queries](/docs/grafana-cloud/monitor-applications/database-observability/monitor/find-application-queries/) - [Link traces and queries](/docs/grafana-cloud/monitor-applications/database-observability/monitor/link-traces/) - [Analyze explain plans](/docs/grafana-cloud/monitor-applications/database-observability/investigate/analyze-explain-plans/)