1. Home
  2. Docs
  3. ClusterControl
  4. User Guide (GUI)
  5. PostgreSQL
  6. Query Monitoring

Query Monitoring

 

Query Monitor (version 2)

Since the release of ClusterControl 1.9.0, the Query Monitor v2 (version 2) has been introduced. It is our new feature that deploys agents for monitoring the database nodes, particularly the database queries. It is only available for MySQL and PostgreSQL database systems.

Features you can use with Query Monitor v2 are the following:

  • Install / remove query monitor agents on the db nodes.
  • Start / stop collecting query stats with the agents.
  • New ‘Query Workload’ overview showing query digests, latency, throughput, and concurrency with a scatter chart.
Attention

Starting from ClusterControl 1.9.7 (September 2023), ClusterControl GUI v2 is the default frontend graphical user interface (GUI) for ClusterControl. Note that the GUI v1 is considered a feature-freeze product with no future development. All new developments will be happening on ClusterControl GUI v2. See User Guide (GUI v2).

Query Monitor Agents

When you click the Install Query Monitor Agent button, ClusterControl will setup and install the agent to all of the database nodes assigned to the particular cluster.

 

The agent has the following configuration which you can find in /etc/cmnd.conf. This is for the agent configuration. Then under /etc/cmnd.d directory for the Top Query configuration. The agent configuration file /etc/cmnd.conf has all the details you can find here. By default, these are the following options that are set:

$ cat /etc/cmnd.conf | sed -e 's/#.*$//' -e '/^$/d' -e '/^$/N;/^\n$/D' | sed '/^\t*$/d'
[cmnd]
data_directory = "/var/lib/cmnd"
log_file = "/var/log/cmnd.log"
pid_file = "/var/run/cmnd.pid"
plugin_names = [
"libpluginMySql.so",
"libpluginSqlite.so",
"libpluginPgSql.so"
]
port = 4433
cert_file = "/etc/ssl/cmnd/cert.pem"
key_file = "/etc/ssl/cmnd/key.pem"

You can change the port to your desired port number based on the firewall policy you have in your organization. So take note, you need to have port 4433 open by default in order to make it work properly.

You can find more of its configuration files under these files/directories,

$ find /etc/ -name "cmn*"
/etc/ssl/cmnd
/etc/logrotate.d/cmnd
/etc/cmnd.conf
/etc/cmnd.d
/etc/cmn.passwd

The Query Monitor Agents are installed using systemd. So you can manage the init scripts with systemd to start and stop the service. To determine if the agents are running, you can do the following,

$ systemctl status cmon-daemon

or verify it with netstat just like below,

$ netstat -ntlvp46|grep cmnd
tcp 0 0 0.0.0.0:4433 0.0.0.0:* LISTEN 8456/cmnd

Query Monitoring Workflow

The agent collects samples from the pg_stat_statements. These metrics which is collected by a database client and sends the query inquiry to the agent. Then the agent that reads the input data and will produce the query statistics and makes it available to the Query Monitor v2 dashboard query metrics. That means, all collected information from the Query Monitoring shall depend upon the following  condition.

  1. The reply should be sent in a timely fashion no matter how big the input data is. Should the computer be very slow or the processing too complicated the query statistics should be produced and made available in a progressive manner so a responsive UI can be implemented.
    This means while the processing of the data happens the client program can access the data that is already processed.

  2. The agent should be able to update the query statistics on itself when the input data is updated by the database server. A simple query or RPC call is invoked so that the agent keeps to monitor the input data and keep the data be updated.

  3. The query statistics should be according to the query inquiry and the input data.
    In simpler words the produced statistical data should be in sync with the input data and the query the user sent. Some query statistics may be derived from the input data.

Overview (Beta)

For PostgreSQL, it requires pg_stat_statements to be enabled.  If you deploy your PostgreSQL cluster using ClusterControl, then you do not have this problem since pg_stat_statements shall be loaded or installed as a plugin extension by default. On the other hand, if you do not have this enabled, you cannot further use the capabilities that the Query Monitor v2 until this is enabled.

See also

