Hello,
I'm monitoring a single file on my Linux machine with Splunk, [monitor:///...]
in inputs.conf
.
As I need to replace some specific strings, I'm using SEDCMD
in props.conf
.
It looks to be working good — when I expand the event in the search, the source in the top has all the strings replaced. Show Source from the Event Actions displays all sources with the properly replaced strings.
However, fields are still populated with original strings!
If I initiate the search on both original or replacement strings, there are no results.
Of course I'm restarting Splunk and cleaning the index. I understand that SEDCMD does not work on things that already have been indexed.
Any hint, please!
NJ
Hi @njandieri,
There are two things you will need to verify.
1 - Are you using any field extractions at index time ?
2 - Are you sure your search is not including data that already had the fields prior to SEDCMD.
I think the best way to test your sed configuration is to make a test index with a test sourcetype and apply there. It will probably work and you can reuse that new sourcetype for your current configuration. It's usually better to avoid using the default "csv" sourcetype especially when you know you're going to customize it.
Cheers,
David
You can make SEDCMD
work by forwarding in your events in the traditional way, not using INDEXED_EXTRACTIONS=csv
making them search-time field extractions, not index-time (this will also save you a good bit of disk space). Just remove that from your props.conf and use something like this instead:
[YourSourcetypeHere]
DELIMS = ", "
FIELDS = firstFieldName, secondFieldName, ..., lastFieldName
Hello,
Thanks for your replies.
No, as I wrote, I'm not using any forwarder. Splunk is monitoring a file which is being copied from another machine.
No, as I wrote, I'm cleaning the index after making changes to SEDCMD to make sure there is no residual data.
Yes, the file is proceeded as 'csv' and field extraction is done at the index time. I believe this is the reason.
I disabled 'csv' proceeding and now everything is looking fine.
Looks like SEDCMD anonymizing just doesn't work with 'csv'
Regards,
NJ
cool please accept answer bellow then ❤️
In addition to @DavidHourani, I'd add - are you using any Heavy Forwarders? If so, does the SEDCMD configuration reside on them? You've stated that you know it won't work if the data's already indexed, but HF's don't need to index that data themselves, and they've already gone through the typing queue - where SECMD resides - before it reaches the indexers.
So if you DO have heavy forwarders, and this data crosses one of them, check to make sure that the SEDCMD configuration is being placed on those.
Hi @njandieri,
There are two things you will need to verify.
1 - Are you using any field extractions at index time ?
2 - Are you sure your search is not including data that already had the fields prior to SEDCMD.
I think the best way to test your sed configuration is to make a test index with a test sourcetype and apply there. It will probably work and you can reuse that new sourcetype for your current configuration. It's usually better to avoid using the default "csv" sourcetype especially when you know you're going to customize it.
Cheers,
David
Update:
https://answers.splunk.com/answers/597431/about-the-license-when-using-sedcmd.html
If so, what is the source type of the data - "csv" by any chance? If so, there is extra index time processing done for them (csv and json)
May be this is the reason. Any workaround?