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

NewRelicMeterRegistry Java Agent Insights API Support #1647

Conversation

neiljpowell
Copy link
Contributor

@neiljpowell neiljpowell commented Oct 17, 2019

This PR is for Issue #1540
NewRelicMeterRegistry support for delegating to the New Relic Java Agent Insights API for previously mentioned benefits. Construction/Builder defaults to original behavior using Insights REST API.

Implementation notes:

  • NewRelicClientProvider interface introduced for easy introduction of Agent support. Bulk of the original registry implementation moved to the Http client provider. Separate client provider impls will also work well for conditional Boot auto configuration based on presence of the Agent, etc. It may also help with incorporating future enhancements like dimensional metrics noted in PR Add support for categorical "MicrometerSample" eventType to publish New Relic metrics. #1588
  • MeterRegistryCustomizer/MeterFilter mentioned in the Issue for preventing duplicate metrics collected by the Agent would be included with the accompanying SpringBoot NewRelicMetricsExportAutoConfiguration updates.

@shakuzen @checketts @breedx-nr

Resolves #1540

@checketts
Copy link
Contributor

checketts commented Oct 17, 2019

@neiljpowell I'm not too familiar with New Relic's offerings. This PR has a lot of changes for the NewRelic registry, however New Relic has created their own dimensional registry (https://github.com/newrelic/micrometer-registry-newrelic#new-relic-micrometer-registry) and has mentioned that it supersedes this one.

Can you summarize the options/approaches at a high level the New Relic users have and how this PR changes that?

@neiljpowell
Copy link
Contributor Author

neiljpowell commented Oct 18, 2019

@checketts Hi. Yes, this enhancement provides the benefits mentioned in the originating issue noted above. It allows users of the New Relic Java agent to continue publishing metrics to Insights in a more consolidated way, that doesn't require additional API Key provisioning. Users have a high likelihood of already using the Agent and it requires its own license key. In a large enterprise, this could easily eliminate lots of extra keys. Delegating to the agent also provides buffering not provided by the current implementation. It can potentially simplify security proxy config by reducing the outbound destinations needed. @shakuzen 's preference for incorporation into the current meter registry resulted in the large amount of change. I was originally going to contribute a separate meter registry. However, the approach taken left most of the original code intact.

Regarding @breedx-nr 's announcement in my other PR, I had previously discussed this Agent based enhancement with him and other New Relic folks. They supported this Insights publishing option, as it may benefit many of their users based on points mentioned above, which may also be a consideration of users wanting to adopt the new dimensional metrics agent.

I'll get the merge conflicts resolved asap. A polish commit snuck in right after I submitted this PR.

https://github.com/micrometer-metrics/micrometer.git into
newrelic-java-agent-meter-registry

Conflicts:
	implementations/micrometer-registry-new-relic/src/main/java/io/micrometer/newrelic/NewRelicMeterRegistry.java
	implementations/micrometer-registry-new-relic/src/test/java/io/micrometer/newrelic/NewRelicMeterRegistryTest.java
@neiljpowell
Copy link
Contributor Author

@checketts @shakuzen This PR changed the registry's baseTimeUnit to milliseconds. It was one of the few registry impls with seconds, which is an eternity when monitoring all the things. Any concerns?

@checketts
Copy link
Contributor

which is an eternity when monitoring all the things

Would this change break user's dashboards they had already created? Does it actually impact the outputted data since you still have the decimals in seconds? Isn't 10 millis and 0.01 seconds the same?

I'm not opposed to making the change if we don't need to worry about breaking existing users. Or we should wait for a 2.x release to do the break.

@neiljpowell
Copy link
Contributor Author

@checketts To ensure backward compatibility, baseTimeUnit has been reverted. It affects output.

@shakuzen
Copy link
Member

I've added the linked issue to the 1.4 milestone. I'll come back to more thoroughly review this in time for that. Others feel free to leave reviews in the meantime.

Copy link
Member

@shakuzen shakuzen left a comment

Choose a reason for hiding this comment

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

I left some review. Could you check those and rebase on the latest master when you get a chance?

@neiljpowell
Copy link
Contributor Author

@shakuzen I've addressed all review comments. I'm happy to look at anything else you may find. Thanks.

@shakuzen
Copy link
Member

@neiljpowell Sorry for the delay on this. Would you be able to rebase your changes here on the latest master so it is easier for me to merge?

@neiljpowell
Copy link
Contributor Author

@shakuzen Sure. I should be able to get it done later today.

@neiljpowell
Copy link
Contributor Author

@shakuzen Master has been merged in. I had to adjust build.gradle. Please take a look.

Copy link
Member

@shakuzen shakuzen left a comment

Choose a reason for hiding this comment

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

Looks good to me. Thank you for contributing this and your patience on it finally landing in a release. I will polish a few things post-merge.

@@ -2,6 +2,7 @@ dependencies {
api project(':micrometer-core')

implementation 'org.slf4j:slf4j-api'
implementation 'com.newrelic.agent.java:newrelic-api:5.+'
Copy link
Member

Choose a reason for hiding this comment

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

We want optionalApi here so we are not adding this dependency for all users of micrometer-registry-new-relic. Users who want to use the Agent client provider should include this dependency for their application.

//gauge
String VALUE = "value";
//counter
String THROUGHPUT = "throughput"; //TODO Why not "count"? ..confusing if just counting something
Copy link
Member

Choose a reason for hiding this comment

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

This is probably an oversight. As the philosophy of Micrometer, we want users to focus on rates of counts rather than the raw count. Accordingly, the intention was probably to ship the rate (throughput) of the counter rather than the step count. I'll open a separate issue to look at that. In this pull request, it is probably best to keep the existing behavior and limit its changes to the purpose of the pull request.

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.

New Relic Java Agent MeterRegistry
3 participants