solidfire log retention

[chinchillaking]

Hi All,

customer want to change log retention, but I cannot found any info, any advise?

[elementx]

Most modern storage systems will not allow you to set retention because they don't have unlimited amount of internal storage available to OS and secondly, the value of storing logs on the storage system over the long term is low.

If the storage system dies, how do you check the logs?

If management network fails and cluster can't  run, how do you check the logs to see what events were last seen by the cluster?

If someone obtains a cluster admin password and wipes cluster config, how do you find out what happened?

SolidFire logs should be forwarded to an outside syslog server where you can do one or more of the following:

- retain them identifitively (on syslog server), or

- forward to Splunk, Elasticsearch, OpenSearch or other location which can keep them identifively, or

- upload syslog-rotated SolidFire log files to S3 WORM buckets (directly from syslog when log files are rotated)

[elementx · Accepted solution]

Log forwarding KB:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/Element_Software/How_to_forward_syslog_messages_to_a_remote_host

Note that for reasons explained above, the VM running syslog shouldn't be hosted on SolidFire. If you want to have the logs even in the case SolidFire is destroyed, syslog server should be hosted elsewhere (stand-alone, or on other storage, or forward data to two syslog machines on different sites - see best practices and HA designs for syslog or other solution such as Splunk or Elasticsearch).

[chinchillaking]

Hello Elementx,

sorry forgot one more question, how long the Solidfire keep logs by default?

[elementx]

I don't know, and I can't find it in the KB. You could ask Support if you need the exact details.

I think there may be a combination of two or more maximums (e.g. max log size and max event age).

On a mostly idle test cluster I have my oldest Events in SF UI go back 34 days to Nov 16. The current number of events in the log is 4039.

So it appears they can go back at least 30 days, but maybe can get pruned if the amount of events hits some limit. 4039 isn't a lot, but those are just what's shown in the UI.

Once you start forwarding events to syslog, you will see there's a *LOT* of service logs; what's seen in the UI is probably ~0.001%. That's why, as logs get forwarded to syslog, you can use regular syslog flters to drop entries that you don't need. The same can be done later in Splunk or Elasticsearch, but it's better to drop them earlier than later.