How to compare results of same search for two different time ranges without using timechart?

[ashbhaic]

I have logs which tell me the service name, time and domain name where this service was called.

I have a query to chart the number of services that were invoked for each domain (channel) as below :

index=realtimelogs earliest=-15m@m | chart count(SERVICE) AS "No. of Services Invoked" by channel

It results in below :

 channel      No. of Services Invoked
    TSYS      1234
Fidelity      2345 

I am looking for a single query that can pull the count in two different time intervals so that I can compare the count by channel in those two time ranges. (I am looking for a way to add a new column to the existing result which lists data from a different time range.

I am not looking for plotting the results against time. I just need a side by side comparison.

[ashbhaic · Accepted solution]

Ok .. so i figured out a way to do this ...
All answers point to use of append but were plotting the data on a timechart. My need is to plot the number of services that were invoked against the channel where they were invoked and do a comparision side by side and append was way too slow.
Below is what I used and gives me exactly what I am looking for :

|multisearch [search index=realtimelogs earliest=-15m@m | eval id="15m back"] [search index=realtimelogs earliest=-30m@m latest=-15m@m | eval id="30m back"] | chart count(SERVICE) by channel id

It plots as a Bar chart (sadly I dont have enought points to post pic here 😞 ) with two bars each channel showing the count of services that were invoked between now-15m back and 15m-30m back.

[Richfez]

Another way to handle this could be:

index=realtimelogs earliest=-30m@m | bin _time bins=2 | stats count by _time, channel | xyseries _time, channel, count

You can change around the order of the parameters of the xyseries to change what's plotted against what, and bin has more options, like span=15m, log spans and all sorts of other things.

Just another option for people who stumble across this question in the future.