Giới Thiệu

Quản lý log là một phần không thể thiếu trong chu trình phát triển của bất kỳ ứng dụng nào. Việc theo dõi log từ sớm là điều lý tưởng, nhưng trong thực tế, log thường bị xếp hạng thấp cho đến khi xảy ra sự cố thực sự. Mặc dù các nhà cung cấp đám mây như AWS CloudWatch hay Google Cloud Logging cung cấp các giải pháp tích hợp, nhưng chúng không phải lúc nào cũng là công cụ tiện lợi hoặc tiết kiệm chi phí cho việc phân tích log sâu hơn.

Một thách thức khác là chia sẻ quyền truy cập. Nếu bạn muốn một đội khác—như hỗ trợ, bảo mật hoặc tuân thủ—xem xét log, bạn có thực sự muốn cấp quyền truy cập AWS hoặc GCP cho họ? Điều đó tạo ra rủi ro không cần thiết, vì môi trường đám mây chứa nhiều tài nguyên nhạy cảm vượt ra ngoài log.

Vậy câu hỏi đặt ra là: làm thế nào để chúng ta xử lý log một cách hiệu quả, an toàn và tiết kiệm chi phí?

Thách Thức Chi Phí của Log

Hầu hết các nền tảng quản lý log (ví dụ: Datadog, Splunk, New Relic, Elastic Cloud) tính phí dựa trên khối lượng dữ liệu tiếp nhận và thời gian lưu trữ. Điều này có nghĩa là chi phí sẽ tăng trực tiếp với:

1. Khối lượng log mỗi tháng (ví dụ: 500GB so với 2TB).
2. Yêu cầu về thời gian lưu trữ (ví dụ: 7 ngày so với 90 ngày).

Ví dụ, việc lưu trữ 1TB log có thể tìm kiếm trong 90 ngày có thể nhanh chóng tiêu tốn hàng nghìn đô la. Nếu bạn không lên kế hoạch trước, bạn có thể sẽ phải trả tiền cho kho dữ liệu nóng trên dữ liệu mà bạn sẽ hiếm khi truy vấn.

Bước 1: Hiểu Yêu Cầu Log của Bạn

Trước khi thiết kế đường ống log của bạn, hãy trả lời các câu hỏi chính sau:

1. Khối lượng log của chúng ta là bao nhiêu?

   • Ví dụ: 2TB/tháng.
   • Thu thập số liệu thực từ CloudWatch, Cloud Logging hoặc máy chủ ứng dụng của bạn.

2. Chúng ta cần log có thể tìm kiếm trong bao lâu?

   • Ví dụ: thời gian lưu trữ 60 ngày.
   • Đôi khi các yêu cầu tuân thủ yêu cầu 90-180 ngày (hoặc hơn).

3. Log của chúng ta được tạo ra và lưu trữ ở đâu?

   • Ví dụ: log được lưu trữ trong AWS S3.
   • S3 là một lựa chọn tuyệt vời cho lớp lưu trữ lạnh: giá rẻ, bền bỉ và thân thiện với nén.

Khi bạn biết được khối lượng + thời gian lưu trữ + nguồn gốc, bạn có thể đưa ra những quyết định kiến trúc tốt hơn.

Bước 2: Tách Biệt Lưu Trữ Nóng và Lạnh

Không phải tất cả log đều cần phải được tìm kiếm ngay lập tức. Để tiết kiệm chi phí, hãy tách log thành:

• Lưu trữ nóng:

  • Thời gian lưu trữ ngắn (ví dụ: 7-14 ngày).
  • Được lập chỉ mục và có thể tìm kiếm trong các công cụ như OpenSearch, Elasticsearch hoặc Datadog.
  • Được sử dụng cho việc gỡ lỗi, giám sát và phản ứng sự cố.

• Lưu trữ lạnh:

  • Thời gian lưu trữ dài (ví dụ: 60-180 ngày).
  • Được lưu trữ một cách rẻ tiền trong S3, Glacier hoặc tương đương.
  • Chỉ được lập chỉ mục lại khi cần thiết (thông qua các script hoặc công việc theo lô).

Phương pháp phân lớp này giảm thiểu chi phí trong khi vẫn giữ dữ liệu lịch sử có sẵn.

