Archive
Highlighted

Splunk 7.2.0 - Field Aliases incorrect behavior

Path Finder

Hi,
I checked my app on version 7.2.0 and I found incorrect behavior.
I exported my log file both to Splunk Enterprise 7.1.2 and 7.2.0.
In version 7.1.2 everything works as expected but in 7.2.0 I noticed that for some reason (which I really have no idea) one field inside the log ("action") is missing from extracted fields.
The method for extracting fields is regex based on key-value pairs.

The mapping was not changed at all and the app is exactly the same.
When I add another field aliases from the missing field into new filed ("action_test"), I can see the new field in the extracted fields on search view but not the original field.

Is anyone have any idea about it?

Thank you

Highlighted

Re: Splunk 7.2.0 - Field Aliases incorrect behavior

Splunk Employee
Splunk Employee

FIELDALIAS behavior change in 7.2:
FIELDALIAS for a specific field overwrites the field value, regardless of whether it is NULL or not. In earlier versions, FIELDALIAS did NOT overwrite the value in case of NULL.

Solution to this is to use COALESCE:

FIELDALIAS-scomputername = scomputername as host
should be something like
EVAL-host=coalesce(s_computername, host)

Highlighted

Re: Splunk 7.2.0 - Field Aliases incorrect behavior

Communicator

This is not the same, and can cause other problems "down stream". If for example you use that alias field in a EVAL you can not do that anymore.
The below (super simplified) example will not work anymore:

raw data1: "2018-12-06 15:54:00 AccountName=arnold sid=123 message=bla"
_raw data2: "2018-12-06 15:54:00 user=arnold sid=123 message=bla"

FIELDALIAS-user = user AS Account_Name
EVAL-userid = case(isnotnull(user),user, isnotnull(sid),sid)

in data1 you will miss the AccountName field even though it is in the data, this cannot be solved with evals in this manner:
EVAL-user = coalesce(Account
Name, user)
EVAL-userid = case(isnotnull(user),user, isnotnull(sid),sid)

Because according to the props.conf spec file:
* When multiple EVAL-* statements are specified, they behave as if they are run in parallel, rather than in any particular sequence.
* For example say you have two statements: EVAL-x = y*2 and EVAL-y=100. In this case, "x" will be assigned the original value of "y * 2," not the value of "y" after it is set to 100.

So in my opinion this is a major breaking change in the way 7.2.x works, and there is no mentioning of it in any doc (spec file/release notes/known issues/.....)

0 Karma
Highlighted

Re: Splunk 7.2.0 - Field Aliases incorrect behavior

Splunk Employee
Splunk Employee

Do you mean to say to use the coalesce in place of the fieldalias definition?

0 Karma
Highlighted

Re: Splunk 7.2.0 - Field Aliases incorrect behavior

Explorer

Found a similar problem in the SplunkTAmicrosoft-iis app.
In the default props.conf they do this:

FIELDALIAS-s_computername = s_computername as host

If s_computername is not found in the event, I no longer have a host field in my event.

This behavior popped up after the upgrade from 6.5 to 7.2.
Disabling this alias does the trick for me because all events come from a forwarder on the server itself, so I did an overwrite of the alias in the local folder like this:

FIELDALIAS-s_computername =
Highlighted

Re: Splunk 7.2.0 - Field Aliases incorrect behavior

Path Finder

Thanks for this - We have just found the same issue. Oh joy!

0 Karma
Highlighted

Re: Splunk 7.2.0 - Field Aliases incorrect behavior

Engager

Hi there, we had the same issue ever since we jumped into 7.2.3 from 7.0.3. For an example on Proxy TA props.conf we had aliases configured such as below.

FIELDALIAS-httpreferrer = csReferer as httpreferrer
FIELDALIAS-user
agent = csUserAgent as httpuseragent

But on transforms.conf had the field alias instead of the actual field name - something like below.

REGEX = (?\d{4}-\d{2}-\d{2})\s+(?[^\s]+) ... (?-|\S+)\ ... (?\S+) ...

By changing the RegEx to actual field name was fixed this issue and Splunk support will update their release notes under SPL-166565 stating that the field extraction is more restrictive on 7.2.3.

0 Karma