For more details (including how to enable the pg_stat_statements, see this blog post, How to Identify PostgreSQL Performance Issues with Slow Queries

Once it is enabled, you are good to go and allowed to enable or install the agents.

To install the agents, click Install Query Monitor Agent button.

Using The Overview Dashboard

The Overview dashboard contains the following:

  • The drop down lists for the list of your PostgreSQL databases and time range that you can select.
  • The database metrics
    • The database metrics has the following:
      • Throughput which is based on Queries per-second/Query Count
      • Concurrency which is based on Lock time (in seconds)
      • Average Latency which is based on Average query time (s)/Average Latency
      • Errors which are all the database connectivity errors per second
  • The digest queries which contains the list of queries based on the following
    • a query fingerprint format listed under Digest field.
    • Schema
    • Count i.e. the number of queries being detected or found
    • Rows which contains the Sent, Examined, Affected sub-fields
    • Exec Time (Execution Time) with contains Average and Total sub-fields

Top Queries

This is an aggregated list of all your top queries running on all the nodes of your database cluster. The list can be ordered by Occurrence or Execution Time, to show the most common or slowest queries respectively. It is also possible to filter and review queries from one particular node.

You can see the explain the output of your queries by selecting a query in the list. Review the Settings → Query Monitor to configure what queries to log (e.g. only log queries that take more than 1 seconds to execute).

Settings

Configures the Query Monitor settings, as explained below:

Field Description
Long Query Time
  • Collects queries taking longer than Long Query Time seconds, for example:
    • 0.1 – Only queries taking more than 0.1 seconds will be accounted.
Log queries not using indexes?
  • Configures ClusterControl behavior on sampling queries without indexes:
    • Yes – Logs queries that are using indexes.
    • No – Ignores queries that are not using indexes (will not be accounted for in ClusterControl → Query Monitor → Query Outliers).
[/su_box]

Top Queries Table

This page is auto-refresh every 30 seconds. You can change the refresh rate by clicking on the Refresh rate dropdown at the top right. The following describes the Top Queries table columns:

Field  Description
Query
  • List of sampled queries.
DB
  • Database name.
Count
  • A total number of query occurrences.
Rows
  • Total rows involved:
    • Sent – The number of rows PostgreSQL returned.
    • Examined – The number of rows PostgreSQL believes it must examine to execute the query.
Tmp tables
  • The number of temporary tables created for this query, on RAM or on disk.
Exec Time
  • Execution time in microseconds of:
    • Max – Maximum execution time.
    • Avg – Average execution time.
    • Stdev – Standard deviation time.
Total Exec Time
  • The total amount of execution time of:
    • Absolute – Total execution time of the query.
    • Relative – Percentage of the query execution time over total time.
[/su_box]

Running Queries

View current running queries on your database nodes similar to select * from pg_stat_activity the command in PostgreSQL. You can stop a running query by selecting to kill the connection that started the query. The process list can be filtered out by the host.

This page is auto-refresh every 30 seconds. You can change the refresh rate by clicking on the arrow beside the green Refresh button.

Field  Description
Host
  • IP address or hostname of the instance.
DB
  • Name of the database this backend is connected to.
User
  • PostgreSQL user.
Client
  • The IP address of the client connected to this backend. If this field is null, it indicates either that the client is connected via a Unix socket on the server machine or that this is an internal process such as auto-vacuum.
Query
  • Text of this backend’s most recent query. If the state is active this field shows the currently executing query. In all other states, it shows the last query that was executed.
State
  • Current overall state of this backend. Possible values are:
    • active: The backend is executing a query.
    • idle: The backend is waiting for a new client command.
    • idle in the transaction: The backend is in a transaction but is not currently executing a query.
    • idle in transaction (aborted): This state is similar to idle in the transaction, except one of the statements in the transaction caused an error.
    • fast-path function call: The backend is executing a fast-path function.
    • disabled: This state is reported if track_activities is disabled in this backend.

Query Outliers

Shows queries that are outliers. An outlier is a query taking a longer time than the normal query of that type. Use this feature to filter out the outliers for a certain time period. After a number of samples and when ClusterControl has had enough stats, it can determine if latency is higher than normal (2 sigmas + average_query_time) then it is an outlier and will be added into the Query Outlier.

This feature is dependent on the Top Queries feature above. If Query Monitoring is enabled and Top Queries are captured and populated, the Query Outliers will summarize these and provide a filter based on timestamp. You can view the query history as old as one year ago.

Field  Description
Time
  • The exact time when the query is captured.
Query
  • The SQL query.
Query Time
  • Query’s execution time in microseconds.
Avg Query Time
  • Query’s average execution time in microseconds.
Stdev
  • Query’s standard deviation execution time in microseconds.
Max Query Time
  • Query’s maximum execution time in microseconds.
Max Lock Time
  • Query’s lock time in microseconds.

Query Statistics

Note

This feature is introduced in v1.7.1.

Views advanced query statistics of individual PostgreSQL server. Some statistics are collected per database-level and some are server-wide, as explained in the following table:

Statistics Description
Access by sequential or index scans Identify whether tables are being accessed by sequential scans or index scans.
Table I/O statistics Table I/O statistics. The ratio of heap blocks read from memory vs Disk I/O for a given table.
Index I/O statistics Disk I/O for every index on a table.
Database wide statistics Server-wide database statistics like Datname, Numbackends, Xact_commit, Xact_rollback, Blks_read,  Blks_hit,  Tup_returned,

Tup_fetched, Tup_inserted ,Tup_updated, Tup_deleted.

Table bloat and index bloat The estimated amount of bloat in your tables and indices.
Top 10 largest tables The largest top 10 tables in the selected database.
Database sizes Every database’s size in MB.
Last analyzed or vacuumed The last time a table was last analyzed or vacuumed.
Unused indexes Returns unused indexes.
Duplicate indexes Returns duplicate indexes.
Exclusive lock waits Returns exclusive lock waits.
Logical Replication Latency Since PostgreSQL 9.4, this view contains replication statistics for each slave the master connects to for sending data. Details at pg_stat_replication View.
Logical Replication Slot Since PostgreSQL 9.4 this view lists all replication slots (and their stats) existing on the database node. Details at pg_stat_replication.
Logical Publication Since PostgreSQL 10 <span class="pre">pg_publication</span> lists all logical replication publications for the database. Details at pg_publication.
Logical Subscription Since PostgreSQL 10 <span class="pre">pg_subscription</span> lists all logical replication subscriptions. Details at pg_subscription.

 

Was this article helpful to you? Yes No