Chuyện cái Log và nỗi ám ảnh SSH
Chắc anh em không lạ gì cảnh mỗi khi ứng dụng quăng lỗi 500. Việc đầu tiên chúng ta làm thường là mở terminal, SSH vào server, rồi tail -f đống file log rối rắm. Cách này vẫn ổn nếu bạn chỉ quản lý 1-2 server. Tuy nhiên, khi hệ thống bắt đầu phình to với chục con VPS chạy microservices, việc nhảy qua nhảy lại giữa các cửa sổ để tìm nguyên nhân lỗi thực sự là một cực hình.
Mình từng quản lý cụm 15 server với Prometheus và Grafana. Setup này giúp phát hiện sự cố nhanh, nhưng nó chỉ cho biết khi nào hệ thống bất thường (như CPU vọt lên 90%). Để biết tại sao ứng dụng crash, mình vẫn phải lặn lội đi đọc log thủ công. Đó là lúc mình nhận ra mình cần một hệ thống giám sát log tập trung (Centralized Logging) thực thụ.
Tại sao chọn Fluentd và OpenSearch thay vì ELK Stack?
Nhắc đến log, ELK Stack (Elasticsearch – Logstash – Kibana) là cái tên đứng đầu bảng. Nhưng có một vấn đề: ELK cực kỳ ngốn tài nguyên. Logstash chạy trên JVM, chỉ riêng việc khởi động nó thôi đã ngốn mất khoảng 500MB – 1GB RAM.
Sau khi chật vật duy trì ELK trên các con VPS rẻ tiền, mình đã chuyển sang combo Fluentd và OpenSearch. Đây là lý do tại sao nó “ngon” hơn:
- Fluentd: Viết bằng C và Ruby nên cực nhẹ. Nó chỉ tiêu tốn khoảng 40MB – 100MB RAM để xử lý lượng log tương đương với Logstash.
- OpenSearch: Đây là bản fork mã nguồn mở từ Elasticsearch. Nó giữ nguyên sức mạnh tìm kiếm thần tốc nhưng thân thiện hơn về mặt bản quyền (Apache 2.0).
- Hệ sinh thái: Fluentd có hơn 500 plugins. Bạn có thể đẩy log đi bất cứ đâu, từ S3 đến Slack hay Telegram chỉ với vài dòng cấu hình.
Chuẩn bị hệ thống
Để anh em dễ hình dung, mình sẽ dùng Docker Compose để dựng nhanh môi trường thực tế gồm:
- OpenSearch: Trái tim lưu trữ và tìm kiếm dữ liệu.
- OpenSearch Dashboards: Giao diện trực quan để xem log (thay cho Kibana).
- Fluentd: Agent thu thập log và đẩy về kho lưu trữ.
Cài đặt OpenSearch và Fluentd với Docker Compose
Đầu tiên, hãy tạo thư mục dự án. Mình thích dùng Docker vì sau này cần scale hay chuyển server chỉ việc copy folder là chạy ngay.
version: '3'
services:
opensearch:
image: opensearchproject/opensearch:latest
container_name: opensearch
environment:
- cluster.name=opensearch-cluster
- discovery.type=single-node
- bootstrap.memory_lock=true
- "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Giới hạn 512MB RAM cho nhẹ
ulimits:
memlock:
soft: -1
hard: -1
ports:
- 9200:9200
opensearch-dashboards:
image: opensearchproject/opensearch-dashboards:latest
container_name: opensearch-dashboards
ports:
- 5601:5601
environment:
OPENSEARCH_HOSTS: '["https://opensearch:9200"]'
fluentd:
build: ./fluentd
container_name: fluentd
volumes:
- ./fluentd/conf:/fluentd/etc
links:
- "opensearch"
ports:
- "24224:24224"
- "24224:24224/udp"
Lưu ý quan trọng: Fluentd bản gốc chưa có sẵn plugin cho OpenSearch. Chúng ta cần tạo một Dockerfile riêng để cài thêm plugin này:
# Thư mục ./fluentd/Dockerfile
FROM fluent/fluentd:v1.16-debian-1
USER root
RUN gem install fluent-plugin-opensearch
USER fluent
Cấu hình Fluentd để “nuốt” log
Đây là khâu định nghĩa luồng dữ liệu. Chúng ta sẽ bảo Fluentd nghe ở cổng 24224 và đẩy về OpenSearch. Tạo file ./fluentd/conf/fluent.conf:
<source>
@type forward
port 24224
bind 0.0.0.0
</source>
<match *.**>
@type opensearch
host opensearch
port 9200
scheme https
user admin
password admin
ssl_verify false
logstash_format true
logstash_prefix itfromzero-logs
flush_interval 5s
</match>
Trong cấu hình này, mình để flush_interval 5s. Điều này giúp log được đẩy đi gần như ngay lập tức, giúp anh em debug real-time mà không phải chờ đợi lâu.
Kiểm tra thành quả
Gõ lệnh docker-compose up -d rồi đợi khoảng 1 phút. Truy cập http://your-ip:5601 với tài khoản admin/admin.
Để thấy log, hãy làm theo 3 bước:
- Vào Stack Management -> Index Patterns.
- Tạo pattern mới là
itfromzero-logs-*. - Mở mục Discover để tận hưởng thành quả.
Thử đẩy một dòng log giả lập xem sao:
echo '{"message": "Test log từ IT From Zero", "level": "info"}' | fluent-cat debug.test
Dòng log sẽ xuất hiện trên giao diện web ngay tức khắc. Cảm giác này “sướng” hơn nhiều so với việc ngồi gõ grep mỏi mắt giữa hàng vạn dòng text đen trắng.
Kinh nghiệm xương máu từ thực tế
Khi triển khai hệ thống này, mình rút ra được vài bài học đắt giá cho anh em:
- Buffer là bảo hiểm: Hãy cấu hình thêm
<buffer>. Nếu OpenSearch tạm thời bị sập, Fluentd sẽ lưu log vào ổ cứng và đẩy bù lại sau, tránh mất dữ liệu quý giá. - Lỗi quyền truy cập: Nếu cho Fluentd đọc trực tiếp file từ
/var/log, hãy chắc chắn userfluentcó quyềnread. Mình từng mất cả buổi chiều chỉ vì quênchmodfile log. - Tận dụng Docker Log Driver: Bạn có thể cấu hình toàn bộ Docker container trên các server khác đẩy log trực tiếp về Fluentd trung tâm. Cách này giúp bạn không cần cài thêm agent trên từng node con, cực kỳ tinh gọn.
Xây dựng hệ thống log tập trung là bước đi bắt buộc nếu bạn muốn tiến xa hơn trong mảng DevOps hay SRE. Với Fluentd và OpenSearch, bạn đã có một vũ khí đủ mạnh nhưng vẫn đủ nhẹ để chạy mượt mà trên những con VPS rẻ tiền nhất.

