friendsofgo / killgrave

Simple way to generate mock servers written in Go

Home Page:https://friendsofgo.github.io/killgrave/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Structured logging

Darkclainer opened this issue · comments

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

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!

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

Nevertheless, this is example of output:
image
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.

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?

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

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

commented

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.

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.

commented

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?

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! :)