Below is my props.conf configuration:
[<some-sourcetype>] FIELDALIAS-0_abc = field1 as field2 FIELDALIAS-pqr = field2 as field3 FIELDALIAS-xyz = field2 as field4
- field1 and field2 are coming from REPORT.
- field1 and field2 are being extracted but not field3 and field4.
- I'm using Splunk 7.3.1 version.
- The FIELDALIAS works based on the lexicographic order of class names. So, 0 comes before p and x in lexicographical order it should correctly alias field3 and field4. This is what I'm expecting.
Can anyone tell me why it is not working? Is it expected? Is there any doc related to it?
I've some calculated fields (EVAL) based on field3 and field4, so I cannot extract field3 and field4 using EVAL as all EVAL executed in parallel. Is there any way I can solve the issue.
Knowledge Objects exist within user-defined, arbitrary, and unique instance-global namespaces (like AWS S3 buckets). One benefit of this is that for some KOs it allows Admins to control the order that they execute.
why add a new "answer" instead of adding to the one you already had?
Sometimes I don't realize that I have already answered.
I agree with that. Do we get any benefit if they execute in order rather than in parallel? Specifically in the case of FIELDALIAS, because we cannot use field created by any other FIELDALIAS just like EVAL but in case of EVAL we get benefit on another side where we'll improve in speed because EVAL executes in parallel.
In that case if FIELDALIAS executes in order what benefit we are receiving?
There's also the stacking that can happen - you may have private (or app-local)
FIELDALIAS statements that override the basic
FIELDALIAS where your observed search behavior is different from mine
That is a good question.
Transitive aliasing is not allowed. You have to do it like this:
FIELDALIAS-0_abc = field1 as field2 FIELDALIAS-pqr = field1 as field3 FIELDALIAS-xyz = field1 as field4
Or you can use a
calculated field like this (but this is a last resort as there are performance downsides to it):
FIELDALIAS-0_abc = field1 as field2 EVAL-field3 = coalesce(field3, field2) EVAL-field4 = coalesce(field4, field2)
I agree with the solution @woodcock.
Then come back here and click
Accept to close the question.
I still don't understand then why FIELDALIAS has
<class> name in it and why it executes in lexicographical order?
This is a good question.
you can not do a field alias based on other field aliases. Take a look into the docs, under restrictions: Field aliasing.
What might help in your case, is the newer "ASNEW" option for field aliases. See under the props.conf specficiation.
I got a solution to resolve my issue from @woodcock and @wmyersas.
Though I had a question where why this is not working which you have answered.
you can not do a field alias based on other field aliases.
But I don't understand then why FIELDALIAS has
class name in it and why it executes in lexicographical order?
@skalliger, @woodcock, @wmyersas - In case you can answer this question?
It executes in lexicographical order because it has to execute in some order - and lexicographical is used everywhere else.
Also, there are some cases wehre you might want to alias different source fields to a new alias (eg they only show up in some (but not all) events).
For example, I had source data which sometimes had a
username sometimes had a
user and sometimes had a
But I wanted them all to be CIM-compliant, so I aliased
user (of course,
user didn't need to be aliased).
I agree. So, what I understand is I can write below field alias.
FIELDALIAS-a = username as user FIELDALIAS-b = domainname as user
If "username" and "domainname" both have values then the final value of the "user" would be the same as "domainname" as it is overrides the value from "username" (as it has b which comes after a). If "domainname" is not available then the "user" value will be the same as "username".
Is this right?
That is exactly correct
If you're going to alias
field1 as field2 followed by
field2 as field3, etc, why not just alias
field1 as field2,
field1 as field3, etc?
I agree with your solution @wmyersas. Thanks!!