Bạn đã từng rơi vào tình trạng khi sử dụng một ứng dụng xảy ra lỗi không biết lỗi chỗ nào chưa? Hay hoặc vào một ngày “đẹp trời” nào đó mà server của bạn “bỗng dưng” hoạt động quá công suất mặc dù chưa chạy bất kỳ thứ gì chưa?
Nếu bạn đang là lập trình viên phát triển ứng dụng phần mềm, đã từng gặp phải những tình huống trớ trêu như trên thì quả thật bài viết này là dành cho bạn đấy!!!
Đối với ngành nghề mà việc trao đổi thông tin và thao tác trên các ứng dụng thì luôn được lưu lại những hành vi và nhập liệu của bạn. Đối với người dùng, điều này nghe có vẻ không cần thiết vì chả ai đọc lại cả đống thao tác cả. Thế nhưng với lập trình viên thì nó lại khác đấy. Nếu có lỗi phát sinh một cách bất thường mà bạn không thể tái hiện lại được thì lập trình viên còn một thứ để làm nơi bấu víu tìm và nguyên nhân của vấn đề.

Log là gì?
Bạn vẫn chưa biết log là gì đúng không nào? Logging – Một trong những giải pháp khiến cho lập trình viên đỡ cực khổ hơn. Chuyên môn một chút thì việc ghi log là một trong những thao tác lưu lại dấu vết của các thông tin, hành vi, sự kiện, thông báo,… trong quá trình xử lý một đoạn code, một hàm, một chức năng hay một ứng dụng nào đó.
Các hệ thống dù lớn hay nhỏ đều cần quan tâm đến quá trình ghi lại log để nắm được hệ thống vận hành ra sao và dễ dàng tìm ra được nguyên nhân của những lỗi phát sinh trong quá trình vận hành và sử dụng.
Một số anh em mới vào ngành chủ quan nghĩ rằng khi có lỗi thì chúng ta chỉ cần debug là ra. No no no. Ngồi xuống đây để mình nói cho mà nghe sự lợi hại của log.
Các hệ thống dù lớn hay nhỏ đều cần quan tâm đến quá trình ghi lại log để nắm được hệ thống vận hành ra sao và dễ dàng tìm ra được nguyên nhân của những lỗi phát sinh trong quá trình vận hành và sử dụng.
Một số anh em mới vào ngành chủ quan nghĩ rằng khi có lỗi thì chúng ta chỉ cần debug là ra. No no no. Ngồi xuống đây để mình nói cho mà nghe sự lợi hại của log.
Có nhiều lỗi phát sinh khi người dùng cuối và khách hàng sử dụng. Và họ thường chỉ để lại lời nhắn “Chức năng A bị sai. Sửa lại em nhé!!” . Bạn chẳng thể nào yêu cầu khách “Anh ơi. Anh làm lại như vừa nãy để em debug với” được. Và thế là hành trình tìm bug dựa theo lời nhắn “đơn giản” đó lại “phức tạp” hơn phải không nào? À thôi. Lấy ví dụ giả định làm gì. Mình lấy ví dụ thực tế mà mình từng chứng kiến luôn nha. Chắc bạn cũng để ý là bữa nay “trending đào coin” vẫn còn nổi lắm phải không nào? Hồi bữa tụi mình phát hiện ra rằng tự dưng server mà tụi mình thuê bỗng dưng “nặng bất thường”.
Để không cũng chạy lên tới tận hơn 70%. Lên tới từng đấy là server cũng lag lắm rồi các bạn ạ. Cũng may thay là hồi nớ cũng có cài log vào cho server đấy. Thế là tụi mình nhảy vào đọc log ngay và phát hiện được có dấu vết vài bạn đang “mượn” server đó để đào coin. Và sau đó…. Tất nhiên là không có sau đó nữa. Làm gì có chuyện mình thuê server để cho người khác đem đi đào coin mà phải không. Tới đây thì cho mình hỏi “liệu debug có xử lý được mấy trường hợp kia không ấy nhờ” ?

Đến đây chắc bạn cũng hiểu được phần nào tầm quan trong của logging rồi nhỉ?
Vậy chúng ta sẽ log những gì?
Điều này thì tùy thuộc vào hệ thống bạn xây dựng, những dữ liệu trao đổi qua lại cùng những thành phần khác, hay đơn giản là các bước hành vi, các hàm chứ năng và các services gọi qua lại với nhau. Mình nghĩ nên log lại. Tuy nhiên bạn nên trả lời 2 câu hỏi này trước khi quyết định log nhé:
– Liệu rằng log này có giúp được bạn phát hiện được quá trình thực hiện của người dùng trong hệ thống hay không?
– Thông tin trong log có ảnh hưởng đến bảo mật dữ liệu người dùng và những thông tin nhạy cảm hay không?
Nếu trả lời được 2 câu trên thì oke rồi. Vậy ta nên đặt Log ở đâu? Nhắc thêm cho bạn 1 chùt là quá trình logging được thực hiện hàng ngày, hàng giờ hàng giây khi hệ thống vận hành, nên khối lượng thông tin của nó không hề nhỏ. Vì chưa biết hệ thống lỗi khi nào nên quá trình log này phải đảm bảo diễn ra liên tục.
Để mình list ra 1 số chỗ để log nhé!
– File à! Có thể được đó, nhưng khi log đầy và file quá lớn thì sao nhỉ? Cắt nhỏ hoặc phân chia theo service giải pháp tốt
– Database à! Nghe thì có vẻ hợp lý đấy. Nhưng mà bạn có thể tự tin đủ chi phí để chi trả cho những thứ được xem là không quan trọng về mặt chức năng nhưng lại chiếm một lượng lớn tài nguyên trong hệ thống không?
– Một nơi nào đó phi tập trung à! Một ý hay khi bạn dành riêng một nơi chỉ để quản lý cho riêng phần logging. Bạn cũng có thể mở rộng hay co hẹp phạm vi hay đối tượng tài nguyên khi cần thiết và dễ dàng phân tích tra cứu về sau.
À. Nhớ là vẫn phải thiết lập bảo mật cho log nha. Thiết lập làm sao cho chỉ có những người liên quan đọc được thôi. Chứ không để public rồi rơi vào tay hacker là…. điiiii!!Có lẽ cũng biết về sự thống khổ này của các anh em lập trình viên, thì các ông lớn như Microsoft, Google, Amazon đều có những dịch vụ riêng đáp ứng nhu cầu logging này. Vậy nên ta chỉ cần lên mạng , cài đặt, cấu hình và đặt vị trí muốn ghi log mà thôi. Lời kết: Sau bài viết này, có lẽ bạn cũng đã hiểu hơn về log là gì.
Với lập trình viên thì nó là một nơi tham khảo tốt để tìm ra lỗi. Nếu thấy bài viết hay thì hãy like và share cho mọi người cùng biết nha. Còn nếu bạn muốn mình viết thêm về nội dung khác hoặc tiếp tục ra lò phần 2 của “Log” này thì hãy comment để mình biết nhaaaa. See yaaaaa!!