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

tracing: Support dynamically loading tracing libraries. #386

Merged
merged 9 commits into from
Jan 23, 2018

Conversation

rnburn
Copy link
Contributor

@rnburn rnburn commented Jan 3, 2018

Add options for specifying a tracing library to load dynamically (See also envoyproxy/envoy#2252.)

api/trace.proto Outdated
string library = 1 [(validate.rules).string.min_bytes = 1];

// File containing the configuration for the tracing library.
string config_file = 2 [(validate.rules).string.min_bytes = 1];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might this be more useful operationally if it was closer to DataSource (https://github.com/envoyproxy/data-plane-api/blob/master/api/sds.proto#L27), as it would avoid having to do filesystem management? Envoy could write files out to the filesystem if need be, i.e. if we can't load directly from memory into the trace driver.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 we should allow inline config. Can we just use Struct here and use JSON, etc. for this? Or is that too restrictive. At minimum agreed we should use Datasource to allow inline configuration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to use an inline configuration. (Looks like we'll be ok with having tracers use JSON for dynamic configurations.)

.. code-block:: json

{
"type": "dynamic",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need v1 support? Unless there is a strong need for this at your end or by folks in the community, we're trying to feature freeze v1 and encourage new features to be v2 first.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 if possible can we drop this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the v1 support.

Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, small comments

api/trace.proto Outdated
string library = 1 [(validate.rules).string.min_bytes = 1];

// File containing the configuration for the tracing library.
string config_file = 2 [(validate.rules).string.min_bytes = 1];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 we should allow inline config. Can we just use Struct here and use JSON, etc. for this? Or is that too restrictive. At minimum agreed we should use Datasource to allow inline configuration.

api/trace.proto Outdated
@@ -52,3 +53,12 @@ message ZipkinConfig {
// /api/v1/spans, which is the default value.
string collector_endpoint = 2 [(validate.rules).string.min_bytes = 1];
}

message DynamicConfig {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we call this DynamicOtConfig? I think it's unlikely but it's possible we would eventually support loadable modules of some other type. Same for above perhaps envoy.dynamic.ot for the type?

.. code-block:: json

{
"type": "dynamic",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 if possible can we drop this.

Signed-off-by: Ryan Burn <[email protected]>
@htuch
Copy link
Member

htuch commented Jan 10, 2018

@rnburn friendly ping.

@rnburn
Copy link
Contributor Author

rnburn commented Jan 10, 2018

Sorry, I'm trying to get agreement on using json/yaml for tracer configurations so that it could be embedded in the way you suggested.

I started a discussion opentracing/opentracing-cpp#45 (comment) but there were a few concerns on how best to proceed.

Will try to get an update soon.

@htuch
Copy link
Member

htuch commented Jan 17, 2018

@rnburn friendly ping :)

@tedsuo
Copy link

tedsuo commented Jan 17, 2018

@htuch @mattklein123 FYI we need to decide on the API between the application and the linked tracer - a serialized protocol like JSON or a more limited interface. Perhaps you'd like to weigh in? My impression is that JSON would be easier for everyone involved, but @yurishkuro needs convincing.

@mattklein123
Copy link
Member

IMO JSON is the way to go. Generic and easy.

Signed-off-by: Ryan Burn <[email protected]>
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, small comments.

api/trace.proto Outdated
// supported HTTP trace driver. *envoy.lightstep* and *envoy.zipkin* are
// built-in trace drivers.
// supported HTTP trace driver. *envoy.lightstep*, *envoy.zipkin*, and
// *envoy.dynamic* are built-in trace drivers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

envoy.dynamic.ot?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

api/trace.proto Outdated
@@ -52,3 +53,13 @@ message ZipkinConfig {
// /api/v1/spans, which is the default value.
string collector_endpoint = 2 [(validate.rules).string.min_bytes = 1];
}

message DynamicOtConfig {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Can you add a small message level description?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

api/trace.proto Outdated
message DynamicOtConfig {
// Dynamic library implementing the `OpenTracing API
// <https://github.com/opentracing/opentracing-cpp>`_.
string library = 1 [(validate.rules).string.min_bytes = 1];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be library_path ? @wora ? Not sure what the standard is here.

@htuch htuch merged commit bbac157 into envoyproxy:master Jan 23, 2018
htuch pushed a commit to envoyproxy/envoy that referenced this pull request Feb 28, 2018
This PR adds support for dynamically loading tracers into Envoy. It will allow authors of OpenTracing compliant tracers to support envoy without requiring envoy to bake their tracers into its build. Tracing libraries can be enabled by adding a section like this to envoy's configuration:

  tracing:
    http:
      name: envoy.dynamic.ot
      config:
        library: /path/to/tracing/library
        config: {
          ....
        }
With this change, Envoy will be able to use Jaeger's new C++ tracing library. Some features this will allow that aren't available when using Jaeger as a collector for Zipkin:

Propagation will work correctly with other services using Jaeger without requiring them to make configuration changes.
Jaeger's different sampling strategies can be used.
More efficient tranports are available.
While it might also make sense sometime in the future to offer a version of Jaeger or other tracers built into Envoy, decoupled plug-in support will allow for quicker on-boarding of tracers and more experimentation in the area without making Envoy's external dependencies become unmanageable.

Notes:

One challenge with using dynamically loaded libraries in Envoy is that the standard c++ library is statically compiled in with the option -static-libstdc++. If plugin libraries are linked to the libstdc++ in a standard way, this will create problems as two versions of the standard library will be loaded and calls to their functions from the plugin will be intermingled between them, breaking many of the standard library functions. The approach I took with Jaeger was to have it also use -static-libstdc++ and then use an export map to ensure that it's version of the standard library is used without any intermingling (see dsohowto for background on the approach). It does mean that there will be multiple copies of libstdc++ running, but from what I've heard this can be made to work. Another approach could be to add a config option to link libstdc++ dynamically.
This depends on opentracing/opentracing-cpp#45 being merged in to opentracing-cpp, but I wanted to get a PR in early to get feedback on the approach in case we need to make changes to that PR.
Risk Level: Medium

Testing:
I have a small example that demoes this functionality using docker and a branch of jaeger.

I also plan to add unit test coverage using a mock tracer library that will be added to opentracing-cpp.

Docs Changes:

envoyproxy/data-plane-api#386

Release Notes:

Included in PR.

Signed-off-by: Ryan Burn <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants