-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structured logging #39
Comments
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! |
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? |
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. |
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! :) |
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
The text was updated successfully, but these errors were encountered: