Ring-logger 1.0.0: Getting back to the roots

[nberger]

Ring-logger 1.0.0: Getting back to the roots

[nberger]

By the way, any feedback about the 0.8.x approach will be much appreciated!

[facundoolano]

My 2 cents: a while ago I wanted to add some basic request/response logging to a small ring web app and looked into using this library. I wanted to have a single line per request with method + path + response status + elapsed time. I think there wasn't such a logger by default so I looked into writing a custom one but felt like it required too much code to pull it off.

What I ended up doing was looking at your source code and copying the bits I needed to write a single middleware function, which looked like this:

(defn- wrap-log-request
  "Middleware that logs incoming requests."
  [handler]
  (fn [{:keys [request-method uri query-string] :as req}]
    (let [start  (System/currentTimeMillis)
          method (-> request-method name str/upper-case)
          path   (if query-string (str uri "?" query-string) uri)
          res    (handler req)
          time   (- (System/currentTimeMillis) start)]
      (log/info (format "%s %s [%d] (%dms)" method path (:status res) time))
      res)))

[nberger]

@facundoolano thanks! I did more or less the same recently :).

In many cases it will be best to simply write your own middleware that way, but I think there's room for a library that provides logging middleware with a few more features (redacted params because you don't want sensitive information in your logs; colors because... well because colors are nice, but also because they make it easier to quickly identify some aspects of the output, especially if params were added to the output; request id to help correlate all the logs related to a request, etc.)

I recently needed to output json structured logs, to make it easier to extract metrics in the log processing pipeline. That's why I'm thinking in making the log to be just a map instead of a string, and let this output-fn convert to whatever format is preferred. Final details are to be defined, maybe the output-fn will actually be the logging middleware of which many will be provided, with a separate function/middleware/convention to take the timing metric and redact the params. The rest of the information is already in the request.