February 2017 - Xymon - Xymon mailman web

Graphing a disk-like check
by nightwatch＠tiscali.it 09 Feb '17

09 Feb '17

Hi all, I'm trying to configure rrd graph for a check of a particular nfs mount point on a linux client. I'm aware that "df" command defined in the xymonclient-linux.sh script excludes network disks and it's ok for me. I'm executing a simple "df -P /NFS01" and sending to xymon server as "vault" column name output: THU FEB 9 14:24:45 CET 2017 Filesystem 1024-blocks Used Available Capacity Mounted on nfs-server:/NFS01 13260711552 11019471040 2241240512 84% /nfs_01 configurations: # ================================ # in the graphs.cfg I've duplicated the [disk] definition [vault] FNPATTERN ^disk(.*).rrd TITLE Disk Utilization YAXIS % Full DEF:p at RRDIDX@=@RRDFN@:pct:AVERAGE LINE2:p at RRDIDX@#@COLOR@:@RRDPARAM@ -u 100 -l 0 GPRINT:p at RRDIDX@:LAST: \: %5.1lf (cur) GPRINT:p at RRDIDX@:MAX: \: %5.1lf (max) GPRINT:p at RRDIDX@:MIN: \: %5.1lf (min) GPRINT:p at RRDIDX@:AVERAGE: \: %5.1lf (avg)\n #========================== #in the xymonserver.cfg I've wrote: TEST2RRD=<standard stuff>,vault=ncv I Have to add this line? NCV_vault=????:GAUGE In the detail page there no graph, and the rrd file reports NaN... any suggestion is appreciated max Con Open 4 Giga a 9 euro/4 sett navighi veloce, chiami e invii SMS dal tuo smartphone verso tutti i fissi e mobili in Italia. Passa a Tiscali Mobile! http://casa.tiscali.it/mobile/

1 0

Automate Daily Report : CSV Output
by Brad.Radjoo＠mtn.com 07 Feb '17

07 Feb '17

G'Day, Is there a way to generate an availability report of the past 24 hours in csv format and set that to e-mail myself on a daily basis ? I notice that it uses the xymon-cgi/report.sh script Kind Regards, - - - - Bradley "This email is confidential. If you have received it in error, you are on notice of its status. Please notify us immediately by reply email and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person as to do so could be a breach of confidentiality. Thank you for your co-operation. " "The information contained in this message is intended solely for the individual to whom it is specifically and originally addressed. This message and its contents may contain confidential or privileged information from MTN Group. If you are not the intended recipient, you are hereby notified that any disclosure or distribution, is strictly prohibited. If you receive this email in error, please notify MTN Group immediately and delete it. MTN Group does not accept any liability or responsibility if action is taken in reliance on the contents of this information . Note that all personal emails are not authorized by MTN Group. "

2 4

findhost.sh search info/description?
by jon.dustin＠gmail.com 04 Feb '17

04 Feb '17

Greetings - I'm a longtime Xymon user (Hobbit and BB before that), and am finally able to start using Xymon in $currentJob. HUGE fan! This operation uses "app-specific" DNS CNAMEs for systems, which I have added as 'descriptions' in hosts.cfg. They show up properly when I hover over hostnames and when clicking the info button. What would REALLY be nice is to have findhost.sh be able to search this field in addition to hostnames. I looked through the archives for a bit of time and didn't find any discussion around this issue. Am I alone in this request? I can certainly dig into the source and see if I can add this functionality myself. Thanks for anything you can pass along.

1 0

drop a test without clearing its history?
by rlhamil2＠gmail.com 03 Feb '17

03 Feb '17

Can one drop the _current_ info for a test, without dropping its history? Sometimes a situation may arise that makes the current state invalid, and one might want to get rid of it; but the earlier history might still be useful. More broadly, can one remove specific history entries for a host/test?

1 0

Absolute free space value for DISK gone rogue?
by David.Mills＠hhsc.state.tx.us 03 Feb '17

03 Feb '17

