Accelerating the cdot collector

After having received feedback from a client saying the cluster mode collector needs up to 45 seconds or more to collect 4500 snapshots, we looked into possibilities to accelerate the getter. In previous versions we relied on the default setting of the NetApp API which is set to 20 instances to be collected on the filer. Our first round of tests on a simulator showed that one could significantly reduce the runtime by increasing this value to 40 instead of 20. We expect that values up to 100 sh_ould_ be reasonable for usage on real hardware. For testing purposes we are releasing version test version 3.6.0_10 to all our clients (with access to test releases). This release includes the parameter ‑‑max_records for  (The performance data collector already supported this parameter for some time)

Things to consider during testing

Changing the default setting for max_records is not recommended for all objects. Currently only volume, vol_snapshot and disk support this parameter. In verbose mode (-v), you can see if ‑‑max_records  is being used or not. Please note that increasing the value of  ‑‑max_records does not always result in a shorter runtime. If set too high, CPU usage (and probably disk usage as well) increases on the filer and the monitoring server. **We recommend testing with values such as 50, 150, 500 and finally 1000. **Please use the command line for testing purposes and observe the total_duration of the getter. Of course, it is supposed to be as low as possible. If it continues to increase, the value for max_records should be reduced. We look forward to receiving your feedback. Feel free to send us an email at  or leave us a comment below the article. Existing clients that don’t have access to the testing release yet can send us a request at  free of charge.

‚–perf_data_prefix‘ deprecated
Version 3.6.0 available