Is there a way to get the Event Log messages generated by NC_Net to go into it's own category. We are getting complaints from our DBAs that there are too many messages and they can not troubleshoot issues because the NC_Net client floods the Event Log with messages? I know i have seen other apps create their own category and have their messages go there instead.
Thanks,
DS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would say it is a good thing your DBA were complaining because one of three conditions exist.
1) you have verbose_logging turned on in the startup config. (this should not be the default of NC_NET)
2) you have some issue and errors from NC_NEt are being reported to the event log and these errors can and should be repaired. If this is the case, post seperate questions to fix the problems.
3) There is a real problem with NC_NET and once again each error should be reported that way the issue can be repaired. (this should be a rare occurance but I can only fix something if it is reported as a problem)
on a well configured NC_NEt install, when logging is turned off, there should be one NC_NET started event when NC_NEt was started. when verbose logging is turned on there is an event for each check that NC_NEt preforms via the Network port. Most other errors or warnings are things that can be repaired by adjusting the configuration. for example if you are asking NC_NEt for a check_disk of a drive that does not exist or you mistyped the name of a performance counter. these are repairable by fixing the configuration files. On rare occations, there may be issues that are not resolvable via configuration. in this case the issue should be reported to this forum and then workarounds could be posed or a fix can be implemented into future releases of NC_NET.
keep us informed as to the progress with this issue.
Good luck,
Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, Thanks for maintaining NC_Net. It's great. One issue I've seen relates to this example / solution.
"... for example if you are asking NC_NEt for a check_disk of a drive that does not exist ... these are repairable by fixing the configuration files ..."
We have some machines we monitor that 99% of the time the drive letter is valid, but periodically the drive is removed. For example, a USB backup drive is removed once a day and replaced with a different one for offsite backup. That's a case where the configuration really can't be changed to avoid the Event log entries (at least with version 3.05 which I'm still using ...
If I remember right, in this situation, you get a bunch of Event Log errors saying the WMI access for Drive X: failed or something like that ... We can't control the timing of these drive changes, because they're frequently done by the small business owner or employee at their convenience during the day.
It would be nice if there was a way to avoid these kind of errors ... I hate having the event log get a lot of errors caused by the monitoring we're doing ... our observing the machine ideally should NOT be the source of event log errors.
I don't know if it's possible to prevent this kind of event log error. Is there a way you can call WMI that says "don't put an error in event log if I fail?" ... It would be nice to have that option if there was.
Thanks again for NC_net.
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
NC_Net should only post one error for each request. (on rare occations it may post two, however if it posts an error, or clogs up the application log, let me know, so that it can be fixed)
It sounds like the best solution would be to use a non-default configuration.
for instance, if your MAX_CHECK_ATTEMPT is large, nagios will retry the check many times, based on the retry interval. This could lead to many errors being posted to the eventlog due to many retries of the request via Nagios.
IF the configuraiton was tweeked to better represent your needs, and reality of whats happening, for instance, if it gets a critical, can the retry interval be increased to large enough number such that you would only get a subseqent check after the swap is complete. does this interfere with any other objectives of monitoring that particular service. Another example is what of the disk being checked for, for instance, disk freespace does not usually change drasticly in a matter of minutes but on most cases it gradually increases over days. so should it be checked every 5 min, or once an hour or once a day?
just some thoughts on how Nagios configuration could be changed to better represent or help eliminate issues on the client sides. If the issue is as you described with the removable media, you should be able to truncate this to one event log entry a day via modifying the Nagios configuration.
A different solution to this problem would require a wrapper script used to call check_nc_net from nagios, were first you would check if the disk exists via a WMICAT, then you can check the result, or you can do a WMIENUM and parse ot the information that you need to return to the Nagios.
I think it is important for a log to be kept, I chose the Application Log, because it is a standard for many applications, and it assits in eliminating issues associated with creating ones own event log. I also experimented with using a text file for errors/debugging, but due several complexities of Log File Managment and limits, size ect... I decided that it was best to use the Application Log and thus, the limits associated with that.
On a side note, Version 4.x (the current version of NC_Net) has several fixes compared to version 3.xx I highly recomend upgrading (natureally test it first) THus far there have been very few issues with this new version. There are some Documentation on this under the Documentation Tab on Sourceforge(This site).
Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply and suggestions. I'm starting to test NC_Net 4 now. It looks like it has some nice new features.
I forgot to mention that most of the remote monitoring I was referring to was passive monitoring. Many of these sites are smaller businesses where we don't have a Nagios server doing distributed monitoring from "inside" their network. To reduce concerns about punching holes in their firewall etc., we do passive monitoring which just sends stuff to our Nagios server without requiring direct access into their network. Since they can look inside the passive.log file and see what we're sending to ourselves (and since I use external send_nsca and encrypt the data), the customers are comfortable with what we're doing from a security perspective.
We sometimes get quite a few NC_Net Event log entries because we typically have two checks for each drive: a Free Space check and a Used Space check, with the Free Space check reporting threshold set at 400 megabytes and the Used Space threshold @ 80% full since between them they give us good warning of disks getting full whether the disk / partition is large or "small". When the user disconnects a USB backup drive we get two event log entries every 5 minutes while they have the drive is unplugged. It's not filling up the event log too fast, but I dislike having the monitoring we're doing leaving "errors" behind during normal operations.
I could follow your suggestion of validating the drive letter before doing the check by writing a wrapper script (or new script of some kind) but I'd rather spend my time testing and implementing version 4 of NC_Net.
I want to test the new "EventLog_New" check on some of our servers. I had to drop event log monitoring on servers with large event logs, because even when I just asked for "Errors" within the last 10 minutes scanning the event log imposed too much of a CPU load on the servers with large event logs (10's of megabytes) or rapid activity.
Maybe the new version will avoid that problem, but I'm not expecting too much because I think the fundamental problem is in Microsoft's Event Log architecture (pre-Vista/Longhorn) and not in NC_Net. We had some servers that had 20%+ CPU load when NC_Net did EventLog monitoring (passively) and less than 1% CPU load when I stopped it! Which is not surprising when you start digging into how Microsoft implements event logs.
re: implementing NC_Net 4.1a:
Can I install 4.1a over the top of NC_Net 3.05 (i.e. without first using Add/Remove Programs to uninstall 3.05)? If that is "safe" that would save a LOT of work on the 50+ machines I have doing remote passive monitoring where we have to go and run batch files I've created to load their configurations and install software, etc. (i.e. we can't do it remotely, but have to go to each machine and do software setup manually). Most of the install / removal problems I've had with NC_Net have really been Dot-Net problems (and I've already had more practice than I want with the "manual NC_Net removal procedure" <g>).
Thanks again for the support and the great tool.
Steve
P.S. your "Uninstall.txt" file has:
"... CAREFUL when using Regedit. I take any responsibility for problems induced from accessing the registry..."
Probably should say something like "I do NOT accept any responsibility...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the note on the Uninstall.txt (the problem may have been induced when I recreateed it, I hate it when I accedently switch to overwrite mode)
The new event log check should work better, once again it uses the event log object of the Dot Net Framework but this time, instead of going though in the order given by the event log object, I search the event log from the last event and decrament through each event until the itteration time is met. so it is best to make sure there is a time incrament otherwise it will search the entire log.
Unfortunatly with Passive checks there is no good way to avoid the Event log error described earlier with the WMI call. NC_Net as stated earlier only has the Application log to report internal issues to, using alternative reporting mechanisms (like a text log file) can be implemented but would need sponsorship before I implement it.
As for installing on top of the old version, I do not think that would work, particularly since they use the same Service name. Also the Startup.cfg has been modified for version 4.x thus you need to go through and make sure to tweek the setups. for installation, I used mostly the default setup application with some minor modification. If you have the ability of creating your own custom Setup application, you can do that, basically NC_NEt requires the folders NC_Net that contains the Main executable, which needs to also be installed as a service since it should not be run as a standalone application.(It has never been tested or designed as a standalone.) It also needs the folowing subfolders created and all *.cfg files (subfolders: config,script, command) everything else is just extra stuff, and documentation.
Things should go reletively easy for the uninstall/install. the most reliable method for this is:
1) Stop nc_net: "net stop nc_net" 2) uninstall nc_net 3) install nc_net (to a different folder since the cfg files should be different) 4) copy in your custom config files 5) start nc_net: "net start nc_net" I found NC_Net almost never required a manual uninstall when these steps were followed. However, sometimes external issues/undetected Windows or Dot Net problems may induce the need of a manual uninstall thus why I put together the document on that. Manual uninstalls were more common on version 2.x of NC_Net as well as on Win 2K. Please send me an email nc_net@montitech.com if you are still having issues with needing the manual uninstall or if you have any comments as to the external things that caused the need for manual uninstalls.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a way to get the Event Log messages generated by NC_Net to go into it's own category. We are getting complaints from our DBAs that there are too many messages and they can not troubleshoot issues because the NC_Net client floods the Event Log with messages? I know i have seen other apps create their own category and have their messages go there instead.
Thanks,
DS
I would say it is a good thing your DBA were complaining because one of three conditions exist.
1) you have verbose_logging turned on in the startup config. (this should not be the default of NC_NET)
2) you have some issue and errors from NC_NEt are being reported to the event log and these errors can and should be repaired. If this is the case, post seperate questions to fix the problems.
3) There is a real problem with NC_NET and once again each error should be reported that way the issue can be repaired. (this should be a rare occurance but I can only fix something if it is reported as a problem)
on a well configured NC_NEt install, when logging is turned off, there should be one NC_NET started event when NC_NEt was started. when verbose logging is turned on there is an event for each check that NC_NEt preforms via the Network port. Most other errors or warnings are things that can be repaired by adjusting the configuration. for example if you are asking NC_NEt for a check_disk of a drive that does not exist or you mistyped the name of a performance counter. these are repairable by fixing the configuration files. On rare occations, there may be issues that are not resolvable via configuration. in this case the issue should be reported to this forum and then workarounds could be posed or a fix can be implemented into future releases of NC_NET.
keep us informed as to the progress with this issue.
Good luck,
Tony
First, Thanks for maintaining NC_Net. It's great. One issue I've seen relates to this example / solution.
"... for example if you are asking NC_NEt for a check_disk of a drive that does not exist ... these are repairable by fixing the configuration files ..."
We have some machines we monitor that 99% of the time the drive letter is valid, but periodically the drive is removed. For example, a USB backup drive is removed once a day and replaced with a different one for offsite backup. That's a case where the configuration really can't be changed to avoid the Event log entries (at least with version 3.05 which I'm still using ...
If I remember right, in this situation, you get a bunch of Event Log errors saying the WMI access for Drive X: failed or something like that ... We can't control the timing of these drive changes, because they're frequently done by the small business owner or employee at their convenience during the day.
It would be nice if there was a way to avoid these kind of errors ... I hate having the event log get a lot of errors caused by the monitoring we're doing ... our observing the machine ideally should NOT be the source of event log errors.
I don't know if it's possible to prevent this kind of event log error. Is there a way you can call WMI that says "don't put an error in event log if I fail?" ... It would be nice to have that option if there was.
Thanks again for NC_net.
Steve
NC_Net should only post one error for each request. (on rare occations it may post two, however if it posts an error, or clogs up the application log, let me know, so that it can be fixed)
It sounds like the best solution would be to use a non-default configuration.
for instance, if your MAX_CHECK_ATTEMPT is large, nagios will retry the check many times, based on the retry interval. This could lead to many errors being posted to the eventlog due to many retries of the request via Nagios.
IF the configuraiton was tweeked to better represent your needs, and reality of whats happening, for instance, if it gets a critical, can the retry interval be increased to large enough number such that you would only get a subseqent check after the swap is complete. does this interfere with any other objectives of monitoring that particular service. Another example is what of the disk being checked for, for instance, disk freespace does not usually change drasticly in a matter of minutes but on most cases it gradually increases over days. so should it be checked every 5 min, or once an hour or once a day?
just some thoughts on how Nagios configuration could be changed to better represent or help eliminate issues on the client sides. If the issue is as you described with the removable media, you should be able to truncate this to one event log entry a day via modifying the Nagios configuration.
A different solution to this problem would require a wrapper script used to call check_nc_net from nagios, were first you would check if the disk exists via a WMICAT, then you can check the result, or you can do a WMIENUM and parse ot the information that you need to return to the Nagios.
I think it is important for a log to be kept, I chose the Application Log, because it is a standard for many applications, and it assits in eliminating issues associated with creating ones own event log. I also experimented with using a text file for errors/debugging, but due several complexities of Log File Managment and limits, size ect... I decided that it was best to use the Application Log and thus, the limits associated with that.
On a side note, Version 4.x (the current version of NC_Net) has several fixes compared to version 3.xx I highly recomend upgrading (natureally test it first) THus far there have been very few issues with this new version. There are some Documentation on this under the Documentation Tab on Sourceforge(This site).
Tony
Thanks for the reply and suggestions. I'm starting to test NC_Net 4 now. It looks like it has some nice new features.
I forgot to mention that most of the remote monitoring I was referring to was passive monitoring. Many of these sites are smaller businesses where we don't have a Nagios server doing distributed monitoring from "inside" their network. To reduce concerns about punching holes in their firewall etc., we do passive monitoring which just sends stuff to our Nagios server without requiring direct access into their network. Since they can look inside the passive.log file and see what we're sending to ourselves (and since I use external send_nsca and encrypt the data), the customers are comfortable with what we're doing from a security perspective.
We sometimes get quite a few NC_Net Event log entries because we typically have two checks for each drive: a Free Space check and a Used Space check, with the Free Space check reporting threshold set at 400 megabytes and the Used Space threshold @ 80% full since between them they give us good warning of disks getting full whether the disk / partition is large or "small". When the user disconnects a USB backup drive we get two event log entries every 5 minutes while they have the drive is unplugged. It's not filling up the event log too fast, but I dislike having the monitoring we're doing leaving "errors" behind during normal operations.
I could follow your suggestion of validating the drive letter before doing the check by writing a wrapper script (or new script of some kind) but I'd rather spend my time testing and implementing version 4 of NC_Net.
I want to test the new "EventLog_New" check on some of our servers. I had to drop event log monitoring on servers with large event logs, because even when I just asked for "Errors" within the last 10 minutes scanning the event log imposed too much of a CPU load on the servers with large event logs (10's of megabytes) or rapid activity.
Maybe the new version will avoid that problem, but I'm not expecting too much because I think the fundamental problem is in Microsoft's Event Log architecture (pre-Vista/Longhorn) and not in NC_Net. We had some servers that had 20%+ CPU load when NC_Net did EventLog monitoring (passively) and less than 1% CPU load when I stopped it! Which is not surprising when you start digging into how Microsoft implements event logs.
re: implementing NC_Net 4.1a:
Can I install 4.1a over the top of NC_Net 3.05 (i.e. without first using Add/Remove Programs to uninstall 3.05)? If that is "safe" that would save a LOT of work on the 50+ machines I have doing remote passive monitoring where we have to go and run batch files I've created to load their configurations and install software, etc. (i.e. we can't do it remotely, but have to go to each machine and do software setup manually). Most of the install / removal problems I've had with NC_Net have really been Dot-Net problems (and I've already had more practice than I want with the "manual NC_Net removal procedure" <g>).
Thanks again for the support and the great tool.
Steve
P.S. your "Uninstall.txt" file has:
"... CAREFUL when using Regedit. I take any responsibility for problems induced from accessing the registry..."
Probably should say something like "I do NOT accept any responsibility...
Thanks for the note on the Uninstall.txt (the problem may have been induced when I recreateed it, I hate it when I accedently switch to overwrite mode)
The new event log check should work better, once again it uses the event log object of the Dot Net Framework but this time, instead of going though in the order given by the event log object, I search the event log from the last event and decrament through each event until the itteration time is met. so it is best to make sure there is a time incrament otherwise it will search the entire log.
Unfortunatly with Passive checks there is no good way to avoid the Event log error described earlier with the WMI call. NC_Net as stated earlier only has the Application log to report internal issues to, using alternative reporting mechanisms (like a text log file) can be implemented but would need sponsorship before I implement it.
As for installing on top of the old version, I do not think that would work, particularly since they use the same Service name. Also the Startup.cfg has been modified for version 4.x thus you need to go through and make sure to tweek the setups. for installation, I used mostly the default setup application with some minor modification. If you have the ability of creating your own custom Setup application, you can do that, basically NC_NEt requires the folders NC_Net that contains the Main executable, which needs to also be installed as a service since it should not be run as a standalone application.(It has never been tested or designed as a standalone.) It also needs the folowing subfolders created and all *.cfg files (subfolders: config,script, command) everything else is just extra stuff, and documentation.
Things should go reletively easy for the uninstall/install. the most reliable method for this is:
1) Stop nc_net: "net stop nc_net" 2) uninstall nc_net 3) install nc_net (to a different folder since the cfg files should be different) 4) copy in your custom config files 5) start nc_net: "net start nc_net" I found NC_Net almost never required a manual uninstall when these steps were followed. However, sometimes external issues/undetected Windows or Dot Net problems may induce the need of a manual uninstall thus why I put together the document on that. Manual uninstalls were more common on version 2.x of NC_Net as well as on Win 2K. Please send me an email nc_net@montitech.com if you are still having issues with needing the manual uninstall or if you have any comments as to the external things that caused the need for manual uninstalls.