Bước 3: Lập Chỉ Mục và Trực Quan Hóa

S3 một mình không thể tìm kiếm—bạn cần một hệ thống có thể lập chỉ mục log và cung cấp trực quan hóa. Các tùy chọn bao gồm:

• Mã nguồn mở:

  • Elasticsearch / Kibana
  • OpenSearch / OpenSearch Dashboards
  • Loki / Grafana

• SaaS thương mại (thiết lập nhanh hơn nhưng đắt hơn):

  • Datadog Logs
  • New Relic
  • Splunk

Mỗi tùy chọn có điểm mạnh và yếu trong việc mở rộng, hiệu suất truy vấn và giá cả. OpenSearch và Loki là sự lựa chọn tuyệt vời cho các đội ngũ tiết kiệm chi phí, trong khi Datadog và Splunk cung cấp sự tiện lợi với mức giá cao hơn.

Bước 4: Gửi Log (Lớp Tiếp Nhận Dữ Liệu)

Để làm cho log có sẵn trong công cụ bạn chọn, bạn cần gửi log từ nguồn đến đích. Các tùy chọn bao gồm:

• AWS-native:

  • Amazon Kinesis Data Firehose – đáng tin cậy, có khả năng mở rộng nhưng đôi khi có thể quá mức cần thiết.

• Các công cụ gửi log nhẹ:

  • Fluent Bit – rất nhanh, tiêu tốn tài nguyên thấp, được sử dụng rộng rãi.
  • Vector (của Datadog) – cấu hình đơn giản, hiệu suất tốt.
  • Filebeat – là một phần của Elastic stack.

Các tác nhân này có thể lấy log từ CloudWatch, Cloud Logging hoặc trực tiếp từ các container ứng dụng và đẩy chúng vào OpenSearch, Elasticsearch hoặc một nền tảng SaaS.

Bước 5: Khôi Phục Log từ Lưu Trữ Lạnh

Khi cần log cũ (cho kiểm toán, điều tra hoặc hậu kiểm), bạn không muốn chúng được lập chỉ mục 24/7. Thay vào đó:

1. Kéo log nén từ S3 (hoặc Glacier).
2. Chạy một script lập chỉ mục lại để nhập chúng vào OpenSearch hoặc Elasticsearch tạm thời.
3. Sau khi điều tra xong, xóa chúng khỏi lưu trữ nóng.

Mô hình “khôi phục theo yêu cầu” này đảm bảo bạn cân bằng giữa hiệu quả chi phí và khả năng truy cập dữ liệu.

Ví Dụ Kiến Trúc

Dưới đây là cách mà các thành phần kết hợp với nhau:

1. Các ứng dụng & dịch vụ tạo ra log.
2. Các tác nhân Fluent Bit / Vector thu thập và chuyển tiếp log.
3. Log chảy vào OpenSearch (lưu trữ nóng) với thời gian lưu trữ khoảng 7 ngày.
4. Song song, log được lưu trữ trong S3 (lưu trữ lạnh) với thời gian lưu trữ 60-180 ngày.
5. Nếu cần log cũ, một script khôi phục lập chỉ mục lại dữ liệu từ S3 vào OpenSearch.
6. Các đội truy cập log một cách an toàn thông qua OpenSearch Dashboards / Kibana, mà không cần quyền truy cập vào bảng điều khiển AWS hoặc GCP.

Những Điều Cần Lưu Ý

• Đừng trả tiền cho lưu trữ nóng trên tất cả log—tách biệt giữa nóng và lạnh.
• Sử dụng các công cụ gửi nhẹ như Fluent Bit hoặc Vector để kiểm soát việc tiếp nhận.
• Tận dụng S3 cho việc lưu trữ—rẻ, đáng tin cậy và thân thiện với nén.
• Cung cấp quyền truy cập thông qua các nền tảng log, không phải bảng điều khiển đám mây—an toàn và dễ dàng hơn cho việc hợp tác.

Bằng cách cấu trúc đường ống log của bạn theo cách này, bạn sẽ đạt được sự cân bằng giữa chi phí, hiệu suất và bảo mật, trong khi vẫn giữ cho đội ngũ của bạn hiệu quả khi xử lý các sự cố.