Is there any plan to eventually migrate the proxy -> mixer metrics pipeline from using the mixer filter’s reporting pipeline to envoy’s metrics service API?
If not, it would be great to get some info on the “official” istio stance with regards to why envoy’s metrics API doesn’t work for this use case.
We’re working on a migration to istio and trying to get a full view on how those approaches for shipping metrics differ.
Hi,
We had discussions about exposing “direct APIs” from envoy to Mixer. I don’t think much progress has happened but the idea was to translate envoy APIs to Mixer internal APIs for metrics as well as external authz service using a shim in front of Mixer.
Something to be aware of is that there is potentially loss of fidelity in this translation. Envoy metrics are based on Envoy config structure (node, upstream, listener, etc) while istio associate samples with service-level concepts (k8s service, namespace, etc). The shim would need to do the reverse translation from envoy symbols back to istio concepts.
There are also functional differences in terms of batching and aggregation, which may affect performance characteristics.
There are plans to migrate the proxy -> mixer pipeline, but in a mechanism slightly different than you outline here. There is a proposal (and ongoing design / poc work) to move mixer entirely into the proxies.
That being said, Mixer does not use the metrics service API for a few reasons. Mixer takes a more generic async Report that consists (mainly) of attributes and their values. Mixer then uses operator supplied config to transform these Reports into instances of various types (metrics, logs, traces, network edges, etc.).
The key distinguishing bit here is that Mixer wasn’t (initially) designed to ingest pre-formed instances. Consuming already formed instances removes operator control (and/or requires a mechanism for editing fully-formed instances). There was a proposal (and some initial PoC work) around adding a “Direct” API to Mixer to support ingest of pre-formed instances, but that work hasn’t been done. There is hope of supporting it in the new architecture.
It looks like while I was typing this Kuat covered another reason for the difference.
I don’t know if this fully answers your questions or not, but I’m happy to discuss further at any time. I’d love to hear more about your use case and your consumption of the metrics service API.
Doug.
Thanks for the feedback! Lots of good info there. Are there any docs on that Direct API proposal? Sounds like it’s pretty far out from being available, but it would be interesting to see what the design of that looks like.
There were a few docs, probably findable on the Istio Team Drive, but they are wildly out of date. There is some discussion of supporting it anew in the docs on MixerV2 however (called Protocol Capture, iirc):
Doc: https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s/edit
Slides: https://docs.google.com/presentation/d/1Ezripop87vyiWvWVnlSSbtOZ3Y-7v0hxGY7yRhKH-ps/edit
We currently run mainline envoy as sidecars with a limited in-house implementation of the control plane in production.We are in the process of migrating to Istio. Metrics are published from envoy to the metrics service that in turn publishes to our company’s telemetry backend. We will need to support this flow during the migration at the very least along with telemetry via mixer.
We would like to send you a PR to make the metrics service configurable via the proxy config. Would you be open to that ?
Open to making the metrics service configurable? I don’t see why not. We have support for statsd export of metrics, so I think that added support for the metrics service should be directly inline with that.