Introducing HTTP server in ProxySQL 1.4.4
ProxySQL exports a lot of metrics, all visible in the stats
schema and queryable using any client that uses the MySQL protocol.
This allows to ingest metrics into external monitoring tools, like Percona PMM, grafana, Severalnines ClusterControl, graphite, datadog, and others already existing or being under development.
Although we believe these monitoring tools are the preferred and right way to monitor ProxySQL, we often faced the issue that ProxySQL isn’t monitored while still being evaluated. This makes very difficult the troubleshooting of performance and behavior in such scenarios. In fact, it is common that users report issues, but without metrics it is often very difficult to distinguish between a real performance bug, or a misconfiguration, or even issues completely unrelated to ProxySQL.
For this reason, ProxySQL version 1.4.4 introduces a new and experimental interface: a web UI to export some metrics.
This feature doesn't replace all the statistics already available through the Admin interface, but facilitate the troubleshooting while ProxySQL is still being evaluated and metrics are not collected into an external software.
This feature is not final yet, only few metrics are available, and it is subject to changes in future.
The web UI also provides a simple dashboard that summarizes the overall configuration and status of ProxySQL itself.
Current metrics available are:
- System Metrics: related to CPU and memory utilization
- MySQL Metrics: related to number of MySQL connections in use (both frontends and backends), and connection pool efficiency
- Query Cache Metrics: related to Query Cache efficiency
Configure HTTP server
If you are familiar with ProxySQL, you already know that most of its configuration can be changed at runtime.
HTTP server is no different, and you can configure it, enable or disable it at runtime.
Currently there are only 2 variables related to HTTP server:
- admin-web_enabled to either enable or disable the feature (disabled by default)
- admin-web_port to specify the listening port
Internally we had a long exchange of opinions on whatever HTTP server should be enabled or disabled by default. Being a new functionality, and very useful, it made sense to enable it by default. Although security was a concern: even if doesn't allow to change the configuration of ProxySQL (it is a read-only interface that exports metrics), it can be potentially used to exploit unknown vulnerabilities.
For this reason we made HTTP server disabled by default (admin-web_enabled=false
).
If you want to access such metrics through the web interface, you can simple enable it by configuring admin-web_enabled=true
. For example:
SET admin-web_enabled='true';
LOAD ADMIN VARIABLES TO RUNTIME;
Similarly, to disable it:
SET admin-web_enabled='false';
LOAD ADMIN VARIABLES TO RUNTIME;
If you want to make the change persistent to disk, do not forget to run SAVE ADMIN VARIABLES TO DISK
.
A note on the above: the HTTP server is considered part of the Admin module, therefore after you change its variables you need to use LOAD ADMIN VARIABLES TO RUNTIME
to make the change effective, and issue SAVE ADMIN VARIABLES TO DISK
to persist them on disk.
Once HTTP server is enabled, you can point your browser to port 6080 (the default), for example http://127.0.0.0.1:6080
, and use admin-stats_credentials to login. For further security, we recommend to change the default admin-stats_credentials
.

Once you login, a dashboard with generic information is displayed:

From here, you can choose a category to get useful metrics.
The examples below show System statistics and MySQL Connections:

Statistics are collected even if HTTP server is nor running
Historical statistics to be exported in the web interface are being collected even if HTTP server is disabled.
In other words, when you enable HTTP server you will have access to statistics collected even when HTTP server was not enabled.
Statistics are stored in a new database file, named proxysql_stats.db
.
During the development of this new feature concerned were raised about the performance impact of this functionality, although we managed to make ProxySQL 1.4.4 even faster than ProxySQL 1.4.3!