Database Monitoring
Một trong những cơ sở dữ liệu quan hệ dựa trên đám mây được sử dụng rộng rãi nhất hiện nay là Amazon RDS. Khách hàng của AWS sử dụng nó một cách rộng rãi do tính hiệu quả về mặt chi phí và tính đơn giản trong quản lý. Là một dịch vụ được quản lý, RDS không cần các DBA để xử lý nhiều tác vụ hàng ngày nhưng vẫn cần kiểm tra hiệu suất và độ ổn định.
Vì trách nhiệm của người dùng là tối ưu hóa cơ sở dữ liệu nên AWS không tự động thực hiện việc đó. Do đó, chúng ta cần xây dựng một chiến lược giám sát (monitoring). Ở bài này, sẽ mô tả các quy trình được đề xuất để theo dõi RDS.
Q1: Tại sao muốn giám sát cơ sở dữ liệu?
Phát triển kế hoạch giám sát cơ sở dữ liệu có thể để tìm các mối đe dọa tiềm ẩn trước khi cơ sở dữ liệu thực sự gặp sự cố và giúp giảm thời gian và chi phí sau bảo trì. Hầu hết các nhóm kiến trúc cơ sở hạ tầng AWS đều giám sát các tài nguyên như EC2, ELB, Auto Scaling Groups, logs, etc. Mức độ ưu tiên giám sát cơ sở dữ liệu tương đối thấp. Vì bản thân dịch vụ RDS được hosted bởi AWS nên khách hàng sẽ dễ dàng bỏ qua điều này hơn khi sử dụng dịch vụ RDS. Vì vậy, DBA/kiến trúc sư nên phát triển và triển khai chiến lược giám sát cơ sở dữ liệu.
Chiến lược giám sát tổng thể cho cơ sở dữ liệu rất phức tạp, bao gồm những điều sau đây khi xác định cơ sở dữ liệu nào cần giám sát:
Thỏa thuận cấp độ dịch vụ (SLA)
Loại lỗi được phân loại (near collapse, severe, medium, available, etc.)
Xây dựng các chỉ số RACI (Responsible, Accountable, Consulted, Informed)
Xác định upgrade path, etc.
Q2：Chính xác thì sẽ giám sát những gì?
Giám sát cơ sở dữ liệu, hay RDS, không chỉ tập trung vào hiệu suất mà còn bao gồm các danh mục và mô-đun chính sau:
Hạng mục giám sát | Các trường hợp giám sát |
Availability | – Client có thể kết nối tới RDS instance hoặc cluster không? |
Resilience | – Các RDS instance có được backup không? Các bản backup có tồn tại không? |
Health checks và performance | – CPU, memory, disk space |
Database instance management operations | – Có bất kỳ thay đổi nào đối với DB instance không? |
Security | – Ai được kết nối với DB instance? |
Fee | Một RDS instance có giá bao nhiêu mỗi tháng? |
Một số trường monitoring tham khảo
1. Các built-in metrics có thể sử dụng
RDS instance có các built-in metrics.
Các metrics này có thể được thu thập từ host manager đang chạy RDS virtual machine. Bạn nên theo dõi các metrics RDS sau bằng CloudWatch:
Index | Tại sao bạn cần giám sát |
CPU usage | Giá trị cao liên tục có nghĩa là một hoặc nhiều process bị blocked. |
Disk queue depth | Disk contention do locking, long-running update queries, etc. |
Database connection | Sự cố có thể xảy ra khi ứng dụng tạo nhiều kết nối cho mỗi request |
Free storage space | Dung lượng lưu trữ trống thấp có nghĩa là dung lượng ổ đĩa sẽ hết dung lượng |
Read IOPS | Việc IOPS đọc tăng vọt có thể có nghĩa là số lượng truy vấn quá lớn. |
Write IOPS | Write IOPS bursts có thể chỉ ra rằng một bản cập nhật đã xử lý rất nhiều dữ liệu. |
Read delay | Độ trễ đọc cao có thể có nghĩa là hoạt động của đĩa, có thể bị blocking |
Write delay | Độ trễ ghi cao có thể đồng nghĩa với việc disk contention nhiều hơn |
Amount of free memory | Khi dung lượng bộ nhớ trống thấp, điều đó có thể có nghĩa là không đủ bộ nhớ. |
Replication delay | Độ trễ cao, độ lệch lớn giữa thao tác read-copy và dữ liệu thời gian thực |
Amazon RDS Aurora engine cũng hiển thị các số liệu giám sát bổ sung hữu ích cho việc khắc phục sự cố mà bạn nên theo dõi:
Index | Tại sao bạn cần quan sát |
DDL operation delay | Giá trị cao hơn có nghĩa là cơ sở dữ liệu có vấn đề về hiệu suất khi chạy lệnh DDL. Điều này có thể là do exclusive lock trên đối tượng. |
Query delay | Giá trị cao hơn có thể có nghĩa là xung đột đĩa, câu lệnh truy vấn kém, thiếu chỉ mục, v.v. |
Insertion delay | Giá trị cao hơn có thể có nghĩa là locking hoặc câu lệnh insert không được viết tốt |
Remove delay | Giá trị cao hơn có thể có nghĩa là locked hoặc các câu lệnh DELETE được viết kém |
Update delay | Giá trị cao hơn có thể có nghĩa là locking hoặc câu lệnh cập nhật được viết không tốt |
Deadlock | Nhiều hơn 0 có thể có vấn đề, truy vấn có thể bị blocked |
Cache hit rate | Nó phải là một giá trị gần 100, có nghĩa là truy vấn không cần truy cập vào đĩa để lấy dữ liệu. Đây là mức trung bình ổn định. |
Number of queries | Tăng giảm đột ngột cần kiểm tra nguyên nhân |
2. Performance Insights
Performance view của Performance Insights thu thập dữ liệu từ truy vấn RDS để xác định truy vấn chậm.
Việc bật Performance insights có các lợi ích sau:
Cung cấp bản tóm tắt hiệu suất hàng giờ, theo thời gian thực của các instance.
Có thể theo dõi average active session (AAS) theo thời gian để biết được load của instance.
Load được chia thành 4 phần:
SQL queries；
hosts；
users；
waits
Bất kỳ sự tăng đột biến load nào trong số này đều có thể chỉ ra rằng cơ sở dữ liệu đã đạt đến điểm nghẽn cổ chai.
3. Tự động monitor alerts và sử dụng dashboards
Chúng ta đã biết số liệu RDS nào cần được theo dõi. Vậy nó sẽ được giám sát như thế nào? Trên thực tế, việc giám sát các số liệu được liệt kê ở trên của RDS instance ở trên rất tốn thời gian và việc sử dụng alert và dashboard sẽ cải thiện hiệu quả giám sát:
Dashboard phải bao gồm những nội dung sau:
i) Báo động cho các sự kiện có mức độ ưu tiên cao: ví dụ: các sự kiện liên quan đến độ ổn định của hệ thống cần được xử lý ngay lập tức.
ii) Báo động được xác định theo ngưỡng: Những báo động này có thể không khẩn cấp nhưng cần có sự giám sát
Dashboards phân tích các xu hướng dài hạn, khắc phục sự cố và phân tích các issues lịch sử.
Alert content | Cách nhận ra |
Không thể kết nối các instances hoặc cluster endpoints | Điều này có thể được thực hiện bằng cách chạy Lambda function để kiểm tra tính khả dụng của instance hoặc RDS cluster. Khi một instance hoặc cluster không phản hồi, function này có thể ghi CloudWatch log event để có thể theo dõi. |
Một hoặc nhiều cơ sở dữ liệu trong một instance không thể truy cập được | Điều này có thể đạt được bằng cách theo dõi nhật ký RDS và ghi log các sự kiện vào CloudWatch log. |
Một instance bị stopped | Có thể giám sát thông qua event subscription |
Master failed over sang replica | Có thể giám sát thông qua event subscription |
Các sự kiện có độ ưu tiên như sau:
Alert content | Mức ưu tiên |
Mức sử dụng CPU trên 90% kéo dài hơn 10 phút | High |
Mức sử dụng File system hoặc mức sử dụng đĩa vượt quá 80% | High |
Disk queue depth lớn hơn 2 và kéo dài hơn 10 phút hoặc disk IO average queue length lớn hơn 2 trong 10 phút | High |
Độ trễ đọc lớn hơn 10 mili giây trong 10 phút | High |
Độ trễ ghi lớn hơn 10 mili giây trong 10 phút | High |
Cache hit rate dưới 100% kéo dài hơn 10 phút | High |
Bộ nhớ còn dưới 2M và kéo dài hơn 10 phút | High |
Nên tạo 2 loại dashboards:
Một là widget được tạo bởi high priority metrics được liệt kê ở trên. Đây là điều đầu tiên DBA sẽ kiểm tra trong dashboard.
Thứ hai, general health indicators: read IOPS, write IOPS; delay (SELECT, INSERT, UPDATE, DELETE), database connection, etc. Tất nhiên, bạn có thể tạo alerts và dashboards trong AWS Cloudwatch.
Bạn cũng có thể stream cloudwatch logs đến các tool bên thứ ba nếu cảm thấy cần thiết.
4. Theo dõi nhật ký RDS
Các phiên bản AWS RDS có thể generate log files của riêng chúng.
Database log files có thể giúp người dùng xác định lỗi và khắc phục sự cố về hiệu suất. Các công cụ cơ sở dữ liệu khác nhau có các loại tệp nhật ký khác nhau: MS SQL Server có Error Log và Agent Log; MySQL/MariaDB có General Log, Error Log, Slow Query Log; PostgreSQL có Query và Error Log; Oracle có Analert Log. Khi chi phí cho phép, mỗi khách hàng nên thu thập log từ RDS instance và phân tích các log này để xử lý một số sự kiện quan trọng, chẳng hạn như: cơ sở dữ liệu không thể truy cập hoặc ngoại tuyến, blocked queries, slow queries, daemon failure, deadlock, login failure, replication delay is more serious, instance failure switching, instance shutdown, database maintenance, database version updates, etc.
Bạn có thể truy cập RDS log files theo một số cách: AWS console, AWS command line, REST API calls, CloudWatch log. Từ console, bạn có thể chọn xem logs và bạn cũng có thể tải logs xuống để phân tích.
5. Monitor RDS events
Với Amazon RDS, bạn cũng cần theo dõi các sự kiện liên quan đến db instances:
CÓ CÁC LOẠI SỰ KIỆN RDS KHÁC NHAU:
Event source | Event types involved |
Instance | Các sự kiện liên quan đến database instances |
Security group | Security group events trên database instances |
Parameter group | Các sự kiện liên quan đến RDS parameter group |
Snapshot | Các sự kiện liên quan đến instance snapshots |
DB cluster | Multi-instance cluster-related events |
DB instance cluster snapshot | Multi-instance cluster snapshot-related events |
Các sự kiện có thể bao gồm những điều sau đây:
Các sự kiện liên quan đến tính khả dụng của RDS instances;
Các sự kiện liên quan đến lỗi trong RDS instances;
Các sự kiện liên quan đến vấn đề về dung lượng ổ đĩa trong RDS instances;
Các sự kiện liên quan đến chuyển đổi dự phòng, khởi động và stop RDS instances;
Các sự kiện liên quan đến backups và snapshots của RDS instances;
Các sự kiện liên quan đến bất kỳ thay đổi cấu hình nào trong phiên bản RDS. DBAs hoặc AWS administrators có thể tạo subscriptions cho các events mà họ muốn theo dõi. Khi một sự kiện xảy ra, subscription sẽ gửi thông báo đến người nhận.
6.CloudTrail
Khi một tài khoản kích hoạt AWS CloudTrail, nó sẽ ghi lại các lệnh gọi tới từng API cho bất kỳ tài nguyên AWS nào nằm trong tài khoản đó. CloudTrail logs có thể được lưu trữ trong S3 buckets và có thể được sử dụng để thực hiện kiểm tra tuân thủ và bảo mật. Chúng tôi khuyến khích sử dụng CloudTrail để giám sát RDS.
Ngoài ra, tên sự kiện, ngày và giờ sự kiện, địa chỉ IP để tạo sự kiện, tên người dùng AWS để tạo sự kiện và ID khóa kết nối đều được hiển thị trong nhật ký CloudTrail. CloudTrail Log là tài liệu JSON với nhiều trường. Có nhiều công cụ có thể được sử dụng để phân tích các log này, ví dụ như Athena
Bạn nên theo dõi CloudTrail đối với các lệnh gọi API RDS sau đây:
RDS API CASE | Tại sao nên giám sát |
DeleteDBInstance | Kiểm tra hành vi xóa DB instance |
DeleteDBCluster | Kiểm tra để loại bỏ xóa DB cluster |
ModifyDBInstance | Kiểm tra hành vi sửa đổi DB instance |
ModifyDBCluster | Kiểm tra hành vi sửa đổi DB cluster |
FailoverDBCluster | Ghi lại hành vi forced failover của cluster |
ModifyDBParameterGroup | Kiểm tra hành vi sửa đổi DB Parameter group |
RebootDBInstance | Kiểm tra hành vi khởi động lại DB instance |
PromoteReadReplica | Audit database read copy promotion to database master instance behavior |
StopDBInstance | Kiểm tra hành vi stop DB instance |
Bạn nên kết hợp sử dụng CloudTrail với AWS Config để giám sát.
7. Monitor với Amazon Trusted Advisor
AWS cung cấp dịch vụ Amazon Trusted Advisor để đánh giá xem các tài nguyên trong tài khoản có phù hợp với AWS best practices hay không. Mặc dù AWS Trusted Advisor không phải là công cụ giám sát hiệu suất nghiêm ngặt nhưng nó có thể trợ giúp rất nhiều.
Bạn có thể sử dụng công cụ này cùng với các công cụ khác để thực hiện các biện pháp kiểm tra bảo mật thích hợp trên các idle database instances, unlimited access ở database security groups, các database instances không snapshot, v.v.
Tài liệu đọc thêm: