Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

Initial implementation of a TracerResolver for Jaeger #175

Merged
merged 7 commits into from
May 14, 2017

Conversation

objectiser
Copy link
Contributor

This TracerResolver implementation uses the ConstSampler and NullStatsReporter. Configuration for other implementations will be provided as separate PRs. This PR is intended to provide a basic resolver implementation.

@codecov-io
Copy link

codecov-io commented May 10, 2017

Codecov Report

Merging #175 into master will increase coverage by 0.91%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #175      +/-   ##
============================================
+ Coverage     79.66%   80.58%   +0.91%     
- Complexity      447      460      +13     
============================================
  Files            76       77       +1     
  Lines          1751     1782      +31     
  Branches        205      208       +3     
============================================
+ Hits           1395     1436      +41     
+ Misses          267      255      -12     
- Partials         89       91       +2
Impacted Files Coverage Δ Complexity Δ
...e/src/main/java/com/uber/jaeger/Configuration.java 83.63% <100%> (+18.2%) 23 <10> (+11) ⬆️
...er/jaeger/tracerresolver/JaegerTracerResolver.java 100% <100%> (ø) 2 <2> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2603cc7...18fcf32. Read the comment docs.

@@ -0,0 +1,31 @@
# Jaeger Tracer Resolver
Copy link
Contributor

@mabn mabn May 10, 2017

Choose a reason for hiding this comment

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

It would be good to have here a short comment describing what it is

jar {
from sourceSets.main.output
manifest {
attributes('Implementation-Title': 'jaeger-tracerresolver', 'Implementation-Version': project.version)
Copy link
Member

Choose a reason for hiding this comment

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

Couldn't be this added to allProjects in root script?

Copy link
Member

Choose a reason for hiding this comment

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

It's repeated in every module.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If its possible then sounds like a good idea, but outside the remit of this PR.

signature 'org.codehaus.mojo.signature:java16:1.1@signature'
}

sourceSets {
Copy link
Member

Choose a reason for hiding this comment

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

Can be this boilerplate avoided? I think it's redundant as we are sticking to default file hierarchy.

I know this is repeated over and over it other modules, but should be used only in places where it's required to override a default conventions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As above, this should probably be discussed as a separate issue and applied to all artifacts.

Copy link
Member

Choose a reason for hiding this comment

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

The previous maybe yes. This can be done independently it does not affect other modules.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep that works.

@Slf4j
public class JaegerTracerResolver extends TracerResolver {

static final String JAEGER_PREFIX = "JAEGER_";
Copy link
Member

@pavolloffay pavolloffay May 10, 2017

Choose a reason for hiding this comment

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

these should be public and with javadoc

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They are only used by the resolver.

Copy link
Member

Choose a reason for hiding this comment

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

They are used outside of this module. Consumers set these when starting instrumented app, so are public. Somebody could use them programmatically. Readmes might get outdated, therefore having javadoc is a plus.

while (iter.hasMoreElements()) {
String propName = (String)iter.nextElement();
if (propName.startsWith(JaegerTracerResolver.JAEGER_PREFIX)) {
System.clearProperty(propName);
Copy link
Member

Choose a reason for hiding this comment

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

nit: clear only properties set by this test

@Before
public void clearProperties() {
// Explicitly clear all TracerResolver properties
System.clearProperty(JaegerTracerResolver.JAEGER_AGENT_UDP_HOST);
Copy link
Member

Choose a reason for hiding this comment

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

This does not clear properties set after this class. We could get all props at @BeforeClass and set them back at @After to keep all tests and class isolated.

}

protected static Reporter getReporter() {
return new RemoteReporter(getSender(),
Copy link
Member

Choose a reason for hiding this comment

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

Could we avoid writing this code and instead use the Configuration class to create the tracer? Here we just need to set the parameters on the respective Config classes, but leave the init logic to one place in the main config.

Property | Default | Description
--- | --- | ---
JAEGER_SERVICE_NAME | _none_ | The service name (must be defined)
JAEGER_AGENT_UDP_MAX_PACKET_SIZE | 65000 | The maximum packet size when communicating with the agent via UDP
Copy link
Member

Choose a reason for hiding this comment

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

These default values can get quickly outdated.

Copy link
Member

Choose a reason for hiding this comment

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

agreed - better to just say required/optional. The defaults will be applied by Configuration class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok will update

Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

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

lgtm, but perhaps we should move the init portion to Configuration class?

@objectiser
Copy link
Contributor Author

@yurishkuro Just to be clear - move everything to the Configuration class, with environment var based config via a default constructor and then the TracerResolver simply use the default constructor and return the tracer?

@yurishkuro
Copy link
Member

  • move all config-related code to Configuration (env var declaration, instantiating config objects)
  • but not to default constructor, that would not be backwards compatible - to a static method Configuration.fromEnv(): Configuration

getSamplerConfiguration(), getReporterConfiguration());
}

protected static ReporterConfiguration getReporterConfiguration() {
Copy link
Member

Choose a reason for hiding this comment

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

  • not private?
  • nit: getReporterConfigurationFromEnv


## Configuration Options

The following configuration properties can be provided either as an environment variable or system property.
Copy link
Member

Choose a reason for hiding this comment

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

Should we move these to the README in core as well? We can link to that file from here.

Right now the main README only suggests

Configuration config = new Configuration("myServiceName", null, null);

for production. I would add a sub-section there "Configuration via Environment" with what we have here. And it would also make sense to add yet another subsection that it's possible to init via TracerLoader, and link to here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good - I'll have to look at this next week.

@yurishkuro yurishkuro merged commit 917dff5 into jaegertracing:master May 14, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants