Why are the individual records merging in single event in CSV monitoring?

[rajim]

I am facing a bizarre problem in csv file monitoring. I am monitoring a csv file from a server path. The records are being indexed. But sometimes, some records of the csv file is being merged into a single event. Attached is the configurations that I have used to on-board that data. Could someone please look into this and let me know how can I overcome this?

Below is the sample output that I'm getting now. The first line shows multiple records in a single event whereas the other two are individual records which are perfect.

[rajim · Accepted solution]

Thank you everybody for your comments. But I got the answer and it's working.

In my case, the monitored file is in a server where UF is installed. I am on-boarding the data using UF. So I had deployed all the configuration files in that server that is in UF. But the parsing doesn't happen at UF. It only happens at HF or Indexer. That's why in my case the props.conf and transforms.conf was not in any use.
What I needed to do is to create an app for HF with the props.conf and transforms.conf and deploy that app to HF, thru which the data are flowing to Indexer from UF server.
So I have changed my original TA and kept the inputs.conf file only in that TA and deployed that into UF server. Then I created another TA with the props.conf and transforms.conf file and deployed this TA to HF.
Now indexing happens properly.
So in short - UF TA ---> only inputs.conf
HF TA ----> props.conf and transforms.conf

[p_gurav]

Can you try adding in props.conf below parameters:

LINE_BREAKER = ([\r\n]+)

[rajim]

This is a default behaviour. So should I add that?

[somesoni2]

Yes please.

[rajim]

I have added this but it's still not working. 😞

[p_gurav]

Can you give sample events before indexing into splunk?

[Richfez]

Could you confirm there's actually the right characters at the end of each line?

In *nix, you should be able to do xxd <filename> | less

Look for the ".." between "lines" (it will no longer be at the end of lines so you'll have to hunt!) and figure out if it equates to 0d0a or only 0d or only 0a when it's on a line break that's problematic.