-
-
Notifications
You must be signed in to change notification settings - Fork 579
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
Logger not wrapped properly #61
Comments
Thanks. It's weird. I will able to check it on the next week. I'm on holiday right now. |
I'm having troubles with bunyan too :(
|
As I'm relying on some additional functionality offered by pino I opted in for a workaround. Instead of providing a logger to moleculer's constructor I override the broker's logger and use mixins to override it per-service: const logger = bindings => pino.child(bindings); // spawns child logger with additional base bindings
const broker = new ServiceBroker({ ... });
broker.logger = logger({ svc: "broker" });
broker.logLevel = broker.logger.level;
const loggerMixin = {
created() {
this.logger = logger({ svc: this.name });
},
};
const serviceN = {
mixins: [loggerMixin],
...
}; @WoLfulus: I assume you can use the same approach. |
My approach was a little bit different, and maybe uglier. This is what I did: const logger = bunyan.createLogger({
name: process.env.SERVICE_NAME || os.hostname(),
level: process.env.LOG_LEVEL || "trace"
});
const log = (name, text) => {
logger[name](text.toString("utf8"));
};
const broker = new ServiceBroker({
logger: {
trace: (text) => log("trace", text),
debug: (text) => log("debug", text),
info: (text) => log("info", text),
warn: (text) => log("warn", text),
error: (text) => log("error", text),
fatal: (text) => log("fatal", text),
},
}); |
I'm considering this issue. I plan I'm going to extend the Example: const broker = new ServiceBroker({
logger: function(entry) {
myLogger[entry.level].apply(myLogger, entry.args)
}
}); The {
nodeID: "node-100", // Local nodeID
module: "broker", // Others: "service", "tx", "transit", ...etc
service: "users", // service name of the `module` is "service"
level: "info", // log level of `this.logger.info` method
args: [ // Arguments of `this.logger.` method
"Test message",
{
a: 5
}
]
} @DeividasJackus @WoLfulus what do you think? It can solve the logger problems? Or any suggestion? |
LGTM. Has all the info I need and I'll be able to get rid of those prefixes and put it into a proper field on the logs (easy to filter in kibana for example). Also, I don't know if it's bunyan related, but I had to encode the message to utf8, or else all the messages were being printed as |
@icebob I like the proposal, but would like to propose that instead of passing a function that gets called w/ every logger call to the broker constructor, you pass a function that takes contextual logger w/ data provided by moleculer and returns a new logger instance. Example: const broker = new ServiceBroker({
logger: function(bindings) {
return pino.child(bindings); // in the case of pino
return bunyan.child(bindings); // in the case of bunyan
return new WinstonContext(winston, '', bindings); // in the case of winston + winston-context
},
}); In other words, moleculer calls the above user-supplied function only once per module/service during creation w/ This also means that Edit: the above means that users can still customize the loggers on a per-module/per-service basis in the above function (could just check |
@DeividasJackus Thanks, I'm going to consider your proposal. Btw, I fixed the original bug. So from now you can use your original code without workaround in v0.8.5 // With Pino
const logger = require("pino")({ level: "info" });
const broker = new ServiceBroker({ logger });
// Or with Bunyan
const bunyan = require("bunyan");
const logger = bunyan.createLogger({ name: "my-broker" });
const broker = new ServiceBroker({ logger });
broker.logger.info("hi"); |
I'm working on it in the next-logger branch. Current state: Pino const pino = require("pino")({ level: "debug" });
const broker = createBroker({
logger: bindings => pino.child(bindings)
}); Bunyan const bunyan = require("bunyan");
const logger = bunyan.createLogger({ name: "moleculer", level: "debug" });
const broker = createBroker({
logger: bindings => logger.child(bindings)
}); Default console logger const broker = createBroker({
logger: console,
logLevel: "debug"
}); The
What do you think @DeividasJackus @WoLfulus ? |
@icebob aside from the addition of So far I've continued to manually override the broker/service loggers, but have made slight changes to the bindings. Purely a matter of taste, but if there's ever a time to share mine I guess it's before v1.0:
On a slight off-note:You might know this already, but when you're using I've personally found their CLI formatter very easy to customize. Simple to make it:
Hope someone finds anything of the mentioned above useful :) |
Thank you for your suggestion. I'm changing the bindings props to a shorter name. But in case the |
@icebob: I agree, |
I prefer the |
Of those two options I'm actually leaning towards |
😆 OK, |
I finished the implementation. I'm starting to update changelog. Btw, there is an other new feature what I implemented. If you are using the built-in const broker = new ServiceBroker({
logger: console,
logFormatter(level, args, bindings) {
return level.toUpperCase() + " " + bindings.nodeID + ": " + args.join(" ");
}
});
broker.logger.warn("Warn message");
broker.logger.error("Error message"); Output:
I think from now every logging logic in Moleculer is customizable :) |
@icebob excellent! Last thing: think it's relevant to list the bindings moleculer uses itself in the documentation so users know what's considered reserved (overrides are still possible: |
Good point! I added it to changelog first. |
Would be great if we could use something like Pino as the logger:
After all, it's really fast and supports custom log levels and child loggers.
The text was updated successfully, but these errors were encountered: