Managing PostgreSQL databases across multiple servers can become difficult as an application grows. A database administrator may need to check CPU usage on one machine, investigate slow queries on another, and compare configuration settings across different environments.
Command-line tools such as psql, pg_stat_activity, and operating-system monitoring utilities are useful, but collecting information from several places takes time. Teams also need to understand which metrics matter before they can identify the cause of a performance problem.
AlloyDB Omni now provides a web-based interface for monitoring self-managed database clusters. The AlloyDB Omni Web UI brings system telemetry, query performance information, database configuration, and other diagnostic details into one place.
The interface reached general availability in October 2026 for supported Red Hat and container deployments. It is designed as a read-only monitoring interface, so administrators can inspect database health without using the dashboard to modify production configurations.
This article explains how to install the Web UI, connect PostgreSQL clusters, configure monitoring permissions, and use its dashboards to investigate common database problems.
What Is the AlloyDB Omni Web UI?
AlloyDB Omni is a downloadable, self-managed database distribution based on PostgreSQL. It allows organizations to run AlloyDB technology in their own infrastructure, including on-premises environments, edge locations, and multi-cloud deployments.
The Web UI provides a visual interface for observing these database installations.
Instead of switching between SQL queries, terminal commands, and monitoring dashboards, administrators can use the interface to inspect several areas of a cluster.
Dashboard | Information available |
|---|
Cluster overview | Cluster instances and available telemetry |
Databases | Database catalog information and database sizes |
System insights | CPU, memory, and disk I/O metrics |
Query insights | Query execution information and slow queries |
Database flags | Active database parameters and configuration differences |
Columnar engine | Columnar storage, memory usage, and scan statistics |
AlloyDB AI | Information about supported vector and AI-related features |
The available information depends on the deployment type and monitoring configuration.
For example, system charts are not available when connecting to a standalone container deployment because the required containerized monitoring agent is not available for that deployment type. Other supported dashboard features remain available.
How the Monitoring Architecture Works
The Web UI does not replace PostgreSQL or act as a database management system. It provides a separate interface for collecting and presenting diagnostic information.
A typical monitoring setup contains four components:
AlloyDB Omni runs the PostgreSQL database.
A monitoring agent exposes system metrics.
Prometheus collects and stores the exported metrics.
The Web UI connects to the database and monitoring endpoints to display information.
The database connection uses a limited monitoring account. The pg_monitor role provides access to PostgreSQL monitoring information without giving the dashboard general administrative privileges.
Prometheus is used for system telemetry. It collects metrics such as CPU consumption, memory allocation, and disk I/O.
Query insights use PostgreSQL statistics, including information collected by pg_stat_statements.
This separation is useful because database information and host-level metrics come from different sources. A slow query might be caused by an inefficient execution plan, while a high response time across many queries might indicate CPU pressure or storage contention.
Combining both views helps administrators investigate the problem more accurately.
Prepare the AlloyDB Omni Environment
Before installing the Web UI, make sure AlloyDB Omni is already installed and running.
You should also have:
Access to the Linux host or supported deployment environment.
Administrative permission to install the Web UI.
Network access between the Web UI, database, and Prometheus.
A database account for monitoring.
A Prometheus endpoint if system charts are required.
A secure password for protecting the Web UI's connection credentials.
The Web UI supports several deployment types, including standalone containers, Kubernetes, and RPM-based Linux installations.
The exact installation steps depend on the deployment. The following example uses an RPM-based Linux installation to demonstrate the setup.
Create a Limited Monitoring User
The Web UI needs a database account that can read monitoring information.
Connect to the AlloyDB Omni database using an administrator account and execute:
CREATE ROLE alloydbui
WITH LOGIN PASSWORD 'ReplaceWithAStrongPassword';
GRANT pg_monitor
TO alloydbui
WITH INHERIT TRUE;
Replace the example password with a strong password managed through your organization's secret-management process.
The pg_monitor role provides access to PostgreSQL monitoring views and functions. It is preferable to using a superuser account for routine dashboard access.
Some dashboard features need additional permissions.
For example, to display vector index information, the monitoring user needs permission to read pg_stat_ann_indexes.
GRANT SELECT
ON pg_stat_ann_indexes
TO alloydbui;
To display vector columns or columnar engine information, the account may also need appropriate permissions on the relevant tables.
Grant only the permissions required by the features you intend to use. Avoid giving the monitoring account broad access to application data merely to make every dashboard section visible.
Configure System Monitoring
The system monitoring agent exports metrics that Prometheus can collect.
For RPM-based installations, the AlloyDB Omni monitoring agent is available as a separate package.
If you use a custom PostgreSQL data directory, configure the monitoring service to point to the correct location.
Create a systemd override directory:
sudo mkdir -p \
/etc/systemd/system/alloydbomni_monitor.service.d
Create the override file:
sudo tee \
/etc/systemd/system/alloydbomni_monitor.service.d/override.conf \
<<'EOF'
[Service]
Environment="PG_DATA_DIR=/data"
EOF
In this example, /data is the database data directory. Replace it with the actual path used by your installation.
Reload systemd and restart the monitoring service:
sudo systemctl daemon-reload
sudo systemctl restart alloydbomni_monitor
Check whether the service is running:
sudo systemctl status alloydbomni_monitor
The monitoring agent exports metrics on port 9187 by default.
You can verify that the endpoint is responding with:
curl http://localhost:9187/metrics
If the command returns Prometheus-formatted metrics, the endpoint is exporting data.
A successful response does not necessarily mean every metric is available. Some hardware statistics require additional resource-accounting configuration on the AlloyDB Omni service.
Configure Prometheus
The Web UI uses Prometheus to display system telemetry.
Install and configure Prometheus in your environment, then configure a scrape target for the AlloyDB Omni monitoring endpoint.
A simplified Prometheus configuration looks like this:
scrape_configs:
- job_name: alloydb-omni
scrape_interval: 15s
static_configs:
- targets:
- "alloydb-host:9187"
Replace alloydb-host with the hostname or address of the database host that Prometheus can reach.
A 15-second scrape interval is a reasonable starting point. Google recommends configuring scrape intervals in the range of 15 to 30 seconds to collect statistics without unnecessarily increasing monitoring overhead.
Make sure that firewall rules allow Prometheus to reach the monitoring endpoint. Do not expose the metrics port publicly.
Once Prometheus is collecting metrics, the Web UI can use its endpoint to display the available system charts.
Install and Start the Web UI
For an RPM-based Linux installation, configure the AlloyDB Omni package repository using the repository information provided for your deployment.
After the repository is configured, install the Web UI package:
sudo dnf install alloydbomni_ui
The Web UI uses a Java Keystore to protect the encryption key used for saved database connection information.
Set a strong keystore password before starting the application:
export ALLOYDB_OMNI_UI_KEYSTORE="YourStrongKeystorePassword"
Start the Web UI:
/opt/alloydbomni/app/alloydb-ui/app/bin/alloydb
By default, the interface listens on port 9080.
Open the following address in a browser:
http://your-server-hostname:9080
Replace the hostname with the address of the machine running the Web UI.
The default interface uses HTTP and does not provide built-in TLS termination. For production environments, place it behind a reverse proxy configured with HTTPS certificates. Restrict access to authorized administrators through network controls and your organization's authentication practices.
The keystore password must remain consistent when reusing saved connection configuration. A mismatched password can prevent the application from decrypting stored connection information.
Connect a Database Cluster
After opening the Web UI, use the cluster selection screen to register a database connection.
Provide the connection details for the target cluster, including:
A descriptive cluster name.
Database hostname or IP address.
PostgreSQL port.
Database name.
Monitoring username.
Monitoring password.
Prometheus endpoint, where required.
Use the alloydbui account created earlier rather than a database superuser.
You can save multiple connection profiles for different environments.
For example:
Development:
alloydb-dev.internal
Staging:
alloydb-staging.internal
Production:
alloydb-prod.internal
This makes it easier to switch between environments during an investigation.
Be careful when saving production credentials. Restrict access to the configuration files and user accounts that store them.
Use the Dashboards to Investigate Performance Problems
Once the connection is established, the Web UI provides several views that help identify database issues.
System insights
System insights displays resource-related information such as CPU consumption, memory usage, and disk I/O.
Consider a situation where an application becomes slow during business hours.
If CPU consumption increases at the same time as application latency, the database host may be under resource pressure.
If disk I/O increases sharply, investigate storage activity, checkpoint behavior, and queries that read or write large amounts of data.
These metrics do not identify the exact cause by themselves. Use them to narrow the investigation.
Query insights
Query insights helps identify SQL statements that consume significant database resources.
It can show execution-related information such as query latency, call frequency, and slow query lists.
For example, a query executed thousands of times with a moderate execution time may consume more total database time than a query that runs once and takes longer.
You can investigate a statement using PostgreSQL's pg_stat_statements extension.
First, configure the required shared libraries and settings:
ALTER SYSTEM SET
shared_preload_libraries =
'google_columnar_engine,google_job_scheduler,google_storage,google_db_advisor,pg_stat_statements';
ALTER SYSTEM SET
pg_stat_statements.max = 10000;
ALTER SYSTEM SET
pg_stat_statements.track_utility = on;
ALTER SYSTEM SET
track_io_timing = on;
Create the extension in each database where you want query statistics:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
The shared-library configuration requires a database restart before it takes effect. Plan the restart carefully, particularly for production clusters.
Database flags
Database flags show active configuration settings and help administrators identify differences from default values.
For example, two database environments may use different memory-related settings. This can make performance comparisons difficult.
Use this dashboard to review configuration differences and compare them with your approved baseline.
The Web UI is read-only. If a setting needs to change, update it through the authoritative configuration process, such as a Kubernetes manifest, GitOps workflow, Ansible playbook, or the appropriate AlloyDB Omni administration tool.
Columnar engine insights
AlloyDB Omni includes a columnar engine for accelerating supported analytical workloads.
The Web UI can display information about columnar memory usage, table and column coverage, and scan execution statistics.
These details help administrators understand whether analytical workloads are benefiting from columnar storage.
If expected tables are not visible, check the monitoring user's permissions and confirm that the columnar engine has been configured.
Common Problems and Troubleshooting
System charts are empty
Check whether Prometheus is running and collecting metrics from the correct endpoint.
Verify the monitoring agent:
sudo systemctl status alloydbomni_monitor
Then check the metrics endpoint:
curl http://localhost:9187/metrics
Also verify that Prometheus can reach the database host and that the scrape target is healthy.
Remember that system charts are not available for standalone container deployments.
Query insights does not show useful information
Check whether pg_stat_statements is configured correctly.
Confirm that the extension exists in the database and that the required shared-library settings have been applied. A restart may be necessary after changing shared_preload_libraries.
Vector index information is missing
Check whether the monitoring user has permission to read pg_stat_ann_indexes.
GRANT SELECT
ON pg_stat_ann_indexes
TO alloydbui;
Also verify that the database contains the expected vector indexes.
Database connection fails
Check the hostname, port, database name, username, and password.
Confirm that network rules allow the Web UI host to reach the PostgreSQL endpoint. If the connection uses TLS, verify that the database and client settings are compatible.
Best Practices for Production Monitoring
A monitoring dashboard is most useful when it is part of a consistent operational process.
Keep separate connection profiles for development, staging, and production. Use a dedicated monitoring account with limited permissions, and rotate its credentials according to your security policy.
Configure Prometheus scrape intervals carefully and avoid collecting metrics more frequently than necessary.
Keep the Web UI behind HTTPS and restrict access to trusted users. Protect its configuration files because they can contain saved connection details.
Finally, establish a baseline for normal database behavior. CPU usage, query latency, and disk activity are easier to interpret when the team knows what is normal for its workload.
Summary
The AlloyDB Omni Web UI provides a visual way to monitor self-managed PostgreSQL clusters. It brings database information, system telemetry, query performance, configuration flags, and columnar engine diagnostics into one interface.
To use it effectively, configure a limited database monitoring account, install the monitoring agent where supported, connect Prometheus, and register the database cluster.
The dashboard can help identify resource pressure, expensive SQL statements, missing permissions, and configuration differences. However, it is a read-only diagnostic interface rather than a replacement for database administration tools.
Combining its dashboards with PostgreSQL statistics, application monitoring, and a consistent operational process gives database teams a clearer view of cluster health and performance.
Join the conversation! Your thoughts help the community grow.