Logging là mớ rác nếu không có discipline càng dùng ELK càng tốn tiền

Sáng có đọc được bài của bác chia sẻ góc nhìn cá nhân. Hôm trước ngồi trà đá với mấy anh em cũ trong nghề, có ông bạn của thằng bạn đi cùng kể chuyện công ty mới chuyển sang dùng ELK để làm logging, bảo:

Bên tôi log chuẩn chỉ, bắn hết vào Elasticsearch, search cực nhanh, dashboard chuẩn xịn.

Chém gió trên dời dưới bể mà cứ ngồi im ngứa mồm quá haha, tôi hỏi nhẹ:

Thế ông bạn có trace ID xuyên service không? Có log rotation chưa? Alert trigger từ log hay metric? Mà cluster giờ tốn bao nhiêu tiền 1 tháng?

Ông bạn im im mấy giây, rồi bảo:

Ờ thì… đang tính làm dần…

Và thế là ngồi chém gió một lúc nói chuyện đúng/sai – tôi gom lại thành bài này, cho gọn nhiều anh em cứ bị ảo tưởng thế nào ấy.

Đừng nhầm giữa việc “có log” với “hiểu hệ thống”. Đừng tưởng cứ gắn ELK vào là mọi thứ gọi là observability.

Tôi nói thẳng: nhiều team log mà như vứt rác vào nhà kho rồi tới lúc cần tìm thì vừa nặng ví, vừa mù mờ.

Cháy X,000 USD chỉ vì log

Cách đây hơn hơn 3 năm trước, một lần team tôi scale hệ thống lên hơn 20 service, mỗi service chạy ít nhất 3 instance. Mỗi instance log khoảng 500MB/ngày (vì log full body, full stacktrace, debug cả query). Tất cả stream về Elasticsearch cluster tầm trung (hot-warm architecture, 6 nodes).

Kết quả:

Chỉ sau 2 tuần, chi phí EBS + Elasticsearch EC2 lên gần X.000 USD – Không tiện tiết lộ lắm lần đó có ông trong team chia sẻ lên mạng và có anh em biết công ty nào rồi (chưa kể S3 backup).
Một nửa log là từ staging, chưa có ILM nên không auto-delete, toàn rác.
Alert bắn loạn vì 90% là log level error nhưng lại chứa cả lỗi timeout tạm thời, không có correlation ID để trace root cause.
Khi cần tìm lỗi cụ thể, mất cả tiếng lọc vì dev log sai format, mỗi service log theo cách khác nhau.

ELK không dành cho đội chưa sẵn sàng

Dùng ELK mà:

Không define index mapping => search chậm như rùa.
Không rotate index theo date hoặc size => cluster chết vì heap.
Không limit field cardinality => cluster vỡ vì có key userId_1, userId_2,…
Không phân tầng hot/warm/cold => tốn chi phí lưu trữ cả log 6 tháng không ai xem.

Và tệ nhất: Không ai trong team hiểu được log đó để debug production.

Bạn log gì? Vì ai? Và để làm gì?

Log mà không trace được theo request ID xuyên suốt microservices thì khác gì đọc nhật ký không ghi tên người viết.
Log mà không có log level, không chuẩn hoá structure thì Prometheus cũng không alert đúng được.

Logging không phải là việc nhét thêm console.log vào code. Đó là cả một quy trình có chiến lược:

Quy định rõ log level và khi nào được dùng.
Tối thiểu hoá log không cần thiết (đặc biệt là debug trong loop hoặc log body nhạy cảm).
Dùng JSON format, chuẩn schema (vd: ts, level, service, traceId, msg).
Kết hợp với trace tool (vd: OpenTelemetry) để chuyển từ log đơn lẻ sang observability có quan hệ.

Vậy giải pháp là gì?

Nếu team chưa có discipline log thì đừng nhảy vào ELK vội. Hãy bắt đầu với:

stdout logging + structured log.
Đẩy log về Loki hoặc Cloud Logging trước.
Định nghĩa log retention, xài ILM policy từ sớm.
Có dev review cả phần log message – xem log có đủ context không, có cần thiết không.

Rồi hãy tính chuyện dùng ELK.

Chẳng biết viết gì nữa

ELK mạnh nhưng không miễn phí, không dễ xài, và không thay thế được tư duy.

Observability không đến từ tool. Nó đến từ việc hiểu hệ thống, log đúng cái cần log, và dùng nó như một phần của quy trình engineering không phải chỉ để show dashboard cho đẹp.

Đừng bro nào nói “team tui xài ELK thấy ổn” mà không show được: