How to start Nimsoft probes from command line?
go to the probe directory on the command line
and run the startup command.
You can find the start up command for each probe if you select it in infrastructure manager and choose edit. For an executable it is normaly just the executable name, for java probes it varies from probe to probe.
Whoa...that really works, and is a supported way?
Not sure if it is supported but normaly works. It can be a handy way to troubleshoot probes that are dieing 'too many retries' often you will see a hint on the command line that does not make it to the log.
When working with Nimsoft support to troubleshoot a probe that is dying on startup, Nimsoft support has asked me to try the startup command from the command line to see what information is returned. (This is the scenario that Robin mentioned.) As long as your user account has permission to write to the files in the probe directory, I think the probe should function normally when run this way. This may not always be the case because the robot sets environment variables that some probes might use. I am fairly certain this would not be considered a supported way of running a probe, but it is a great troubleshooting technique for certain kinds of problems.
If a probe dies the controller will do its best to resurect it. If that can't get it going I doubt you would have much more luck with processes. If you do want to give down probes an extra kick you could catch the probe down events in the nas and use a nimbus request to the controller to de-active/re-activate the probe.
I would definitely recommend against using the processes probe to start other probes. The main job of the controller is to start and stop probes. If you start probes outside the controller, it loses some ability to control the probes.
As Robin said, the controller will restart probes automatically if they stop. The only situation in which that might not help is if the probe continuously crashes at startup. If that happens, the controller will generate an alarm. At that point manual intervention is probably required anyway.
If you do not want to fully trust the controller (which is understandable), you can still monitor the probes with the processes probe. And if there is a problem detected by the processes probe, manual intervention probably makes the most sense, in which case having it generate an alarm should be sufficient. But if this is not as rare of a situation as I think it should be, I agree with Robin that the best approach would be to kick the probes with requests to the controller rather than by starting the processes directly.
Retrieving data ...