Add the possibility to get TOP N groups when aggregating metrics

[scolinas]

When the selected grouping has many results it will be usefull to get top N and others alltogether aggregated.

[chungg]

can you provide an example of what you mean?

[scolinas]

For example: if you have a cost metric (we're using gnocchi to store rating measures) and you want to get the top N projects that are spending more money, just to mention one possible use case.

[xuyao18]

wow! @scolinas I have same requirement like you .

I wrote some code using aggregation to implement this ,but not efficient.

I think we should add some API like this :

method: POST
url: /v1/top?metric_name=cpu_util&limit=10&aggregation=last&start=201701108T02:00:00

body:

{
     "=": {"project_id": "project_1"}
}

then , the result should be like this:

{
     [
        {"instance_uuid1": 
              {} # some information about resource
         "cpu_util": {}  # some information about metric
         "value": "1.5"     #value to display?
        }
....
      ]
}

[sileht]

The rule for ordering metrics have a good chance to be different depending of what the metric represent (e.g: a cost, cpu_util, a rate), and also if the meter is a gauge, a delta, ....

The API already allows to group by resource attributes retrieved with aggregates API.

For example:

I want the top N instances for project_1 that consume the most cpu this week.

Request:

POST /v1/aggregates?start=20171108T02:00:00&stop=20171115T02:00:00&group_by=original_resource_id
{
  resource_type: instance,
  search: {"=": {"project_id": "project_1"}}
  operations: "(resample 1w mean (metric cpu_util mean))"
}

Answer:

[
{"group": { "original_resource_id": "<id1>" },
 "measures": { "cpu_util_mean": [["2017-11-15T02:00:00", 1w, 58.4  ]]}}
{"group": { "original_resource_id": "<id2>" },
 "measures": { "cpu_util_mean": [["2017-11-15T02:00:00", 1w, 12.5  ]]}}
{"group": { "original_resource_id": "<id3>" },
 "measures": { "cpu_util_mean": [["2017-11-15T02:00:00", 1w, 1.1  ]]}}
{"group": { "original_resource_id": "<id4>" },
 "measures": { "cpu_util_mean": [["2017-11-15T02:00:00", 1w, 42.42  ]]}}
]

Note that start - stop is exactly one week and we resample series to 1w too. This will ensure, each resulting series have only one point.

Now we have this list, it's easy to order it as you like and pick to top N.

I don't think Gnocchi should do the order/filtering/top N thing, because in all case we have to get all points from the storage to order/filter them. For my point of view this filter could easily be done by the client applications, at least for now.

If the aggregates API call is well crafted, the ordering/filtering should be fast and straightforward on the client side.

In my use case, sorting/filtering is easy because I ensure I got only one point per timeseries.
If we decide to implement that in Gnocchi itself, we have also to take care when the result have multiple points per timeseries. I have no clue about how we can express in the API which timeseries will be greater than another.

[sileht]

Also my example use resample, in case you didn't set an archive policy with a 1 week timespan.
For better performance, the archive policy of cpu_util must have 1w timespan and then the request will perform better and looks like:

POST /v1/aggregates?start=20171108T02:00:00&stop=20171115T02:00:00&group_by=original_resource_id&granularity=1w
{
  resource_type: instance,
  search: {"=": {"project_id": "project_1"}}
  operations: "(metric cpu_util mean)"
}

[jd]

Even if there's no code to write, we should at least document this with an example.

[scolinas]

@sileht Hi! Thanks for the explanation. I was thinking about the generic case where you could have one or multiple points, in this case the resampling feature can be used to resample the timeseries (using the same aggregation and reaggregation) to get aggregated timeseries with only one point so you can easily sort and get the top N. What do you think?

[scolinas]

@sileht, I still think this feature should be handled by gnocchi api because the use case it's very common when you plot the timeseries in a chart for example, and you probably want to get the less significative categories althogether aggregated in the same manner in a new category "N More" (that aggregation definitely should be handled by gnocchi). It is not trivial to get the top N and others aggregated to plot in a chart when you have multiple points and having that feature native in gnocchi api would be differentiator.

[chungg]

i'm ok with having it in Gnocchi if absolutely required. that said, the point @sileht is making is that whether it's done on server or client, they will be the exact same operations. because you're query is querying in an orthogonal dimension to what gnocchi stores it's data as, it will be doing the same steps of pulling every single data series, getting the last point, etc... whether it's done on server/client makes it no more/less efficient.

[jd]

Probably less things to transfer to client if u can do it server-side?

[chungg]

i think in this case it's negligible but yeah, i see your point :)