Interested in hosting legacy new-relic Meter registry?

[checketts]

Congrats on the new dimensional metrics option! That is so great! I'm a contributor to the Micrometer project and would love to deprecate the old registry in favor of this one.

Would New Relic be interested in creating a github repo we could migrate the old registry to?

[jkwatson]

Hello @checketts ! Is your thought that we could keep the code around somewhere for reference, or would you also need builds and publishes to maven central?

[jkwatson]

Also, @checketts , are you interested in moving this new registry into the micrometer repo directly, or should it live externally?

[checketts]

The old meter registry would likely need to be setup to support new builds/releases in case of fixes and or if the New Relic API changes. Hopefully, they won't be needed.

I think having this registry live externally is good since you can iterate as you see fit and release as often as you like. If it were moved into the Micrometer Repo directly, then you would be contributing PRs, which would create extra work for the maintainers, or delays for your fixes.

For example, I personally only can honestly help with the PRs for registries I have access to use (Prometheus, Datadog, Splunk) since I don't have New Relic experience. (That being said I'm happy to answer questions in your repo if I'm able)

That being said, @shakuzen would really make the call regarding moving repos.

[jkwatson]

@abhihub I'm going to leave this with you to figure out if/when we want to spend the time on this one. I don't think there's a technical reason why we couldn't do it, it'll just take some time to make it happen.

[jkwatson]

@checketts @shakuzen Is micrometer moving to a model where vendors will host their own integrations? It would be weird for us to be hosting our own, while our competitors stay in the main micrometer project.

[checketts]

There is no model change. This issue was merely to investigate willingness and capability. If the New Relic registry were to move out, it would make sense to leave the folder in the main project directing contributors to look here.

My main concern is that the code follow the expertise. If a user were to submit a PR for a New Relic meter registry, I have no way to validate it nor really understand the implications.

I would love if each registry in the main repository has a sponsoring contributor that would review all PRs that relate to that specific registry. But I don't think that is my call to make.

[jkwatson]

@checketts @shakuzen
Before we think about hosting the old registry, can we get the official docs updated to point to our new, supported registry? Is that something we should PR ourselves?

[danifitz]

hey @checketts I'll ask the same question as @jkwatson did above. We'd like to get the official docs updated to point to the new registry implementation using dimensional metrics. Can that be done using a PR or does one of the maintainers need to be involved? Thanks in advance!

[checketts]

Yes. You can do it via a PR in the docs repo: https://github.com/micrometer-metrics/micrometer-docs

I haven't contributed to that repo myself though so I'm not super familiar with the development requirements

[jkwatson]

I created this issue to track the work: #60

[subvocal]

@shakuzen - We're interested in figuring out the best path for the New Relic Micrometer registry. Today, there's the original registry that the Micrometer project created and then there's the new one that New Relic released that sends metrics to the new Metric API.

We like the idea of moving the new version of the registry into the Micrometer project so it's where users expect to find it and deprecating the existing impl. We're fine with needing to submit PRs. What are your thoughts?

[shakuzen]

Sorry for my absence here. Regarding documenting this repository in the official Micrometer docs, that was taken care of with micrometer-metrics/micrometer-docs#102. It can be seen at https://micrometer.io/docs/registry/new-relic

There are some tradeoffs to consider when it comes to where the New Relic registry implementations live. It may have better discoverability by users in the Micrometer main repository. However, issues and pull requests can get buried in unrelated things because it's one repository for everything - it makes it harder for those with the expertise in New Relic to notice and respond to those, perhaps. Also, the release cycle is tied to the main Micrometer repository. As a separate repository, it can be released at its own pace. Just some things for us to consider.
In the end, I am fine with the code living here or in the Micrometer repository. If it is moved to the Micrometer repository, I would request that we setup some process by which New Relic experts can be easily involved in issues and pull requests requiring such expertise.

On deprecating the existing New Relic MeterRegistry implementation, I am curious how quickly/smoothly users will be able to transition to the new one. Are the requirements (API keys) different? We recently merged support for sending metrics via the New Relic Java agent as there was some request from users that this would be easier configuration-wise and less keys required for them. See micrometer-metrics/micrometer#1647 (comment) and micrometer-metrics/micrometer#1761

[neiljpowell]

@victorNewRelic @jkwatson Let me know if additional user perspective would help.

[MikhailAsadchyIDT]

As @shakuzen, has already mentioned, there is a problem for migrating to this new lib from deprecated one. Reason - there is no option to use NewRelic Java agent.

Instead it's required to use API key.
When I use API key, I get two different services in NewRelic (one from Java agent with metrics it sends, second - from API with its metrics). And looks like this is a root cause (or some sort of it) of entity duplication issue.

Is there a plan to support sending metrics via NewRelic Java Agent?
@checketts, @jkwatson

[checketts]

I'm not working on any New Relic code. So I'm guessing @jkwatson or @abhihub would be best to handle that question.

[XiXiaPdx]

@MikhailAsadchyIDT - Apologies for the absence here! Watson and Abhi are no longer at New Relic so I'll see if I can answer your question here.

There is active work into having the new Micrometer accept the same key as the New Relic Java Agent - the license key. This would eliminate the need for the API key. This should ease the transition for users of the deprecated registry to the new one.

@shakuzen @neiljpowell From my interpretation of this conversation, my understanding is having a smooth path for users to transition to the new registry is the crux here?

[neiljpowell]

@XiXiaPdx Hi. I'm glad to hear that you are working on supporting use of the Agent's license key. That should address the primary concern I noted on the Micrometer NewRelicMeterRegistry issue I submitted before the contribution. See: micrometer-metrics/micrometer#1540 for details. The other concerns were related to how/if New Relic's new MeterRegistry would compare to the Agent with regard to publishing retries and needing additional connectivity through firewalls. I'd personally like to see this metric API exposed on the Agent and continued option of delegating Boot's metrics to it.

Regarding a transition path, the Micrometer implementation delegates to the Agent Insights API which publishes to an event bucket and New Relic's implementation publishes to a metrics bucket, transitioning will take some work. i.e. Updating NRQL queries for dashboard, alerts, etc. Offering a migration tool or guidance could be helpful. Otherwise, I suspect that some users may employ both registries simultaneously, until comfortable cutting over.

[kford-newrelic]

Hi @checketts, appreciate you initiating this suggestion on the repo. Unfortunately, we're not able to prioritize this for our roadmap. We'll have to close this with no further action.