Splunk Add-on for Microsoft Cloud Services: Why $SPLUNK_HOME/var/lib/modinputs directories are not reaping files generated by this TA?

[pkeller]

Running Splunk Add-on for Microsoft Cloud Services v 2.0.1.1

The directories underneath, var/lib/splunk/modinputs/ that are being written to by this Technology Add-on are not cleaning themselves up.

Does this get fixed in 2.1?

The performance of my heavy forwarder running this TA is very, very poor.

[AGLbwa]

Ok so to the other 20 folks following this question vainly hoping that something is going to happen, what are people doing to work around this? Is this a minor nuisance for most folks or actually a big deal for anyone? Any other gotchas with this aside from the logging verbosity?

[pkeller]

There's been no workaround by either Splunk or Microsoft ... so, I've just implemented a job to remove everything over 2 days old under the Azure related modinputs directories and run it every 4 hours.

[vhallan_splunk]

If you do see this issue please raise a support case and reference internal splunk bug number ADDON-12867 to get an update

[scheng_splunk]

There's feature enhancement request raised under ADDON-14309

[AGLbwa]

@vhallan_splunk is this for tracking purposes to determine whether or not this is worth fixing? Because spoiler alert, it is. When I was asking above about whether or not this was a major issue, I hadn't seen that due to the way it works, if you delete files, you reingest the blobs they corresponded to. If you don't delete files and you have people who just basically spray sh!t into blob storage, you end up bringing pretty much any filesystem to a grinding halt (NTFS dies early, but even Ext-4 doesn't like 4M+ files in a single directory!) Also, in the worst case, ingest starts looping even when you take the hit and don't delete the files.

[pkeller · Accepted solution]

According to support, this appears to be a known issue, although there is no information as to when a fix will be available nor any recommended best practices for manually maintaining the integrity of the instance running the TA.