Logging id about hemera HOT 15 CLOSED

@danielo515 please upgrade to 5.6.0 I fixed the logging message and added logs for the server side as well.

from hemera.

No, in debug mode we log the request$.id when a request is made or received. You are looking for the trace$.traceId which can be served as correlation id. We don't attach it on each log but I'm open for a proposal.

You have always access to the request and trace informations at any point in hemera inside add and act.

• https://hemerajs.github.io/hemera/docs/trace.html

from hemera.

Hello @StarpTech
When you have a distributed system like the one this framework and Seneca were made for, you need an unique ID to trace a transaction across systems. What I want is to be able to trace a transaction down the logs by it's ID. For that reason it is needed that a transaction gets an ID when it enters the system and that ID is kept across the entire lifecycle of the transaction as it pass through the different microservices that compose your backend. So, in order to search on the log system (files, graylog, or whatever) for a concrete transaction you need that unique id to be present on all the transaction logs.

I'm not sure if I'm being clear, hope I am.

from hemera.

Hi @danielo515 we provide a correlation id across calls in hemera. You can use the trace$.traceId. You're right this information should be annotated to the logs. Would you like to create a PR?

from hemera.

Sure, it will be a fun way of learning. Should it require a new plugin or modifying an existing one?

from hemera.

It should be easy to extend. We are using the Pino logger module.

from hemera.

But is it one particular place or should I look for all the calls to the pino logger?

from hemera.

Hi @danielo515 I think it's not possible without to wrap the default logger interface.
If you want to track the correlation id on each log you have to do:

hemera.log.info({ traceId: this.trace$.traceId, ...props })

from hemera.

Forget what I said 😄 It's possible via childLogger feature but it costs performance so it should be enabled by a flag.

from hemera.

Here https://github.com/hemerajs/hemera/pull/211/files check it out 😄

from hemera.

Hello @StarpTech , thanks for your comments.
The provided example seems to be extending the hemera core, is that correct ? Or maybe you are suggesting that this is something each microservice should extend ? I would prefer to have this on the core, even if it is behind a flag.

Do you think that the performance impact of this is one of the reasons why hemera is more performant than Seneca ?

from hemera.

The provided example seems to be extending the hemera core, is that correct ? Or maybe you are suggesting that this is something each microservice should extend ? I would prefer to have this on the core, even if it is behind a flag.

Yes, it's correct. In the current implementation, you can set the flag and all logs will contain the tracing data.

Do you think that the performance impact of this is one of the reasons why hemera is more performant than Seneca?

Definitely not. Hemera was implemented from the ground up to be lightweight, flexible and maintainable. Performance is important but it's not the main aim.

from hemera.

The feature was released! Thank you for the impulse.

from hemera.

Awesome ! So it is already available ? How can I activate it ?

from hemera.

Look at the PR. Option traceLog:true

from hemera.