|
I have a little problem with summary indexing seemingly ignoring some fields. My logfile looks like this:
I've scheduled an index-populating query called "index-populating-query" that runs every 15 minutes and saves its results to the summary index:
When I run this query from search, Splunk correctly shows all the discovered fields on the left hand side: tx, orderId, outcome, execution_time_ms. But when I run queries against the summary index, it seems that the fields tx and outcome aren't contained in the index:
produces an empty result set, and
shows the fields orderId and execution_time_ms on the left hand side, but no outcome or tx. Does anyone have an explanation for this behaviour? I noticed that the missing fields are the ones that aren't following a comma in the log file. The outcome field could probably be extracted during my queries against the summary index using a regex (e.g. rex "(?i) outcome=(?P<outcome>[^,]+)"), but doesn't that somehow defeat the purpose of summary indexing? |
|
In general, summary index generating searches need to use a transforming/reporting command such as timechart, stats, chart, etc. So, you could change your search to be something like:
Then, your search against the summary index becomes something like:
And would yield a result like:
is there a way to preserve the fields while still populating the index with the full set of events like the requestor has? im running into the same issue, but need to run ad hoc search commands... not just preset timecharts. for ex. ironport logs all of the "from, to, subject, etc" attributes as separate events on new lines. most searches i run need to return the full results associated with that mail. so i am using a summary index to store the events in transaction form, and then run my searches against that.
(05 Dec '11, 15:16)
jshaynes
here is the command used to populate the summary index: eventtype=cisco_esa [search | fields mid] | transaction fields=mid mvlist=t | collect index=summary there is more context in this answer, where folks were recommending the summary index for this use case, even though it isn't the standard usage: http://splunk-base.splunk.com/answers/35267/very-large-lookup-tables-exceeding-2gb-bundle-size
(05 Dec '11, 15:18)
jshaynes
If you insist on storing each message id in the summary index, you can try:
However, it seems like this is a heavy handed and probably wrong approach. You would probably be better off using a python script or building some additional business logic in via the Splunk view system, depending on how you want to represent the data.
(05 Dec '11, 15:24)
araitz ♦
|