-
Notifications
You must be signed in to change notification settings - Fork 14
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
Log glue - herbs2winston #6
Comments
did you have some suggest for the log metadata and log string/object format? |
As we have many "configuration files" of the configuration of logs, of Winston and his transporters, we could create a lib that already comes pre-configured and that automatically collects the audit of all use cases and other layers of herbs (infra, API, repo, etc) in a configured way.
Yes, and inside this lib the usecase.audit() you be called automatically The idea here is to reduce a lot of config files and audit everything without concern if the dev is calling this or not |
so, the usage could be: class MyLogger extends Herbs2Winston{
constructor(){
super({
streamName: "KINESIS_FIREHOSE_LOGGER_NAME",
firehoseOptions: {
region: "KINESIS_LOGGER_REGION",
accessKeyId: "KINESIS_LOGGER_ACCESS_KEY_ID",
secretAccessKey: "KINESIS_LOGGER_SECRET_ACCESS_KEY"
},
messageFormat: {
error: (logTxt) => `if I dont specify this function, we follow with a default herbs format`,
info: (logTxt) => `if I dont specify this function, we follow with a default herbs format`,
audit: (logTxt) => `if I dont specify this function, we follow with a default herbs format`
[...]
},
levels: {
error: 0,
audit: 1,
info: 2
[...]
}
})
} what do you think? |
As we are using practically all herbs projects with winston + kinesis, with code repetition in several places, I imagined that we can create a new herb glue that automatically connects herbs with winston (and still remains compatible for winston connectors ), possible a herbs2winston glue;
I would like to know if you think that there would be a real gain in this implementation and how it could work (breaking as little as possible of what we have today)
Add: Imagine just like the buchu that you can put in .env the audit for it to blow the exception, we can put this glue to log the entire use case execution that happens, I don't know, it was just an idea.
Add: I imagine the lib going more towards, for example, automatically auditing all usecases with a predefined (winston) transport. Or log all usecases that return error automatically.
The text was updated successfully, but these errors were encountered: