Log Tập Trung: Khái Niệm và Tại Sao Nó Quan Trọng Trong Microservices (Phần 1)

I. Giới thiệu về log tập trung trong hệ thống microservices

Trong bối cảnh phát triển công nghệ hiện đại, nhiều dự án đã chuyển từ mô hình monolithic sang microservices để nâng cao tính linh hoạt và khả năng mở rộng. Tuy nhiên, sự chuyển đổi này cũng mang lại nhiều thách thức mới, đặc biệt là trong việc quản lý và giám sát log. Dưới đây là những vấn đề chính mà các team thường gặp:

Khó khăn trong quá trình gỡ lỗi (debugging): Một request có thể đi qua nhiều dịch vụ khác nhau. Mỗi dịch vụ tạo ra log riêng, gây khó khăn trong việc xác định lỗi và thời gian truy vết.
Phản hồi chậm đối với sự cố: Thay vì phát hiện lỗi kịp thời, team thường chỉ phát hiện lỗi qua phản hồi từ người dùng.
Khó khăn trong phân tích hiệu suất: Phân tích bottleneck trở nên khó khăn vì cần thu thập log từ nhiều dịch vụ, tiêu tốn thời gian.
Thiếu cái nhìn tổng quan: Không có dashboard thống nhất để theo dõi tình trạng sức khỏe của toàn bộ hệ thống.

Ví dụ, khi một đơn hàng gặp lỗi trong quá trình đặt hàng, nếu hệ thống chỉ có một dịch vụ, bạn chỉ cần tìm kiếm từ khóa error. Tuy nhiên, với hàng chục dịch vụ khác nhau liên quan đến một tác vụ, việc tìm ra nguyên nhân sẽ mất rất nhiều thời gian và dễ dẫn đến nhầm lẫn.

Để giải quyết những thách thức trên, log tập trung ra đời với nhiều mục tiêu hữu ích:

Theo dõi và gỡ lỗi hệ thống: Sử dụng Correlation ID, log tập trung cho phép theo dõi toàn bộ hành trình của một request, giúp gỡ lỗi nhanh chóng.
Giám sát sức khỏe hệ thống: Tự động phát hiện và cảnh báo các bất thường như tăng độ lỗi hoặc latency cao.
Phân tích hiệu suất: Thu thập và hình dung các chỉ số quan trọng như thời gian phản hồi, throughput.
Phân tích dữ liệu kinh doanh: Tổng hợp các chỉ số để hỗ trợ quyết định trong marketing và sản phẩm.
Đảm bảo an ninh và tuân thủ quy định: Lưu trữ đầy đủ audit trail cho các thao tác nhạy cảm và phát hiện sớm các dấu hiệu tấn công.

II. Kiến trúc hệ thống log tập trung

1. Tổng quan kiến trúc

Một hệ thống log tập trung thường bao gồm ba thành phần chính: log collection, storage, và visualization.

Log collection: Thu thập thông tin từ các nguồn log khác nhau, chuẩn hóa định dạng rồi gửi đến storage. Log collection có thể bao gồm hai thành phần nhỏ hơn:
1. Agent: Công cụ nhẹ đi kèm với server để thu thập log.
2. Collector: Trạm trung chuyển, tập trung log từ nhiều agent, lọc dữ liệu và định tuyến đến storage.
Storage: Lưu trữ log lâu dài với khả năng xây dựng index để tối ưu hóa tìm kiếm.
Visualization: Tạo ra các dashboard để người dùng dễ dàng theo dõi và phân tích log.

Ba thành phần này kết hợp với nhau để tạo thành một quy trình xử lý log hoàn chỉnh, đảm bảo tính sẵn sàng và khả năng mở rộng.

2. Mô hình thu thập log

2.1. Pull Model (Thu thập dựa trên polling)

Ưu điểm: Kiểm soát tốt tải hệ thống, dễ debug, không cần cài đặt agent.
Nhược điểm: Độ trễ cao, khó mở rộng, tiêu tốn băng thông.

2.2. Push Model (Thu thập dựa trên sự kiện)

Ưu điểm: Real-time, hiệu quả băng thông, dễ mở rộng.
Nhược điểm: Tốn tài nguyên, phức tạp trong quản lý, vấn đề bảo mật.

3. Kiến trúc log tập trung theo quy mô

Nhỏ (1-10 services): Đơn giản, dễ backup nhưng không có tính dự phòng.
Trung bình (10-50 services): Tách biệt collector và agent, cluster storage giúp tăng tính chịu lỗi.
Lớn (50+ services): Sử dụng message queue như Kafka để tạo layer tin cậy, phù hợp cho các hệ thống lớn và phức tạp.

4. Phương thức thu thập log

4.1. File-based Collection

Mô hình áp dụng: Pull Model
Ưu điểm: Đơn giản, hiệu quả, tiêu tốn ít tài nguyên.
Nhược điểm: Độ trễ, mất mát dữ liệu.

4.2. Direct Shipping

Mô hình áp dụng: Push Model
Ưu điểm: Gửi log theo thời gian thực, không phụ thuộc vào files.
Nhược điểm: Phải thay đổi code ứng dụng.

4.3. Mô hình Sidecar

Mô hình áp dụng: Kết hợp Pull và Push Model
Ưu điểm: Tính isolation cao, dễ scale.
Nhược điểm: Tốn nhiều tài nguyên, tăng độ phức tạp khi vận hành.

III. Kết luận

Xây dựng một hệ thống log tập trung là rất cần thiết khi chuyển từ mô hình monolithic sang microservices. Việc chọn lựa kiến trúc phù hợp dựa trên yếu tố như khả năng của team, latency, và ngân sách. Điều quan trọng là chúng ta cần thiết kế với khả năng mở rộng trong tương lai.

Trong phần tiếp theo, chúng ta sẽ tìm hiểu về các stack phổ biến và cách chọn stack phù hợp dựa trên từng loại dự án cũng như triển khai log với EFK stack.

✏️ System Design VN: https://fb.com/groups/systemdesign.vn
📚 Đọc thêm tài liệu khác: https://roninhub.com/tai-lieu
🎬 Youtube: https://youtube.com/@ronin-engineer
source: viblo