You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using OpenSearch client in combination with New Relic (e.g. when migrating from Elasticsearch)
does not work immediately. I.e. OpenSearch client does not get instrumented, so no span for the OpenSearch requests gets created. So the time the OpenSearch request takes gets attributed to time spend in PHP in New Relic.
This distorts and complicates run-time analysis.
The reason is using an old and relatively unmaintained dependency ezimuel/ringphp instead of up to date version of Guzzle Library.
See here))) and here
Just using Guzzle because a random provider has support for it feels wrong, and in my opinion, they developed it wrong. They should instrument curl and not a specific Http Client library implementation which other providers like Blackfire, Tideways, Datadog do.
1. Is there a trivial fix like a version upgrade of a dependency? 2. In other languages I see clients support multiple HTTP clients/adapters. In java we have 3, in Ruby we use Faraday that is flexible, etc. @shyim do you think it makes sense to add support for Guzzle next to whatever we have here now? 3. @normalerweise Would you like to try and contribute any of the above? We could really use some help.
Is your feature request related to a problem?
Using OpenSearch client in combination with New Relic (e.g. when migrating from Elasticsearch)
does not work immediately. I.e. OpenSearch client does not get instrumented, so no span for the OpenSearch requests gets created. So the time the OpenSearch request takes gets attributed to time spend in PHP in New Relic.
This distorts and complicates run-time analysis.
The reason is using an old and relatively unmaintained dependency
ezimuel/ringphp
instead of up to date version of Guzzle Library.See here))) and here
What solution would you like?
Upgrade to work with Guzzle HTTP client library 7
What alternatives have you considered?
Dealing with custom instrumentation
Do you have any additional context?
none
The text was updated successfully, but these errors were encountered: