Khi nào lượng log thực sự trở thành vấn đề?
Lượng log trở thành vấn đề khi một trong ba dấu hiệu sau xuất hiện: màn hình tra cứu log chậm đến mức người vận hành bỏ dùng, hoá đơn lưu trữ cloud tăng đều mỗi tháng dù số người dùng không tăng tương ứng, hoặc lúc có sự cố thì không ai lấy ra được đúng đoạn log cần xem.
Con số "hàng chục triệu dòng" tự nó chưa phải là vấn đề. PostgreSQL hay MySQL vẫn xử lý được bảng cỡ đó nếu bảng được chia theo thời gian và câu truy vấn luôn có điều kiện ngày giờ. Trong các hệ thống VAON từng xem lại, nguyên nhân thường gặp hơn là:
- Log nằm chung cơ sở dữ liệu với dữ liệu nghiệp vụ, nên mỗi lần ghi log là một lần tranh tài nguyên với chính ứng dụng.
- Log debug vẫn bật ở môi trường production từ lúc phát triển.
- Xoá log cũ bằng `DELETE` từng dòng, chạy lâu và làm phình bảng thay vì làm nhẹ đi.
- Mọi loại log, từ log truy cập đến log thao tác của quản trị viên, cùng một thời hạn lưu.
Vì vậy, câu hỏi đầu tiên không phải là "đổi sang công nghệ nào" mà là "đang giữ những log gì, ai cần đọc, và cần đọc trong bao lâu".
Phải giữ log bao lâu, và có phải giữ tất cả không?
Thời hạn lưu log không có một con số chung cho mọi hệ thống. Thời hạn phụ thuộc vào ngành, hợp đồng với khách và loại log.
Ba nguồn hay được nhắc tới cho thấy rõ điều này:
- Luật bảo vệ thông tin cá nhân của Nhật (APPI). Hướng dẫn chung (通則編) của Uỷ ban Bảo vệ Thông tin Cá nhân (PPC) đưa ra ví dụ về biện pháp an toàn như ghi lại tình trạng sử dụng hệ thống (lịch sử đăng nhập, log truy cập) và định kỳ phân tích log để phát hiện truy cập trái phép. Hướng dẫn không quy định thời hạn lưu cố định cho log hệ thống.
- PCI DSS (chuẩn bảo mật dữ liệu thẻ thanh toán). Yêu cầu 10.5.1 bắt buộc giữ lịch sử audit log ít nhất 12 tháng, trong đó 3 tháng gần nhất phải sẵn sàng để phân tích ngay.
- GDPR (châu Âu). Nguyên tắc giới hạn lưu trữ yêu cầu không giữ dữ liệu cá nhân lâu hơn mức cần thiết. Log có địa chỉ IP hay mã người dùng cũng thuộc diện này. Giữ "tất cả, mãi mãi" vì thế cũng là một rủi ro.
Nói cách khác, "xoá log để tiết kiệm là vi phạm pháp luật" là cách nói quá. Điều cần làm là quyết định thời hạn cho từng loại log và ghi lại lý do.
Bốn cách giảm chi phí lưu trữ log, từ thay đổi nhỏ đến lớn
Bốn cách dưới đây xếp theo mức thay đổi hệ thống tăng dần. Nên làm theo thứ tự, vì nhiều hệ thống đã đủ nhẹ sau bước 1 và 2.
Chia theo thời gian là bước hay bị bỏ qua nhất. Khi bảng log chia theo ngày hoặc tháng, xoá log hết hạn chỉ là bỏ một partition, chạy trong tích tắc, không cần `DELETE` hàng triệu dòng.
Chuyển log cũ sang kho rẻ hơn (hot/cold tiering) giữ log gần đây ở chỗ tra cứu nhanh, còn log cũ chuyển sang object storage như Amazon S3. Ví dụ với yêu cầu PCI DSS ở trên, 3 tháng gần nhất nằm ở kho nhanh, 9 tháng còn lại nằm ở kho rẻ. Trước khi chuyển, hãy thử lấy lại một ngày log cũ và đo thời gian, vì lúc điều tra sự cố không ai muốn chờ.
Cơ sở dữ liệu dạng cột như ClickHouse lưu từng cột riêng, nên dữ liệu log vốn lặp lại nhiều thường nén tốt. ClickHouse còn cho đặt TTL (thời gian sống) để tự chuyển dữ liệu sang ổ khác hoặc xoá theo tuổi, ví dụ giữ log lỗi 6 tháng nhưng log thường chỉ 1 tháng. Mức nén thật phụ thuộc vào dữ liệu của bạn. Hãy nạp thử một tuần log thật rồi đo, thay vì tin vào con số chung.
Ghi log bất đồng bộ có làm ứng dụng nhanh hơn không?
Ghi log bất đồng bộ giúp ứng dụng không phải chờ ghi log xong mới trả kết quả cho người dùng. Ứng dụng đẩy log vào hàng đợi hoặc một tiến trình thu gom (như Vector hay Fluent Bit), phần ghi vào kho để tiến trình đó lo.
Cách này có cái giá riêng mà người ra quyết định nên biết:
1. Có thể mất log. Nếu bộ đệm nằm trong bộ nhớ và tiến trình chết, phần log chưa ghi sẽ mất. Với log kiểm toán, cần hàng đợi ghi xuống đĩa và có cơ chế gửi lại.
2. Có thể dừng mà không ai biết. Đường ống log ngừng chạy thì ứng dụng vẫn chạy bình thường. PCI DSS (yêu cầu 10.7) cũng yêu cầu phát hiện và xử lý kịp thời khi cơ chế ghi audit log bị lỗi. Cần cảnh báo khi lượng log về kho giảm bất thường.
3. Thêm thành phần phải vận hành. Kafka hay một hàng đợi riêng là thêm máy chủ, thêm việc nâng cấp, thêm điểm có thể hỏng.
Ghi bất đồng bộ không làm độ trễ bằng 0. Ghi bất đồng bộ chuyển phần việc nặng ra khỏi đường xử lý request, và đổi lại bạn phải lo thêm độ tin cậy của đường ống log.
Khi nào không nên đổi kiến trúc log?
Không nên đổi kiến trúc log khi lượng log còn nhỏ, câu truy vấn hiện tại vẫn đủ nhanh, hoặc đội vận hành chưa có người quen với hệ thống mới. Một cụm ClickHouse hay Kafka tự vận hành cần người theo dõi, sao lưu và nâng cấp. Với một hệ thống vài triệu dòng log mỗi tháng, chi phí người vận hành có thể lớn hơn khoản tiết kiệm lưu trữ.
Dịch vụ log có sẵn của nhà cung cấp cloud cũng là một lựa chọn hợp lý. Đổi lại, chi phí sẽ tăng theo lượng dữ liệu nạp vào, nên vẫn phải làm bước 1 (bỏ log thừa) trước.
Nếu sau bước 1 và 2 mà truy vấn đã đủ nhanh và hoá đơn đã ổn, dừng ở đó là quyết định đúng.
VAON bắt đầu từ đâu khi xem lại hệ thống log?
VAON có đội hạ tầng riêng, phụ trách cả vận hành máy chủ lẫn kiểm thử bảo mật. Khi khách nhờ xem lại hệ thống log, đội hạ tầng bắt đầu bằng số liệu thật chứ không bằng công nghệ: lượng log mỗi ngày theo từng loại, những câu truy vấn người vận hành hay dùng, và thời hạn lưu mà hợp đồng hoặc quy định của khách yêu cầu. Từ đó mới chọn dừng ở bước nào trong bốn bước ở mục 3.
Thời hạn lưu log cũng cần được viết thành văn bản, không chỉ nằm trong cấu hình. Với ONEBOT, dịch vụ AI chatbot do VAON vận hành, điều khoản sử dụng ghi rõ dữ liệu của khách được giữ 30 ngày sau khi chấm dứt hợp đồng rồi xoá hoặc ẩn danh, còn bản sao lưu và audit log được xoá theo chu kỳ cập nhật hệ thống. Người dùng biết trước log của mình nằm ở đâu và khi nào bị xoá.
SIer và agency vận hành cho nhiều khách nên ghi gì vào hợp đồng?
SIer và agency vận hành hệ thống cho nhiều khách với phí cố định hằng tháng chịu rủi ro lớn nhất khi log tăng: chi phí lưu trữ tăng nhưng phí thu về thì không. Năm điểm sau nên được thoả thuận từ đầu:
1. Thời hạn lưu của từng loại log, và ai quyết định thay đổi.
2. Ai được xem log, xem qua công cụ nào.
3. Log được lưu ở quốc gia nào, ở nhà cung cấp cloud nào.
4. Khi kết thúc hợp đồng, log được bàn giao theo định dạng nào hay bị xoá.
5. Khi lượng log vượt một mức nhất định, phí vận hành thay đổi ra sao.
Điểm 5 thường bị bỏ quên. Ghi sẵn một ngưỡng (ví dụ theo dung lượng mỗi tháng) giúp cả hai bên không phải thương lượng lại lúc hoá đơn đã tăng. Điểm 3 cũng là câu hỏi đầu tiên bộ phận bảo mật của khách thường đặt ra khi duyệt một dịch vụ SaaS, chi tiết trong bài 5 câu hỏi bảo mật cần trả lời trước khi duyệt AI chatbot cho doanh nghiệp. Nếu bạn đang chọn một AI chatbot để bán lại cho khách, các câu hỏi tương tự về dữ liệu có trong bài so sánh tự phát triển, bán lại và OEM AI chatbot cho agency và SIer.
Log đang làm chậm hệ thống hoặc làm hoá đơn cloud tăng mỗi tháng? Hãy cho VAON biết lượng log, loại log và thời hạn bạn cần giữ. Đội hạ tầng sẽ cùng bạn xem nên dừng ở bước nào.
Tài liệu tham khảo
- Uỷ ban Bảo vệ Thông tin Cá nhân Nhật Bản (PPC), "Hướng dẫn về Luật Bảo vệ Thông tin Cá nhân (通則編)", mục 10-3, 10-6: https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
- Microsoft Learn, "Microsoft Entra ID and PCI-DSS Requirement 10" (trích nguyên văn yêu cầu 10.5.1): https://learn.microsoft.com/en-us/entra/standards/pci-requirement-10
- ClickHouse Docs, "Manage data with TTL (time-to-live)": https://clickhouse.com/docs/guides/developer/ttl