Trong bất kỳ hệ thống IT nào, log chính là tài nguyên quý giá, là bằng chứng để các IT-er có thể biết được tình trạng sức khỏe của hệ thống, hoặc biết hệ thông đang gặp những mối đe dọa nào. Khi ứng dụng lỗi, máy chủ bị sập, hay có hacker xâm nhập, log là thứ duy nhất nói cho bạn biết chuyện gì vừa xảy ra. Tuy nhiên, nếu log chỉ nằm chết trên từng máy chủ riêng lẻ, bạn sẽ không thể xâu chuỗi được vấn đề.
Đó là lý do chúng ta cần một Logging Pipeline. Dưới đây là 3 thành phần chính mà một Logging Pipeline cần có:
Hãy cùng phân tích và xem xem từng công cụ có từng đặc điểm và điểm mạnh của chúng là gì nhé.
Tôi sẽ lập một bảng so sánh các công cụ Shipper cho các bạn dễ hình dung:
Bảng so sánh trực quan các công cụ Shipper
Ví dụ cấu hình Filebeat đẩy thẳng OpenSearch:
output.elasticsearch:
hosts: ["https://your-opensearch-cluster:9200"]
username: "admin"
password: "StrongPassword123!"
index: "filebeat-%{+yyyy.MM.dd}"
Ví dụ cấu hình Vector đẩy thẳng OpenSearch:
[sinks.to_opensearch]
type = "elasticsearch"
inputs = ["my_transform_step"]
endpoints = ["https://your-opensearch-cluster:9200"]
auth.user = "admin"
auth.password = "StrongPassword123!"
mode = "bulk"
---> Nhiều công cụ dùng chung plugin elasticsearch cho cả Elastic và OpenSearch vì API cơ bản tương thích với nhau.
Bạn có thể tự viết một đoạn script Python hoặc Bash lấy log và gọi API này.
Định dạng gói tin JSON gửi qua REST API:
{ "create": { "_index": "my-custom-logs" } }
{ "timestamp": "2026-04-24T12:00:00Z", "level": "ERROR", "message": "Database timeout" }
{ "create": { "_index": "my-custom-logs" } }
{ "timestamp": "2026-04-24T12:00:01Z", "level": "INFO", "message": "Retry successful" }
Lệnh curl đẩy dữ liệu:
curl -X POST "https://your-opensearch-cluster:9200/_bulk" -u admin: password -H "Content-Type: application/json" --data-binary @logs.json
---> Nhược điểm của cách này là bạn phải tự lo khâu lập lịch gửi lại (retry) nếu mạng rớt.
Đó là lý do chúng ta cần một Logging Pipeline. Dưới đây là 3 thành phần chính mà một Logging Pipeline cần có:
- Log Sources: Đây là nguồn sinh ra log/nguồn phát từ máy chủ Linux, Windows, Firewall, Docker hoặc Ứng dụng.
- Log Shippers/Agents: Đây là những công cụ vận chuyển log về nơi lưu trữ, phân tích và phân loại chúng: Syslog, Beats, Fluent Bit, Vector.
- Nơi lưu trữ và phân tích (Backend): OpenSearch
Hãy cùng phân tích và xem xem từng công cụ có từng đặc điểm và điểm mạnh của chúng là gì nhé.
1. Syslog Cổng UDP/TCP 514
Syslog không phải là một phần mềm, nó là một giao thức tiêu chuẩn đã tồn tại vài thập kỷ. Mọi thiết bị mạng (Router, Switch, Firewall) và hệ điều hành Linux đều có thể nói "ngôn ngữ" Syslog. Nó mặc định hoạt động trên cổng 514.- UDP 514: Hoạt động theo cơ chế gửi đi mà không cần ghi nhớ/lưu lại. Thiết bị cứ thế đẩy log đi mà không cần biết đích đến có nhận được hay không. Tốc độ rất nhanh, nhưng nếu đường truyền nghẽn, log sẽ bị mất vĩnh viễn.
- TCP 514: Chậm hơn một chút nhưng an toàn hơn. Nó yêu cầu hai bên phải "bắt tay" (handshake) xác nhận. Đảm bảo log không bị rơi rớt dọc đường.
2. Beats
Beats là một bộ sưu tập các Agent siêu nhẹ viết bằng ngôn ngữ Golang do Elastic phát triển. Dù là sản phẩm của Elastic, chúng hoạt động cực kỳ mượt mà với OpenSearch.- Filebeat: Nhiệm vụ duy nhất là đọc các file log văn bản như /var/log/nginx/access.log, nhận biết khi file có dòng mới và gửi đi. Hỗ trợ xử lý log nhiều dòng multiline - rất hữu ích cho log lỗi Java.
- Winlogbeat: Chuyên gia đọc log của hệ điều hành Windows. Nó móc thẳng vào Windows Event Viewer để lấy các log về Security, System, Application một cách chính xác nhất.
- Metricbeat: Khác với hai dạng trên, Metricbeat không lấy text log. Nó định kỳ lấy các con số Metrics như: CPU đang chạy bao nhiêu %, RAM còn trống bao nhiêu, Disk đọc ghi thế nào.
3. Fluent Bit
Nếu bạn đang chạy Docker hay Kubernetes, Fluent Bit là cái tên bắt buộc phải biết. Được viết bằng ngôn ngữ C, nó tiêu thụ cực kỳ ít RAM (chỉ vài Megabyte).- Điểm mạnh: Kiến trúc Plugin mạnh mẽ. Nó có thể vừa nhận log từ Container, vừa nhận Syslog, thực hiện cắt ghép chuỗi, thêm Tag, và gửi song song đến cả OpenSearch lẫn AWS S3.
4. Wazuh (SIEM)
Bạn cần hiểu rõ: Wazuh không chỉ là một công cụ thu thập log. Nó là một hệ thống giám sát an ninh toàn diện.- Cách hoạt động: Wazuh Agent cài trên máy chủ sẽ quét các thay đổi file (FIM), phát hiện mã độc, và lấy log. Nó gửi mọi thứ về máy chủ trung tâm là Wazuh Manager.
- Tích hợp OpenSearch: Wazuh Manager sẽ dùng chính các tập luật (Rules) của mình để phân tích log. Nếu phát hiện bị tấn công, nó sẽ sinh ra một cảnh báo (Alert) và dùng Filebeat (hoặc Wazuh Indexer) đẩy cảnh báo đó vào OpenSearch.
5. Vector
Vector là một công cụ thế hệ mới, được viết bằng Rust. Ngôn ngữ Rust giúp nó đạt được hai thứ tưởng chừng mâu thuẫn: Tốc độ cực cao (như C) và Độ an toàn bộ nhớ (không bị crash).- Điểm mạnh: Vector có thể đóng vai trò là Agent cài trên máy con, nhưng cũng có thể làm Aggregator (trạm thu gom trung tâm) chịu tải khổng lồ thay thế cho Logstash. Cấu hình của Vector rất rõ ràng theo dạng Nguồn (Sources) -> Chuyển đổi (Transforms) -> Đích (Sinks).
Tôi sẽ lập một bảng so sánh các công cụ Shipper cho các bạn dễ hình dung:
Bảng so sánh trực quan các công cụ Shipper
| Tiêu chí | Syslog | Beats (Filebeat) | Fluent Bit | Wazuh | Vector |
| Ngôn Ngữ | Plain Text | Go | C | C/C++ | Rust |
| Mức Tiêu Thụ Tài Nguyên | Cực thấp | Thấp | Rất thấp | Vừa phải | Rất thấp |
| Hiệu Năng Xử Lý | Tốt | Tốt | Rất tốt | Khá | Xuất sắc |
| Chức Năng Chính | Truyền tải log mạng | Đọc file, lấy metrics | Xử lý đa luồng, K8s | Security, SIEM, XDR | Router log tốc độ cao |
| Phù Hợp Cho | Firewall, Switch, Router | Máy chủ Linux/Window | Docker, Kubernetes | Cẩn cảnh báo an ninh | Xử lý dữ liệu siêu lớn |
Cách đẩy Log vào OpenSearch
Sau khi đã thu thập được log, làm sao để đưa nó vào OpenSearch? Bạn có hai con đường.Cách 1: Sử dụng Output Plugin
Hầu hết các phần mềm trên đều đã viết sẵn mã nguồn để giao tiếp mượt mà với OpenSearch. Bạn chỉ cần cấu hình.Ví dụ cấu hình Filebeat đẩy thẳng OpenSearch:
output.elasticsearch:
hosts: ["https://your-opensearch-cluster:9200"]
username: "admin"
password: "StrongPassword123!"
index: "filebeat-%{+yyyy.MM.dd}"
Ví dụ cấu hình Vector đẩy thẳng OpenSearch:
[sinks.to_opensearch]
type = "elasticsearch"
inputs = ["my_transform_step"]
endpoints = ["https://your-opensearch-cluster:9200"]
auth.user = "admin"
auth.password = "StrongPassword123!"
mode = "bulk"
---> Nhiều công cụ dùng chung plugin elasticsearch cho cả Elastic và OpenSearch vì API cơ bản tương thích với nhau.
Cách 2: Sử dụng REST API (Linh hoạt cho Developer)
OpenSearch cung cấp một API có tên là _bulk. API này cho phép bạn đóng gói hàng nghìn dòng log vào một request HTTP duy nhất để tiết kiệm băng thông.Bạn có thể tự viết một đoạn script Python hoặc Bash lấy log và gọi API này.
Định dạng gói tin JSON gửi qua REST API:
{ "create": { "_index": "my-custom-logs" } }
{ "timestamp": "2026-04-24T12:00:00Z", "level": "ERROR", "message": "Database timeout" }
{ "create": { "_index": "my-custom-logs" } }
{ "timestamp": "2026-04-24T12:00:01Z", "level": "INFO", "message": "Retry successful" }
Lệnh curl đẩy dữ liệu:
curl -X POST "https://your-opensearch-cluster:9200/_bulk" -u admin: password -H "Content-Type: application/json" --data-binary @logs.json
---> Nhược điểm của cách này là bạn phải tự lo khâu lập lịch gửi lại (retry) nếu mạng rớt.
Tổng kết
Để xây dựng hệ thống thu thập log cho OpenSearch thành công, bạn không cần phải dùng tất cả các công cụ trên, mà hãy "chọn mặt gửi vàng":- Nếu thu thập log từ Switch/Firewall: Dùng công cụ trung gian hứng Syslog 514.
- Nếu là Máy chủ truyền thống (VMs): Dài Beats (Filebeat/Winlogbeat).
- Nếu là môi trường Kubernetes/Container: Fluent Bit là vô địch.
- Nếu ưu tiên số 1 là Phát hiện tấn công mạng: Wazuh là giải pháp toàn diện.
- Nếu bạn cần một trạm trung chuyển (Aggregator) chịu tải hàng chục nghìn log/giây: Vector là sự lựa chọn tốt nhất hiện nay.