Skip to content
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

TraceabilityHandler not being logged? #234

Open
DSchrupert opened this issue Jun 28, 2018 · 4 comments
Open

TraceabilityHandler not being logged? #234

DSchrupert opened this issue Jun 28, 2018 · 4 comments
Assignees
Labels
question Issue: Question

Comments

@DSchrupert
Copy link
Member

Hi Steve,

I just had a question about the differences between the correlation handler and the traceability handler. I understand differences in the code where correlation takes from the request and adds to mdc, while traceability takes from request and adds to response. But i dont understand what the use case for traceability handler is...

I already read this doc: https://doc.networknt.com/concern/traceability/

is it suppose logged anywhere else in the chain? where would that happen?

@DSchrupert DSchrupert added the question Issue: Question label Jun 28, 2018
@DSchrupert DSchrupert changed the title TraceabilityHandler not adding to MDC context TraceabilityHandler not being logged? Jun 28, 2018
@stevehu
Copy link
Contributor

stevehu commented Aug 11, 2018

@ddobrin @ChenYan71 @NicholasAzar We are not putting the traceabilityId into the MDC which make it an extra column in the log file like correlationId. There are two reasons:

  1. This header is optional.
  2. This header is not globally unique.

I am thinking to put the CorrelationIdHandler in front of this one in the middleware chain and put a logging statement in the handlerRequest method. In this case, users can search the traceabilityId and find out the correlationId in the same log statement to perform a secondary lookup with correlationId. What do you think?

@ddobrin
Copy link
Contributor

ddobrin commented Aug 11, 2018

Ideally we wish to have it in all requests, to allow for the premise of true tracing across invocations.

In the APIs build for my current project:
We have made the Traceability ID mandatory in the Swagger/OpenAPI defs, and they are also audited in BOR-type of APIs. I am thinking of moving the specification validator in front of the traceability ID handler, which will make the request fail elegantly in case it is not provided.

Can be added to MDC or not after the spec has been validated.

@stevehu
Copy link
Contributor

stevehu commented Aug 11, 2018

For some organizations, it is OK to enforce it, but it would be very hard to ask every client to pass in the traceabilityId. In your case, it makes sense to move validator in front of the traceabilityId and correlationId. In the case that traceabilityId is optional, do you think move correlationId before it and log traceabilityId and correlationId together is a good idea?

@ddobrin
Copy link
Contributor

ddobrin commented Aug 12, 2018

For the case where it is left optional, this is an idea to "bring them together" so to say.
I am not sure where the best location for such statement would be, as handlers should maintain their separation and we should not forget that this statement will be visible if the level is at debug/info.
If the respective microservice operates at warn/error, it might be missed.

I am thinking also about an additional ID which would fall also in this bucket, as an example: APIs which have a transactionID generated in their handlers. They log the id and the timestamp when it was issued.
One change I will make is to log all 3 IDs in the same statement.

Maybe one suggestion would be:

  • if a Framework or APIException is thrown and caught in the ExceptionHandler, maybe that log statement should log not only that status and respective context, but also Traceability and CorrelationID. The error would definitely be logged and could be tied together with the logs for that execution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Issue: Question
Projects
None yet
Development

No branches or pull requests

3 participants