Một cuộc thảo luận gần đây về các chiến lược logging trong các hệ thống có lưu lượng cao đã khơi mào một cuộc tranh luận thú vị giữa các nhà phát triển. Cuộc trò chuyện tập trung vào việc liệu các ứng dụng nên ghi log tiến trình mỗi X giây (theo thời gian) hay mỗi X mục được xử lý (theo số lượng), nhưng phản hồi từ cộng đồng đã tiết lộ một vấn đề sâu xa hơn về mục đích cơ bản của logging.
Vấn đề cốt lõi với các phương pháp Logging truyền thống
Đề xuất ban đầu cho rằng logging theo thời gian cung cấp tốc độ đầu ra nhất quán hơn so với logging theo số lượng. Trong các hệ thống có thể xử lý hàng triệu sự kiện mỗi giây trong môi trường sản xuất nhưng chỉ một vài sự kiện trong quá trình thử nghiệm cục bộ, logging theo số lượng tạo ra khối lượng log rất khác nhau. Logging theo thời gian nhằm giải quyết vấn đề này bằng cách duy trì đầu ra ổn định bất kể tốc độ xử lý.
Tuy nhiên, các nhà phát triển có kinh nghiệm trong cộng đồng đã nhanh chóng xác định một vấn đề cơ bản hơn. Cuộc tranh luận không thực sự về các chiến lược thời gian - mà là về việc nhầm lẫn giữa logs và metrics. Sự phân biệt này quan trọng vì mỗi loại phục vụ các mục đích khác nhau và nên được xử lý khác nhau.
So sánh Logging dựa trên Số lượng và dựa trên Thời gian
| Phương pháp | Ưu điểm | Nhược điểm |
|---|---|---|
| Dựa trên Số lượng | • Sử dụng bộ nhớ có giới hạn<br>• Tiêu thụ tài nguyên có thể dự đoán<br>• Triển khai đơn giản | • Tốc độ log không nhất quán<br>• Khả năng mở rộng kém giữa các môi trường<br>• Khối lượng đầu ra thay đổi |
| Dựa trên Thời gian | • Tốc độ đầu ra log nhất quán<br>• Hoạt động độc lập với môi trường<br>• Khối lượng log có thể dự đoán | • Có thể sử dụng bộ nhớ không giới hạn<br>• Triển khai phức tạp hơn<br>• Nhu cầu lưu trữ dữ liệu thay đổi |
Logs so với Metrics: Hiểu sự khác biệt
Cộng đồng nhấn mạnh rằng logs nên ghi lại các sự kiện và thông tin trạng thái cụ thể, trong khi metrics nên theo dõi các phép đo và thống kê. Logs được dùng để ghi lại các sự kiện thú vị như lỗi, thay đổi trạng thái, hoặc các sự cố đáng chú ý xảy ra. Ngược lại, metrics đo lường những thứ như tốc độ xử lý, hiệu suất hệ thống và thống kê vận hành.
Một mục log nên ghi lại một sự kiện trong thời gian, ví dụ: một người đăng nhập, một lỗi, một bản ghi về một sự kiện đáng chú ý xảy ra, v.v. Ngược lại, một metric là một giá trị đơn lẻ, ghi lại kích thước của một thứ gì đó tại một thời điểm, được đo bằng đơn vị hoặc với một chiều kích.
Sự phân tách này quan trọng vì việc trộn lẫn hai loại này tạo ra vấn đề. Khi metrics được nhúng trong logs, chúng trở nên phụ thuộc vào các mức log, khó phân tích hơn, và buộc các ràng buộc thời gian bao gồm các hoạt động I/O không cần thiết.
Sự khác biệt chính: Logs và Metrics
- Logs: Ghi lại các sự kiện cụ thể, thay đổi trạng thái, lỗi và các sự cố đáng chú ý tại thời điểm chúng xảy ra
- Metrics: Đo lường hiệu suất hệ thống, tốc độ xử lý và thống kê hoạt động theo thời gian
- Lưu trữ: Logs thường được lưu trữ dưới dạng text/ JSON ; metrics được lưu trữ trong cơ sở dữ liệu chuỗi thời gian
- Phân tích: Logs được tìm kiếm và lọc; metrics được tổng hợp và trực quan hóa
- Thời gian: Logs được ghi khi các sự kiện xảy ra; metrics được thu thập định kỳ
Các giải pháp Observability hiện đại
Cuộc thảo luận tiết lộ cách các nền tảng observability hiện đại đã phát triển để xử lý những thách thức này. Các công cụ như Datadog , Honeycomb , và các hệ thống được xây dựng trên tiêu chuẩn OpenTelemetry cho phép các nhà phát triển phát ra dữ liệu có cấu trúc có thể được phân tích theo nhiều cách khác nhau. Các nền tảng này có thể xử lý các sự kiện riêng lẻ và cho phép người dùng tạo các chế độ xem metrics tùy chỉnh mà không cần tổng hợp dữ liệu trước.
Phương pháp này mang lại những lợi thế đáng kể cho việc gỡ lỗi và phân tích hệ thống. Các nhà phát triển có thể theo dõi các phiên người dùng riêng lẻ qua nhiều dịch vụ, lọc dữ liệu theo các thuộc tính cụ thể, và đi sâu từ metrics cấp cao xuống các trace riêng lẻ khi có vấn đề phát sinh.
Các cân nhắc triển khai thực tế
Đối với các hệ thống thực sự cần logging tiến trình, một số thành viên cộng đồng đã đề xuất các phương pháp kết hợp. Những phương pháp này kết hợp ngưỡng thời gian và số lượng, ghi log khi một trong hai điều kiện được đáp ứng. Điều này cung cấp việc sử dụng bộ nhớ có giới hạn trong khi duy trì tốc độ đầu ra hợp lý.
Một số nhà phát triển cũng chỉ ra các ràng buộc tài nguyên với logging thuần túy theo thời gian. Việc giữ lượng dữ liệu thay đổi trong các khoảng thời gian cố định có thể tiêu thụ bộ nhớ không giới hạn, trong khi các phương pháp dựa trên số lượng sử dụng tài nguyên có thể dự đoán được.
Con đường phía trước
Sự đồng thuận của cộng đồng cho thấy rằng hầu hết các tình huống theo dõi tiến trình được phục vụ tốt hơn bởi các hệ thống metrics thích hợp thay vì logs. Logs nên tập trung vào việc ghi lại các sự kiện và lỗi có ý nghĩa, trong khi metrics nên xử lý các phép đo hiệu suất và thông lượng.
Đối với các nhóm mới bắt đầu với các hệ thống có lưu lượng cao, điều này có nghĩa là đầu tư vào cơ sở hạ tầng observability thích hợp từ sớm. Các công cụ hiện đại giúp việc phân tách mối quan tâm một cách thích hợp dễ dàng hơn và cung cấp khả năng gỡ lỗi tốt hơn so với các phương pháp logging truyền thống.
Cuộc tranh luận làm nổi bật cách các quyết định kiến trúc hệ thống có vẻ đơn giản trên bề mặt thường tiết lộ các nguyên tắc thiết kế sâu xa hơn. Trong trường hợp này, câu hỏi về khi nào nên ghi log đã dẫn đến các cuộc thảo luận quan trọng về mục đích cơ bản của các công cụ observability khác nhau.
Tham khảo: Log by Time, not by Count