Why does this transform (in pertained sourcetype from Splunk, not the TA) exists for this sourcetype?

[wryanthomas]

Hi there. Could someone please explain why this transform (in pertrained sourcetype from Splunk, not the TA) exists for this sourcetype? It has the consequence of (in many cases) creating divergent host values for a single host, and we're wondering why Splunk has chosen to "bake it in" to do this.

Thanks for any insight.

[PickleRick]

Well, ingesting /var/log/messages as a whole is not the best idea. By default many different  types of events land there and there is really no standard format. That's why the events can, and often will get "misparsed".

[warwicks1]

Not sure why it is there exactly but I understand the idea. I do not like the out of the box "syslog" sourcetype for many things, I prefer to instead create sourcetypes specific to the syslogs from the sources I am dealing with at each new client. Their are multiple syslog patterns used by various vendors and on top of that often I see them modified during collection/centalization.
There is a bunch of questionable stuff in the nix TA though, look at the eventtypes.conf for some terrible examples of eventtype searches. Ever looked at your logs and wondered why the os and unix and error tags show up on such a wide variety of things? Nix TA eventtypes out of the box is the answer.
Also not forcing more care to be take with the broad ingestion of directories like /var/log/ results in forcing Splunk to do a lot of sourcetype guessing and, in most places I have been, initially results in many incorrect sourcetypings.