Telemetry support
Opened this issue · 13 comments
Hello, do you have any plans about adding support of telemetry?
From edgurgel/httpoison#383
@benoitc , from what I understand this lib can connect both: https://github.com/opencensus-beam/opencensus_telemetry . But I think this is just for metrics and not tracing?
So basically adding telemetry to hackney would enable people to use opencensus if they wanted to or something else completely.
@edgurgel that something that could be don with hooks long time before telemetry was existing :) And I don't like the implementation of telemetry . Dispatching events using ets is exactly what I replaced with hooks.
Anyway since it's used by some people I will add a support for it in next version, that will work with hooks and some other additions.
Just stopping by to note that I'm interested in this feature as well. Given that OpenCensus has been superseded by OpenTelemetry, and in the BEAM ecosystem, it seems that the desire is to use Telemetry library as a bridge for library authors (like Hackney in this case) to emit their metrics and events, and then there would be an integration to connect that to OpenTelemetry-Erlang in case someone wants to use that.
@GregMefford thanks for the feedback. I agree supporting telemetry may be useful for some users :)
The current plan is the following . Hackney will provide inline hooking and replace metrics by it. Support of telemetry and open-telemetry will be provided by add-ons attached to these hooks. This will provide more flexibility and also support for any other solutions and usages around.
This work will land sometimes this month once I committed the changes in pooling and made the new release. Starting by adding the hooks. I will provide a better roadmap in the coming week.
Sounds great, thanks! 🚀
I'm interested to learn more about the "hooks" idea... One potential use case that is just a step beyond what telemetry provides is the ability to add Distributed Tracing instrumentation - that involves attaching an additional HTTP header to the outgoing request for context propigation.
Would this kind of use case be a target for hooks?
Here's some context: beam-telemetry/telemetry#48
@binaryseed so it's partly reusing the hooks library i've written (though with some changes). It will allows to indeed manipulate the request before if it is sent and such things. It can also be used to intercept it completely if needed. More over the coming week :)
@benoitc any update on this? I'd love to use it, so I'd be happy to help contribute to it.
@zoidbergwill i have been side tracked but it still on the pipe. I will describe the feature more accuratly this weekend so anyone can see where it's going and maybe help. I 'm not sure though it should be done on 1.x version..
Another voice of someone who would be interested in this issue, and will be interested in reviewing the code, if needed.
Hello again! Any way folks in the community might be able to help get this work moving forward?