Giám sát WordPress với InitTop: Từ MySQL monitoring đến full-stack observability

Ở bài giới thiệu trước, chỉ nói về cách cài đặt và các tính năng cơ bản. Trong bài này, sẽ đi sâu vào v1.2.0 — phiên bản mang InitTop từ một “công cụ nhìn” lên thành một profiler, action center, và database health advisor thực sự cho WordPress. Nội dung bao gồm Query History, Export Slow Log, JSON mode, InnoDB Lock/Deadlock analysis, Health Advisor, và cách biến InitTop thành một mảnh ghép trong hệ thống giám sát full-stack.

WordPress + MySQL: Cặp bài trùng và điểm nghẽn ẩn

WordPress là CMS chiếm hơn 40% web toàn cầu, và hầu hết đều chạy trên MySQL hoặc MariaDB. Vấn đề là: khi plugin bị lỗi, transient cache bị bloat, hoặc một cron job nào đó chạy query không tối ưu, sẽ không bao giờ biết chính xác điều gì đang xảy ra chỉ bằng htop hay mysql -e "SHOW PROCESSLIST".

InitTop v1.2.0 giải quyết bài toán này bằng cách cung cấp:

• Processlist real-time với phân loại màu theo mức độ nguy hiểm.
• Query History — phát hiện query lặp lại ngay trong session.
• EXPLAIN inline — tối ưu query ngay trên terminal, hỗ trợ cả INSERT/UPDATE/DELETE.
• Kill query & Kill connection — giải cứu site đang đơ mà không cần restart MySQL, có xác nhận y/N.
• InnoDB Lock Waits — nhìn thấy ngay ai đang bị block, ai đang giữ lock.
• Deadlock Viewer — trích xuất deadlock gần nhất từ InnoDB status.
• Health Advisor — 10 chỉ số then chốt tự động phân tích, gợi ý tuning cụ thể.
• Export slow log — ghi nhận bằng chứng để phân tích sau.
• JSON mode — tích hợp với cron, log parser, hoặc monitoring stack.

InitTop v1.2.0 có gì mới?

Trước khi đi vào use case WordPress, đây là danh sách tính năng mới trong v1.2.0:

Scenario thực tế: WordPress đột ngột chậm

Hãy tưởng tượng website đột nhiên đơ, không vào được admin. SSH vào VPS, chạy InitTop.

Bước 1: Quan sát tổng quan

Ngay dòng đầu tiên, sẽ thấy:

MySQL 8.0.36  |  Uptime 12:34:56  |  MaxConn 151  |  SlowAt >=1.0s  |  QPS  245.3  ▁▂▃▄▅▆▇█

QPS đột ngột từ 15 lên 245? Sparkline hiển thị một cột “█” cuối cùng — đây là dấu hiệu traffic spike hoặc một process nào đó đang bombard database.

Bước 2: Phát hiện thủ phạm bằng màu sắc và Lock Waits

Trong danh sách processlist, sẽ thấy một dòng RED bold:

PID     USER    DB              CMD     TIME    STATE           QUERY
48291   wp_user wp_database     Query   8.2     Sending data    SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'product' AND ...

TIME = 8.2 giây, màu đỏ. Nhưng nếu STATE hiển thị Waiting for table lock hoặc Waiting for row lock, đây không phải query chậm do tối ưu — mà do bị block bởi transaction khác. Nhấn T — InnoDB Lock Waits — sẽ thấy ngay:

WAITING     pid 48291   waited 8s
   SELECT * FROM wp_posts WHERE ...
BLOCKED BY  pid 48285   trx age 12s   rows locked 147
   UPDATE wp_postmeta SET meta_value = ... WHERE post_id = 123

Một transaction UPDATE từ plugin đang giữ lock, làm hàng loạt SELECT sau đó bị block. Biết chính xác blocker là PID 48285, có thể kill connection đó ngay.

Bước 3: EXPLAIN ngay trên terminal — giờ đã mạnh hơn

Di chuyển xuống query đó, nhấn e. InitTop hiển thị overlay:

 EXPLAIN output - any key to close  (RED = full scan / filesort / temp table)
  select_type=SIMPLE  type=ALL  possible_keys=NULL  key=NULL  key_len=NULL  ref=NULL  rows=45231  Extra=Using where

type=ALL và key=NULL — đây là full table scan trên bảng wp_posts với 45,231 rows. Plugin đang query mà không dùng index. Cần thêm composite index trên (post_type, post_status), hoặc tối ưu lại logic query.

