The best place to look might be in the TailingProcessor's own status endpoint. There you can see which status each monitor input currently has. Read more about it here: http://blogs.splunk.com/2011/01/02/did-i-miss-christmas-2/ ... View more

Did you look into using "unarchive_cmd" for this? It sounds like it could solve your situation, even though you're not strictly "unarchiving" anything, but the principle should still be the same - Splunk detects a change, invokes the script, then ingests the data that the script outputs. http://docs.splunk.com/Documentation/Splunk/latest/admin/Propsconf unarchive_cmd = <string> * Only called if invalid_cause is set to "archive". * This field is only valid on [source::<source>] stanzas. * <string> specifies the shell command to run to extract an archived source. * Must be a shell command that takes input on stdin and produces output on stdout. * Use _auto for Splunk's automatic handling of archive files (tar, tar.gz, tgz, tbz, tbz2, zip) * Defaults to empty. ... View more

Automatic upvote for question regarding multi-tenant deployments... 🙂 We're in a pretty similar situation as yours in that we have totally different "customers" with completely separate environments, probably even more so than in your case, so even IP addresses, hostnames, critical assets, privileged users etc could theoretically have the same name at two different customers but still be completely different things. Yet we run most things from central search heads. Unfortunately I don't have a "silver bullet" for you in how to deal with this - I can only verify that multi-tenancy with Splunk IS a pain and the more you look at it the more it seems like doing multi-tenancy is really bending how you're supposed to use Splunk. In the case of apps that explicitly use a certain index - yes, you will have to rewrite the app to take that away, and instead set the app to not care about the index at all, using each user or role's index access to define which data will be visible to which user. For users with access to several customers' data (like your own admin user) you'd have to rewrite your app to include something like dropdowns for choosing the correct index. With more and more apps making use of Splunk's high performance datastore via tsidx files this becomes tricky as well, as these have separate permission models - I'm actually unsure if Splunk is enable to enforce access to these at all right now. It gets hairier if you want to run environment-dependent lookups too, but I don't know if you're trying to do this right now. In short, this becomes a problem if you want to use the same lookup for different environments and have different environments return different data. Sorry for not giving you better news... ... View more

Your rex doesn't do anything because you're not telling it to do anything. When you do rex field=move1 "(?<mytest>)" you're not including anything to capture in your matching group, and so nothing will be captured either. The simplest form to try out would be a matching group with .+ ("read all characters from input", more or less), so in your case you would do: ... | rex field=move1 "(?<mytest>.+)" ... View more

No. If you're after getting unique id's for events, you could have a look at the _cd field which contains a bucket ID and an address within that bucket. A combination of index and _cd will be unique. ... View more