topic Re: Occasional trailing white space in created field in Getting Data In

Occasional trailing white space in created field

yh — Mon, 24 Nov 2025 07:22:19 GMT

Hi,

I have this unusual problem where I am trying to modify the host name in my windows log (text file ingestion) in my heavy forwarder before it is forwarded to the indexer. The source for my windows data are text files with the following naming convention. i.e. Zone1_date.txt etc. Therefore, for my host field I am using the extracted zone and combining it with the host from the ComputerName field. The problem is that occassionally the created hostname becomes:

Zone1@computerA.mydomain.net
Zone1@computerA.mydomain.net[][][]

[][][] denotes white spaces that are additionally added from nowhere. It would be great if the traling spaces can be removed.

In [props.conf]

[XmlWinEventLog]
TRANSFORMS-winxmlhost_override = winxmlhost_override

In [transforms.conf]

[winxmlhost_override]
INGEST_EVAL = extracted_zone=replace(source, ".*(Zone\d{0,2}).*", "\1"), extracted_computername=replace(_raw, ".*<Computer>[\s\xa0]*([a-zA-Z0-9.\-_]+?)[\s\xa0]*<\/Computer>.*", "\1"), host=extracted_zone . "@" . extracted_computername

I have checked the raw files and I do not see any spaces in the <Computer></Computer> field so I am unsure where the spaces come from. The trailing spaces are seen in both extracted_computername and also the final host field but maybe in 1/30 events. Any advice on why it is happening and what better way should I use to append a dynamic pretext to my hostname?

Thanks!

Re: Occasional trailing white space in created field

livehybrid — Mon, 24 Nov 2025 10:21:21 GMT

Hi @yh

I cant really explain where the whitespace is coming from, but you could wrap a trip command around the replace to ensure any spaces/tabs are removed:

[winxmlhost_override] INGEST_EVAL = extracted_zone=replace(source, ".*(Zone\d{0,2}).*", "\1"), extracted_computername=trim(replace(_raw, ".*<Computer>[\s\xa0]*([a-zA-Z0-9.\-_]+?)[\s\xa0]*<\/Computer>.*", "\1")), host=extracted_zone . "@" . extracted_computername

🌟 Did this answer help you? If so, please consider:

Adding karma to show it was useful
Marking it as the solution if it resolved your issue
Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

Re: Occasional trailing white space in created field

ITWhisperer — Mon, 24 Nov 2025 11:34:40 GMT

Can you share the raw event(s) for which this is happening, preferably using the code block </> so that formatting information is not lost. Obviously, obfuscate any sensitive information but keep this to a minimum.

Re: Occasional trailing white space in created field

yh — Tue, 25 Nov 2025 01:48:05 GMT

I tried using trim in the ingest_eval but it still shows the mystery white spaces occasionally. I am wondering perhaps I should do a trim host on all incoming inputs to the sourcetype in the indexer too.

Re: Occasional trailing white space in created field

yh — Tue, 25 Nov 2025 02:49:54 GMT

I have analyzed the event that has these white spaces based on the full timestamp added and opened up the source text file with notepad++ but I don't see any different in the Computer field though.

The field looks like this:
<Computer>XXXX_A.yyyy.zzzz</Computer>

With no whitespace at all when I show all symbols in notepad++. So it's quite confusing between the heavy forwarder and indexer where did the two white space came from.

Re: Occasional trailing white space in created field

PickleRick — Tue, 25 Nov 2025 14:04:16 GMT

Are you sure there are no more transforms affecting that data? Maybe you have something defined for [default]? Or some other host- or source-based definition?

Re: Occasional trailing white space in created field

yh — Wed, 26 Nov 2025 07:33:47 GMT

I tried looking but I can't really find it. If it is a transforms affecting it, I am thinking shouldn't it have affected all events, and why it's only 1/30 events for example exhibiting the additional spaces at times. I am using the default windows TA, but I suppose my local props and transforms should have overwritten those.