Extend metrics command to expose all or a range of metrics

[Adam Israel]

The `juju metrics` command retrieves the most recent metrics for an application/unit, but there is no way (i.e., a flag or alternate command) to retrieve all stored metrics, or a range of metrics.

In my use-case, metrics collected by Juju will be ingested into a user-defined aggregator (collecting and cross-referencing metrics from various things like applications, network, etc).

This will ultimately be done via the Juju API (to be implemented in libjuju), but it'd be useful to be able to accomplish this via CLI as well.

[John A Meinel (jameinel)]

I don't think we guarantee to store a long history of metrics. I believe we
store the current value and any values that haven't been forwarded yet. It
might be better to implement some sort of "push" support. So when we get
metrics we forward them. Internally I'm not sure we could trivially support
multiple forwarding targets.

Another possibility would be to not remove metrics for a period of time so
polling faster than that rate would be sure to get all metrics.

One concern is identifying metrics you've already seen, but I think we
already flag them with a way to identify them.

John
=:->

On Thu, Apr 12, 2018, 21:30 Adam Israel <email address hidden> wrote:

> Public bug reported:
>
> The `juju metrics` command retrieves the most recent metrics for an
> application/unit, but there is no way (i.e., a flag or alternate
> command) to retrieve all stored metrics, or a range of metrics.
>
> In my use-case, metrics collected by Juju will be ingested into a user-
> defined aggregator (collecting and cross-referencing metrics from
> various things like applications, network, etc).
>
> This will ultimately be done via the Juju API (to be implemented in
> libjuju), but it'd be useful to be able to accomplish this via CLI as
> well.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1763459
>
> Title:
> Extend metrics command to expose all or a range of metrics
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1763459/+subscriptions
>

[Adam Israel (aisrael)]

Hi John,

A few thoughts. I don't think Juju should worry about flagging metrics you've already seen, because you can't guarantee who's seen them. For example, you could have an automated process reading them via the API, and a user who checks them from the CLI, and you wouldn't want to hide "seen" metrics from either one of them.

As far as forwarding metrics, are you referring to the transmit-vendor-metrics flag? The documentation for that flag suggests it's used for collecting anonymized, aggregate metrics. Are metrics removed from the local store once metrics have been anonymized and uploaded? If so, at what interval do these uploads happen?

The core problem, I think, is that we advertise via the docs that metrics can be used to observe the behavior of an application -- "fine-grained, lower-level data sources with a model-level overview", but if we can't reliably access more than the most recently collected metrics then it's not really useful at all.

[John A Meinel (jameinel)]

We don't intend to save metrics history inside a Juju controller, but we could provide mechanisms for you to scrape and/or register a place for us to publish them.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.