Với v1.2.0, nếu thủ phạm là một UPDATE wp_options hoặc DELETE wp_transient, EXPLAIN vẫn hoạt động — không còn giới hạn SELECT nữa. Và nếu thấy Using filesort hoặc Using temporary trong EXPLAIN, InitTop tự động highlight màu đỏ — không cần mò từng dòng.

Bước 4: Health Advisor — kiểm tra sức khỏe hệ thống

Trước khi hành động, nhấn A để xem Health Advisor. Đây là 10 chỉ số tích lũy từ lúc MySQL khởi động:

[ OK ] Buffer pool hit       98.5%   
[WARN] Tmp tables on disk     34.2%   -> raise tmp_table_size + max_heap_table_size
[ !! ] Joins w/o index        247     -> add indexes on JOIN columns
[ OK ] Thread cache miss       2.1%
[WARN] Peak connections      128/151 (85%)  -> raise max_connections or reduce PHP-FPM children

Với WordPress, Joins w/o index = 247 là dấu hiệu điển hình của plugin đang join wp_posts với wp_postmeta mà không có index trên meta_key. Tmp tables on disk cao thường do plugin chạy GROUP BY trên TEXT/BLOB (ví dụ: lấy danh sách order notes). Advisor cho biết chính xác cần điều chỉnh biến nào.

Bước 5: Giải cứu tạm thời bằng Kill Query / Kill Connection

Trong lúc chờ fix code, không muốn site tiếp tục đơ. Chọn query, nhấn K (chữ hoa). InitTop hỏi:

KILL QUERY pid 48291 ?   [y] confirm   [any other key] cancel

Nhấn y để xác nhận. Query bị dừng ngay lập tức, CPU giảm, site thở được.

Nếu thủ phạm là một connection từ một IP cụ thể đang spam (ví dụ: bot brute-force wp-login.php tạo hàng trăm query), chọn row đó và nhấn X (chữ hoa) để KILL CONNECTION — đóng toàn bộ kênh kết nối, không chỉ một query.

Bước 6: Export bằng chứng để phân tích sau

Nhấn W để export toàn bộ slow queries hiện tại ra file:

# InitTop export — 2026-07-01 14:32:15  QPS=245.3
# Slow threshold: 3s
# Processes: 47  Slow: 12
# PID=48291  USER=wp_user  DB=wp_database  TIME=8.2s  STATE=Sending data
SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'product' AND ...

File này được append vào inittop_slow.log (hoặc path chỉ định qua --log-file). Có thể dùng nó để:

• Gửi cho developer/theme support.
• Phân tích bằng pt-query-digest nếu cần.
• Lưu vào ticket để theo dõi regression sau khi fix.

Bonus: Deadlock trong WooCommerce checkout

Một tình huống khác: khách hàng báo lỗi “Could not complete checkout”, nhưng không thấy query nào chậm trong processlist. Nhấn D — Deadlock Viewer — InitTop trích xuất phần LATEST DETECTED DEADLOCK từ InnoDB status:

*** (1) TRANSACTION:
TRANSACTION 123456, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 48291, OS thread handle 123456789, query id 99999 wp_database
UPDATE wp_wc_order_stats SET status = 'processing' WHERE order_id = 456
*** (2) TRANSACTION:
TRANSACTION 123457, ACTIVE 1 sec starting index read
UPDATE wp_posts SET post_status = 'wc-processing' WHERE ID = 456

Hai plugin (WooCommerce Core và một plugin bên thứ ba) đang cập nhật cùng một order_id nhưng theo thứ tự ngược nhau — classic deadlock. Biết chính xác bảng nào, query nào, để báo lại developer.

Giám sát định kỳ với JSON Mode

Tính năng interactive TUI của InitTop rất mạnh khi đang online. Nhưng để biến InitTop thành một phần của hệ thống giám sát, cần JSON mode.

Chạy snapshot định kỳ qua cron

# Mỗi 5 phút, ghi snapshot JSON vào log
*/5 * * * * MYSQL_PWD=your_password /usr/local/bin/inittop -u root -S /run/mysqld/mysqld.sock --json --json-count=1 --interval=2 >> /var/log/inittop.jsonl 2>/dev/null

Output mỗi dòng là một object JSON hoàn chỉnh:

{
  "ts": "2026-07-01T14:35:22",
  "version": "8.0.36",
  "uptime_sec": 45231,
  "qps": 245.3,
  "connections": {
    "connected": 47,
    "running": 12,
    "slow": 3,
    "locked": 0
  },
  "buffer_pool": {
    "size_mb": 1024,
    "hit_pct": 98.5,
    "used_pct": 82.3
  },
  "processes": [...]
}

