用lograge记录URI查询参数（附代码示例）

DebugUsery
69 阅读5分钟

用于驯服Rails日志的logragegem默认情况下会对URI的path ，但不包括查询字符串/查询参数。

例如，也许你有一个指向你的应用程序的URL/search?q=libraries 。

lograge将记录类似的内容。

method=GET path=/search format=html...

q=libraries 部分完全被排除在日志之外。我有点想要这部分，这很重要。

lograge的README提供了 "记录请求参数 "的说明，通过params哈希的方式。

我打算稍微修改一下，以便:

  • 使用较新的custom_payload 配置，而不是custom_options 。（我不确定为什么会有这两种配置，但我认为主要是出于传统的原因，较新的custom_payload? 是你应该阅读的内容？）
  • 如果我们只是把params 放在那里，那么如果你有嵌套的哈希参数，就会有一堆丑陋的<ActionController::Parameters 出现在日志中。我们可以用params.to_unsafe_h 来解决这个问题，但是...。
  • 我们真的应该用request.filtered_parameters ，以确保我们没有记录任何被Rails 6 config.filter_parameters过滤掉的东西。(谢谢/u/ezekg on reddit）。这也可以转换为一个普通的哈希值，而不是ActionController::Parameters，从而解决前面的问题。
  • (看起来lograge的README可以用PR来更新它？)
  config.lograge.custom_payload do |controller|
    exceptions = %w(controller action format id)
    params: controller.request.filtered_parameters.except(*exceptions)
  end

这样我们就得到了一个日志行，可能看起来像这样:

method=GET path=/search format=html controller=SearchController action=index status=200 duration=107.66 view=87.32 db=29.00 params={"q"=>"foo"}

好的。params 哈希值与查询字符串不完全相同，它可以包括URL查询字符串中没有的东西（如控制器和行动，我们必须在上面剥离，以及其他），在某些情况下，它可以省略查询字符串中的东西。这只是取决于你的路由和其他配置和逻辑。

params哈希值本身就是默认的rails日志......但如果我们只是记录实际的URL查询字符串呢？好处是。

  • 更容易在日志中搜索一个确切的、已知的URL（这可能会变得更复杂，比如/search?q=foo&range%5Byear_facet_isim%5D%5Bbegin%5D=4&source=foo 或其他）。这是我有时想做的事情，比如说我从一个错误跟踪服务中得到了一个URL报告，现在我想在日志中找到这一行。
  • 实际上，我喜欢在日志里有确切的实际URL（好吧，从路径开始）。
  • 这就简单多了，我们不需要过滤掉控制器/动作/格式/ID等等。
  • 它实际上更简明一些？而我使用lograge的部分原因是想减少papertrail的日志文件的字节数!

缺点是什么？

  • 如果你有某种结构化的日志搜索（我目前没有，但我想可以通过切换到json格式的papertrail功能来实现），可能会更容易做一些类似于 "找到一个/search，q=foo和source=ef，而不用担心其他参数 "的事情。）
  • 在params hash可以包括不在实际url中的东西的情况下，这样的记录重要吗？
  • ....?

很好奇其他人怎么想......我想把实际的URL放在那里，而不是params hash，是不是疯了？

无论如何，这是很容易做到的。注意，我们使用filtered_path ，而不是fullpath ，以再次考虑到Rails 6的参数过滤，再次感谢/u/ezekg。

  config.lograge.custom_payload do |controller|
    {
      path: controller.request.filtered_path
    }
  end

这实际上是覆盖了默认路径，使之成为一个也有查询字符串的路径。

method=GET path=/search?q=libraries format=html ...

当然，如果你想保持path ，你可以添加一个不同的键fullpath ，也许是为了在某种日志分析系统中方便整理，该系统希望通过查询字符串的相同路径不变性来分组。

我要试试这个。

同时，关于lograge...

只要我们在谈论lograge....，根据提交历史、问题和拉动请求的历史......事实上，CI目前没有运行（travis.orggrr），甚至没有尝试在Rails 6.0+上测试（尽管lograge似乎工作正常）......人们可能担心lograge目前没有/维护不足.... 对5月份提交的关于项目状态的GH问题没有任何评论。

它似乎仍然是试图驯服Rails那种失控的日志的更流行的解决方案之一。例如，在papertrail和honeybadger的文档中提到了它，还有许多其他的博客文章。

它的未来会是什么？

在四处寻找其他可能性的时候，我发现了semantic_logger（rails_semantic_logger）。它也有类似的功能。 它似乎得到了更多的维护。 它在github上有相当多的星星，尽管没有lograge那么多，而且它在博客和第三方平台文档中的出现也没有那么多。

它也更复杂，功能更多。不管是好是坏。例如，我主要在想它是如何通过将日志记录转移到后台线程来提高应用性能的。这很好......但也可能导致一类全新的错误、神秘的警告或配置负担。

目前，我坚持使用更受欢迎的lograge，但我希望它的CI至少能在Rails 6.1上测试。

顺便提一下，试图让Rails像lograge和rails_semantic_logger那样更紧凑地记录日志......比你想象的要复杂得多，正如这两个项目中的代码所证明的那样尤其是semantic_logger，它有几百行有点像巴洛克式的代码，被分割在几个文件中。在Rails 5（我认为）前后对日志进行的重构，以使用ActiveSupport::LogSubscriber ，使得像这样定制Rails日志成为可能（尽管我认为lograge和rails_semantic_logger也仍然在进行一些猴子式的修补！），但是最终并没有使之变得那么简单或明显，也没有使之面向未来。对于lograge和rails_semantic_logger最初的主要用例而言，这可能会阻碍太多的其他替代方案--将一个rails动作变成一条日志线，并采用结构化的格式。

avatar
文章
阅读
粉丝