Is it only this one directory? or are there others that need to be identified/hunted down? The "for instance" is unhelpfully vague. ... View more

Thank you for the suggestions, I'll keep them in mind for when I get to the searching stage, but the part that's got me stopped is getting the data indexed in the first place. ... View more

I'm not aware of any way to force the lookup command to use more than one field on the input side but you could do two lookups to get 2 new columns: index=abc |lookup lookupfile col1 OUTPUTNEW col3 AS Match_col1 |lookup lookupfile col2 OUTPUTNEW col3 AS Match_col2 Then use the eval command to compare those 2 new columns: | eval combined=if(isnull(Match_col1,"null",Match_col2) This will create a new column called "combined" where if the value of Match_col1 is blank (ie: col1 did NOT produce an output of col3) it will display "null" otherwise (for those lookups where col1 DID match), it'll carry forward the value Match_col2, which is where looking up col2 also resulted in an output of col3 This is particular option has been tested on a dataset where both the "col1" and "col2" will always have at least one matching entry to "col3".... I'm not certain how it'll behave if you have entries where both "col1" and "col2" don't have any corresponding value on your table. I'd assume it will result in a null entry, but you should probably validate that rather than assume. ... View more

The comment made by somesoni2, recommending the bucket command worked like a charm but I can't accept it as the correct answer because it was posted as a comment. 😞 If it gets moved I'll accept it as a great answer. Thank you! ... View more

Recommend you read all the details here: http://docs.splunk.com/Documentation/Splunk/6.6.0/SearchReference/Lookup But in short, from your search: (index=abc| table col1 col3| lookup lookupfile col1 OUTPUTNEW col3) On the assumption that col3 doesn't already exist in your raw event data , you don't necessarily need to do the | table command before the lookup. There's nothing wrong with doing so, it just doesn't make a lot of sense if that column is just blank. If col3 does exist in your raw events, that's a whole other story and there's nothing at all wrong with the table command. But assuming you just want to lookup up col1 and output col3, you've got the basic lookup syntax. The tricks are: 1) Make sure that "lookupfile" matches the stanza in the transforms.conf file which specifies the location of the lookup table file. Depending on if you created a lookup definition or not (http://docs.splunk.com/Documentation/Splunk/6.6.0/Knowledge/Aboutlookupsandfieldactions) this value may require the .csv at the end or be a different name than your csv file. 2) Make sure that col1 and col3 from your events each match the exact field name (case-sensitive) of what you're referencing in the table. If there's any differences use AS clauses as specified from the doco under the "Syntax" section. So in the end I'd tend to do: index=abc| lookup lookupfile lookupcol1 AS eventcol1 OUTPUTNEW col3 | table lookupcol1 col3 OR index=abc | table eventcol1 | lookup lookupfile lookupcol1 AS eventcol1 OUTPUTNEW col3 Either should get you basically the same end results. To specifically answer your questions: 1) No, you can use any combinations of the fields from your event data to cross-reference to any number of columns from the lookup table. There's no need to use all, just what you need. You can also do multiple lookups to also get any other combination you might be interested in... lookup col2 output col4, or lookup col1 output col 3 and col2 2) You don't need to create col3 the lookup command itself creates it. Read the "Usage" section of the doco to explain when/why you'd prefer to use OUTPUT vs OUTPUTNEW either of those options. ... View more

I'm curious about overriding this behavior locally also... I have 27 dashboard panels I'm trying to build that are unique filterings of the same underlying search that contains 80,000+ results. I'd prefer to just run that underlying search once, then call the loadjob and add the filters. It seems to be working just fine when the filtered results are less than 10,000 but if/when it's over that it truncates. ... View more

Thank you for the quick reply, and for the warning! I'll be sure to take precautions to preserve the original and any changes that are made now! ... View more

Thanks for the suggestion. We're currently bumping our license limit so thank you for the warning about that particular complication. I'll also have to ponder this a bit because I want to keep the existing host/source information I just want to add the heavy forwarder as a troubleshooting/monitoring function. Not to mention the complications of managing separate props/transforms on each heavy forwarder.. I hadn't previously considered that added complexity. But you've given me a good place to start. Thank you! ... View more

It's a range of devices including routers, switches, firewall, various security and networking appliances so they're ending up in a half-dozen or so individual indexes. ... View more

Sorry! Didn't realize that my original post cut out some information regarding the file name. I've tried removing the -$time:%Y-%m-d$ as you recommend, leaving just $name$ I've also tried removing the entire default ($name$-$time:%Y-%m-%d$) and manually entering just a filename without the .csv at the end. And I've also tried removing the entire default, manually entering the filename with the .csv at the end. All of them end up with the default ($name$-$time:%Y-%m-%d$) as the results. ... View more