Forum Discussion
Pravin Ohal
Jun 22, 2018Copper Contributor
Union operator return results out of sequence in Azure Log Analytics Query
Hi,
I'm working on the following query. The union will give me count of the message in out of sequence fashion always for e.g The expected behavior should be that it should return results as count of xyz message first, then abc and then pqr, but the results are always out of sequence. Please help me out on this just wan to know why is this happening and how to obtain result in the same order as the statements are executed. Thanks
union
(search in (traces) message : "xyz" and timestamp > ago(1d)
| summarize count()),
(search in (traces) message : "abc" and timestamp > ago(1d)
| summarize count()),
(search in (traces) message : "pqr" and timestamp > ago(1d)
| summarize count())
This should output(expected result)
cnt_
13
2
4
but the result is
4
13
2
This sequence will always change whenever I execute the query.
Hi
I think probably the easier solution for this is :
let result1 = search in (traces) message : "New Request Received" and timestamp > ago(1d) | summarize count() | extend rank = 1; let result2 = search in (traces) message : "Listing Customers" and timestamp > ago(1d) | summarize count()| extend rank = 2; let result3 = search in (traces) message : "pqr" and timestamp > ago(1d) | summarize count()| extend rank = 3; result1 | union result2, result3 | sort by rank asc
Seems like union does not care on the order of how you stitch results. Probably this is done due to performance reasons.
3 Replies
Hi
I think probably the easier solution for this is :
let result1 = search in (traces) message : "New Request Received" and timestamp > ago(1d) | summarize count() | extend rank = 1; let result2 = search in (traces) message : "Listing Customers" and timestamp > ago(1d) | summarize count()| extend rank = 2; let result3 = search in (traces) message : "pqr" and timestamp > ago(1d) | summarize count()| extend rank = 3; result1 | union result2, result3 | sort by rank asc
Seems like union does not care on the order of how you stitch results. Probably this is done due to performance reasons.
- Pravin OhalCopper ContributorThanks Stanislav_Zhelyazkov.
BTW it is good not to use search as this slows down queries. Query like this is better:
traces | where message has "xyz" and timestamp > ago(1d) | summarize count()