TraceabilityHandler not being logged?

[whoamnick]

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?

[stevehu]

@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]

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]

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]

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.