In props.conf, I would like to create a field abc by saying:
abc = "xyz".
Is there any way to say this so that Splunk understands?
This worked for me:
[mysourcetype]
EVAL-abc = "xyz"
I've found this transfom in "unix" app that sets a fixed value field based on a specific regex:
[userdel]
REGEX = .*?((?:remove|delete) (?:user|group|account)) .(\w+).
FORMAT = action::delete name::$1 user::$2
where the value of field "action
" is set to "delete
". So, in a similar way also my example should work.
Marco
If you mean create a field at search time, it's simple , use an eval, or to make it automatic define a calculated field.
example :
<mysearch> | eval myfield="myvalue" | table _time myfield host source sourcetype _raw etc....
for calculated fields, look at this
http://docs.splunk.com/Documentation/Splunk/latest/Knowledge/definecalcfields
This answer abore modifies the _raw data adding unwanted stuff not originally present.
The right solution is in between:
the transforms should be just something like
transforms.conf:
[metrics]
REGEX = .
FORMAT = abc::xyz
that's it.
Marco
Those docs are inaccurate. As I mentioned, Splunk by default assumes that the value of the given field exists in the raw data. If you don't change this behavior, Splunk will effectively be searching for a value that doesn't exist. If you do change this behavior via fields.conf, those searches will be far slower.
Sorry, but why shouldn't be effective from a performance point of view? The REGEX is simple and matches immediately? And this solution was reported also on Splunk doc (http://docs.splunk.com/Documentation/Splunk/5.0.6/Admin/Transformsconf) with this example of search time extraction:
FORMAT = first::$1 second::$2 third::other-value
BUT, to be honest, I was also trying to make it work and I didn't, and had to use a lookup-based solution similar to your suggestion.
Marco
PS: BTW, why didn't it work?!
This is not an optimal solution from a performance or reliability perspective. Splunk assumes that extracted field values (such as xyz above) exists in the raw data. You can change this default behavior using fields.conf, but even then performance won't be very good.
Well, they may be correct but neither is appealing, so I have lost interest. I can't even remember why I asked in the first place.
Sorry.
But thanks anyway to the people who went to the trouble of answering.
(Does this constitute the feedback you want, or should I have put it somewhere else? It is difficult to be polite in text.)
If you would, please accept one of the below answers or update the question with feedback as to why neither of them worked. Thanks.
I would not recommend creating an index-time field. Rather I would recommend doing it at search-time and with a lookup.
local/props.conf:
[metrics]
LOOKUP-metrics = keywords sourcetype OUTPUT abc
local/transforms.conf:
[keywords]
filename = keywords.csv
lookups/keywords.csv:
sourcetype,abc
metrics,xyz
Despite the OPs lack of interest in this question I have found your answer very useful. This is exactly what I needed to do and having it happen at search time is ideal. Thanks!
Yes, props+transforms!
cat inputs.conf
[monitor:///Desktop/foobar.log]
disabled = false
followTail = 0
sourcetype=metrics
cat props.conf
[metrics]
TRANSFORMS-metrics=metrics
cat transforms.conf
[metrics]
DEST_KEY = _meta
REGEX = .
FORMAT =$0 abc::xyz
This will create field abc with value xyz.
Cheers!
.gz