Monasca/Instrumentation

Self-instrumenting Monasca

Goal: instrument Monasca components in the same way end users might instrument their own applications.

Options

monasca-statsd

Pros:

• Already part of Monasca: https://github.com/openstack/monasca-statsd
• Good developer API

Cons:

• statsd dialects are not compatible between backends, e.g. monasca, prometheus, datadog, statsd proper
  • i.e., language-specific libraries are needed. The only Monasca-compatible library is for Python (monasca-statsd)
• In a k8s environment, a sidecar would need to run with every pod being instrumented

prometheus

Pros:

• Simple data format: easy to write simple metrics endpoint from scratch in any language
• Large number of client libraries for major languages
• Can be scraped with zero configuration or authentication

Cons:

• Requires sidecar in certain situations, new code needed (see below)

See blueprint: https://blueprints.launchpad.net/monasca/+spec/prometheus-instrumentation

Sidecar

Prometheus monitoring with multiprocessing apps, like in the Python implementations of monasca-api and monasca-persister, leads to issues:

1. Multiprocessing support in the python prometheus_client is less than ideal
2. Overloads '/metrics' endpoint (api)

See blueprint: https://blueprints.launchpad.net/monasca/+spec/monasca-sidecar