Getting Data In

Can you help me with some weird search behavior with SEDCMD?

njandieri
Explorer

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

1 Solution

DavidHourani
Super Champion

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

View solution in original post

woodcock
Esteemed Legend

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
0 Karma

njandieri
Explorer

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

0 Karma

DavidHourani
Super Champion

cool please accept answer bellow then ❤️

0 Karma

johnvr
Path Finder

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.

0 Karma

DavidHourani
Super Champion

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

View solution in original post

njandieri
Explorer

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?

0 Karma
Take the 2021 Splunk Career Survey

Help us learn about how Splunk has
impacted your career by taking the 2021 Splunk Career Survey.

Earn $50 in Amazon cash!