Cấu hình JMX để giám sát hiệu năng node Cassandra
JMX (Java Management Extensions) là giao diện tiêu chuẩn để giám sát các ứng dụng Java, bao gồm Cassandra. Mặc định, Cassandra chỉ lắng nghe JMX trên localhost, cần cấu hình để cho phép các công cụ giám sát như Prometheus hoặc Zabbix truy cập từ xa.
Đầu tiên, xác định file cấu hình JMX của Cassandra nằm tại /etc/cassandra/cassandra-env.sh. Chúng ta sẽ thêm biến môi trường JVM_OPTS để chỉ định địa chỉ IP của node và cổng JMX (mặc định là 7199).
Sửa file cấu hình để mở cổng JMX ra toàn bộ mạng (0.0.0.0) và thiết lập xác thực cơ bản nếu cần (ở đây dùng cấu hình đơn giản cho môi production nội bộ):
sudo nano /etc/cassandra/cassandra-env.sh
Tìm dòng JVM_OPTS hoặc thêm mới nếu chưa có, và bổ sung các tham số sau vào cuối dòng đó:
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=7199 \
-Dcom.sun.management.jmxremote.address=0.0.0.0 \
-Dcom.sun.management.jmxremote.rmi.port=7199 \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false"
Khởi động lại dịch vụ Cassandra để áp dụng thay đổi cấu hình JMX.
sudo systemctl restart cassandra
Kiểm tra kết quả bằng cách sử dụng lệnh netstat hoặc ss để xác nhận cổng 7199 đang lắng nghe trên tất cả các giao diện mạng.
sudo ss -tlnp | grep 7199
Kết quả mong đợi: Bạn thấy dòng output hiển thị 0.0.0.0:7199 và tiến trình java (Cassandra) đang lắng nghe trên cổng này.
Sử dụng nodetool và cqlsh để kiểm tra health của cluster
nodetool là công cụ dòng lệnh mạnh nhất để quản lý và kiểm tra sức khỏe của Cassandra. Nó giao tiếp trực tiếp với JMX của node để lấy thông tin thời gian thực.
Thực hiện lệnh status để xem trạng thái tổng quan của cluster, bao gồm số node đang hoạt động (UN) và node đang khởi động (U).
nodetool status
Kết quả mong đợi: Tất cả các node trong cluster đều hiển thị trạng thái UN (Up/Normal). Nếu thấy UN ở cột State và Data Center chính xác, nghĩa là cluster khỏe mạnh.
Để kiểm tra độ trễ và thông số phân vùng, sử dụng lệnh tpstats (Thread Pool Stats) để xem các queue đọc/đăng ký.
nodetool tpstats
Kết quả mong đợi: Các giá trị Current và Completed ổn định. Quan trọng nhất là giá trị Blocked phải bằng 0. Nếu Blocked tăng cao, cluster đang bị quá tải.
Sử dụng cqlsh để kiểm tra tính nhất quán của dữ liệu và cấu hình schema từ góc độ truy vấn.
cqlsh -u cassandra -p cassandra
Trong giao diện CQL, chạy lệnh kiểm tra các chỉ số quan trọng của bảng.
DESCRIBE KEYSPACE system_auth;
Kiểm tra số lượng partition và hành động TRACING để phân tích truy vấn chậm.
TRACING ON;
SELECT * FROM system_auth.roles LIMIT 5;
TRACING OFF;
Kết quả mong đợi: Truy vấn trả về dữ liệu ngay lập tức, bảng Tracing hiển thị thời gian thực thi của từng bước (Coordinator, Node 1, Node 2...) dưới 100ms.
Tự động hóa backup dữ liệu bằng công cụ sstables
Backup trong Cassandra nên thực hiện ở cấp độ file sstables để tránh khóa dữ liệu (snapshot). Cassandra sử dụng cơ chế Copy-on-Write, nên backup không ảnh hưởng hiệu năng ghi.
Tạo snapshot cho toàn bộ keyspace cần backup. Lệnh này tạo một thư mục snapshot trong dữ liệu mà Cassandra sẽ tự động cập nhật khi có file mới.
nodetool snapshot -t backup_prod_$(date +%F_%H%M) system_auth
Thay thế system_auth bằng tên keyspace thực tế của bạn. Sau khi tạo snapshot, tiến hành copy các file sstables ra vị trí lưu trữ ngoài (backup server hoặc S3).
Xác định đường dẫn thư mục dữ liệu của Cassandra (mặc định là /var/lib/cassandra/data) và tìm thư mục snapshot vừa tạo.
ls -la /var/lib/cassandra/data/system_auth/backup_prod_2023-10-27_1430/
Viết script bash để tự động hóa quá trình này: tạo snapshot, nén và lưu trữ, sau đó xóa snapshot cũ để tiết kiệm dung lượng.
cat > /usr/local/bin/cassandra_backup.sh
Cấp quyền thực thi cho script và thiết lập crontab để chạy tự động hàng ngày lúc 2 giờ sáng.
chmod +x /usr/local/bin/cassandra_backup.sh
(crontab -l 2>/dev/null; echo "0 2 * * * /usr/local/bin/cassandra_backup.sh >> /var/log/cassandra_backup.log 2>&1") | crontab -
Để verify kết quả, kiểm tra thư mục backup có file .tar.gz mới nhất và kích thước hợp lý.
ls -lh /backup/cassandra/system_auth/
Kết quả mong đợi: Có thư mục với ngày tháng hiện tại chứa file sstables.tar.gz và file log backup thành công.
Thiết lập cảnh báo (alerting) cho các lỗi phổ biến
Giám sát chủ động là yếu tố sống còn. Chúng ta sẽ tập trung vào hai lỗi phổ biến nhất: GC overhead (Gatherer) và Request Timeout.
Cấu hình nodetool để xuất dữ liệu ra file log định kỳ, sau đó dùng script đơn giản để quét các ngưỡng cảnh báo.
Tạo file script cảnh báo check_cassandra_health.sh để kiểm tra GC và Timeout.
cat > /usr/local/bin/check_cassandra_health.sh
Cấp quyền thực thi và thêm vào crontab để chạy mỗi 5 phút.
chmod +x /usr/local/bin/check_cassandra_health.sh
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/check_cassandra_health.sh") | crontab -
Để test cảnh báo, chúng ta có thể tạo tình huống giả lập hoặc kiểm tra log file xem script đã chạy chưa.
/usr/local/bin/check_cassandra_health.sh
cat /var/log/cassandra/system.log | grep "Request timed out" | wc -l
Kết quả mong đợi: Script chạy không lỗi, và nếu có sự cố thực tế (hoặc giả lập), email cảnh báo sẽ được gửi. Log của cron (/var/log/syslog) sẽ ghi lại việc script đã được thực thi đúng lịch.
grep "check_cassandra_health" /var/log/syslog | tail -5
Điều hướng series:
Mục lục: Series: Triển khai Database phân tán với Apache Cassandra và Ubuntu 24.04
« Phần 5: Quản lý dữ liệu: Chèn, đọc và các mẫu truy vấn hiệu suất cao
Phần 7: Khắc phục sự cố và các mẹo nâng cao để vận hành ổn định »