Define plan for monitoring mixer itself

[istio]

Define plan for monitoring mixer itself

[wora]

Mixer essentially needs to do self billing/logging/monitoring/quota/etc. We need to design it carefully to avoid infinite loop.

[cmluciano]

Are you interested in a PR with promotheus instrumentation?

[douglas-reid]

I think we need more than just a prometheus instrumentation PR. For instance, it might be nice if mixer's metrics would be exported through whatever backend metrics adapters were configured for a running instance (could be prometheus, could be statsd, could be cloudwatch, etc.).

If you have prometheus expertise, however, we could always use another set of eyes on the //adapter/prometheus code that currently exists. Any improvements and suggestions there would be more than welcome.

I'd also be interested in a sketch of what metrics we think we should collect about ourselves (which would be independent of prometheus). That level design for instrumentation would be a good first step. If that sounds good to you, then I'd love to work with you on that too.

[kyessenov]

I think it would be nice to reuse mixer backend adapters for manager/proxy too. The important bit is to allow direct passthrough so we don't end up monitoring the monitoring path.

[geeknoid]

Hey Doug, can this be considered done?

[douglas-reid]

Yes. Let's close this. We can always make our existing choices/impl better, but we have monitoring in place now.