Unable to delete indices

[jkatz]

Why do you say that host is sending bad times? From what I see they're all 2017.08.15?

I also checked the host and it is indeed synchonized with its configured NTP server and the time is accurate. Our hosts are joined to the domain. So if the time was off by more than 15 minutes, we'd be having Kerberos problems.

But even if this document had a bad time, how do I delete this index?

[cdienger]

Perhaps it's just another rsyslog config for the Rhttpproxy. If a message comes through with a timestamp of 2017-08-15 then an index will be created with that timestamp. The message is coming from something with this timestamp.

NLS can be configured to delete older indexes(based on the YYYY-MM-DD in the name) by setting the "Delete indexes older than" option under Admin > System Snapshots & Maintenance. This is enforced once a day so there could be older indexes on the system through the day but are cleaned up later. This will prevent the "old" indexes from growing too large.

A filter can also be put in place that drops data with old timestamps from ever getting to the db(resulting in an new "old" index). I found and tested the code at https://discuss.elastic.co/t/identify-l ... days/60388 with success:

ruby {
init => "require 'time'"
code => "if event['@timestamp'] < ( Time.now - 432000 )
event.cancel
end"
}

Place this in a filter under Configure > Global > Global Config > Filters.

[jkatz]

I looked through a bunch of the 'old' re-created indices and couldn't find a correlation between the hosts. I found some from some older hosts that need updating/patching and some new hosts that have been recently patched. So it looks like a VMware bug. I'll bring it up to them the next time I see our technical rep.

I put the filter in place and deleted all the older indices again. They have not been re-created. YAY!

Thanks for your help sorting this out!

Jonathan

[cdienger]

Thanks for the update!