If we can make a slight change to your premise, and never have rows in your lookup without prices, e.g... | inputlookup Price where Price=* | outputlookup Price Then one way to solve your puzzle would be... <base search> | lookup Price Description, Vintage OUTPUT Price | lookup Price Description OUTPUT Price as APrice Vintage as AVintage | eval APrice = "(".mvindex(mvzip(AVintage,APrice,") "),0), Price=coalesce(Price,APrice) | fields - APrice,AVintage What's happening here is that we perform both the exact price lookup and approximate price/vintage lookups, as you have found already. Next we use mvzip to combine the corresponding Vintage and Price pairs for the guide prices (Why it's important that every row in the lookup has a Price, as if a vintage did not, the corresponding lists would not necessarily line up correctly.)... we then use mvindex to select the first one, and an append to finish up the value correctly. Then using coalesce, we're able to pick the exact match price, for those rows with such, but if not present we pick the built guide price. A variation on this, you could set the maximum number of matches on your lookup to 1, then you only need to use string append to build the guide price, coalesce would then be the same. ... View more

Yes there is! If you put values outside any stanza they will apply to all unless overridden within a specific stanza. See the top of: https://docs.splunk.com/Documentation/Splunk/6.5.2/Admin/Indexesconf ``` GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. ``` ... View more

ChrisG is correct... you're probably interested in the Keep Specific events and Discard the rest: section of this doc: http://docs.splunk.com/Documentation/Splunk/6.5.2/Forwarding/Routeandfilterdatad#Keep_specific_events_and_discard_the_rest But it sounds like you're also interested in the mechanics of the indexing pipelines, which can be found as an overview: http://docs.splunk.com/Documentation/Splunk/6.5.2/Indexer/Howindexingworks but I really like the detailed diagram https://wiki.splunk.com/Community:HowIndexingWorks When data comes from the forwarder, it's first broken into individual lines (parsing pipeline, linebreaking processor)... then those lines are merged into events (Merging pipeline, aggregator processor)... then we apply regexes to the event (Typing pipeline, regex extraction processor). So if your regex matches a single part of your multi-line event, then you'll get all of the lines of the event. (because all lines are a whole event by that point). If you are not getting particular lines, then you'll need to adjust props settings to fix how Splunk is breaking your stream of data ultimately into events. Does that make sense? ... View more

I'm assuming this is for an audit of some sort of variety or another. Another way to attack the problem therefore might be to prove that a process to create and set such a complex password is in place, and has not been circumvented: If you developed a admin password generator app, similar to Skip's https://splunkbase.splunk.com/app/2722/ that through a scripted input, would generate and set a random password that would be guaranteed to meet your complexity requirements, and would record (as it is an input) that such a procedure was successfully performed for the admin user. You then add some form of file change monitoring for the splunk passwd file, and then you can demonstrate that 1) your automatic password setter is guaranteed to generate a password that meets your complexity requirements, 2) that the password setter was successfully ran at a particular time for a particular server, and 3) the password file has not been changed other than with the password setter (because lest we forget if you control the splunk system user you could in fact reset the admin password back to changeme). Other Splunk admins would of course be mapped from an external repository that would enforce such requirements independently of Splunk. If expiration time is part of your password requirements (instead of set something and forget), then you would want your password changing app to work with a password store, and then be able to demonstrate that the passwords in the store meet the requirements, and that the passwords have been updated on the boxes on at least the prescribed basis. (again auditing that the password file only changes with your app). Developing either might be a bit of an undertaking but depending on what you need to prove in terms of requirements could be worth it. As such data is in Splunk, you could even setup alerting when the regular password changing pieces fail. Depending on how you're installing Spunk and the exact requirement you're trying to prove compliance with, you could have your installation / configuration management scripts perform the generation of the complex password on a regular basis instead of a Splunk App. ... View more