Hầu hết mọi người chỉ nhận ra sự cần thiết của nhật ký khi họ cần chúng nhất. Nhưng khi ứng dụng của bạn bị hỏng, khiếu nại của người dùng bắt đầu tràn vào và bạn không biết cách khắc phục, đã quá muộn để thêm một số thông điệp tường trình có thể hữu ích.
Những khúc gỗ tốt sẽ mang lại lợi nhuận gấp mười lần. Chúng giúp việc chẩn đoán những lỗi phức tạp đó trở nên dễ dàng và nếu bạn ghi nhật ký đúng cách, chúng có thể cảnh báo cho bạn về các vấn đề ngay cả trước khi người dùng của bạn nhận thấy. Nhưng 'ghi nhật ký đúng cách' có nghĩa là gì?
Ghi nhật ký rất dễ bắt đầu nhưng khó thành thạo. Trong bài đăng này, chúng tôi sẽ đi sâu vào cách bạn có thể sử dụng hết tiềm năng của nhật ký ứng dụng Rails của mình.
Đăng nhập Rails
Trước tiên hãy nói về những điều cơ bản. Khi bạn khởi động một ứng dụng Rails mới, việc ghi nhật ký đã được thiết lập cho bạn. Rails sẽ khởi tạo phiên bản mới của ActiveSupport::Logger mà bạn có thể sử dụng ở bất cứ đâu trong ứng dụng của mình.
Trình ghi nhật ký Rails ghi vào đầu ra tiêu chuẩn hoặc log/<environment>.log và sẽ tự động ghi nhật ký những người yêu cầu gửi đến hoặc các truy vấn đã thực hiện bên cạnh bất kỳ thông điệp nhật ký nào bạn viết một cách rõ ràng.
Có nhiều cách để bạn có thể định cấu hình nhật ký Rails, như được nêu rõ trong tài liệu về Rails.
Để tận dụng tối đa nhật ký của mình, chúng tôi đặc biệt quan tâm đến việc thiết lập cấp độ nhật ký cũng như định dạng nhật ký.
Nhưng trước khi giải quyết vấn đề đó, hãy nói về lý do tại sao chúng ta nên viết nhật ký.
Ghi nhật ký tốt, Ghi nhật ký xấu
Mục đích của nhật ký là thông báo cho bạn về các sự kiện hệ thống để bạn có thể phản ứng với chúng. Ví dụ:khi xảy ra lỗi, thông báo nhật ký sẽ cho bạn biết về lỗi đó theo cách bạn có thể hiểu được.
Mức độ hiểu thông điệp log của bạn phụ thuộc vào mức độ mô tả và ngữ cảnh của nó. Thông điệp tường trình mô tả cung cấp thông tin liên quan về những gì đã xảy ra. Thông báo nhật ký theo ngữ cảnh bao gồm thông tin về trạng thái của hệ thống khi hệ thống ghi nó.
Hãy xem xét một ví dụ đơn giản để hiểu tại sao chúng ta cần cả hai. Đây là một số mã gọi API bên ngoài và trả về phản hồi của nó khi người dùng thực hiện một yêu cầu.
Bây giờ, hãy tưởng tượng một tình huống trong đó khách hàng báo cáo sự cố và bạn xem nhật ký để được trợ giúp. Đây là những gì bạn có thể thấy:
Những thông điệp tường trình này cung cấp một số thông tin nhưng gần như chưa đủ. Chúng tôi chưa thể tìm ra nguyên nhân gây ra lỗi mà khách hàng đã báo cáo. Những thông điệp tường trình này thiếu tính mô tả và ngữ cảnh. Họ không ồn ào. Chúng ta có thể cải thiện chúng bằng cách nào?
Các cấp độ nhật ký trong Rails
Trình ghi nhật ký Rails mặc định cung cấp các cấp độ nhật ký DEBUG , INFO , WARN , và ERROR . Bằng cách sử dụng chúng, bạn có thể nhóm các thông điệp nhật ký thành các danh mục liên quan khác nhau. Điều này không chỉ giúp bạn lọc thông điệp tường trình mà còn cung cấp một số ngữ cảnh.
Có thể khó quyết định khi nào nên sử dụng cấp độ nhật ký nào. Dưới đây là một số quy tắc chung:
DEBUG:Sử dụng cấp độ nhật ký này để biết thông tin chi tiết về các hành động xảy ra trong hệ thống. Bạn có thể sử dụng câu lệnh gỡ lỗi khi các phương thức được nhập hoặc thoát hoặc bất cứ nơi nào bạn nghĩ rằng nó có thể tăng thêm giá trị trong quá trình gỡ lỗi.INFO:Bất cứ khi nào hệ thống của bạn thay đổi trạng thái hoặc xảy ra sự kiện liên quan nào đó, hãy liên hệ vớiINFOcấp độ. Ví dụ về các thông báo thông tin phổ biến trong ngữ cảnh của ứng dụng Rails là các yêu cầu đã nhận, yêu cầu được gửi tới các API bên ngoài hoặc các công việc bắt đầu và kết thúc.WARN:Sử dụng nhật ký này để biểu thị rằng có điều gì đó không mong muốn đã xảy ra. Đây chưa phải là vấn đề (vì ứng dụng của bạn có thể xử lý nó), nhưng nếu nó tiếp tục xảy ra thì bạn cần chú ý.ERROR:Sử dụng cấp độ nhật ký này khi xảy ra lỗi. Lỗi là trạng thái ứng dụng không hợp lệ mà bạn phải giải quyết càng sớm càng tốt.
Bạn có thể thay đổi loại thông điệp tường trình mà ứng dụng của bạn ghi bằng cách sửa đổi tệp môi trường tương ứng. Thông thường, Rails sẽ loại bỏ DEBUG thông báo đang được sản xuất nhưng bạn có thể thay đổi điều đó.
Hãy áp dụng các đề xuất ở cấp độ nhật ký ở trên cho mẫu mã của chúng tôi.
Khi gỡ lỗi, giờ đây chúng tôi có thể xác định nguyên nhân cốt lõi của sự cố bằng cách xem xét WARN và ERROR tin nhắn. Đáng tiếc là tin nhắn nhật ký của chúng tôi không có mô tả gì thêm.
Thông điệp tường trình mô tả
Thông điệp tường trình mang tính mô tả không có chỗ cho việc diễn giải. Chúng cung cấp những chi tiết cần thiết để người đọc biết ngay về những gì đã xảy ra.
Khi bạn đọc các tin nhắn như 'An error occurred' , bạn vẫn đang thắc mắc lỗi là gì. Bạn muốn tránh sự nhầm lẫn như vậy khi viết thông điệp tường trình của mình. Điều quan trọng nhất khi viết thông điệp tường trình mang tính mô tả là hãy đặt mình vào vị trí của người đọc nhật ký. Liệu họ có nhận được tất cả thông tin họ cần khi đọc nhật ký của bạn không?
Hãy thay đổi thông báo 'An error occurred' tới chính lỗi đó, bao gồm cả thông báo của nó.
Đó là một sự cải tiến. Hãy kiểm tra các thông điệp tường trình khác trong ví dụ của chúng tôi. 'Method entered' không cho chúng tôi biết phương thức nào được gọi, 'Response success' bỏ đi phản hồi thực tế và 'Response failure' không cung cấp thông tin về bản chất của sự cố. Hãy thay đổi điều đó.
Lưu ý :Bạn có thể nhận thấy chúng tôi sử dụng cú pháp khối khi thực hiện phép nội suy chuỗi với nhật ký của mình. Việc sử dụng nó sẽ tránh được việc tính toán không cần thiết khi cấp độ nhật ký của ứng dụng cao hơn cấp độ của thông điệp tường trình. Ví dụ:log.debug("Some #{concatenation}") sẽ luôn thực hiện nối chuỗi, nhưng log.debug { "Some #{concatenation}" } sẽ chỉ làm như vậy khi cấp độ nhật ký được đặt thành gỡ lỗi.
Nhật ký của chúng tôi đọc tốt hơn nhiều bây giờ. Có rất ít nghi ngờ về ý nghĩa của mỗi thông điệp tường trình.
Bối cảnh bổ sung cho thông điệp tường trình
Thông báo tường trình mới của chúng tôi cung cấp một bức tranh rõ ràng về những gì đã xảy ra. Vì đây là một ví dụ đơn giản nên chúng ta cũng hiểu rõ lý do tại sao một số điều lại xảy ra. Trên thực tế, việc này thường không dễ dàng như vậy.
Việc cung cấp thêm thông tin về ngữ cảnh mà hệ thống viết từng thông báo có thể giúp ích đáng kể cho việc gỡ lỗi.
Ví dụ:khi ghi nhật ký yêu cầu hoặc phản hồi, việc biết ai đã thực hiện yêu cầu đó có thể hữu ích. Việc đính kèm dấu vết ngăn xếp để tìm lỗi có thể hữu ích để chúng tôi có thể thu thập thêm thông tin về lý do xảy ra lỗi.
Lưu ý :Bạn có thể nhận thấy rằng việc tạo thông điệp tường trình với thông tin theo ngữ cảnh có thể phức tạp khi bạn sử dụng trình ghi nhật ký mặc định của Rails. May mắn thay, các trình ghi nhật ký tùy chỉnh như Ougai hoặc MrLogaLoga giúp việc này trở nên dễ dàng hơn nhiều.
Ghi nhật ký có cấu trúc
Khi bạn đã làm cho nhật ký của mình có thể đọc được đối với con người, bạn đã sẵn sàng đưa mọi thứ lên cấp độ tiếp theo. Bây giờ, bạn cần làm cho máy có thể đọc được nhật ký của mình để có thể sử dụng chúng cho việc theo dõi và phân tích dữ liệu.
Định dạng tôi sử dụng là JSON, nhưng tùy thuộc vào công cụ bạn sử dụng, bạn có thể thích các định dạng nhật ký khác như Logstash. Bạn có thể thay đổi định dạng của thông điệp tường trình bằng cách tạo một trình định dạng nhật ký tùy chỉnh.
Thay vì tự viết các trình định dạng tùy chỉnh, bạn có thể sử dụng một trong nhiều viên ngọc quý cung cấp các trình định dạng nhật ký tùy chỉnh. Tôi khuyên bạn nên sử dụng Lograge, nó không chỉ cung cấp định dạng sẵn dùng mà còn dọn dẹp định dạng yêu cầu dài dòng của Rails để dễ đọc hơn nhiều.
Ghi nhật ký Rails bằng AppSignal
Bây giờ nhật ký của bạn đã đẹp và dễ đọc, thật tuyệt nếu làm cho chúng dễ truy cập hơn. Rốt cuộc, bạn không muốn SSH vào một số máy và theo dõi hoặc grep nhật ký ở đó phải không?
May mắn thay, AppSignal gần đây đã ra mắt tính năng ghi nhật ký ở phiên bản beta! Tính năng này cho phép bạn kiểm tra và phân tích nhật ký Rails trực tiếp trong giao diện web AppSignal.
Bạn có thể truy cập phiên bản beta ghi nhật ký của chúng tôi thông qua tab 'Ghi nhật ký' ở menu bên trái:
Nếu bạn làm theo các bước trong tài liệu ghi nhật ký Ruby của chúng tôi, bạn có thể định cấu hình Rails Logger để sử dụng AppSignal::Logger lớp bằng cách đặt mã bên dưới vào config/environment.rb tập tin trước initialization :
Bạn cũng có thể nhập nhật ký có cấu trúc ở định dạng JSON hoặc bằng Lograge.
Sau khi thiết lập xong mọi thứ, bạn sẽ thấy nhật ký Rails của mình hiển thị trên AppSignal!
Ghi nhật ký và báo cáo lỗi
Bạn đang đọc nội dung này trên blog AppSignal, vì vậy bạn có thể thắc mắc:tại sao tôi phải quan tâm đến việc ghi nhật ký nếu tôi đang sử dụng một nền tảng báo cáo lỗi tốt?
Đó là một câu hỏi hay. Công cụ theo dõi lỗi cung cấp thông tin chi tiết về lỗi ứng dụng. Họ ghi lại dấu vết đầy đủ của bất kỳ lỗi ứng dụng nào và cung cấp nhiều thông tin theo ngữ cảnh ngay lập tức.
Tuy nhiên, trong khi hầu hết các công cụ cho phép bạn nắm bắt các sự kiện không phải lỗi, thì việc gửi cho các công cụ này một lượng thông báo tùy ý nói chung là không khả thi. Bạn sẽ không thể thay thế thông tin lịch sử chi tiết mà nhật ký viết tốt cung cấp.
Trong thực tế, nhật ký được viết tốt sẽ bổ sung và hỗ trợ các công cụ theo dõi lỗi. Có lẽ bạn nên sử dụng cả hai.
Kết thúc
Trong bài đăng này, chúng tôi đã xem xét cách bạn có thể tận dụng tối đa nhật ký của mình. Chúng tôi thấy rằng việc bắt đầu đăng nhập vào Rails rất dễ dàng nhưng việc viết nhật ký hữu ích có thể là một thách thức.
Nhật ký thiếu tính mô tả hoặc ngữ cảnh sẽ chỉ lấp đầy ổ đĩa của bạn trong khi cung cấp ít giá trị. Tuy nhiên, nhật ký sử dụng đúng cấp độ nhật ký và cung cấp cho người đọc thông tin họ cần là một tài sản tuyệt vời.
Sau khi đã thành thạo việc viết các thông điệp tường trình hay, bạn có thể tiến xa hơn và định dạng chúng theo cách cho phép phân tích nhật ký và lọc dễ dàng.
Chúng tôi cũng đã khám phá cách bạn có thể sử dụng tính năng ghi nhật ký mới của AppSignal để truy cập nhật ký của mình một cách dễ dàng. Cuối cùng, chúng tôi đã đề cập đến cách nhật ký sẽ hỗ trợ các công cụ theo dõi lỗi thay vì thay thế chúng.
Chúc bạn đăng nhập thành công!
Tái bút. Nếu bạn muốn đọc các bài đăng của Ruby Magic ngay khi chúng được đăng tải, hãy đăng ký nhận bản tin Ruby Magic của chúng tôi và không bao giờ bỏ lỡ một bài đăng nào!
Hans-Jörg Schnedlitz
Tác giả khách mời Hans của chúng tôi là kỹ sư Rails đến từ Vienna, Áo. Anh ấy dành phần lớn thời gian của mình để viết mã hoặc đọc về mã hóa, và đôi khi còn viết về nó trên blog của mình! Khi anh ấy không ngồi trước màn hình, bạn có thể sẽ tìm thấy anh ấy ở bên ngoài, đang leo núi.
Tất cả bài viết của Hans-Jörg Schnedlitz