Với dữ liệu này, có thể:

• Parse bằng Python/Node để gửi alert qua Telegram/Slack khi slow > 5 hoặc hit_pct < 90.
• Đẩy vào Loki hoặc Elasticsearch nếu đã có log stack.
• Vẽ biểu đồ đơn giản bằng script Python với matplotlib — không cần Prometheus phức tạp.

Script alert đơn giản

#!/bin/bash
# /usr/local/bin/inittop-alert.sh
export MYSQL_PWD="your_password"
/usr/local/bin/inittop -u root -S /run/mysqld/mysqld.sock --json --json-count=1 | python3 -c "
import sys, json
data = json.loads(sys.stdin.readline())
slow = data['connections']['slow']
locked = data['connections']['locked']
hit = data['buffer_pool']['hit_pct']
if slow > 3 or locked > 0 or hit < 90:
    print(f'[ALERT] InitTop: slow={slow}, locked={locked}, buffer_hit={hit}%')
"

Chạy script này qua cron mỗi phút — vừa có một hệ thống alerting tự động mà không cần cài thêm bất kỳ agent nào khác.

Full-stack observability: InitTop là mảnh ghép nào?

“Full-stack observability” nghe sang chảnh, nhưng với WordPress self-hosted, nó chỉ đơn giản là có thể nhìn thấy toàn bộ chuỗi từ request đến phản hồi. InitTop chiếm vị trí ở tầng database, và giờ đã có thể nhìn sâu hơn vào InnoDB internals.

Mô hình 3 tầng giám sát cho WordPress

Khi kết hợp cả ba, có thể trace một vấn đề như sau:

1. Goaccess cho thấy spike 500 errors từ IP X.
2. PHP-FPM log cho thấy request timeout sau 30 giây.
3. InitTop cho thấy query từ user wp_user đang Waiting for row lock 28 giây trên bảng wp_postmeta — nhấn T thấy một transaction UPDATE từ plugin cache đang giữ lock.
4. EXPLAIN xác nhận thiếu index trên meta_key. Advisor cho thấy Joins w/o index = 312.
5. Kill connection để site sống lại, export log để fix sau.

Đó là full-stack observability thực sự — không cần Datadog, không cần New Relic, chỉ cần terminal và log.

Buffer Pool, Connections, và Health Advisor

Ngoài processlist, InitTop v1.2.0 hiển thị các chỉ số quan trọng và phân tích chúng qua A — Health Advisor.

Buffer Pool Hit Rate

Tỷ lệ này cho biết MySQL đọc dữ liệu từ RAM (buffer pool) thay vì đọc từ disk. Với WordPress:

• ≥ 99%: Tuyệt vời. Buffer pool đủ lớn cho toàn bộ dataset.
• 95–98%: Tạm ổn. Có thể cần tăng innodb_buffer_pool_size nếu site lớn.
• < 95%: Cảnh báo. Disk I/O đang là bottleneck. WooCommerce với hàng nghìn sản phẩm sẽ rất chậm.

InitTop hiển thị hit rate bằng thanh tiến trình màu: xanh → vàng → đỏ. Không cần nhớ số, nhìn màu là biết. Nhấn A để xem advisor tự động đánh giá chỉ số này và đề xuất innodb_buffer_pool_size phù hợp.

Buffer Pool Used %

Nếu thanh này đầy (>90%), MySQL sẽ bắt đầu đuổi dữ liệu cũ ra khỏi RAM. Với WordPress có nhiều plugin, bảng wp_options và wp_postmeta thường rất lớn — dễ làm đầy buffer pool. Health Advisor sẽ cảnh báo nếu kết hợp với hit rate thấp.

Connections

• Connected: Số kết nối hiện tại. Nếu gần max_connections (thường 151), WordPress sẽ báo lỗi “Error establishing a database connection”.
• Running: Số query đang thực thi. Nếu Running cao nhưng QPS thấp, có nghĩa là các query đang bị treo hoặc đang chờ lock — nhấn T để xác nhận.
• Slow: Số query vượt ngưỡng. Chỉ số này nhấp nháy đỏ là lúc cần hành động ngay.
• Locked: Số query đang bị khóa bảng. MyISAM hoặc các operation ALTER TABLE không tối ưu sẽ gây ra lock cascade. Với InnoDB, T sẽ cho thấy chi tiết hơn.

Mouse Support: Terminal cũng có thể “click”

