- 03/28/05 12:24:08 (8 years ago)
- 1 edited
rf7f536b rebcb766 1 1 NSClient++ 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 compatible 3 3 but yet extendable performance service for windows. 4 4 5 6 This is an initial NSClient++ test release. 7 8 This version has many of the features from NSClient. 5 NSClient 9 6 The following commands (from check_nt) are supported. 10 7 * CLIENTVERSION … … 16 13 * PROCSTATE 17 14 15 16 17 18 18 19 Installation: 19 20 To install simply copy all files to directory on the server and run 20 the following command: "NSClient++ /install" to un install run: 21 the following command: "NSClient++ /install" to uninstall run: 21 22 "NSClient++ /uninstall". 22 23 … … 29 30 about - Show some info (version et.al.) 30 31 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. 33 33 34 34 The directory structure: 35 35 <install root> 36 36 - 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 38 41 <modules> 39 42 - Various NSClient++ modules available to this instance. 40 43 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. 44 A 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. 53 61 54 62 Settings: 55 The following things can be changed ion the NSC.ini file. 63 . 56 64 57 [generic] 58 password=secret-password 59 # The password to use. 65 About NSClient++ 66 URL: http://www.sf.net/projects/nscplus 60 67 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 68 Contact the author: 69 Michael Medin 70 EMail: michael <at> medin <dot> name 71 Address: (feel free to send a postcard if you find this useful :) 72 Michael Medin 73 Terapivaegen 6b 3tr 74 SE-141 55 HUDDINGE 75 SWEDEN
Note: See TracChangeset for help on using the changeset viewer.