How to build a summary index that uses eval statements to configure timechart results?

[a109120]

I am trying to build a summary index to pull a week over week comparison of specific applications. The below query works normally, but for efficiency reasons I would like to place this in a summary index. I am having trouble getting the results I want displayed for the comparison in question. My results with sitimechart are using the date and time that the data was ingested into the Summary Index which prevents my comparison method from working.

The search results off of the summary index places events in a "NULL" column and does not follow the eval statements.

index=1 host=1234 sourcetype=sourcetype application=app earliest=-2w@w latest=@w 
| eval marker = if (_time < relative_time(now(), "-1w@w"), "last week", "this week") 
| eval _time = if (marker=="last week", _time + 7*24*60*60, _time)
| timechart count by marker cont=FALSE

See attached for stats table

[skoelpin]

You should try using the collect command to put into a summary index and query it. This will also include _time so its broken in the correct days, just as your table is showing

 index=1 host=1234 sourcetype=sourcetype application=app earliest=-2w@w latest=@w 
 | eval marker = if (_time < relative_time(now(), "-1w@w"), "last week", "this week") 
 | eval _time = if (marker=="last week", _time + 7*24*60*60, _time)
 | timechart count by marker cont=FALSE
| collect index=summary 

Then when its collected, you can then query your summary index

index=summary sourcetype=..
| timechart span=1d max(last_week) AS last_week max(this_week) AS this_week

[a109120]

I gave this a try and the timechart did not assign any values to the this_week/last_week columns. I think I have a few ideas to get that to work. Thanks for the input

[ddrillic]

Please consider the new features, such as report acceleration before attempting the legacy tricky summary index.

[skoelpin]

Agreed that an accelerated data model would probably be better, but it would depend on the scenario. An accelerated data model eats up disk space for the additional tsidx files and also consumed 3 concurrent searches every 5 mins to update the summary range. This is a lot of overhead if OP wants a simple solution with minimal overhead. I wouldn't consider a summary index old legacy tricky technology.. ITSI uses it and doesn't plan on ditching it anytime soon

[a109120]

Yes that is exactly why I am looking into summary indexing. I am trying to avoid using up the large amount of resources.