当您遇到一个奇怪的看似无法解决的错误时,改进日志记录可能是您可以采取的最佳步骤。 良好的日志记录是检测和修复所有类别的错误的最简单方法。 记录足够的信息后,您可以查看请求期间数据的变化。 您可以跟踪对其他服务的呼叫,并调查响应。 实际上,当调试器失败时,日志记录帮助我修复了我遇到过的最棘手的错误。
但是日志太多了,您的日志文件将Swift变成一堆不可读,无用的消息。 您如何才能从那堆数据中切出您关心的信息? 您能否以一种易于稍后过滤的方式打印邮件?
标记您的日志消息
Rails包含TaggedLogging ,可以帮助您快速分类相关的日志消息。 标记记录器时,您会在消息的开头得到一个标记。 所以代替:
Finding people...
Person Load (0.3ms) SELECT "people".* FROM "people"
Found 0 people!
您可以标记Rails记录器:
logger.tagged("People") do
logger.debug "Finding people..."
@people = Person.all
logger.debug "Found #{@people.length} people!"
end
您会看到类似以下内容:
[People] Finding people...
[People] Person Load (0.3ms) SELECT "people".* FROM "people"
[People] Found 0 people!
现在,关心不同事物的日志消息看起来可能会有所不同。
一些标记记录器示例
随着您越来越频繁地记录日志以及记录更复杂的事情,您自然会注意到这些标签将使您的消息更清晰的区域。 但是我发现有些地方标记日志记录特别有用。 我通常会立即标记这些。
您可以记录对其他API的请求:
logger.tagged("GitHub API") do
uri = URI("https://api.github.com/repos/rails/rails/tags")
logger.info { "Fetching #{uri}" }
tags = JSON.parse(Net::HTTP.get(uri))
logger.info { "First tag: #{tags.first["name"]}" }
end
[GitHub API] Fetching https://api.github.com/repos/rails/rails/tags
[GitHub API] First tag: v4.2.4.rc1
这样,您可以轻松查看应用程序与该API进行通信的方式和时间。 (这对于Faraday中间件特别有效,或者如果您仅通过Gateway与服务器通信,则效果特别好)。
后台作业也可以与带标记的日志记录一起很好地工作:
require "active_support/tagged_logging"
Resque.logger = ActiveSupport::TaggedLogging.new(Resque.logger)
module LoggedJob
def around_perform_log_job(*args)
logger.tagged(name) do
logger.info { "Performing #{name} with #{args.inspect}" }
yield
end
end
end
class MyJob
extend LoggedJob
def self.perform(*args)
...
end
end
现在,任何扩展LoggedJob的作业都将使用其作业的类名标记其所有日志消息。
如果您有登录用户,则可以使用其用户ID标记消息:
logger.tagged(current_user_id ? "user-#{current_user_id}" : "user-anonymous") do
logger.debug "Finding people..."
@people = Person.all
logger.debug "Found #{@people.length} people!"
end
[user-123] Finding people...
[user-123] Person Load (0.3ms) SELECT "people".* FROM "people"
[user-123] Found 0 people!
最后,如果在config/environments/production.rb
(或development.rb
)中添加一行,则可以让Rails自动标记消息:
config.log_tags = [ :subdomain, :uuid ]
log_tags
列出要在每个Rails日志条目的开头显示的标签。 每个符号都引用ActionDispatch :: Request上的方法,因此:uuid
表示request.uuid
。
您还可以传递带有request
对象的Proc:
config.log_tags = [ :subdomain, :uuid, lambda { |request| request.headers["User-Agent"] } ]
但我很少看到这种情况。
这些默认标记很不错: uuid
可以将一个请求中发生的所有日志条目捆绑在一起,如果您将会话保留在服务器上,则会话ID也很有用。 有了这些标签和足够的消息,您就可以通过应用程序跟踪一些非常复杂的路径。 通常,这就是找出讨厌的错误是如何发生的。
您在应用程序中使用了多少Rails记录器? 您是否尝试过标记日志记录? 如果还没有,请尝试找到它的地方。 标记用户采取的措施是一个好的开始。 下次需要调试疯狂的多步骤错误时,它将为您提供帮助。
如果您想了解有关日志记录和其他调试技术的更多信息,我将在《 实践Rails》的整个章节中专门介绍如何查找和修复在创建应用程序时会遇到的错误。 在此处免费获取第一章 。
翻译自: https://www.javacodegeeks.com/2016/10/keeping-logs-becoming-unreadable-mess.html