Về Logging: Mắt thần của bạn trên hệ thống thực
Bài viết được sự cho phép bởi tác giả Vũ Thành Nam
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 nhưng bộ não cá vàng của bạn lại không thể nhớ mình đã làm gì và tại sao lại bị lỗi như vậy?
Bạn là một lập trình viên phát triển ứng dụng phần mềm và đã từng gặp phải những tình huống trớ trêu của những lỗi không biết nguyên nhân tại đâu và không thể tái hiện lại được vấn đề?
Khi này với tư cách của một lập trình viên lâu năm của mình thì mình khuyên bạn hãy lơ nó đi và xem như bạn chưa từng thấy gì trên cõi đời này!
Đùa chút thôi! Đối với các ngành nghề cần trao đổi thông tin nói chung và ngành phần mềm nói riêng thì việc bạn làm và thao tác trên ứng dụng luôn được hệ thống lưu lại những hành vi và dữ liệu nhập vào của bạn. Để làm gì ư? 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 đề.
Logging là gì?
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 và chạy từng bước để lần ra dấu vết lỗi ở đâu. Tuy nhiên đời không như là mơ, có những lỗi xảy ra khi khách hàng hay người dùng đầu cuối thao tác phát sinh và bạn không thể bắt buộc họ thử lại để bạn có thể debug, hay bắt người kiểm thử có thể tái hiện được trên máy của bạn và tìm hiểu nó. Rồi có những hệ thống thuộc ứng dụng tích hợp trao đổi dữ liệu với bên thứ ba, các services nằm trong nhiều team phát triển trao đổi với nhau. Bạn không thể chứng mình và tìm ra nguyên nhân lỗi phát sinh kia là nằm ở phía bên bạn hay phía bên họ, nó thuộc phạm vi của đội ngũ nào. Khi này bạn sẽ ước giá như có một file log hoặc nơi nào đó ghi lại những hành vi và đầu vào đầu ra của hệ thống.
Để có được những lưu vết đó thì bạn cần phải ghi log lại trong quá trình phát triển phần mềm. Và để tìm ra nguyên nhân cũng như vấn đề phát sinh nằm ở đâu thì bạn phải phân tích log mà bạn và đồng đội của mình đã ghi ra trước đó.
Đến đây chắc bạn cũng hiểu được phần nào tầm quan trọng của logging rồi, vậy chúng ta cần ghi 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, giao tiếp với 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 có một điều mà mình nên lưu ý giúp bạn đánh giá được cần log lại những gì thì bạn nên trả lời giúp mình 2 câu hỏi này trước:
– Những gì bạn ghi lại 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 khi bạn truy vết lại không?
– Những thông tin bạn log ra 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?
Khi trả lời được hai câu hỏi trên có lẽ nó sẽ giúp bạn nhận ra được bạn cần log những gì và cần log ở những đâu.
Log được lưu ở đâu?
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ỏ. Bình thường vấn đề không hay xảy ra nhưng bạn cũng chẳng biết lúc nào phát sinh nên vẫn phải đảm bảo quá trình theo dõi này được chạy một cách liên tục.
Vậy nơi nào có thể chứa được log của bạn?
– File ư! Có thể được đó, nhưng khi log đầy và file quá lớn thì sao, cắt nhỏ theo size, theo chức năng, theo services cũng là một giải pháp bạn nên cân nhắc.
– Database ư! Cũng được luôn nếu 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 của bạn.
– 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.
Để có thể tối ưu và chuyển đổi các chế độ và nơi lưu trữ log bên trên thì các nền tảng công nghệ cũng đã dự trù sẵn những khả năng và nhu cầu của bạn. Microsoft, Google, Amazon đều có những dịch vụ riêng đáp ứng nhu cầu logging này. Còn nếu bạn muốn tự mình xây dựng và quản lý thì các framework hay thư viện trong các ngôn ngữ cũng đã có những phần xử lý giúp bạn vấn đề này rồi. Bạn chỉ cần cài đặt, cấu hình và đặt vị trí muốn ghi log mà thôi.
Một số lưu ý khi sử dụng logging?
– Lưu ý đến bộ lọc hay công cụ giúp bạn lọc thông tin trong log. Điều này rất cần thiết để giúp bạn phân tích log tốt hơn. Bạn không thể ngồi nhìn cả trăm file log nếu không biết thứ bạn cần tìm nằm ở đâu.
– Quan tâm đến cấp độ log. Không phải bạn lưu lại tất cả những thông tin của hệ thống ra bên ngoài. Điều này có 2 rủi ro đó là hiệu suất sẽ giảm bởi vì chính quá trình ghi log của bạn và bạn sẽ có thể mất tất cả những thông tin hệ thống nếu bị tấn công khi bảo mật kém. Vậy nên chia cấp độ log (Verbose, Debug, Information, Warning, Error, Fatal) tùy theo mức độ quan trọng và những môi trường cần mà thôi.
– Cấu trúc thông tin của log. Khi bạn có được log rồi thì để rút ngắn thời gian phân tích logging của bạn và team thì bạn nên định nghĩa trước cấu trúc logging. Thời gian, tên service, tên chức năng, tên hàm, thông tin cần thiết đầu vào và đầu ra nên được sắp xếp một cách gọn gàng và khoa học. Cố gắng nhớ rằng không chỉ một mình bạn sử dụng những thông tin đó, mà nó sẽ dành cho nhiều bên khác đọc nữa, và nó cũng có thể là bằng chứng chứng mình phạm vi bạn làm đúng khi giải trình với phòng ban khác (một cách tự bảo về mình trước).
– Phạm vi log. Ngoài cấp độ log ra thì bạn cũng cần phải quan tâm đến phạm vi những thông tin bạn cần log. Đủ dùng để bạn có thể hiểu những gì xảy ra mà thôi chứ đừng lạm dụng nó mọi lúc mọi nơi nhé. Những thông tin nhạy cảm cũng không nên log ra nó có thể khiến bạn gặp rắc rối về sau đó.
– Quan tâm đến những thành phần định danh (Event Identity). Nó có thể là Trace Id, Correlation Id hay Guid Id nào đó giúp bạn dễ dàng truy vết và xâu chuỗi các bước hành vi của bạn khi giao tiếp các thành phần hệ thống với nhau hay một bên thứ ba nào đó. Điều này sẽ giúp bạn vẽ được một workflow hoàn chỉnh chỉ với việc đọc và phân tích log.
– Chọn một thư viện logging phổ biến và có thể đáp ứng được những sự thay đổi của hệ thống. Bạn không thể biết được hệ thống của bạn thay đổi ra sao trong tương lai và cũng không thể biết được bên thứ ba mà bạn tích hợp sử dụng cơ chế log như thế nào. Việc của bạn lúc này là tìm hiểu và cho thư viện log đủ phổ biến để có thể thích ứng và cũng dễ dàng thay đổi các chế độ log khác nhau chỉ thông qua việc cấu hình.
Trên đây là những chia sẻ của bản thân khi một thời ngang dọc truy vết bugs và issues chỉ bằng với những dòng log thay vì debug. Nó cho mình một tư duy hoàn toàn khác nếu chỉ chăm chăm vào debug và việc tái hiện bug. Tin mình đi, bạn sẽ thay đổi hoàn toàn nếu làm chủ được logging và tracing.
Bài viết sau sẽ là bài kỹ thuật và demo sử dụng Serilog, Seq và ELK trong quá trình logging và tracing của bản thân mình.
Đón đọc nhé!
Bài viết gốc được đăng tải tại ntechdevelopers.com
Có thể bạn quan tâm:
- Hướng dẫn xóa logs docker, giới hạn file log docker
- Log MySQL Query
- Code ví dụ TypeScript logger (ghi log TypeScript với log4js)
Xem thêm Việc làm IT hấp dẫn trên Station D
Bạn có thể quan tâm
- Applicant Tracking System là gì? ATS hoạt động ra sao(Cẩm Nang Tuyển Dụng)
- Tối ưu tỉ lệ chuyển đổi với Google Optimize và Google Analytics(Công Nghệ)
- Vừa đủ để đi (go)(Công Nghệ)