All - I have a file system on a host which is alarming "red" even though the file system is brand new / empty. In the notes below, the mis-reporting filesystem is "/ora_data_estdmprd" The stanza in analysis.cfg that covers it is: HOST=pwdu008 # Stand-alone prod DB hosts: won't have shared FS's DISK /ora_bin 85 95 # 85%/95% = CRQ000000013038 DISK /ora_data 85 95 # 85%/95% = CRQ000000013038 DISK /ora_admin 85 95 # 85%/95% = CRQ000000013038 DISK /ora_temp 85 95 # 85%/95% = CRQ000000013038 DISK /ora_redoa 85 95 # 85%/95% = CRQ000000013038 DISK /ora_redob 85 95 # 85%/95% = CRQ000000013038 DISK /ora_arch 85 95 # 85%/95% = CRQ000000013038 DISK /ora_data_finprod1 85 95 # 85%/95% = CRQ000000013038 DISK /ora_finbin 85 95 # 85%/95% = CRQ000000013038 DISK %/ora_data_perpr 85 95 # 85%/95% = CRQ000000013038 DISK %/ora_ 262144000U 209715200U # I.e. Yellow: <= 256GB; Red <= 204.8GB The output from the "Disk" detail page for that host was: status pwdu008.disk yellow Tue Jan 31 14:06:20 CST 2017 - Filesystems NOT ok &red /ora_data_estdmprd (3045500329 units free) has reached the CRITICAL level (209715200 units) Filesystem kbytes used avail capacity Mounted on /dev/md/dsk/d1 16525754 7879972 8480525 49% / /dev/md/dsk/d4 20655025 2723628 17724847 14% /var /dev/md/dsk/d7 17197130 2708305 14316854 16% /export /dev/odm 0 0 0 0% /dev/odm sharefs 0 0 0 0% /etc/dfs/sharetab swap 147391344 1936 147389408 1% /etc/svc/volatile swap 147396208 6840 147389368 1% /tmp swap 147389344 0 147389344 0% /dev/vx/dmp swap 147384744 0 147384744 0% /dev/vx/rdmp /dev/vx/dsk/ORA_DATA/ora_data 249925632 5610862 229045230 3% /ora_data /dev/vx/dsk/ORA_ARCH/ora_arch 249958400 685078 233695152 1% /ora_arch /dev/vx/dsk/ORA_BIN/ora_bin 124930048 54292389 66222935 46% /ora_bin /dev/vx/dsk/ORA_ADMIN/ora_admin 62465024 202884 58405611 1% /ora_admin /dev/vx/dsk/ORA_REDOA/ora_redoa 124962816 833493 116371374 1% /ora_redoa /dev/vx/dsk/ORA_ARCH_ESTDMPRD/ora_arch_estdmprd 1749710848 966260000 777330408 56% /ora_arch_estdmprd /dev/vx/dsk/ORA_TEMP/ora_temp 999961600 521070 936975632 1% /ora_temp /dev/vx/dsk/ORA_REDOB/ora_redob 124962816 423857 116755408 1% /ora_redob /dev/vx/dsk/ORA_DATA_DMSTGPRD/ora_data_dmstgprd 4999072768 1751121 4728890415 1% /ora_data_dmstgprd /dev/vx/dsk/ORA_DATA_ESTDMPRD/oradata_estdmprd01 3249462272 929825 3045500329 1% /ora_data_estdmprd In the report above, we see that the "critical" threshold (in KB on Solaris) is 209,715,200 free space (about 256 GB), but the actual free space for that file system is 3,045,500,329 (around 3 TB). Something is clearly not right! Also, note the file system second-from-the bottom: /ora_data_dmstgprd. It has _even more_ free space and should be triggered by the same rule in analysis.cfg (DISK %/ora_ ...) yet it is not flagged as having a problem. As a stop-gap to keep the filesystem from alarming, I've had to change the "DISK" rule in analysis.cfg to percentages (85 95) which makes everything go green. Particulars: Xymon v. 4.3.3 running on Solaris 10 host. (Have also tried restarting the server without impact.) Any thoughts? Thanks! david ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ David Mills Systems Administrator Northrop Grumman (512) 595-1238 (mobile)

1 1

linux client disk warning levels
by kspringer＠innovateteam.com 02 Feb '17

02 Feb '17

An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20170130/6cf79fc2/attach…>

7 8