> ## Documentation index > Fetch the complete documentation index at: https://upstash.com/docs/llms.txt > Ask it with GET https://upstash.com/docs/ask?q=. Short keywords rank best. > Use these to discover all available pages before exploring further. > Feature requests: https://upstash.com/docs/common/help/feature-requests.md lists what users asked for and how to vote for a request or add one. > Page rating: `GET https://upstash.com/docs/feedback?path=/docs/redis/integrations/prometheus&helpful=true` (or `false`) records whether this page helped. An optional `comment` (URL-encoded, at most 500 characters) says what was missing or wrong. It is anonymous and needs no key. Comments hold no code, secrets or personal data. # Prometheus - Upstash Redis Integration To monitor your Upstash database in Prometheus and visualize metrics in Grafana, follow these steps: **Integration Scope** Upstash Prometheus Integration covers Pro databases, databases included in the Enterprise Plan, and databases with the Production Pack. ## **Step 1: Log in to Your Upstash Account** 1. Open your web browser and navigate to [Upstash](https://console.upstash.com/). 2. Navigate to the main dashboard, where you’ll see a list of your databases. ## **Step 2: Select your Database** 1. Select the database you want to integrate with Prometheus. 2. This will open the database settings, where you can manage various configuration options for your selected database. ![configuration.png](/img/prometheus/configuration.png) 3. Enable Prometheus by toggling the switch. This allows you to monitor metrics related to your Upstash database performance, usage, and other key metrics. ## **Step 3: Connect Accounts** 1. After enabling Prometheus, a monitoring token is generated and displayed. 2. Copy this token. This token is unique to your database and is required to authenticate Prometheus with the Upstash metrics endpoint. **Header Format** You should add monitoring token according to this format `Bearer ` ![monitoring-token.png](/img/prometheus/monitoring-token.png) ## **Step 4: Set Up Prometheus Connection** ### **Grafana Dashboard Setup** 1. Open your Grafana instance, navigate to the Data Sources section, and select Prometheus as the data source. ![datasource.png](/img/prometheus/datasource.png) 2. Enter the data source name, set `https://api.upstash.com/monitoring/prometheus` as the data source address, and then add your monitoring token in the HTTP Headers section. ![headers.png](/img/prometheus/headers.png) 3. Then, click Test and Save to verify that the data source is working properly. ![datasource-final.png](/img/prometheus/datasource-final.png) ### **Prometheus Federation Setup** Federation lets your Prometheus pull metrics from Upstash’s API and store them in **your own** Prometheus instance, so Grafana can query your Prometheus instead of hitting the Upstash endpoint directly. #### When to use federation - You already run Prometheus and want to persist Upstash metrics locally. - You want to control retention, recording rules, or alerts on Upstash metrics 1. Set up a new scrape job in your Prometheus configuration file (`prometheus.yml`): ```yaml scrape_configs: # Federation job: pull from Upstash API - job_name: "federate_upstash" honor_labels: true metrics_path: "/monitoring/prometheus/federate" scheme: https params: match[]: - 'upstash_db_metrics{}' static_configs: - targets: - "api.upstash.com" authorization: type: Bearer credentials: "" ``` This configuration assumes you want to pull all metrics. You can adjust the `match[]` parameter to filter specific metrics if needed. - `upstash_db_metrics{database_id="your_database_id"}` can be used to pull metrics for a specific database - `upstash_db_metrics{replica_id=~"us-east-1.*"}` can be used to pull metrics for replicas in a specific region 2. Verify the Federation Target - Reload (or restart) your Prometheus server to apply the new configuration. - Visit **Prometheus → Status → Targets** and confirm `federate_upstash` is **UP** ## **Step 5: Wait for Metrics Availability** To visualize your Upstash metrics, you can use a pre-built Grafana dashboard. Select your Prometheus data source when prompted, and complete the import. Please check this address to access Upstash Grafana Dashboard Dashboard ![grafana-dashboard.png](/img/prometheus/grafana-dashboard.png) ## **Available Metrics** Every series is named `upstash_db_metrics` and carries the labels `database_id`, `database_name`, `account_id`, `replica_id` and `metric_name`. Query one metric by its `metric_name` label, for example `upstash_db_metrics{metric_name="daily_processed_commands"}`. A database with several replicas reports one series per replica; sum or take the max over `replica_id` as the metric suggests. Metrics counted by the Upstash proxies carry `replica_id="proxy-"`, one series per region of proxies. Latencies are in nanoseconds and describe the last ten minutes. Daily counters reset at midnight UTC, monthly counters at the start of the month, and totals since the database started. | `metric_name` | What it measures | |---|---| | `persistence_entry_count` | Number of keys | | `total_data_size` | Data size on disk, bytes | | `total_processed_commands` | Commands processed since start | | `daily_processed_commands`, `daily_read_commands`, `daily_write_commands` | Commands today, and the read and write share | | `monthly_read_commands`, `monthly_write_commands` | Commands this month by type | | `monthly_processed_console_commands` | Commands issued from the console this month, not billed | | `non_billable_commands` | Commands excluded from billing | | `daily_rest_commands` | Commands received over REST today | | `command_` | Executions of each command today, for example `command_GET` | | `daily_used_bandwidth`, `daily_bandwidth_ingress`, `daily_bandwidth_egress` | Bandwidth today, total and by direction, bytes | | `monthly_used_bandwidth` | Bandwidth this month, bytes | | `current_client_count`, `total_client_count` | Open TCP connections, and connections opened since start | | `rest_conn_count` | Open REST connections | | `total_hits`, `total_misses` | Key hits and misses since start | | `simple_service_latency_p50`, `_p90`, `_p99` | Simple service latency: server time from reading a request to writing its response, for requests where every command is a single-key read or write; multi-key commands, scripts and cross-region requests are excluded | | `read_service_latency_p50`, `_p99`, `_p99_9` | Read request latency | | `write_service_latency_p50`, `_p99`, `_p99_9` | Write request latency | | `command_latency_p50`, `_p99` | Time the engine spent executing commands, excluding network and queueing | | `wait_latency_p99` | Time commands waited for the execution lock | | `replication_latency_p99_9` | Time writes were held because of replication: waiting for the backup to acknowledge, or backpressure while a replica catches up | | `replication_backup_lag` | Updates written on the primary that have not yet been sent to the replica | | `lua_latency_p50`, `_p99`, `_p99_9`, `_p99_99` | Lua script execution latency | | `daily_script_commands`, `daily_commands_in_scripts` | Script executions today, and the commands they ran | | `lua_script_count`, `lua_script_failures`, `lua_script_timeouts`, `lua_script_memory_limits` | Scripts tracked today, and how many runs failed, timed out or hit the memory limit | | `throttled_commands` | Writes delayed today because persistence was falling behind | | `auth_failures`, `rest_auth_failures` | Refused authentications over TCP and REST, and commands sent before authenticating, since the database started. REST requests over the rate limit are counted in `rest_auth_failures` as well | | `tcp_over_size_requests`, `rest_over_size_requests` | Requests rejected for exceeding the request size limit today | | `over_size_record_accesses` | Accesses to keys above the record size limit today | | `monitor_count`, `monitored_commands` | Clients running MONITOR, and commands they observed | | `keyspace_notifications` | Keyspace notifications sent since start | | `inmemory_memory_expired_entry_count`, `persistence_expired_entry_count` | Keys removed because their TTL passed since start, in memory and on disk | | `slow_command_`, `slow_command_count_` | Commands that took 500 milliseconds or longer today: the slowest run in nanoseconds and how often it happened, for example `slow_command_count_KEYS` | | `proxy_undeliverable` | Requests and connections the proxies of a region could not hand to any replica today | ## **Conclusion** You've now integrated your database with Upstash Prometheus, providing access to improved monitoring and analytics. Feel free to explore Upstash's features and dashboards to gain deeper insights into your system's performance. If you encounter any issues or have questions, please refer to the Upstash support documentation or contact our support team for assistance.