Comment 1 for bug 1763459

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
>