Database เป็นหัวใจของระบบ application ส่วนใหญ่ — เมื่อฐานข้อมูลช้าหรือล่ม ผลกระทบจะลามไปทั่วทั้งระบบ การ monitor ที่ดีจึงเน้นการตรวจจับสัญญาณเตือนก่อนที่จะกลายเป็นปัญหา ไม่ใช่รอให้ user แจ้งว่าช้า บทความนี้อธิบาย metric สำคัญสำหรับ MySQL และ PostgreSQL พร้อม query สำหรับ debug และแนวทาง alert rule

ทั้ง MySQL และ PostgreSQL มีปรัชญาการออกแบบต่างกัน แต่ metric พื้นฐานที่ต้องดูคล้ายกัน — throughput, latency, connection, lock, buffer hit ratio และ replication lag

Metric หลักที่ต้อง Monitor

• QPS/TPS — จำนวน query/transaction ต่อวินาที
• Query Latency — p50, p95, p99 ของเวลาที่ query ใช้
• Slow Query Count — จำนวน query ที่ใช้เวลาเกิน threshold
• Connection Count — active, idle, max_connections
• Buffer/Cache Hit Ratio — % ของ request ที่อ่านจาก memory ไม่ใช่ disk
• Lock & Deadlock — จำนวน row/table lock, deadlock ที่เกิดขึ้น
• Replication Lag — เวลาที่ replica ตามหลัง primary
• Disk I/O — read/write throughput, IOPS, queue length
• Table Bloat — (PostgreSQL) พื้นที่ที่สูญเสียจาก MVCC

MySQL Monitoring

MySQL มี built-in views ใน information_schema และ performance_schema ที่ใช้ตรวจสุขภาพได้ทันที โดยไม่ต้องติดตั้ง tool เพิ่ม

-- connection stats
SHOW STATUS LIKE 'Threads_%';
SHOW STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';

-- query counters
SHOW GLOBAL STATUS LIKE 'Com_%';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Slow_queries';

