I am seeing many answers, but they seem conflicting.
sample of log file
TimeStamp : 10/24/2014 11:50:01 PM
FullName : Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35
AppDomainName : /LM/W3SVC/3/ROOT-1-130586652039568763
ThreadIdentity : joeblow
WindowsIdentity : xxxx\xxxx
Title:Enterprise Library Exception Handling
Application Domain: /LM/W3SVC/3/ROOT-1-130586652039568763
Process Id: 6108
Process Name: c:\windows\system32\inetsrv\w3wp.exe
Win32 Thread Id: 5336
Extended Properties: ActorsClientIP - x.x.x.x
ActorsCompany - mycompanyname
ActorsFirstName - Joe
ActorsLastName - Blow
ActorsUserName - jblow
ActorsUserEmail - email@example.com
ActorsBrowserVersion - IE,8.0
RequestURL - https://mysecure.site.net
so, for this specific example:
How do may ActorsUserEmail = firstname.lastname@example.org work
have several approaches for search time, but need index time
does the field have to be defined in fields.conf on search head or indexer or forwarder
if so what is the syntax (complete please)
seen props.conf for indexer with just sourcetype and name of transform e.g.
TRANSFORMS-set = extrace_actorsuseremail
and transform.conf for indexer
REGEX = ActorsUserEmail\s+-\s+(?P.+?)\s*\n
Format = ActorsUserEmail::$1
WRITEMETA = true
DEST_KEY = _meta
but this does not work.
so, to restate original question. extract and index name/value pair
name = ActorsUserEmail
value= email address to be extracted from log file that comes right after ActorsUserEmail -
Sure hope that was clearer than some of the answers I've seen
On the search head, you will need this in fields.conf:
And you DON'T want DEST_KEY = _meta in your transform.
That said. Why do you think this needs to be an indexed field? There are really only a few cases where it is advantageous:
1. The thing you are extracting is in a metadata field (source, sourcetype, host)
2. The thing you need to search on is not an indexed term already, for instance a portion of a string.
3. The term you are looking for is very common, and creating the indexed field will drastically reduce the number of matched items.
So, unless #3 is true, this indexed field isn't actually going to speed things up for you, and will really just make your index bigger.
I am also challenging you on the need to add an indexed field. If you care to explain: why do you think you need it and what benefits do you expect?
In any case, I would recommend reading this, specifically the "Caution:" section at the top of the page. If you still feel you have a requirement for index-time fields, the doc contains all details on how to go about it; including examples.
,I would also challenge the need for an index-time field here. But if you insist and have a good reason, this has all the caveats, warnings and detailed instructions on how to go about ignoring those warnings; along with examples.
Attitude check, please.
Of course you can specify fieldname=value in a search using fields extracted at search time. That's one of the biggest values of Splunk to NOT define schema (fields) at index time.
And if you feel the documentation is lacking, I encourage you to post a comment on the page to point that out.