Using /query/exp with a single metric.

[Marcin Januszkiewicz]

Hi,

we are experimenting with 2.3 and using the /query/exp endpoint for computations. We would like to compute the ratio of two series that are part of the same metric, i.e.:


(sum:queries{type=http})/(sum:queries{type=*})

We'd like to express this as a query like this:

{
    "time": {"start": "1h-ago", "aggregator": "sum"},
    "filters": [
        {
            "tags": [{ "type": "literal_or", "tagk": "type", "filter": "http", "groupBy": false}],
            "id": "f_http"
        },
        {
            "tags": [],
            "id": "f_all"
        }
    ],
    "metrics": [
        {
            "id": "http",
            "metric": "hits",
            "filter": "f_http",
            "fillPolicy":{"policy":"zero"}
        },
        {
            "id": "all",
            "metric": "hits",
            "filter": "f_all",
            "fillPolicy":{"policy":"null"}
        }
    ],
    "expressions": [
        {
            "id": "part",
            "expr": "http / all"
        }
    ]
}

but this produces a response with as many series as there are tagvs for the tag "type". Is there a way to do this that doesn't require client-side computation?

[ManOLamancha]

Ahh, this is a problem that it doesn't address very well right now.  We ran into a similar issue lately and I'll have to come up with a fix in Q1. Posted an issue for tracking here: https://github.com/OpenTSDB/opentsdb/issues/907

[Jonathan Creasy]

Can we allow qexp funcitions from exp?

[ManOLamancha]

On Monday, December 19, 2016 at 2:48:39 PM UTC-8, Jonathan Creasy wrote:

Can we allow qexp funcitions from exp?

Hmm, we might be able to, would have to shim the formats. But we may have an entirely different under-the-hood flow for 3.0 so it may be worth focusing on that.