Monitor GCP Memorystore for Redis Metrics in SigNoz

The Memorystore for Redis integration brings instance metrics (uptime, CPU, memory, clients, cache hit ratio, keyspace, and command latency) into SigNoz, with a pre-built dashboard for the service.

Memorystore publishes its metrics to Cloud Monitoring, and SigNoz reads them through the OpenTelemetry Collector running in your GCP project.

This page covers Memorystore for Redis (the redis.googleapis.com/* metrics on redis_instance resources). Memorystore for Redis Cluster publishes a different metric set and is not covered here.

Choose a setup method

Available now. You run the OpenTelemetry Collector in your own GCP project and add Memorystore metrics to its configuration. You control which metrics are pulled and how often.

Complete the GCP integration setup once, then follow the steps on this page for each project that hosts Redis instances.

Prerequisites

Before configuring this service, complete the shared GCP integration setup:

Your GCP account is connected in SigNoz, and the project running your Redis instances is in Projects to Monitor.
The OpenTelemetry Collector is deployed and running.
The signoz-integration service account has roles/monitoring.viewer on the project that hosts the instances. See Create a service account.
The Cloud Monitoring API is enabled in that project.

Step 1: Enable the service in SigNoz

In SigNoz, go to Integrations > Google Cloud Platform.
Select GCP Memorystore for Redis from the service list.
Toggle Metric Collection on to activate the pre-built dashboard.
Open the Data Collected tab and note the metrics listed there. These are the metrics the dashboard's panels query.

Enabling the toggle does not start collection on its own. The metrics that reach SigNoz are exactly the ones in your Collector's metrics_list. If you skip a metric in step 2, its dashboard panel stays empty.

Step 2: Add the metrics to your Collector config

Open the otel-collector-config.yaml you created in Deploy the Collector and add the Memorystore metric names to the metrics_list of the googlecloudmonitoring receiver for the project your instances run in. Only the metrics_list shown below changes; leave the rest of the file as is:

receivers:
  googlecloudmonitoring:
    project_id: "<monitored-project-id>"
    collection_interval: 300s   # 5 minutes; minimum is 60s
    metrics_list:
      # Availability
      - metric_name: "redis.googleapis.com/server/uptime"
      # Compute and memory
      - metric_name: "redis.googleapis.com/stats/cpu_utilization_main_thread"
      - metric_name: "redis.googleapis.com/stats/memory/usage_ratio"
      - metric_name: "redis.googleapis.com/stats/memory/system_memory_usage_ratio"
      # Clients
      - metric_name: "redis.googleapis.com/clients/connected"
      - metric_name: "redis.googleapis.com/clients/blocked"
      - metric_name: "redis.googleapis.com/stats/reject_connections_count"
      # Keyspace and cache effectiveness
      - metric_name: "redis.googleapis.com/keyspace/keys"
      - metric_name: "redis.googleapis.com/stats/cache_hit_ratio"
      # Commands
      - metric_name: "redis.googleapis.com/commands/calls"
      - metric_name: "redis.googleapis.com/commands/usec_per_call"

Verify these values:

<monitored-project-id>: The GCP project that hosts your Redis instances. It must be one of the entries in your Projects to Monitor list.

If your instances span several projects, add one named receiver per project (googlecloudmonitoring/<name>) and list them all in the metrics pipeline. See Configure multiple projects.

Step 3: Apply the configuration

The Collector loads its config from the signoz-collector-config secret, so a config change needs a new secret version and a redeploy:

Save your updated otel-collector-config.yaml.
Add a new secret version (step 2 of Deploy the Collector).
Redeploy the Cloud Run service (step 3).

Validate

Wait one or two collection intervals (up to about 5 minutes with the default 300s).
In SigNoz, go to Dashboards and open the Memorystore for Redis dashboard. Panels should start filling in.
To check a single metric, open Metrics Explorer and query redis.googleapis.com/stats/memory/usage_ratio.

What's collected

Metrics

See the Data Collected tab in the SigNoz integration for the definitive list the dashboard uses, and the GCP metrics list for full definitions.

Metric name	Unit	Type
`redis.googleapis.com/server/uptime`	Seconds	Gauge
`redis.googleapis.com/stats/cpu_utilization_main_thread`	Seconds	Sum
`redis.googleapis.com/stats/memory/usage_ratio`	None	Gauge
`redis.googleapis.com/stats/memory/system_memory_usage_ratio`	None	Gauge
`redis.googleapis.com/clients/connected`	Count	Gauge
`redis.googleapis.com/clients/blocked`	Count	Gauge
`redis.googleapis.com/stats/reject_connections_count`	Count	Sum
`redis.googleapis.com/keyspace/keys`	Count	Gauge
`redis.googleapis.com/stats/cache_hit_ratio`	None	Gauge
`redis.googleapis.com/commands/calls`	Count	Sum
`redis.googleapis.com/commands/usec_per_call`	Microseconds	Gauge

Troubleshooting

A dashboard panel is empty. The metric backing that panel is missing from your metrics_list. Compare the Data Collected tab against your otel-collector-config.yaml, add what's missing, and repeat step 3.

No Memorystore metrics at all. Confirm the signoz-integration service account holds roles/monitoring.viewer on the project in project_id, and that the Cloud Monitoring API is enabled there. Then check the Cloud Run logs for googlecloudmonitoring receiver errors.

Cache hit ratio looks wrong right after a restart. The ratio is derived from counters that reset when the instance restarts. Check server/uptime before reading too much into a sudden change.

Next steps

Create alerts on memory usage ratio approaching eviction, rejected connections, or a falling cache hit ratio.
Build custom dashboards to correlate cache behavior with application latency.
Monitor Cloud SQL for PostgreSQL if your stack also uses a managed database.

Get Help

If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack. If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.