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

[docs] Document feature matrix for client libraries #384

yurishkuro opened this Issue Sep 6, 2017 · 2 comments


None yet
2 participants

yurishkuro commented Sep 6, 2017

First column:

  • standard tracer metrics
  • standard rpc metrics
  • logging reporter
  • configurable
  • env configurable - Java only atm
  • remotely controlled sampler
  • adaptive sampling
  • baggage restrictions
  • reporter: Jaeger Thrift over UDP
  • reporter: Zipkin Thrift over UDP (Python client still does that, needs upgrade)
  • reporter: Jaeger Thrift over HTTP
  • reporter: Zipkin Thrift over HTTP
  • reporter: Jaeger JSON over HTTP - don't think we have any, just i case. Node.js might be a good candidate for that
  • reporter: Zipkin JSON over HTTP - don't think we have any, just i case
  • Uber headers format
  • Zipkin/B3 headers format
  • in the future - other formats

The other columns are for individual clients

  • header - language and link to the repo
  • values - :white_check_mark: or :x: + optional link to open issue
    • :white_check_mark: is a bit long, could use 🆗 :ok:

@yurishkuro yurishkuro added this to the Release 1.0 milestone Oct 8, 2017


This comment has been minimized.

pgadige commented Mar 28, 2018

I'd like to build this feature matrix. I'd consider Jaeger client libraries in GO, Java, Python, Node and C++ on successive columns, and determine whether each feature in the first column is present/supported or not in each of the above client libraries? Could you please provide a hint on where to gather information about each feature, for instance, code snippets, other documentation posts?


This comment has been minimized.


yurishkuro commented Mar 28, 2018

Hi @pgadige ,

Thanks for offering to help with this. The only reliable way to determine if a feature is supported is to actually check the code (sometimes README) of each of the clients. We can actually start with setting up the document structure and just filling cells with a question mark, at least for things that you're not sure about.

Another thing I was thinking of is what format should the source of this information take. We can certainly create a table in Markdown, but my concern is that it will be very hard to maintain due to formatting issues, e.g. say we want to add a link to an existing issue for one of the cells, it would change the cell width significantly, making the table very hard to edit. A more maintainable way would be if we used some config file format, e.g. yaml, to define the features for each client, and then generate the Markdown from that yaml file programmatically. For example:

    standard_tracer_metrics: yes
    standard_rpc_metrics:    no
    standard_tracer_metrics: yes
    standard_rpc_metrics:    yes
    standard_tracer_metrics: custom
    standard_rpc_metrics:    no -

etc. We can use a simple python script to read this file and produce a Markdown table

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment