Databases 6 min read

Real-Time Slow Query Monitoring Architecture for MySQL

This article describes a real‑time slow‑query monitoring solution for MySQL, detailing the overall architecture, the agent that tails slow‑log files and pushes entries to Redis, and the consumer that processes logs, stores them, and alerts DBAs, enabling near‑instant detection of performance issues.

Aikesheng Open Source Community
Aikesheng Open Source Community
Aikesheng Open Source Community
Real-Time Slow Query Monitoring Architecture for MySQL

Slow query monitoring is crucial in MySQL operations to diagnose performance fluctuations and slow business queries. When the number of clusters and instances grows, collecting and storing slow queries becomes difficult and real‑time alerts are hard to achieve.

Common Approaches

1. Slow Log Collection

Typically a scheduled task runs pt-query-digest to collect each instance's slow log into a MySQL table; because it is triggered periodically, it is not real‑time.

2. Slow Log Statistics

Queries can be run against the MySQL table using host, port, user, fingerprint, time range, etc., to generate statistics.

3. Slow Log Alerting

Alerts are sent to DBAs and developers after querying the MySQL table, but since the data is stored in full and queried in batches, alerts cannot be real‑time.

Real‑Time Slow Query Monitoring Architecture

The solution introduces an agent that continuously tails MySQL slow‑log files. Each slow‑log segment is pushed as a list item into Redis. One agent can monitor all MySQL instances on a host, aggregating dispersed logs into a single Redis store.

A consumer service pops the assembled entries from Redis, parses host, port, database, and user, matches them to the responsible DBA or developer, and pushes the slow‑query information to the appropriate personnel in real‑time. The service also stores the logs as files keyed by host‑port for later analysis.

Collector Implementation

The collector treats a slow‑log entry as a block that starts with the line # Time and ends before the next # Time. Additional MySQL instance metadata is appended before pushing the block to Redis, resulting in a data structure similar to the diagram shown.

Consumer Implementation

The consumer performs two tasks: (1) it writes the popped messages to files named by ip:port for subsequent pt-query-digest analysis; (2) it looks up the cluster owner and DBA for the ip:port and sends the slow‑query details via SMS or email.

Frontend Display

The UI lists centralized slow‑log files, shows log size aggregated by cluster and instance for a selected time window, and provides an “Analyze” button that runs pt-query-digest on the file, presenting the result.

Real‑time slow SQL queries are displayed by continuously popping data from Redis, allowing rolling updates and optional push notifications to subscribers.

Upcoming Event

An announcement for the D+Talks 2021 technical conference on October 24, where the database operations platform will be presented.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Real-Timeredismysqlslow-query
Aikesheng Open Source Community
Written by

Aikesheng Open Source Community

The Aikesheng Open Source Community provides stable, enterprise‑grade MySQL open‑source tools and services, releases a premium open‑source component each year (1024), and continuously operates and maintains them.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.