The files in the niscache directory contain information about the metrics, devices and interfaces currently monitored by probes running under this controller. Each probe generates a unique metric id/device ID for all metrics and devices that are monitored and puts this into the niscache folder. The algorithm used is partially based on robot name/id and partially based on the contents of the metrics themselves.
The more 'metrics' this server monitors, the greater the number of files will be in the niscache directory. The .ci files can be opened with wordpad, the text contained within gives an indication of its origin.
The discovery_server is the only probe to fetch these files. It should fetch the diff from the last time on every interval, but if it has to transfer a lot that might mean the robot is temporarily unresponsive, from the hubs point of view.
The niscache populates a file per metric, device, and interface currently monitored by probes running under the controller.
In version 5.41 of robot_update and higher we added a function to delete/ignore old files into the code:
"Added functionality to enable NIS cache maintenance. "
- Implemented '_nis_clean' callback which takes a 'min_age' parameter and removes matching cache entries.
In preceding versions, the niscache was not cleaned out. The controller will not do this automatically, but only when specifically asked through the 'nis_clean' callback which is called by the discovery_server on regular intervals.
and in robot_update v5.63 note that:
"NIS cache read fixed for memory leak problem with large NIS cache."
Note that you may see some log entries in the controller that indicate that the controller is skipping the files, as they're too old - this is checked when going through the nis_cache when requested by the discovery_server.
Dec 21 15:31:23:440  Controller: ReadCacheFile - file C:\Program Files (x86)\Nimsoft Infrastructure\niscache\MFFFB8401F77AE13DB4F10D9C559D5FD6.met too old, skipping
Note that without a discovery_server running, the controller will not handle the files after adding them to the nis_cache directory.
***A very large niscache directory can adversely impact the robot/connection or anytime information is retrieved from it, e.g., Robot visibility relies on the discovery_server retrieving the niscache folder information and inserting a record in the CM_COMPUTER_SYSTEM table.
Note that each robot should be assigned a unique device id - but there may be some in your environment that are not unique. The robot creates its device id when it starts up for the first time. Duplicate device IDs can occur when you use a VM image for the Robot, and that image has a niscache folder that has not been cleaned out as the basis for a new robot.
Note that you can delete the robot's niscache directory and upon restart the robot will automatically generate a device id and the niscache directory will begin to repopulate as well. Therefore, you might want to set up a scheduled job to clear out the niscache before it gets too large, e,g., keep it at less than a few thousand files.
niscache file contents:
- .robot_device_id - is the unique identifier for the robot.
- .dev file - represents a monitored device.
- .ci file - each device has a number of CIs associated; it's link between the device and the resources (interface, disk, memory, etc) monitored on the device.
- .met file - maps CIs and the actual data.
If the process of deleting so many files is hanging using Windows explorer, a quick and effective means of deleting these niscache files can be performed by opening a Windows cmd prompt and cd'ing to the niscache directory first, e.g., ...\Program Files (x86)\Nimsoft\niscache
Issue a dir command to see the files in the directory.
and then run a del /Q *.* command.