Init Sentinel – Bài 4: Chiến lược xoay Log ngẫu nhiên và vì sao không cần Cron

Sau khi triển khai logging và ghi nhận đúng các sự kiện 403, câu hỏi tiếp theo luôn xuất hiện là làm sao để bảng log không phình to theo thời gian. Init Sentinel giải quyết bài toán này ngay trong hàm core bằng một chiến lược xoay log ngẫu nhiên, không cần cron và không tạo thêm gánh nặng hệ thống.

Init Sentinel – Bài 4: Chiến lược xoay Log ngẫu nhiên và vì sao không cần Cron

Bài viết này giải thích vì sao cách làm đó là hợp lý trong bối cảnh WordPress, cách nó vận hành, và những giới hạn đã được đặt ra để đảm bảo an toàn.

Vấn đề thực tế: Cron không đáng tin trong WordPress

Trong WordPress, cron không phải là cron thật mà phụ thuộc vào traffic. Trên site ít truy cập, cron có thể không chạy đúng lịch, còn trên site lớn, cron chạy dày có thể tạo áp lực không cần thiết.

Với một hệ thống logging bảo mật, việc phụ thuộc vào cron để dọn log thường dẫn đến hai trạng thái xấu: hoặc log không bao giờ được dọn, hoặc việc dọn log trở thành một tác vụ nặng định kỳ.

Cách Init Sentinel tiếp cận bài toán xoay log

Init Sentinel không coi xoay log là một nhiệm vụ riêng biệt mà là một hành vi phụ trợ gắn liền với vòng đời ghi log.

Mỗi lần ghi log thành công, hệ thống có một xác suất rất thấp để thực hiện cleanup các log cũ dựa trên thời gian lưu trữ.

Cơ chế cleanup ngẫu nhiên trong hàm core

Thay vì chạy cleanup theo lịch cố định, Init Sentinel sử dụng xác suất để kích hoạt việc dọn log.

// Cleanup log cũ theo xác suất
if ( mt_rand(1,100) === 1 ) {
    $days = (int) apply_filters('init_html_sentinel_retention_days', 30);
    if ($days < 1) { $days = 1; } if ($days > 3650) { $days = 3650; }
    $wpdb->query(
        "DELETE FROM {$table}
         WHERE created_at < (UTC_TIMESTAMP() - INTERVAL {$days} DAY)"
    );
}

Với xác suất 1%, cleanup sẽ được phân tán đều theo thời gian, tránh việc dồn tải vào một thời điểm cụ thể.

Vì sao chiến lược này hoạt động tốt

Trong thực tế, số lần ghi log tỷ lệ thuận với mức độ tấn công hoặc hành vi đáng ngờ. Điều này đồng nghĩa với việc khi log tăng nhanh, cleanup cũng được kích hoạt thường xuyên hơn.

Ngược lại, khi hệ thống yên ổn và ít log, bảng log cũng không tăng nhanh đến mức cần cleanup gấp.

Giới hạn retention để tránh sai lệch cấu hình

Init Sentinel không tin tưởng tuyệt đối vào cấu hình bên ngoài. Dù retention có thể chỉnh qua filter, giá trị này luôn bị ép trong khoảng an toàn.

  • Tối thiểu 1 ngày để tránh mất dữ liệu tức thời.
  • Tối đa 10 năm để tránh lỗi logic hoặc query quá nặng.

Giới hạn này đảm bảo hệ thống không tự bắn vào chân khi bị cấu hình sai.

Lưu UTC và tác động đến cleanup

Việc lưu toàn bộ timestamp ở UTC giúp câu lệnh cleanup hoạt động chính xác bất kể timezone WordPress hay PHP được cấu hình thế nào.

Điều này đặc biệt quan trọng khi so sánh thời gian trực tiếp trong MySQL.

Khi nào cần nâng cấp chiến lược xoay log

Chiến lược hiện tại phù hợp với phần lớn website WordPress, kể cả những site có traffic lớn.

Chỉ khi bảng log đạt quy mô rất lớn hoặc cần tuân thủ chính sách lưu trữ nghiêm ngặt, bạn mới nên cân nhắc các giải pháp như partition table hoặc cleanup theo batch riêng.

Kết luận

Xoay log trong Init Sentinel không phải là một tính năng phụ mà là một phần của triết lý thiết kế: đơn giản, phân tán và không phụ thuộc vào cơ chế mong manh.

Với chiến lược cleanup ngẫu nhiên, Init Sentinel giữ được bảng log gọn gàng theo thời gian mà không cần cron, không thêm cấu hình phức tạp và không tạo điểm nghẽn hiệu năng.

Bình luận


  • Không có bình luận.

Init Toolbox

Nhấn Ctrl + \ trên máy tính, hoặc vuốt sang trái ở bất kỳ đâu trên mobile.

Đăng nhập





Đang tải...