Giới thiệu về monitoring cơ sở dữ liệu

Hãy tưởng tượng bạn là thuyền trưởng của một con tàu đang lướt trên đại dương dữ liệu. Bạn không chỉ muốn con tàu chạy thôi đâu. Bạn còn muốn chắc chắn nó không đâm vào tảng băng của những truy vấn dài, không bị bất ngờ bởi cơn bão lock, và con tàu không chìm vì quá tải kết nối. Monitoring database chính là radar, barometer và sonar của bạn, giúp tránh băng, bão và hoảng loạn.

Tại sao và làm thế nào để monitoring database

Monitoring giúp đảm bảo database chạy ổn định và phát hiện sớm các vấn đề tiềm ẩn. Hãy tưởng tượng thay vì dịch vụ tự dưng sập, bạn nhận được tín hiệu sớm: "Ê, ở đây có truy vấn chạy đã 30 giây rồi, có gì đó không ổn". Bạn biết trước chỗ nào bị tắc, ai đang giữ lock, và database sắp nghẹt thở vì thiếu tài nguyên ở đâu.

Đây là những thứ nên chú ý:

• Hoạt động của truy vấn và transaction. Theo dõi luồng truy vấn như cách điều phối viên theo dõi giao thông ở ngã tư. SQL command nào đang làm chậm người khác? Ai đang "đốt" database nhiều nhất? Những câu trả lời này giúp tối ưu mà không phải vội vàng hay hoảng loạn.

• Sử dụng tài nguyên. CPU, RAM và dung lượng ổ đĩa giống như nhiên liệu và thân tàu. Nếu một tài nguyên nào đó "rò rỉ" hoặc quá tải, cả con tàu có thể dừng lại. Monitoring cho thấy chỗ nào quá tải và cho phép bạn phân phối lại tải.

• Hiệu suất truy vấn. Một số SQL query như những hành khách khó chiều: đòi hỏi quá nhiều, làm chậm người khác và luôn than phiền. Monitoring sẽ chỉ ra ai "ăn nhiều" nhất — để bạn có thể index, viết lại hoặc thay thế.

• Lock và conflict. Đôi khi các truy vấn xung đột với nhau: một bên giữ tài nguyên, bên kia phải chờ. Giống như ai đó giữ cửa một chiều, người khác kéo ngược lại. Monitoring những lock này giúp bạn can thiệp kịp thời và giải tỏa căng thẳng.

Monitoring tốt không chỉ báo database "còn sống". Nó chỉ ra chỗ nào database có thể "lăn ra chết" — và cho bạn thời gian sửa trước khi vấn đề thành sự thật.

Những metric quan trọng để monitoring PostgreSQL

Để hiểu trạng thái database của bạn, bạn cần biết nên nhìn vào đâu. Những metric này là "mạch" và "huyết áp" của database. Đây là các tham số chính:

1. Số lượng kết nối active.

   Có bao nhiêu user đang kết nối? Họ có đang "phá" database bằng những truy vấn ngớ ngẩn không? Ví dụ, pg_stat_activity mà tụi mình sẽ nói ở các bài sau, sẽ cho thấy hoạt động hiện tại.

2. Thời gian thực thi truy vấn.

   Truy vấn nào chạy nhanh nhất? Ngược lại, truy vấn nào nghĩ mình đã "nghỉ hưu"?

3. Sử dụng index.

   Nếu bạn có index mà không dùng, chắc chắn có gì đó sai. Kiểm tra qua pg_stat_user_indexes.

4. Mức độ lock và conflict.

   Rất hay dùng để ngăn "Deadlocks" (lock lẫn nhau).

5. Tải CPU và sử dụng RAM.

   Ví dụ, PostgreSQL đang "ăn" bao nhiêu tài nguyên của server?

Thực tế thì nó trông như thế nào?

Cùng xem một ví dụ thực tế. Đây là truy vấn đơn giản giúp bạn biết kích thước một database cụ thể:

SELECT pg_size_pretty(pg_database_size('ten_database_cua_ban')) AS database_size;

Truy vấn nhỏ này sẽ trả về kích thước database ở dạng dễ đọc — ví dụ, 243 MB hoặc 1.2 GB. Rất tiện khi bạn cần xem database đã "phình" ra bao nhiêu thời gian gần đây.

Nếu muốn xem kích thước tất cả database cùng lúc — không cần gõ từng cái — bạn có thể dùng kiểu này:

SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database;

Cái này cho bạn cái nhìn tổng thể về tất cả database trên server — rất tiện cho admin nào đang canh dung lượng ổ đĩa và muốn "bắt" mấy database "ăn nhiều" trước khi nhận mail từ hosting: "Bạn sắp hết chỗ rồi đó".