3.2 Phân tích và lựa chọn công nghệ
3.2.7 Hệ thống thu thập và quản lý log
Cách thức thu thập log phổ biến hiện nay cho các cluster là sử dụng các log collector trên các máy triển khai nhằm thực hiện nhiệm vụ phân giải nội dung log thành các trường thông tin và gửi về hệ thống lưu trữ. Để cung cấp khả năng tìm kiếm nhanh cho người sử dụng, log thường được lưu và đánh chỉ số trong elasticsearch.
Kibana, một công cụ khám phá trực quan và hỗ trợ phân tích dữ liệu thời gian thực cho elasticsearch, sẽ được sử dụng như giao diện tìm kiếm log cho người dùng.
Như vậy, các giải pháp quản lý log khác biệt cơ bản nhất ở thành phần log
collector. Trong thế giới mã nguồn mở, hai log collector phổ biến nhất là Logstash và Fluentd, đại diện cho hai stack công nghệ ELK và EFK.
Điểm khác biệt cơ bản của Logstash và Fluentd được thể hiện trong bảng sau
[20]:
Log collector Phương pháp
định tuyến log
Tầng giao vận Hiệu năng
Log stash Dựa vào các lệnh theo thuật toán
Cần triển khai với Redis để đảm bảo độ tin cậy
Sử dụng nhiều bộ nhớ hơn. Sử dụng Elastic Beats cho các lá.
Fluentd Dựa vào các thẻ Độ tin cậy được tích hợp sẵn nhưng khó cấu hình Sử dụng ít bộ nhớ hơn. Dùng Fluent Bit và Fluentd Forwarder cho các lá. Bảng 3-2: So sánh Logstash và Fluentd
Logstash định tuyến tất cả dữ liệu log vào một luồng và sử dụng các câu lệnh
theo dạng if-else để gửi dữ liệu tới đúng đích. Ví dụ: output {
if [loglevel] == "ERROR" and [deployment] == "production" { pagerduty {
... } } }
Fluentd sử dụng các thẻ để định tuyến các sự kiện log. Mỗi một sự kiện của
Fluentd được gắn một thẻ để giúp Fluentd biết địa điểm mà sự kiện muốn gửi đến. Ví
dụ: Để gửi sự kiện lỗi trong môi trường production tới Pager Duty, cấu hình của
Fluentd được viết như sau: <match production.error> type pagerduty
…
</match>
Cách tiếp cận của Fluentd mang tính khai báo cao, cho phép người dùng thực hiện các phương án định tuyến phức tạp với cú pháp đơn giản và gọn gàng.
Về tầng giao vận, Logstash thiếu hàng đợi tin nhắn persistent: Logtash chỉ có
hàng đợi trong bộ nhớ với kích thước lưu trữ tầm 20 sự kiện
(https://github.com/elastic/logstash/issues/2605 ). Để đảm báo tính persistent cho các
lần khởi động lại, Logstash cần được sử dụng kèm với các hàng đợi ngoài như Redis. Ngược lại, Fluentd có hệ thống bộ nhớ đệm với khả năng cấu hình cao. Bộ nhớ
đệm có thể ở dạng in-memory hoặc on-disk, giúp đảm bảo tính ổn định lâu dài.
Về hiệu năng, Logstash tiêu thụ nhiều bộ nhớ hơn Fluentd (120MB vs 40MB).
Đây là một con số nhỏ trên mỗi máy nhưng khi số lượng các máy trong cluster tăng
lên, sự chênh lệch về tiêu thụ bộ nhớ sẽ ngày một nhân lên và ảnh hưởng tới hiệu năng của cả cluster.
Với hệ thống vi dịch vụ sử dụng container, số lượng container là rất lớn với khối lượng và chủng loại log khổng lồ. Do vậy sử dụng Fluentd sẽ giúp người vận hành cấu hình được cách thức định tuyến log linh hoạt, đảm bảo độ tin cậy mà không cần cài đặt thêm các dịch vụ ngồi và tối ưu hóa tài nguyên cũng như hiệu năng sử dụng.
Hình 3.11: Luồng sử dụng cơ bản Fluentd với Elasticsearch và Kibana