[Nagios-users] Problem with check_nt MEMUSE
Hi there, I've got a Problem with the check_nt MEMUSE check. Don't know, if this is a known issue, maybe a patch already exists, or maybe I'm totally wrong here ;) Here's the problem: check_nt MEMUSE seems to check the perfmon instances \Memory\Committed Bytes and \Memory\Commit Limit, it then calculates the procentual proportion of committed bytes to commit limit, the output then refers to the procentual proportion of the physical ram. Problem is, that the commit limit is != physical ram! e.g. physical ram = 1GB, pagefile = 4GB -> Commit Limit is 1GB + 4GB = 5GB when committed bytes is 500MB (10%), the plugin reports that there are 100MB used RAM (10% from 1GB RAM). In the Task Manager the Value 500MB is displayed correctly. I'm using the check_nt from the nagiso-plugins 1.4.0alpha2 1.21 Any suggestions to solve this problem? Regards, Philipp _ Philipp Sand Sprach & Datenkommunikation SYCOR GmbH Heinrich-von-Stephan-Straße 1-5 D - 37073 Göttingen Telefon +49 (0) 551 - 490 - 0 Telefax +49 (0) 551 - 490 - 232468 [EMAIL PROTECTED] www.sycor.de sycor plastics - die Branchenloesung fuer die Kunststoffindustrie www.sycor-plastics.de sycor plastics - the solution for the plastic industry www.sycor-plastics.com Diese E-Mail ist vertraulich und kann darueber hinaus persoenliche Informationen beinhalten. Wenn Sie nicht der bestimmungsgemaesse Empfaenger sind, loeschen Sie bitte die E-Mail und deren Anhaenge sofort und benachrichtigen Sie uns darueber. Die Firma sycor willigt in keine Vertraege oder vertragliche Verpflichtungen ein oder uebermittelt rechtsverbindliche Angebote, die in Form von E-Mail versandt werden, sofern dies nicht ausdruecklich in schriftlicher Form zwischen den Parteien vereinbart wurde. This e-mail is confidential and may contain personal and/or privileged information. If you are not the intended recipient please delete this e-mail and all attachments immediately and inform us. The company sycor does not agree with contracts or contract obligations sent by e-mail, neither do we transmit legally binding offers by e-mail, unless this is not expressly agreed upon between the parties and documented in written form. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] bulk update thru send_nsca
In message <[EMAIL PROTECTED]>, "Joseph Hardeman" writes: >Does anyone know a way to post multiple checks thru a single send_nsca >post? Afraid not. I do everything over ssh and this is easy to do. >Currently every process/device that we check sends an individual >send_nsca post to our central server. As we have anywhere between 5 to 250 >devices at over 450 different locations this can be quite consuming at the >sites. Currently we are primarily doing pings on most of our devices to make >sure they are live, but want to do much more and to keep the amount of >nsca's on the central server down, I was wondering if it wouldn't be better >to have multiple posts sent thru a single connection, verses every post >establishing a connection. I used ssh and a small perl script for this. Setup ssh from the remote system to the master nagios system using public key ssh. On the remote system have each check send it's properly formatted *CHECK_RESULT output to a file. Then a small shell script that is run when you want to submit your checks. The small script cats the file into "ssh [EMAIL PROTECTED]". On the master nagios system create a small shell or perl script that: reads a line of input verifies it has the proper form for a PROCESS_HOST/SERVICE_CHECK_RESULT submits the result to the command queue Install the shell script/perl script as a forced command for the keys that you are using from the remote system. So loss of the key doesn't allow the user to do anything other than submit *CHECK_RESULTS. Specifically they can't run any programs or submit other passive nagios commands. Obviously this works best if you already use ssh for your remote infrastructure. I used it to have a Cyclades terminal servers report events back to the central nagios server, worked like a charm. You can also use 'tail -f local_input_file_or_pipe | autossh nagios_master_host' to keep a persistent ssh open if you don't have too many permanent connections that you need to set up. I used this setup with SEC to handle alerts coming from syslog monitoring and analysis. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
[Nagios-users] bulk update thru send_nsca
Greetings,Does anyone know a way to post multiple checks thru a single send_nsca post? Currently every process/device that we check sends an individual send_nsca post to our central server. As we have anywhere between 5 to 250 devices at over 450 different locations this can be quite consuming at the sites. Currently we are primarily doing pings on most of our devices to make sure they are live, but want to do much more and to keep the amount of nsca's on the central server down, I was wondering if it wouldn't be better to have multiple posts sent thru a single connection, verses every post establishing a connection. Thanks in advance on your thoughts and help.Joseph
[Nagios-users] Nagios not writing to nagios.log
A few days ago we started testing Nagios as a monitoring tool. At this moment we are recording a number of PureTest scripts to enable us to monitor advanced use cases when checking our web applications. The Nagios/PureTest integration works rather well. We have only one (in our perception) strange problem: When running the scripts as user NAGIOS we get all the necessary entries in the nagios.log file. When running the scripts from NAGIOS no entries are written to this file (but the status in the console is correct). Other http_checks do generate log-entries and the permissions seem OK. Your advice & comments are very much appreciated. With best regards, Fred Janssen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Nagios 'Out Of Memory' Problems
Hi,
i forgot to reply to the list. Lets share knowledge.
It is true, the problem can be in a newer perfparse version too. To
explain the problem:
If you compile nagios with --with-file-perfdata, then nagios opens at
start the perfdata file and writes there. If the file gets too large and
you try to delete it, then you won't see any change in disk usage. This
is because nagios never closes the file and even if you delete it,
nagios still has a reference to that file.
So if you choose to use perfparse to read that file then perfparse can
be configured to delete the file and restart nagios (send a restart
signal) to avoid filling the disk with the perfdata file.
This is very bad for performance if you run more than some 100 service
checks.
To avoid this, you should choose another method to get performance data
to perfparse. You can get very good performance with the method "pipe to
perfparse" and if you enable embedded perl in nagios. Here is a example
configuration (nagios 2.0):
In misccommands.cfg:
define command{
command_nameprocess-service-perfdata
command_line
/usr/local/nagios/bin/perfparse_nagios_pipe_command.pl
/usr/local/nagios/var/serviceperf.log "$TIMET$" "$HOSTNAME$" "$SERVICEDESC$"
"$SERVICEOUTPUT$" "$SERVICESTATE$" "$SERVICEPERFDATA$"
}
in nagios.cfg:
process_performance_data=1
service_perfdata_command=process-service-perfdata
in perfparse.cfg:
Service_Log ="|/usr/local/nagios/var/serviceperf.log"
Service_Log_Position_Mark_Path = "no"
The (embedded) perl script writes to a pipe and the perfparsed daemon
reads continously from that pipe. Make sure perfparsed is running!
One problem here is, that perfparsed should be started before the
service command generates the output file, because perfparsed wants to
create a pipe. Therefore a perfparsed startscript should delete/move a
stale outputfile. Send me a mail if you need a perfparsed startskript.
Flo
Stephen Barron schrieb:
We are using the current release v0.105.6. Could this be due to using
the Periodic Nagios Log Parse method of perfparse? This is what we
are using and we have had serious stability problems with nagios ever
since installing perfparse.
Thanks
Stephen Barron
On 3/25/06, Florian Gleixner <[EMAIL PROTECTED]> wrote:
Stephen Barron schrieb:
Hi
I had this problem also, and in our case it was NCSA that was filling
up the memory on the Nagios Central Server. We noticed the problem
increasingly after we installed perfparse, which attempts (poorly) to
stop and restart the nagios process.
This was a problem of older perfparse versions. If you use newer
versions then perfparse does not need to restart nagios.
Flo
--
Steve
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] monitoring cisco bri interface
On Sun, 26 Mar 2006, Brandino Andreas wrote:
> any idea???
>
> Friday, March 24, 2006, 4:18:34 PM, you wrote:
>
> > hi all!
> > Anyone has an idea how can i monitor the state of the interfaces???
> > I want to check the layer 2 of the bri interfaces
>
> > Also is possible to make them appear on the map?
> > Is a workaround for this?
>
> > Any idea will be appreciated
Don't tell me you did not look at the vast array of interfaces in your
SNMP section of the router. You can find just about any interface there.
Use snmpwalk to get the proper details.
I check my IPv6 tunnel with:
define service{
use generic-service
host_name anfalas,InternetV6
service_description InternetV6
max_check_attempts 3
normal_check_interval 1
retry_check_interval3s
contact_groups admins
check_command check_snmp_int!mycommunity!Tunnel0
}
define command{
command_namecheck_snmp_int
command_line$USER1$/check_snmp_int.pl -H $HOSTADDRESS$ -C $ARG1$ -n
$ARG2$
}
Using a new host with the address of your router has been described on the
list before.
Connecting the dots and such is left as an exercise to the reader. The
script is taken from one of the contrib sites.
Hugo.
--
I hate duplicates. Just reply to the relevant mailinglist.
[EMAIL PROTECTED] http://hvdkooij.xs4all.nl/
Don't meddle in the affairs of magicians,
for they are subtle and quick to anger.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] monitoring cisco bri interface
any idea??? Friday, March 24, 2006, 4:18:34 PM, you wrote: > hi all! > Anyone has an idea how can i monitor the state of the interfaces??? > I want to check the layer 2 of the bri interfaces > Also is possible to make them appear on the map? > Is a workaround for this? > Any idea will be appreciated > > Brandino Andreas > [EMAIL PROTECTED] > --- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > ___ > Nagios-users mailing list > Nagios-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagios-users > ::: Please include Nagios version, plugin version (-v) and OS when reporting > any issue. > ::: Messages without supporting info will risk being sent to /dev/null Brandino Andreas [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
