-
Notifications
You must be signed in to change notification settings - Fork 232
Initial implementation of a TracerResolver for Jaeger #175
Conversation
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
@@ -0,0 +1,31 @@ | |||
# Jaeger Tracer Resolver |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
jaeger-tracerresolver/build.gradle
Outdated
signature 'org.codehaus.mojo.signature:java16:1.1@signature' | ||
} | ||
|
||
sourceSets { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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_"; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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
…th jdoc, explicit clearing of properties
@Before | ||
public void clearProperties() { | ||
// Explicitly clear all TracerResolver properties | ||
System.clearProperty(JaegerTracerResolver.JAEGER_AGENT_UDP_HOST); |
There was a problem hiding this comment.
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(), |
There was a problem hiding this comment.
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.
jaeger-tracerresolver/README.md
Outdated
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok will update
…efault values from the README.
There was a problem hiding this 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?
@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? |
|
getSamplerConfiguration(), getReporterConfiguration()); | ||
} | ||
|
||
protected static ReporterConfiguration getReporterConfiguration() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- not private?
- nit: getReporterConfigurationFromEnv
jaeger-tracerresolver/README.md
Outdated
|
||
## Configuration Options | ||
|
||
The following configuration properties can be provided either as an environment variable or system property. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…tifact's README and cross reference
This
TracerResolver
implementation uses theConstSampler
andNullStatsReporter
. Configuration for other implementations will be provided as separate PRs. This PR is intended to provide a basic resolver implementation.