MySQL Integration

Monitor MySQL query performance, connection pressure, InnoDB internals, schema growth, index usage, lock contention and replication health from a single Watchlog agent.

Works with MySQL and MariaDB. The agent detects which one it is talking to and adapts — the two diverge on replication statements and lock tables, and version detection handles that rather than assuming.

Supported Platforms

• Ubuntu
• Windows
• Source Code
• Docker Container
• Kubernetes

Supported Versions

Version differences are detected, not assumed. Two boundaries matter:

• MySQL 8.0 introduced performance_schema.data_locks / data_lock_waits. Below that (and on all MariaDB) the agent reads information_schema.innodb_lock_waits.
• MySQL 8.0.22 renamed the replication statements (SHOW REPLICA STATUS). MariaDB kept the old terminology permanently.

Required Privileges

CREATE USER 'watchlog_monitor'@'%' IDENTIFIED BY 'your_password';

GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'watchlog_monitor'@'%';
GRANT SELECT ON performance_schema.* TO 'watchlog_monitor'@'%';
GRANT SELECT ON information_schema.* TO 'watchlog_monitor'@'%';

FLUSH PRIVILEGES;

No SUPER, no ALL PRIVILEGES, and no access to your application data — the agent never reads a row from a user table.

What each grant buys:

A missing grant disables that section only. The integration stays connected.

Capability Detection

Several features depend on server configuration rather than privileges, and are probed rather than assumed:

When performance_schema is off, the Queries, Indexes and Locks tabs are hidden and a capability note explains why — rather than showing three empty tabs.

SHOW VARIABLES LIKE 'performance_schema';

Turning it on requires a restart and costs a few percent of memory. It is what makes query-level analysis possible.

What Watchlog Collects

Server Version and flavour, uptime, connections against max_connections, running and cached threads, aborted clients and connects, questions and slow-query counters, open tables against table_open_cache, and temporary tables created on disk.

Queries (needs performance_schema) Per normalized digest: executions, total and average latency, rows examined against rows sent, temporary tables, sorts, and full-scan counts — ranked by impact (executions × average latency), which is the database time actually consumed. That ordering surfaces a 2 ms query running 50 000 times ahead of one 4-second report; sorting by average hides it.

InnoDB Buffer pool size, usage and hit rate, dirty page percentage, log waits, row lock waits and average wait time, pending IO, and deadlock counts.

Schemas and tables Per schema: table count, data and index size. Per table: rows, data length, index length, average row length and engine. System schemas (mysql, sys, information_schema, performance_schema) are excluded everywhere — they would otherwise dominate every "largest table" list.

Indexes (needs performance_schema) Per index: reads, writes and usage, with unused candidates flagged. An unused index is reads = 0 — not reads = 0 && writes = 0, which would exclude every index on a write-heavy table. UNIQUE and PRIMARY indexes are never proposed for removal; they enforce correctness regardless of scan count.

Locks Blocking and waiting transactions with the statements involved, plus deadlock counts.

Replication Role, IO and SQL thread state, seconds behind source, relay log position, and the last error.

Health Score and Insights

A 0–100 score computed server-side, with a written reason on every deduction:

A number is not a verdict. A low buffer pool hit rate over 200 reads means nothing; the score requires volume before it judges.

Slow Queries

Watchlog does not read the MySQL slow query log file. It uses performance_schema.events_statements_summary_by_digest, which gives the same information without the file, without a threshold to configure, and without the write cost.

slowQuery.thresholdMs (default 100) only decides what the dashboard calls slow. The agent, the API and the UI all use that one number so they cannot disagree.

Query text is normalized by MySQL itself before Watchlog ever sees it — the digest text has literals replaced with ?. Parameter values never leave your host.

Collection Intervals

Safety

Watchlog is read-only. It never runs any of the following:

ANALYZE TABLE · OPTIMIZE TABLE · ALTER TABLE · KILL · FLUSH TABLES · SET GLOBAL · DROP of anything · any write to any table

There are no full table scans for monitoring, and every monitoring statement carries a timeout so it can never be the thing that hangs a busy server.

Advanced Options

{
  "service": "mysql",
  "monitor": true,
  "host": "localhost",
  "port": "3306",
  "username": "watchlog_monitor",
  "password": "your_password",
  "database": [],
  "ssl": false,

  "advanced": {
    "enabled": true,
    "queries": true,
    "schema": true,
    "indexes": true,
    "locks": true,
    "replication": true,
    "maxDigests": 200,
    "maxTables": 300,
    "maxIndexes": 500,
    "maxLockWaits": 50,
    "schemaIntervalSeconds": 300,
    "indexIntervalSeconds": 300
  },

  "slowQuery": {
    "thresholdMs": 100
  }
}

Multiple Instances

Add one entry per instance. Each is identified by its host:port:

[
  {
    "service": "mysql",
    "monitor": true,
    "host": "127.0.0.1",
    "port": "3306",
    "username": "watchlog_monitor",
    "password": "your_password"
  },
  {
    "service": "mysql",
    "monitor": true,
    "host": "127.0.0.1",
    "port": "3307",
    "username": "watchlog_monitor",
    "password": "your_password"
  }
]

Troubleshooting