Unable to fetch data from multiple metrics if single metric doesn't exist.

[KrishnaFlutura]

Hi,
I am facing an issue when I make a query containing multiple metrics.
Suppose the DB contains the following metrics,
METRIC-1 METRIC-2 METRIC-3
And i make a query as
http://ipAddress:8888/api/query?start=928233840&end=1561545840&ms=true&m=sum:633312000s-mimmax-none:METRIC-1{Type=EVENT}&m=sum:633312000s-mimmax-none:METRIC-2{Type=EVENT}&m=sum:633312000s-mimmax-none:METRIC-3{Type=EVENT}

I get proper response as
[ { "metric": "METRIC-1", "tags": { ... }, "aggregateTags": [], "dps": { "1266624000000": 327.8999938964844 } }, { "metric": "METRIC-2", "tags": { ... }, "aggregateTags": [], "dps": { "1266624000000": 0.004755097907036543 } }, { "metric": "METRIC-3", "tags": { ... }, "aggregateTags": [], "dps": { "1266624000000": 0.23775489628314972 } } ]

But if there is a new metric METRIC-4 which isn't present in the DB,
and new URL is http://ipAddress:8888/api/query?start=928233840&end=1561545840&ms=true&m=sum:633312000s-mimmax-none:METRIC-1{Type=EVENT}&m=sum:633312000s-mimmax-none:METRIC-2{Type=EVENT}&m=sum:633312000s-mimmax-none:METRIC-3{Type=EVENT}&m=sum:633312000s-mimmax-none:METRIC-4{Type=EVENT}

I get the following error
{ "error": { "code": 400, "message": "No such name for 'metrics': 'METRIC-4'", "details": "No such name for 'metrics': 'METRIC-4'" } }

I expect the response to other metrics that exist.

[kiddico]

This is exactly the response you should expect, you gave it an invalid query and it responded appropriately.

If you need the described behavior you'll need to break each metric into a separate query.
Alternatively query for all metrics that match "METRIC-*" and query for those like you're already doing.

[coderLinJ5945]

Hi,
I also encountered this kind of trouble. Due to the uncertainty of query parameters, there was no hbase in the multi-metric or multi-tags query, and all the results could not be returned.
I want to return the correct METRIC value, and my current approach is to decompose the query, which greatly reduces query efficiency.
Dear kiddic can be configured to allow the user to choose whether to return abnormal information or normal data in this case