New Observability Tables in ProxySQL 3.0.7: stats_proxysql_global and stats_tls_certificates

Monitoring TLS certificates has historically required either external tooling or manual inspection of ProxySQL’s configuration. ProxySQL 3.0.7 introduces two new statistics tables that bring certificate lifecycle management directly into the admin interface.

The Problem

Operators need to answer questions like:

When do my certificates expire?
Was the last TLS reload successful?
Which certificate file is currently loaded?
How many times has TLS been reloaded since startup?

Before 3.0.7, the only way to check certificate expiry was to inspect the files on disk using openssl. There was no programmatic way to query ProxySQL’s TLS state from within the admin interface.

`stats_proxysql_global`

This new table collects global proxy-level metrics that are not specific to any database protocol. In 3.0.7, it is focused on TLS state:

Admin> SELECT * FROM stats.stats_proxysql_global;
+--------------------------+------------------------------------------+
| Variable_Name            | Variable_Value                           |
+--------------------------+------------------------------------------+
| TLS_Load_Count           | 3                                        |
| TLS_Last_Load_Timestamp  | 1712345678                               |
| TLS_Last_Load_Result     | SUCCESS                                  |
| TLS_Server_Cert_File     | /etc/proxysql/server-cert.pem            |
| TLS_CA_Cert_File         | /etc/proxysql/ca-cert.pem                |
| TLS_Key_File             | /etc/proxysql/server-key.pem             |
+--------------------------+------------------------------------------+

Key Variables

Variable	Description
`TLS_Load_Count`	Number of TLS load or reload operations since startup
`TLS_Last_Load_Timestamp`	Unix timestamp of the most recent TLS load attempt
`TLS_Last_Load_Result`	`NONE` (not yet loaded), `SUCCESS`, or `FAILED`
`TLS_Server_Cert_File`	Path to the server TLS certificate
`TLS_CA_Cert_File`	Path to the CA certificate
`TLS_Key_File`	Path to the private key

The TLS_Last_Load_Result variable is particularly useful for automated monitoring. A value of FAILED immediately signals that the last certificate reload did not succeed, allowing alerting systems to detect TLS configuration problems.

`stats_tls_certificates`

This table provides detailed information about the currently loaded certificates:

Admin> SELECT cert_type, subject_cn, issuer_cn,
              not_after, days_until_expiry
       FROM stats.stats_tls_certificates;
+-----------+------------+------------+-------------------------+-------------------+
| cert_type | subject_cn | issuer_cn  | not_after               | days_until_expiry |
+-----------+------------+------------+-------------------------+-------------------+
| server    | proxysql   | proxysqlCA | Mar 10 12:00:00 2027 GMT | 339              |
| ca        | proxysqlCA | proxysqlCA | Mar 10 12:00:00 2027 GMT | 339              |
+-----------+------------+------------+-------------------------+-------------------+

Table Schema

Field	Type	Description
`cert_type`	VARCHAR	Certificate type: `server` or `ca`
`file_path`	VARCHAR	File system path to the certificate
`subject_cn`	VARCHAR	Common Name from the certificate subject
`issuer_cn`	VARCHAR	Common Name from the certificate issuer
`serial_number`	VARCHAR	Serial number of the certificate
`not_before`	VARCHAR	Start of validity period
`not_after`	VARCHAR	End of validity period (expiration)
`days_until_expiry`	INT	Days until the certificate expires
`sha256_fingerprint`	VARCHAR	SHA-256 fingerprint for identification
`loaded_at`	INT	Unix timestamp when loaded

The days_until_expiry field makes it straightforward to set up alerts. For example, to check if any certificate is expiring within 30 days:

Admin> SELECT cert_type, subject_cn, days_until_expiry
       FROM stats.stats_tls_certificates
       WHERE days_until_expiry < 30;

Design Decisions

Why not `stats_mysql_global`?

Earlier versions of ProxySQL tracked some TLS metrics in stats_mysql_global. This was problematic because TLS configuration applies to the entire proxy, not just MySQL. In hybrid MySQL/PostgreSQL deployments, having TLS metrics in a MySQL-specific table was confusing.

The new stats_proxysql_global table provides a protocol-neutral home for these metrics. The initial table name was stats_global, but we renamed it to stats_proxysql_global because the short name caused substring collision issues in ProxySQL’s admin table resolution (stats_global matched as a prefix of stats_mysql_global and stats_pgsql_global).

Why query-time population?

Both tables are populated at query time rather than maintained continuously. This means there is zero runtime overhead when you are not actively querying them, and the data is always current.

Integration with Monitoring Systems

These tables can be queried by any monitoring system that supports the MySQL protocol. For Prometheus-based monitoring, you can use the REST API or a custom exporter to scrape these tables at regular intervals.

A practical approach for certificate expiration alerting:

# Check if any certificate expires within 30 days
mysql -u admin -padmin -h 127.0.0.1 -P6032 -e \
  "SELECT cert_type, subject_cn, days_until_expiry
   FROM stats.stats_tls_certificates
   WHERE days_until_expiry < 30" \
  | grep -v "cert_type" && echo "ALERT: Certificate expiring soon"

For more details, see the stats_proxysql_global and stats_tls_certificates documentation.