Databases Reference
In-Depth Information
The problem is that on a busy mail server, this search might retrieve millions
of events and then throw most of the work away. We want to actually use the
index efficiently, and a subsearch can help us do that.
Here is how we could tackle this with a subsearch:
[search sourcetype=mail from=mary@companyx.com | fields msgid]
sourcetype=mail to
Let's step through everything that's happening here:
1.
The search inside the brackets is run:
sourcetype=mail from=mary@companyx.com
Given our sample events, this will locate two events:
2012-04-20 13:07:03 msgid=123456 from=mary@companyx.com
2012-04-20 13:07:06 msgid=234567 from=mary@companyx.com
2. | fields msgid then instructs the subsearch to only return the field msgid .
Behind the scenes, the subsearch results are essentially added to the outer
search as an OR statement, producing this search:
( (msgid=123456) OR (msgid=234567) ) sourcetype=mail to
This will be a much more efficient search, using the index effectively.
3.
This new search returns the answer we're looking for:
2012-04-20 13:07:05 msgid=123456 to=bob@vendor1.co.uk
2012-04-20 13:07:07 msgid=234567 to=larry@vender3.org
Subsearch caveats
To prevent a subsearch from being too expensive, they are limited by a time and
event count:
• The default time limit for the subsearch to complete is 60 seconds. If the
subsearch is still running at that point, the subsearch is finalized, and only
the events located up to that point are added to the outer search.
• Likewise, the default event limit for the subsearch is 1,000. After this point,
any further events will be truncated.
 
Search WWH ::




Custom Search