{"action":"closed","issue":{"url":"https://api.github.com/repos/opentracing/opentracing-cpp/issues/28","repository_url":"https://api.github.com/repos/opentracing/opentracing-cpp","labels_url":"https://api.github.com/repos/opentracing/opentracing-cpp/issues/28/labels{/name}","comments_url":"https://api.github.com/repos/opentracing/opentracing-cpp/issues/28/comments","events_url":"https://api.github.com/repos/opentracing/opentracing-cpp/issues/28/events","html_url":"https://github.com/opentracing/opentracing-cpp/issues/28","id":268219058,"number":28,"title":"OpenTracing support for dynamic loading.","user":{"login":"rnburn","id":1923871,"avatar_url":"https://avatars3.githubusercontent.com/u/1923871?v=4","gravatar_id":"","url":"https://api.github.com/users/rnburn","html_url":"https://github.com/rnburn","followers_url":"https://api.github.com/users/rnburn/followers","following_url":"https://api.github.com/users/rnburn/following{/other_user}","gists_url":"https://api.github.com/users/rnburn/gists{/gist_id}","starred_url":"https://api.github.com/users/rnburn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rnburn/subscriptions","organizations_url":"https://api.github.com/users/rnburn/orgs","repos_url":"https://api.github.com/users/rnburn/repos","events_url":"https://api.github.com/users/rnburn/events{/privacy}","received_events_url":"https://api.github.com/users/rnburn/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":17,"created_at":"2017-10-24T23:24:56Z","updated_at":"2018-02-22T21:37:57Z","closed_at":"2018-02-22T21:37:57Z","author_association":"COLLABORATOR","body":"Many C/C++ projects (e.g. nginx, haproxy, varnish, envoy) that would benefit from OpenTracing instrumentation are distributed as binary executables instead of libraries.\r\n\r\nWhen instrumenting such projects, the practice so far has been to write code for each tracer that exposes its configuration options as part of the applications configuration. (See for example [nginx-opentracing/lightstep](https://github.com/opentracing-contrib/nginx-opentracing/tree/master/lightstep) and [nginx-opentracing/zipkin](https://github.com/opentracing-contrib/nginx-opentracing/tree/master/zipkin)).\r\n\r\nThis increases the cost of maintaining these projects and goes against OpenTracing's goal of making it easy to switch tracing implementations. Furthermore, since many of the projects are used as building blocks in larger systems that interact with the application's configuration, the cost compounds since those systems also need to be aware a tracer's configuration. (See for example how OpenTracing was incorporated into Kubernetes' [ingress-nginx controller](https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L18)).\r\n\r\nI propose we adopt some conventions for C++ tracers that would allow applications to load tracers in dynamically using [dlopen](http://man7.org/linux/man-pages/man3/dlopen.3.html) and decouple applications from specific tracer configuration options.\r\n\r\nThis could be done by standardizing on a function that could be looked up from a tracer's shared library using [dlsym](https://linux.die.net/man/3/dlsym). Consider for example a C function (to avoid mangling) like\r\n```\r\nextern \"C\" int opentracing_make_vendor_tracer(void** tracer, const char* json_configuration);\r\n```\r\nthat would take in a configuration string for the tracer in JSON, set `tracer`, and return 0 on success or some non-zero error code on failure.\r\n\r\nA user of an application like nginx, then, might configure a tracer by adding something like\r\n```\r\nopentracing_tracer_option access_token abc123;\r\nopentracing_tracer_option collector_host localhost;\r\nopentracing_load_tracer liblightstep_tracer.so;\r\n``` \r\ninto `nginx.conf` which would cause nginx to lookup `opentracing_make_vendor_tracer`in `liblightstep_tracer.so` and call it with\r\n```json\r\n{\r\n  \"access_token\": \"abc123\",\r\n  \"collector_host\": \"localhost\"\r\n}\r\n```\r\navoiding the need to have specific configuration directives for each LightStep option.\r\n\r\nProjects that want to avoid the pains associated with dynamic library management could still link in some tracers statically, but might also add dynamic loading functionality like this as an optional way to plug in additional tracers.\r\n\r\nStandards around both trace encoding and transport (such as what's outlined [here](https://github.com/opentracing/specification/issues/86)) might make it possible some day to have a vendor neutral tracer that could report to any tracing system and avoid the need to dynamically load anything in, but this would address a more immediate need to make OpenTracing scalable and maintainable for these projects."}}
{"actor":{"display_login":"rnburn"}}