Loopback-next: log extension within the loopback/extensions

Created on 9 Nov 2019  路  11Comments  路  Source: strongloop/loopback-next

Suggestion

It would be great to have a log extension (something similar to the log-extension example within the supported loopback extensions

Use Cases

Just to be able manage log level indevelopment and production mode

Examples

see log-extension example

Acceptance criteria

TBD - will be filled by the team.

feature

Most helpful comment

All 11 comments

@fidgi , you mean something like this ?

https://github.com/strongloop/loopback-next/issues/3975#issuecomment-549667967

@marioestradarosa What I'm looking for is a mixin to ease the integration of a logging framework such as winston and an option in loopback/cli to enable this mixin at app creation time .

@fidgi correct!, I just wanted to make sure that's final log functionality you were looking for. Indeed that could be a good feature "external extension/package" to leverage the extensibility of looback 4 framework. I will try to write an external extension similar to the example I provided for winston.

@raymondfeng thank for working on this

_Cross-posted from https://github.com/strongloop/loopback-next/pull/4117#issuecomment-554256489_

I'd like to start the discussion with building a better understanding of different loggers and log collectors that we can choose from.

@raymondfeng Why did you pick winston and fluentd in particular?

Personally, I prefer to use pino for logging, it's more modern than winston/bunyan and is significantly more performant (2x faster according to pino's benchmarks).

I am not familiar with log collectors. I see that fluentd is a part of Cloud Native Computing Foundation, I guess that makes it a good candidate.

@strongloop/loopback-next thoughts?

I'm fine with any logging framework that is extensible and that provide a way to hide sensible data in the logs depending of the log level. For what I know winston is ok.
fluentd is also a good choice for us as we planned to use it to collect logs from our loopback-based microservices running in Kubernetes.

For the record, Pino seems to focus more on efficiency but its extensibility has room for improvement, for example, formatter to transform logs and transports to collect logs to physical destinations.

@raymondfeng , we have been using winston as a logger in production with no problems so far. Indeed we chose it because of its formatter capabilities.

@raymondfeng Thanks for this great work. .

Closing as done. Thanks.

Was this page helpful?
0 / 5 - 0 ratings