Một điểm nhỏ nhưng rất thực dụng trong v1.2.0: InitTop hỗ trợ chuột trên các terminal như iTerm2, GNOME Terminal, và cả Windows Terminal qua SSH.

• Click vào một dòng để select query đó — không cần dùng phím mũi tên.
• Double-click để auto EXPLAIN query đang chọn, kể cả UPDATE/DELETE.

Điều này đặc biệt hữu ích khi đang screen-share với khách hàng hoặc đồng nghiệp. Họ thấy click đúng query, double-click xem EXPLAIN — rất trực quan.

InitTop so với các công cụ khác: Góc nhìn WordPress

InitTop không thay thế Query Monitor — nó bổ sung cho Query Monitor. Khi WordPress còn sống, Query Monitor giúp debug theme/plugin. Khi WordPress đã chết vì database, InitTop là công cụ duy nhất cần mở — và giờ nó còn cho bạn biết tại sao database chết (deadlock, lock wait, buffer pool miss, v.v.).

Workflow khuyến nghị cho admin WordPress

Đây là quy trình áp dụng cho các site Init Manga và WordPress khách hàng:

1. Cài đặt InitTop ngay khi triển khai server (đã tích hợp trong InitOps).
2. Để TUI chạy trong tmux/screen khi đang bảo trì hoặc deploy update lớn.
3. Setup cron với --json để ghi snapshot mỗi 5 phút.
4. Viết script parser đơn giản để alert khi slow query > 3 hoặc buffer hit < 95%.
5. Khi incident xảy ra:
   • Mở InitTop → quan sát màu sắc.
   • Nếu thấy lock trong STATE → nhấn T xem ai đang block.
   • Nhấn H để xem query lặp lại.
   • e để EXPLAIN query nghi ngờ (kể cả UPDATE/DELETE).
   • A để kiểm tra health advisor — có joins w/o index, tmp disk table không?
   • K để kill query nếu cần giải cứu ngay (có xác nhận).
   • X để kill connection nếu một IP đang spam.
   • W để export log trước khi thoát.
   • Nếu WooCommerce checkout lỗi mà không thấy query chậm → D xem deadlock.
6. Sau incident: dùng slow log để thêm index, tối ưu plugin, hoặc liên hệ developer.

Kết luận

InitTop v1.2.0 không chỉ là một công cụ “nhìn” MySQL nữa. Với Query History, Export Slow Log, EXPLAIN inline cho DML, Kill query/connection có xác nhận, InnoDB Lock Waits, Deadlock Viewer, Health Advisor, và JSON mode, nó đã trở thành một profiler, action center, và database health advisor thực sự cho WordPress.

Điều quan trọng nhất: nó vẫn giữ nguyên triết lý của Init HTML — self-contained, minimal dependency, chạy trên mọi terminal. Không cần cài đặt một stack monitoring phức tạp chỉ để biết tại sao website WordPress đang đơ, ai đang giữ lock, deadlock vừa xảy ra ở đâu, hay buffer pool có đang bị bóp nghẹt không.

Nếu đã dùng InitOps để deploy server, InitTop đã sẵn sàng. Nếu chưa, một dòng lệnh là đủ.

Lệnh cài đặt nhanh

curl -sSL https://inithtml.com/inittop/install.sh | bash

Tham khảo nhanh phím tắt v1.2.0

• ↑ / ↓ hoặc k / j — Di chuyển giữa các process.
• Mouse click — Chọn row trực tiếp.
• Mouse double-click — EXPLAIN row đang chọn.
• K (capital) — Kill query đang chọn (có xác nhận y/N).
• X (capital) — Kill connection đang chọn (có xác nhận y/N).
• e — EXPLAIN query đang chọn (SELECT / UPDATE / DELETE / INSERT / REPLACE).
• T (capital) — InnoDB lock waits: ai đang bị block, ai đang block.
• D (capital) — Xem deadlock gần nhất từ InnoDB status.
• A (capital) — Health advisor: 10 chỉ số tuning + gợi ý khắc phục.
• / — Lọc processlist.
• ESC — Xóa bộ lọc hoặc đóng overlay.
• s — Chuyển đổi cột sắp xếp.
• p — Tạm dừng / tiếp tục auto-refresh.
• r — Refresh ngay lập tức.
• W (capital) — Export slow queries ra file log.
• H (capital) — Xem Query History overlay.
• C (capital) — Xóa Query History.
• ? — Mở màn hình trợ giúp.
• q — Thoát InitTop.

Trong các overlay T / D / A: j / k để scroll, phím bất kỳ để đóng.