Field Alias by sourcetype not working

[torowa]

Hi Splunkers.
I'm trying to troubleshoot an issue with field aliases based on a particular sourcetype.

1) Field alias was configured in SplunkWeb as the follows (modified for privacy reasons):

Name_Mode:Type_of_access:SECURED : FIELDALIAS-Mode_extract_for_web
(Name_Mode:Type_of_access:SECURED is the sourcetype.)

uri = uri_path.

2) If I run the following, it lists the alias definition correctly:
| rest /services/data/props/fieldaliases
| rename title as Name, value as "Field aliases", eai:acl.app as App, eai:acl.owner as Owner
| table Name "Field aliases" App Owner

3) When searching specifically for that sourcetype, the events are returned but without the field alias.
The sourcetype has multiple colons in the name.  I can't see that causing the alias to fail as there are other field aliases used against similarly-named sourcetypes (in other apps) that are working without issue.

It is running on a SH cluster.  Splunk is v8.02
Permissions for alias is "All apps" with read for Everyone.

"uri" field is an inline field extraction.
Search-time operation order puts inline field extraction (1st) ahead of field aliasing operations (4th). (https://docs.splunk.com/Documentation/Splunk/8.2.1/Knowledge/Searchtimeoperationssequence)

... so I don't see this being a Search-time operation issue.  Any ideas where else to check?

Apologies if the above is not clear due to the obfuscation.
Let me know if you need clarification.

Thanks,

[DavidHourani]

Hi @towara,

This kind of issue generally happens because of the sequence of search time operation shown here:

https://docs.splunk.com/Documentation/Splunk/8.2.1/Knowledge/Searchtimeoperationssequence#Search-tim...

The aliasing operation happens 4th, and therefore cannot be applied on calculated fields, lookups fields, eventtypes or tags. 

Could you please confirm that the field you are trying to alias (uri_path) created before the aliasing happens in the sequence ?

Cheers,

David

[torowa]

While I understand the importance of search time operations, I don't believe this to be the cause.

The field aliases were operating against in-line extracted fields.

eSearch-time operation order puts inline field extraction (1st) ahead of field aliasing operations (4th).

[jhanvidattani]

@torowa 

Can you try the below solution:

| rest /services/data/props/fieldaliases 
| rename title as Name, value as "Field aliases", eai:acl.app as App, eai:acl.owner as Owner, stanza as "Source Type"
| table Name "Field aliases" App Owner "Source Type"

I observed that even if we mention source type the fields are coming. Additionally, the pattern in the Name field is <stype>: FIELDALIAS-<class>

Can you try the above solution?

If it's still not working can you check whether the mentioned configurations in your props are working?

[torowa]

@jhanvidattani, formatting was due to a transcription error as had to redact content from the definition names.

This seems to have sorted itself out (by itself unfortunately) after a few days.
Perhaps this was related to a SH cluster member not having fully received the KO bundle.

When testing on different cluster members accessed directly, it works fine.
When trying on a particular cluster member directly the issue occurs again.

It has subsequently started working on the recalcitrant server.

[torowa]

Upon further digging, this seems to be related to when using the sourcetype in the definition.

If I set the definition up using a host name, the field alias works.
If it is set up using the sourcetype, the field alias doesn't get set.

If I copy the sourcetype from the definition and manually search on it, I get events of that sourcetype.  i.e. The sourcetype as used in the definition is correct.

Also, as the sourcetype is one of the default fields, I wouldn't expect a definition that uses a sourcetype to be affected by the sequence of search-time operations.

Any other suggestions?

Thanks.