-- InnoDB buffer pool hit ratio
SELECT
  (1 - (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS
        WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') /
       (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS
        WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')) * 100 AS hit_ratio_percent;

-- find top slow queries
SELECT digest_text, count_star, avg_timer_wait/1e9 AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY avg_timer_wait DESC LIMIT 10;

-- replica lag
SHOW REPLICA STATUS\G   -- look at Seconds_Behind_Source

PostgreSQL Monitoring

PostgreSQL มี view ชื่อ pg_stat_* ครอบคลุม database, table, index, activity และ replication — รวมทั้ง extension pg_stat_statements ที่ต้องเปิดใน shared_preload_libraries สำหรับเก็บสถิติ query level

-- active connections
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;

-- cache hit ratio (> 99% คือดี)
SELECT sum(heap_blks_read) AS disk_read,
       sum(heap_blks_hit) AS cache_hit,
       sum(heap_blks_hit) * 100.0 /
       nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0) AS hit_pct
FROM pg_statio_user_tables;

-- top slow queries (ต้องเปิด pg_stat_statements)
SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC LIMIT 10;

-- replication lag
SELECT client_addr,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

-- table bloat (ประมาณ)
SELECT schemaname, relname,
       n_dead_tup, n_live_tup,
       round(n_dead_tup * 100.0 / nullif(n_live_tup + n_dead_tup, 0), 2) AS dead_pct
FROM pg_stat_user_tables
ORDER BY dead_pct DESC NULLS LAST LIMIT 10;

Threshold และ Alert Rule

Metric	Warning	Critical
Connection % ของ max	> 70%	> 90%
Buffer/Cache Hit Ratio	< 95%	< 90%
Replication Lag	> 10s	> 60s
Slow Query Rate	> 5/min	> 20/min
Deadlock Rate	> 1/min	> 5/min
Disk Usage (DB)	> 75%	> 90%
Dead Tuple %	> 10%	> 25%

Exporter สำหรับ Prometheus

• mysqld_exporter — ดึง metric จาก MySQL/MariaDB (port 9104) รองรับ performance_schema, innodb, replication
• postgres_exporter — ดึง metric จาก PostgreSQL (port 9187) รองรับ custom queries ผ่าน config YAML
• pg_stat_monitor — wrapper แบบขยาย pg_stat_statements ให้มี bucket แบ่งตามเวลา

# docker-compose.yml - MySQL exporter
version: '3.8'
services:
  mysqld-exporter:
    image: prom/mysqld-exporter:latest
    environment:
      - DATA_SOURCE_NAME=exporter:password@(db:3306)/
    ports:
      - "9104:9104"
    command:
      - --collect.info_schema.processlist
      - --collect.info_schema.innodb_metrics
      - --collect.info_schema.tables
      - --collect.perf_schema.eventsstatements

Prometheus Alert Rule ตัวอย่าง

groups:
- name: database
  rules:
  - alert: MySQLHighConnections
    expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.9
    for: 5m
    annotations:
      summary: "MySQL {{ $labels.instance }} ใช้ connection เกิน 90%"

  - alert: PostgresLowCacheHit
    expr: rate(pg_stat_database_blks_hit[5m]) /
          (rate(pg_stat_database_blks_hit[5m]) + rate(pg_stat_database_blks_read[5m])) < 0.95
    for: 15m
    annotations:
      summary: "Postgres cache hit ต่ำกว่า 95% ติดต่อกัน — ตรวจ shared_buffers"

  - alert: ReplicaLagHigh
    expr: mysql_slave_lag_seconds > 60
    for: 5m
    annotations:
      summary: "Replica lag ของ {{ $labels.instance }} สูงกว่า 60 วินาที"

  - alert: DeadlockSpike
    expr: rate(mysql_global_status_innodb_deadlocks[5m]) * 60 > 5
    for: 5m
    annotations:
      summary: "Deadlock rate สูงผิดปกติบน {{ $labels.instance }}"

Workflow การ Debug Slow Query

• Step 1: เปิด slow_query_log (MySQL) หรือ log_min_duration_statement (Postgres) ให้บันทึก query ที่เกิน threshold
• Step 2: ใช้ pt-query-digest (MySQL) หรือ pg_stat_statements (Postgres) หา top offender
• Step 3: รัน EXPLAIN ANALYZE ดู query plan — มองหา Seq Scan บนตารางใหญ่, nested loop ที่ไม่ควร, สถิติที่ไม่ตรง
• Step 4: ตรวจ index ที่เกี่ยวข้อง — missing index หรือ cardinality ต่ำ
• Step 5: ดู connection pool — ถ้าจำนวน connection สูงและเกือบหมด อาจเป็น connection leak ไม่ใช่ DB ช้า

Best Practices

• ใช้ user แยกสำหรับ exporter — มีสิทธิ์แค่ SELECT, PROCESS, REPLICATION CLIENT เท่าที่จำเป็น
• Monitor ทั้ง primary และ replica — อย่า monitor แค่ primary เพราะ replica อาจมีปัญหา lag/disk/lock แยก
• เก็บ query plan snapshot — เมื่อ query plan เปลี่ยน (optimizer เลือก plan ใหม่หลัง ANALYZE) พฤติกรรมจะเปลี่ยนทันที
• ตั้ง alert vacuum freeze — PostgreSQL ต้อง vacuum ก่อน xid wraparound (2^31) — ถ้าปล่อยจนถึงจะ readonly
• Alert disk ให้เผื่อ binlog/WAL — database ไม่ใช่แค่ datadir พังบ่อยเพราะ log เต็ม
• Dashboard แยกระหว่าง OLTP กับ OLAP — metric ที่สำคัญต่างกัน (OLTP เน้น latency, OLAP เน้น throughput)

สรุป

Database monitoring ที่ดีต้องครอบคลุมทั้ง 3 ชั้น — resource (CPU, disk, memory), throughput (QPS, connection) และ query quality (slow query, lock, replication lag) การใช้ built-in views (information_schema, pg_stat_*) ร่วมกับ exporter สำหรับ Prometheus ทำให้เห็น trend ระยะยาวได้ และสามารถตั้ง alert ที่ fire ก่อนปัญหาจะลุกลาม

อย่าลืม monitor replica แยกจาก primary และเก็บ query plan snapshot ไว้เปรียบเทียบ เพราะหลายครั้งปัญหา production ไม่ได้เกิดจาก load สูงขึ้น แต่เกิดจาก optimizer เปลี่ยน plan หลังสถิติอัปเดต การมี baseline และ alert ที่ตรงจุดจะช่วยย่น mean time to detect และทำให้ DBA มีเวลาแก้ก่อนกระทบ end user