Changeset ebcb766 in nscp for trunk/readme.txt


Ignore:
Timestamp:
03/28/05 12:24:08 (8 years ago)
Author:
Michael Medin <michael@…>
Children:
ce6eabf
Parents:
f705d34
Message:
  • Changed the Thread class a bit (mutex -> signal, and CreatThread? does not return the instance)
  • Moved settings "keys" fro NRPE to config.h
  • Changed build options (added Distribution) which builds a zip file under ./dist (requires 7z installed)
  • Minor tweaks to error/debug logging and small fixes "here and there"
File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/readme.txt

    rf7f536b rebcb766  
    11NSClient++ is a windows service that allows performance metrics to be gathered by Nagios  
    2 (and possibly other monitoring tools). It is an attempt to create a NSClient compatible  
     2(and possibly other monitoring tools). It is an attempt to create a NSClient and NRPE compatible  
    33but yet extendable performance service for windows. 
    44 
    5  
    6 This is an initial NSClient++ test release. 
    7  
    8 This version has many of the features from NSClient. 
     5NSClient 
    96The following commands (from check_nt) are supported. 
    107 * CLIENTVERSION 
    … …  
    1613 * PROCSTATE 
    1714 
     15NRPE 
     16All scripts "should" work (haven't actually tried myself though). 
     17Notice that encryption is still missing. 
     18 
    1819Installation: 
    1920To install simply copy all files to directory on the server and run  
    20 the following command: "NSClient++ /install" to uninstall run:  
     21the following command: "NSClient++ /install" to un-install run:  
    2122"NSClient++ /uninstall". 
    2223 
    … …  
    2930    about - Show some info (version et.al.) 
    3031    version - Show some info 
    31     test  - Run interactively (hint: enable ConsoleLogger for  
    32       this to make sense). Useful for debugging purposes. 
     32    test  - Run interactively. Useful for debugging purposes. 
    3333 
    3434The directory structure: 
    3535  <install root> 
    3636    - NSClient++.exe  - The executable (and service) 
    37     - NSC.ini   - The INI file (settings) 
     37    - NSC.ini     - The INI file (settings) 
     38    - changelog     - "Whats new" 
     39    - *.dll       - Various runtime DLLs 
     40    - readme.txt    - This file 
    3841    <modules> 
    3942      - Various NSClient++ modules available to this instance. 
    4043 
    41 The default modules: 
    42 CheckEventLog.dll 
    43   An eventlog checker (has yet to get a Unix client) 
    44 ConsoleLogger.dll 
    45   Log messages to console. (Usefull when run with -test) 
    46 FileLogger.dll 
    47   Log messages to file (Usefull when run as service) 
    48 NSClientCompat.dll 
    49   NSCLient compatibility module. Provides NSClient commands. 
    50 SysTray.dll 
    51   Shows a sytray when the service (exe) is started and allows you to  
    52   view the logfile and inject commands. 
     44A quick description of the included modules: 
     45* CheckDisk.dll 
     46  Dick check plug-in (not very complete as of yet). 
     47* CheckEventLog.dll 
     48  A very basic event log checker (HINT feedback wanted :) 
     49* FileLogger.dll 
     50  Log messages to file (Useful when reporting bugs, also please enable debug=1) 
     51* NRPEListener.dll 
     52  NRPE client code. Both listener and executer.  
     53  Might in the future rename this to NRPE or I will split the module into two. 
     54* NSClientCompat.dll 
     55  NSCLient compatibility module. Provides NSClient commands. 
     56  This module will be migrated in to various other modules in the "near" future. 
     57* NSClientListener.dll 
     58  The NSClient listener. 
     59* SysTray.dll 
     60  Shows a system tray when the service (exe) is started and allows you to view the log file and inject commands. 
    5361 
    5462Settings: 
    55 The following things can be changed ion the NSC.ini file. 
     63For details refer to NSC.ini. 
    5664 
    57 [generic] 
    58 password=secret-password 
    59 # The password to use. 
     65About NSClient++ 
     66URL: http://www.sf.net/projects/nscplus 
    6067 
    61 port=1234 
    62 # The port to bind to 
    63  
    64 [main] 
    65 bufferSize=4096 
    66 # Maximum buffer size for commands to return 
    67  
    68 [log] 
    69 file=nsclient.log 
    70 # The file to log to. 
    71  
    72 [nsclient compat] 
    73 version=modern 
    74 # The version string to return to the client. 
    75 # Modern returns the nsclient++ version string in a new syntax: 
    76 # <application> <version> <date> 
    77 # Notice this is not automated as of yet (as in date/version is not updated). 
    78  
    79 [systray] 
    80 defaultCommand= 
    81 # The default command to show in the inject command dialog. 
    82  
    83  
    84 Using the API: 
    85 The following functions are available for a module to "export": (think DLL) 
    86  
    87 NSLoadModule 
    88 - Loading of modules (done when the service starts) 
    89 NSGetModuleName 
    90 - Used to get a nice name for the module. 
    91 NSGetModuleVersion 
    92 - Not really used but... 
    93 NSHasCommandHandler 
    94 - Let the "core" know it can handle commands (from nagios) 
    95 NSHasMessageHandler 
    96 - Used to let the "core" know it wants to see all log/debug/error messages that are generated. 
    97 NSHandleMessage 
    98 - Used to digest a log/debug/error message. 
    99 NSHandleCommand 
    100 - Used to (possibly) digest a command. 
    101 When a command is "injected" then command is parsed and then sent along to all plugins (which accept commands) in order (they are listed in NSC.ini) and they are allowed to act on the command. If they do act on the command the "injection" is aborted and the resulting "return string" is returned to the "injecter" (normaly check_nt through a TCP stream. The ordering can thus be used to 1, optimize if things are slow (though I fail to see that unless someone makes some pretty f*cked up modules) and priority if one module overlaps the command of another (though then I would recommend someone to change the plugin command strings :) 
    102  
    103 NSUnloadModule 
    104 - Used to unload and terminate "stuff" nicely. (Generally this is when the service terminates) 
    105 NSModuleHelperInit 
    106 - Used to send along callbacks to the module (for making calls to the "core". (Ie. To allow the module to inject commands, get versions, names, and settings) 
    107  
    108 So the API is quite simple and straight forward (I hope :) 
    109  
    110 To make a simple call graph: 
    111  
    112 * Service starts: 
    113 * For each plugin 
    114         - call NSLoadModule 
    115         - call NSModuleHelperInit 
    116         - if NSHasCommandHandler 
    117                 . Send to "command plugin" stack 
    118         - if NSHasMessageHandler 
    119                 . Send to "message plugin" stack 
    120 * Wait for socket data 
    121         - Parse socket data 
    122         - For each "command plugin" 
    123                 . call NSHandleCommand 
    124                 . if Command handled abort 
    125  
    126 <termination signal sent to service> 
    127 * For each plugin 
    128         - NSUnloadModule 
    129 * Terminate service 
    130  
    131 <Log/debug/error message generated in a module> 
    132 * On incoming message: 
    133         - For each "message plugin" 
    134                 . call NSHandleMessage 
    135  
    136 There are a few more things to this but overall I have tried to keep things simple. 
    137  
    138 The extensions (to the API) I'm considering as of now (depending on the fallout) is: 
    139 * "SettingsHandler" to allow registry/INI/* settings modules. As the overhead of reg/ini settings system is quite low, perhaps this is overkill. But I don't know: thinking wildly there might be a reason for someone to want to load settings from a central server or whatever :) 
    140  
    141 * "SocketHandlers" though this will not be a specific handler I have considered to refactor out the code and allow the socket handler (that reads the TCP socket and parses the command) to be a plugin when I do SSL as I assume SSL will come with quite a high overhead and thus I might not need it all the time. 
    142  
    143 Also as mentioned this might be a good place to do a NRPE socket parser module to allow compatibility with NRPE. But this I assume is a bit in the future as I need to get "NSClient++" before I can get "NRPEClient++"... 
    144  
    145 As for PassiveChecks that could be implemented as a plugin today as any plugin can inject commands into the "core". Thus a plugin can be loaded, have a background thread that every X minutes calls "core".injectCommand(); and sends the result over to nagios. (This is how I assume that passive checks work) 
    146  
    147  
    148  
    149  
    150 // Michael Medin - michael <at> medin <dot> name - http://www.medin.name 
     68Contact the author: 
     69Michael Medin 
     70EMail: michael <at> medin <dot> name 
     71Address: (feel free to send a postcard if you find this useful :) 
     72Michael Medin 
     73Terapivaegen 6b 3tr 
     74SE-141 55 HUDDINGE 
     75SWEDEN 
Note: See TracChangeset for help on using the changeset viewer.