This is one of two action items for integrating with OpenTelemetry. This issue is focused on enabling us to collect OpenTelemetry data from services that have OT instrumentation, as well as to forward that data to analytics aggregation platforms such as Prometheus or Jaeger for processing.
There are two general approaches we could take, so I am going to describe them both here, but we should choose the highest-impact approach and just implement that one for our first iteration (I will describe which one I think is higher-impact).
We could build library integrations for services instrumented with OT to link to, in order to provide a direct integration, or
We can create standalone-process connectors which communicate with OT-instrumented services to collect/deliver data
I believe this second approach will have a higher impact because it should require less effort from potential adopters in order to get up-and-running with Fluvio. Let me dive in a bit deeper and explain how I imagine this playing out.
We create "OpenTelemetry Connector" executables that may be deployed alongside OT-instrumented services
I'm imagining something like a fluvio opentelemetry [push|pull] plugin
The executable can operate in "push" or "pull" mode:
In "push" mode, our connector opens a server and the 3rd-party-instrumented-service pushes metrics to it
In "pull" mode, the 3rd-party-instrumented-service opens a server and our connector requests metrics from it
I have to learn a bit more about exactly how the OpenTelemetry ecosystem works, but I think this has a lot of potential to get us pretty far on these use-cases.
This is one of two action items for integrating with OpenTelemetry. This issue is focused on enabling us to collect OpenTelemetry data from services that have OT instrumentation, as well as to forward that data to analytics aggregation platforms such as Prometheus or Jaeger for processing.
There are two general approaches we could take, so I am going to describe them both here, but we should choose the highest-impact approach and just implement that one for our first iteration (I will describe which one I think is higher-impact).
I believe this second approach will have a higher impact because it should require less effort from potential adopters in order to get up-and-running with Fluvio. Let me dive in a bit deeper and explain how I imagine this playing out.
fluvio opentelemetry [push|pull]
pluginI have to learn a bit more about exactly how the OpenTelemetry ecosystem works, but I think this has a lot of potential to get us pretty far on these use-cases.
https://github.com/infinyon/fluvio/issues/2083