Structured logging

[Darkclainer]

I think this project can hugely benefit from structured logging.
User should be able to see what request server handled and how (maybe why they haven't handled by supposed handler, what errors of validation happened. It can be difficult to inspect this manually).
So structured logging can help to deal with possibly huge logs that current project can generate.

We can use some dependency for this functionality such as:
https://github.com/sirupsen/logrus (very user friendly, also can be used instead of standard log)
https://github.com/uber-go/zap

[joanlopez]

Yeah, a verbose mode (-v / --verbose) with that kind of logs is a really good idea.

Could you share with us how these logs would looks like?

Thanks!

[Darkclainer]

I've just realized it can be not so easy, as I thought.

Nevertheless, this is example of output:

We can add more context, like actual body (and it will be almost unreadable) and other things.

The actual problem is that to log everything nicely, we need to make our router because of how gorilla's works. For example, current router can reject some url because it has not some parameters, and we will never know about it.

[joanlopez]

IMHO, logging everything isn't the best approach. We might provide some useful data (imposter file, path, params or the satisfied regex) instead, in order to let the user know why or why not it has matched.

What do you think?

[aperezg]

I think that an approach like the middleware of gin-gonic will be fine, I'm agree with Joan that logging everything could be a little messy, instead of that logging all http request and loading file is a better approach

[Darkclainer]

So, everything should stay as it is in case of logging?

[euzu]

I miss the log functionality as well. I would like to be able to see the requests in the logs. For this, log levels could be specified for the respective path. This way the log level can be set in config. As an example, if LogLevel of the path is set to "Trace" but in the config the LogLevel is set to "Error" no log is written. This can reduce the amount of logs. This is even supported by the log frameworks. There is nothing to reinvent.

[joanlopez]

I miss the log functionality as well. I would like to be able to see the requests in the logs. For this, log levels could be specified for the respective path. This way the log level can be set in config. As an example, if LogLevel of the path is set to "Trace" but in the config the LogLevel is set to "Error" no log is written. This can reduce the amount of logs. This is even supported by the log frameworks. There is nothing to reinvent.

We're already working and discussing it, but looks like we're going to introduce multiple levels of verbosity. However, the idea is to start by adding verbosity levels at program scope instead of imposter, as you suggested. You can find more information at #100 and #101.

[tateexon]

Sorry to reply to an old topic. I have a need for this or #100. Basically anything that makes it easier to get access to specific requests. Was this work dropped at this point or was it completed in a different way?

[joanlopez]

Sorry to reply to an old topic. I have a need for this or #100. Basically anything that makes it easier to get access to specific requests. Was this work dropped at this point or was it completed in a different way?

hey @tateexon,

I think there has been no news since then, but contributions are welcome! :)

[tomp21]

hey @joanlopez , i'd like to lend a hand on this, can i get this assigned to me?

[joanlopez]

Hey, @tomp21!

Yeah, sure! I assigned you! Thanks for engaging! 🙇🏻

Just to be clear, I'd expect you to come with a more or less formal proposal before starting to write some lines of code, as I think the challenge here is having a clear idea on what levels of verbosity the logger should have, and what amount of information to print on each.

[tomp21]

hey @joanlopez i just took a look at the codebase and gave it a thought, IMO having the full request logged could be useful in limited scenarios, I'd have that at debug level logs, and keep the useful data you proposed before at normal info level logging, which would be the default, having an error log level available for quieter runs.

I'm not sure we can give much info on why something matched or not, but we definitely could have a catch all handler to log whatever hasn't matched, which could be useful to see the dropped ones, which I'd also include at info loglevel

WDYT?