search

SoftInstigate / restheart

Rapid API Development with MongoDB
https://restheart.org
GNU Affero General Public License v3.0
807 stars 171 forks source link

OpenTracing support #287

Closed lenalebt closed 6 years ago

lenalebt commented 6 years ago

This is a feature request.

Expected Behavior

Restheart should handle incoming trace IDs (e.g. X-B3-TraceId) and write them to log entries where appropriate. There are multiple ways of doing it - I think keeping it simple and stupid would be enough. If a request has such an ID, write it to the logs for all log entries originating from that call.

Current Behavior

Trace IDs are ignored.

Context

This would make it easier to get an idea of what is happening within the system in cases where restheart is part of a larger microservice architecture (e.g. if you use a log tool like Kibana, getting all log entries of all services for one specific trace would be easy). This is mainly a feature that is useful for debugging purposes.

Environment

n/a

Steps to Reproduce

n/a

Possible Implementation

You can most probably extract the X-B3-TraceID header when it enters your system, write that to the thread-local MDC that is used in your logger, and then simply use that in your logback configuration.

There may be more headers than just that X-B3-TraceID. I have seen multiple (e.g. X-Flow-ID and X-Trace-ID), but the concept has always been the same: Single header containing the trace ID, that one being written to all log entries. Maybe it makes sense to make it configurable which header should be used with a default for X-B3-TraceID (that one is used by the OpenTracing initiative which is being used by many people).

lenalebt commented 6 years ago

Just to be clear about this: I don't think that it is necessary to have full OpenTracing support. I am currently only interested in having header contents in the logs, which is sufficient for most cases and does not require additional dependencies.

chwal commented 6 years ago

That would be great!

mkjsix commented 6 years ago

@lenalebt sounds interesting, thank you. At first sight it doesn't look too complex, but we need to have a deeper look. I think making configurable which header must be logged is the most reasonable option. However we need to study a bit the Opentracing initiative, at the end it might be useful to make the project fully Opentracing compliant.

lenalebt commented 6 years ago

Yep, maybe OpenTracing can help with the rest of the application as well - but I think for most users, this is not really needed - especially since restheart itself does not open HTTP connections to other services. One possibility would also be to first implement the lean version with only logging, and make use of the richer options when you feel it might be a good thing...

mkjsix commented 6 years ago

We've just released RESTHeart 3.4.2 which includes the PR.

The docs are here. Feel free to edit / improve them, thank you.