ProxySQL is a high-performance SQL proxy designed to improve the performance and scalability of open source database systems. It is a MySQL-aware proxy server that can be used to improve the performance of database-driven web applications. ProxySQL also provides a wide range of features that can make it easier to manage and monitor your database environment.
The prerequisites for monitoring ProxySQL with Netdata are to have ProxySQL and Netdata installed on your system.
Netdata auto discovers hundreds of services, and for those it doesn’t turning on manual discovery is a one line configuration. For more information on configuring Netdata for ProxySQL monitoring please read the collector documentation.
You should now see the ProxySQL section on the Overview tab in Netdata Cloud already populated with charts about all the metrics you care about.
Netdata has a public demo space (no login required) where you can explore different monitoring use-cases and get a feel for Netdata.
This metric measures the total number of client connections to ProxySQL. Monitoring this metric can help identify performance bottlenecks due to too many concurrent connections. It can also help identify potential security issues, such as unauthorized access.
This metric measures the rate of client connections to ProxySQL. Monitoring this metric can help identify trends in usage and identify if the system is being overloaded. Tracking the rate of connection creation and connection abortions can help identify performance issues, such as slow or failing queries.
This metric measures the total number of server connections to ProxySQL. Monitoring this metric can help identify performance bottlenecks due to too many concurrent connections to the database server. It can also help identify potential security issues, such as unauthorized access.
This metric measures the rate of server connections to ProxySQL. Monitoring this metric can help identify trends in usage and identify if the system is being overloaded. Tracking the rate of connection creation, connection abortions, and connection delays can help identify performance issues, such as slow or failing queries.
This metric measures the total amount of traffic sent and received by ProxySQL to and from the backends. Monitoring this metric can help identify performance bottlenecks due to too much traffic. It can also help identify potential security issues, such as data leakage.
This metric measures the total amount of traffic sent and received by ProxySQL to and from the clients. Monitoring this metric can help identify performance bottlenecks due to too much traffic. It can also help identify potential security issues, such as data leakage.
This metric measures the total number of active client transactions on ProxySQL. Monitoring this metric can help identify performance bottlenecks due to too many concurrent transactions. It can also help identify potential security issues, such as unauthorized access.
This metric measures the rate of questions sent to the backends by ProxySQL. Monitoring this metric can help identify performance bottlenecks due to too many requests being sent to the backends. It can also help identify potential security issues, such as unauthorized access.
This metric measures the rate of queries that take longer than the defined query_timeout. Monitoring this metric can help identify performance bottlenecks due to slow queries. It can also help identify potential security issues, such as unauthorized access.
This metric measures the rate of all queries sent to the backends by ProxySQL. Monitoring this metric can help identify performance bottlenecks due to too many requests being sent to the backends. It can also help identify potential security issues, such as unauthorized access. By tracking the rate of autocommit, autocommit_filtered, commit_filtered, rollback, rollback_filtered, backend_change_user, backend_init_db, backend_set_names, frontend_init_db, frontend_set_names, and frontend_use_db queries, you can identify which specific queries may be causing performance issues.
Backend statements count is a metric that measures the number of queries sent to the backend database by ProxySQL. This metric can be broken down into two categories: total and unique. Total is the total number of queries sent to the backend database, while unique is the number of distinct queries sent to the backend database. By monitoring this metric, you can identify performance issues and/or bottlenecks in the backend database. Additionally, it may be useful to monitor this metric over time to see if the total number of queries is increasing too quickly, which could indicate a potential scalability issue.
Backend statements rate is the rate at which queries are sent to the backend database. This metric can be broken down into three categories: prepare, execute, and close. The prepare rate is the number of queries prepared for execution, the execute rate is the number of queries executed, and the close rate is the number of queries that are closed. Monitoring this metric can help identify potential performance issues or bottlenecks in the backend database. Additionally, this metric can be used to identify any sudden spikes in queries that could indicate a potential issue.
Client statements count is a metric that measures the number of queries sent to the client by ProxySQL. This metric can be broken down into two categories: total and unique. Total is the total number of queries sent to the client, while unique is the number of distinct queries sent to the client. By monitoring this metric, you can identify potential performance issues or bottlenecks in the client. Additionally, it may be useful to monitor this metric over time to see if the total number of queries is increasing too quickly, which could indicate a potential scalability issue.
Client statements rate is the rate at which queries are sent to the client by ProxySQL. This metric can be broken down into three categories: prepare, execute, and close. The prepare rate is the number of queries prepared for execution, the execute rate is the number of queries executed, and the close rate is the number of queries that are closed. Monitoring this metric can help identify potential performance issues or bottlenecks in the client. Additionally, this metric can be used to identify any sudden spikes in queries that could indicate a potential issue.
Cached statements count is a metric that measures the number of queries cached by ProxySQL. This metric is used to measure the effectiveness of ProxySQL’s query cache, which stores the results of frequently executed queries to reduce the load on the backend database. By monitoring this metric, you can identify performance issues and/or bottlenecks in the backend database. Additionally, it may be useful to monitor this metric over time to see if the number of queries being cached is increasing too quickly, which could indicate a potential scalability issue.
Query cache entries count is a metric that measures the number of entries stored in ProxySQL’s query cache. This metric is used to measure the size and effectiveness of ProxySQL’s query cache. By monitoring this metric, you can identify potential performance issues or bottlenecks in the query cache. Additionally, this metric can be used to identify any sudden spikes in query cache entries, which could indicate a potential issue.
Query cache memory used is a metric that measures the amount of memory used by ProxySQL’s query cache. This metric is used to measure the effectiveness of ProxySQL’s query cache. By monitoring this metric, you can identify potential performance issues or bottlenecks in the query cache. Additionally, this metric can be used to identify any sudden spikes in memory usage, which could indicate a potential issue.
Query cache IO is a metric that measures the amount of input/output (I/O) activity performed by ProxySQL’s query cache. This metric is used to measure the effectiveness of ProxySQL’s query cache. By monitoring this metric, you can identify potential performance issues or bottlenecks in the query cache. Additionally, this metric can be used to identify any sudden spikes in I/O activity, which could indicate a potential issue.
Query cache requests rate is a metric that measures the rate at which requests are made to ProxySQL’s query cache. This metric can be broken down into three categories: read, write, and read_success. The read rate is the number of requests made to read from the query cache, the write rate is the number of requests made to write to the query cache, and the read_success rate is the number of requests made to read from the query cache that succeeded. By monitoring this metric, you can identify potential performance issues or bottlenecks in the query cache. Additionally, this metric can be used to identify any sudden spikes in requests, which could indicate a potential issue.
MySQL Monitor Workers Count is a metric that measures the number of worker threads used by ProxySQL’s MySQL Monitor. This metric can be broken down into two categories: workers and auxiliary. Workers are the threads used to monitor the backend databases, while the auxiliary threads are used to manage other tasks. By monitoring this metric, you can identify potential performance issues or bottlenecks in the MySQL Monitor. Additionally, this metric can be used to identify any sudden spikes in the number of worker threads, which could indicate a potential issue.
MySQL Monitor Workers Rate is a metric that measures the rate at which worker threads are started by ProxySQL’s MySQL Monitor. This metric is used to measure the effectiveness of the MySQL Monitor. By monitoring this metric, you can identify potential performance issues or bottlenecks in the MySQL Monitor. Additionally, this metric can be used to identify any sudden spikes in the rate of worker thread starts, which could indicate a potential issue.
MySQL Monitor Connect Checks Rate is a metric that measures the rate at which connection checks are performed by ProxySQL’s MySQL Monitor. This metric can be broken down into two categories: succeed and failed. The succeed rate is the number of connection checks that succeeded, while the failed rate is the number of connection checks that failed. By monitoring this metric, you can identify potential performance issues or bottlenecks in the MySQL Monitor. Additionally, this metric can be used to identify any sudden spikes in connection checks, which could indicate a potential issue.
MySQL Monitor Ping Checks Rate is a metric that measures the rate at which ping checks are performed by ProxySQL’s MySQL Monitor. This metric can be broken down into two categories: succeed and failed. The succeed rate is the number of ping checks that succeeded, while the failed rate is the number of ping checks that failed. By monitoring this metric, you can identify potential performance issues or bottlenecks in the MySQL Monitor. Additionally, this metric can be used to identify any sudden spikes in ping checks, which could indicate a potential issue.
MySQL Monitor Read Only Checks Rate is a metric that measures the rate at which read-only checks are performed by ProxySQL’s MySQL Monitor. This metric can be broken down into two categories: succeed and failed. The succeed rate is the number of read-only checks that succeeded, while the failed rate is the number of read-only checks that failed. By monitoring this metric, you can identify potential performance issues or bottlenecks in the MySQL Monitor. Additionally, this metric can be used to identify any sudden spikes in read-only checks, which could indicate a potential issue.
MySQL Monitor Replication Lag Checks Rate is a metric that measures the rate at which replication lag checks are performed by ProxySQL’s MySQL Monitor. This metric can be broken down into two categories: succeed and failed. The succeed rate is the number of replication lag checks that succeeded, while the failed rate is the number of replication lag checks that failed. By monitoring this metric, you can identify potential performance issues or bottlenecks in the MySQL Monitor. Additionally, this metric can be used to identify any sudden spikes in replication lag checks, which could indicate a potential issue.
Jemalloc Memory Used is a metric that measures the amount of memory used by ProxySQL’s jemalloc allocator. This metric can be broken down into six categories: active, allocated, mapped, metadata, resident, and retained. The active memory is the amount of memory currently in use, allocated is the amount of memory allocated, mapped is the amount of memory mapped to a file, metadata is the amount of memory used for metadata, resident is the amount of memory that is resident in physical memory, and retained is the amount of memory that is retained in physical memory. By monitoring this metric, you can identify potential performance issues or bottlenecks in the jemalloc allocator. Additionally, this metric can be used to identify any sudden spikes in memory usage, which could indicate a potential issue.
Memory used is a metric that measures the amount of memory used by ProxySQL for various components. This metric can be broken down into the following categories: auth, sqlite3, query_digest, query_rules, firewall_users_table, firewall_users_config, firewall_rules_table, firewall_rules_config, mysql_threads, admin_threads, and cluster_threads. By monitoring this metric, you can identify potential performance issues or bottlenecks in the various components of ProxySQL. Additionally, this metric can be used to identify any sudden spikes in memory usage, which could indicate a potential issue.
Uptime is a metric that measures the amount of time that ProxySQL has been running. This metric is used to measure the availability of ProxySQL. By monitoring this metric, you can identify potential performance issues or bottlenecks in ProxySQL. Additionally, this metric can be used to identify any sudden drops in uptime, which could indicate a potential issue.
Monitoring the mysql_command_execution_rate can help identify any issues with the database server performance. It is the rate at which commands are being executed on the server and should be monitored in order to ensure that the database is responding optimally. If the rate is too high, it could indicate a bottleneck in the system and may need to be addressed.
Monitoring the mysql_command_execution_time can help identify any potential issues related to the execution of SQL commands on the server. It is the time taken to execute a given command on the server and should be monitored in order to ensure that the commands are being executed within an acceptable timeframe. If the time taken to execute a command is too high, it could indicate a bottleneck in the system and may need to be addressed.
Monitoring the mysql_command_execution_duration can help identify any potential issues related to the execution of SQL commands on the server. It is the duration of the command execution on the server and should be monitored in order to ensure that the commands are being executed within an acceptable timeframe. If the duration of the command execution is too high, it could indicate a bottleneck in the system and may need to be addressed.
Monitoring the mysql_user_connections_utilization can help identify any potential issues related to user connections to the server. It is the percentage of user connections that are in use on the server and should be monitored in order to ensure that the system is not overburdened. If the utilization rate is too high, it could indicate that the server is overloaded and may need to be scaled to address the issue.
Monitoring the mysql_user_connections_count can help identify any potential issues related to user connections to the server. It is the number of user connections that are in use on the server and should be monitored in order to ensure that the system is not overburdened. If the number of user connections is too high, it could indicate that the server is overloaded and may need to be scaled to address the issue.
Monitoring the backend_status can help identify any potential issues related to the backend connection. It is the status of the backend connection and should be monitored in order to ensure that the connection is online and functioning properly. If the status is offline, it could indicate an issue with the backend connection and may need to be addressed.
Monitoring the backend_connections_usage can help identify any potential issues related to the number of connections to the backend. It is the number of connections that are in use on the backend and should be monitored in order to ensure that the system is not overburdened. If the usage is too high, it could indicate that the backend is overloaded and may need to be scaled to address the issue.
Monitoring the backend_connections_rate can help identify any potential issues related to the rate of connections attempted to the backend. It is the rate of connections attempted to the backend and should be monitored in order to ensure that the connection is being attempted within an acceptable timeframe. If the rate is too high, it could indicate a bottleneck in the system and may need to be addressed.
Monitoring the backend_queries_rate can help identify any potential issues related to the rate of queries executed on the backend. It is the rate of queries executed on the backend and should be monitored in order to ensure that the queries are being executed within an acceptable timeframe. If the rate is too high, it could indicate a bottleneck in the system and may need to be addressed.
Monitoring the backend_traffic can help identify any potential issues related to the amount of traffic to and from the backend. It is the amount of traffic sent and received from the backend and should be monitored in order to ensure that the traffic is within an acceptable level. If the traffic is too high, it could indicate a bottleneck in the system and may need to be addressed.
Monitoring the backend_latency can help identify any potential issues related to the latency of requests to the backend. It is the time taken for the backend to respond to requests and should be monitored in order to ensure that the latency is within an acceptable level. If the latency is too high, it could indicate a bottleneck in the system and may need to be addressed.