New Relic Insights has been deprecated

[ebullient]

I tested the lib for new relic and found out that it connects to New Relic Insights which is deprecated at this moment
docs

Additional context
Originally raised against the Micrometer support in Quarkiverse

We had conversations with @breedx-nr and @jkwatson about the forked New Relic MeterRegistry: https://github.com/newrelic/micrometer-registry-newrelic, but I'm not sure if it is dead or alive (and both have left New Relic in the interim).

[shakuzen]

Thanks for bringing the deprecation to our attention. There have been discussions in the past about converging towards one registry implementation for New Relic support going forward. Related discussions: micrometer-metrics/micrometer-docs#137 and newrelic/micrometer-registry-newrelic#46. Since New Relic has deprecated Insights, I think deprecating the registry here and directing users to the New Relic maintained https://github.com/newrelic/micrometer-registry-newrelic is probably the best path forward. There were concerns from a user about transitioning from Insights to New Relic One here. @neiljpowell have you had a chance to try out the New Relic maintained registry and what a transition from the registry hosted here to that one looks like? Is there anything we can do in either implementation to help users migrate more easily?

[wilkinsona]

I think deprecating the registry here and directing users to the New Relic maintained [registry]

Given the breaking API changes that are coming in Micrometer 2.0, are the New Relic team committed to releasing a new 2.x-based version? That would require them to support the Micrometer 1.x- and 2.x-based implementations in parallel.

[breedx-splk]

Maybe @jack-berg or @jasonjkeller can add some thoughts on this.

[neiljpowell]

Hi. The Insights API is not deprecated yet in NR Java Agent code (v7.x), Agent API docs or APM Custom Event docs.

The docs link shared in the issue description above, appears specific to how NR is transitioning away from Insights usage within their own products. Does NR have a roadmap for when the Insights REST API and Java Agent's API will be deprecated? That should play into the existing NR MeterRegistry support decision (who/when/where), IMO.

[jack-berg]

I think deprecating the registry here and directing users to the New Relic maintained [registry]

This is what is preferred from New Relic's perspective.

Given the breaking API changes that are coming in Micrometer 2.0, are the New Relic team committed to releasing a new 2.x-based version?

The team that maintains micrometer-registry-newrelic has been informed about the changes in Micrometer 2.0 and is deciding on whether to release a 2.x-based version.

[marcingrzejszczak]

@jack-berg @neiljpowell we're not going to plan a 2.0 release any time soon. How can we proceed with this in the best way for our community?

[jack-berg]

Ok so a several things have changed since this issue was originally opened and I think we're in a place where we can do something definitive.

• New Relic now has GA support for OTLP
• newrelic/micrometer-registry-newrelic was archived in favor of using the opentelemetry micrometer shim
• Micrometer has a built-in OTLP registry

Under the same reasoning that New Relic archived support for newrelic/micrometer-registry-newrelic in favor of an OTLP / OpenTelemetry solution, I think its fair to archive / delete / deprecate (whatever your end-of-life strategy is) micrometer-registry-newrelic. Instead, users can use the mcirometer OTLP registry, or the OpenTelemetry micrometer shim with the OpenTelemetry SDK configured to use the OTLP exporter.

https://docs.newrelic.com/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/get-started/opentelemetry-set-up-your-app/

[neiljpowell]

@marcingrzejszczak @jack-berg Hi. Sorry for the delayed response. NewRelic's move to OTLP as the preferred approach for 3rd-party / non-Java Agent custom metric collection makes sense. However, collection of custom metrics via Java Agent Insights API still has not been deprecated per their latest Docs and Javadoc. This lends me to believe that the NewRelicInsightsAgentClientProvider can still be a valid NewRelicMeterRegistry option for users of their Java Agent.

[jack-berg]

The docs you reference are for sending custom event data. Sending metric data via the event protocol is like fitting a square peg in a round whole, and results in suboptimal and / or incorrect results in the UI compared to sending those metrics via OTLP. Additionally, its uncommon for folks to use the protocol directly - its much more common use the programatic APIs implemented by New Relic's various language agents.

I'm not sure what is accomplished by keeping the NewRelicMeterRegistry option around. We (New Relic) will advise users against using it, so it seems to just be extra code to maintain with better options available and just as easy to use.

[neiljpowell]

Hi. Yeah, not as optimal as the newer OTLP approach. For some background, it was equivalent to the other publishing option (NewRelicInsightsApiClientProvider) at the time. Besides the Agent API abstraction, publishing through the Agent via the MeterRegistry eliminated additional API key and Account Id management.