DX Unified Infrastructure Management

  • 1.  Start Nimsoft Probes from command line

    Posted Feb 05, 2012 08:15 AM

    How to start Nimsoft probes from command line?

     

    Thanks.



  • 2.  Re: Start Nimsoft Probes from command line

    Posted Feb 05, 2012 05:50 PM

    go to the probe directory on the command line

     

    <nimsoft_root>/probes/<probe_group>/<probe_name>

     

    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.

     

    Regards,

    Robin



  • 3.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 06:06 AM
    Robin,

    Thanks for the info. Could you help to give an example to start a probe with the startup command? from the GUI edit there are several parameters and I'm not really sure if all of them are needed.


  • 4.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 11:26 AM

    Hi!

     

    Whoa...that really works, and is a supported way?

     

    cheers

    Matthias

     



  • 5.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 12:30 PM

    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.



  • 6.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 04:41 PM

    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.



  • 7.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 04:50 PM
    The reason this question comes in the first place is to have Nimsoft the capability of self monitoring. It means that we will use processes probe to monitor the availability of the other probes. In a huge environment where the robots are 4000+, this is the only way we can ensure that the probes are running as expected by using the processes probe to auto-start the probe process in case it was intentionally or accidentally stopoped.

    Of course we still have to monitor spooler and processes externally.

    So, just to recap, for instance, I would like to start a cdm probe using command line in Linux box. Will this just work:

    /path/to/cdm/binary/


  • 8.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 05:11 PM

    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.



  • 9.  Re: Start Nimsoft Probes from command line

    Posted Feb 06, 2012 05:18 PM

    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.