Out of process Mixer adapter to receive information about non-HTTP calls

Policies and Telemetry
8

Thank you very much for this information. A bunch of questions if you have time:

  1. What is an “Istio filter” exactly? For the HTTP filter, I see what appears to be a native Envoy component here (https://github.com/istio/proxy/blob/8455b9eb514c1a527fc4447951af00acd83104f5/src/envoy/http/mixer/filter.cc). Is there more to an Istio filter? How is it different from a regular native Envoy filter?

  2. Do I understand correctly that directly configuring Envoy filters through this configuration here (https://istio.io/docs/reference/config/networking/v1alpha3/envoy-filter/) is not a good long-term solution? It’s referred to as a break-glass configuration in the docs. What’s the appropriate way of configuring a filter then?

  3. Do I understand correctly that your preferred plan of actions would be roughly as follows?

  • pick a protocol to support (say, Redis)
  • write the native Envoy filter for that protocol (in case of Redis already exists). An implementation would be similar to the implementation for, say, HTTP filter found here (https://github.com/istio/proxy/blob/8455b9eb514c1a527fc4447951af00acd83104f5/src/envoy/http/mixer/filter.cc), except maybe it doesn’t directly send data to mixer through the mixer client, but rather generates attributes which other filters down the chain process and send.
  • write some sort of pilot-side configuration component which configures the Envoy-side filter (Is this needed? What would it look like?)

If there’s a documentation regarding this subject that I’m unable to find, please feel free to point me to it :slight_smile: