Xymon Mailing List Archive search

reducing size of /dev/shm/msg.<hostname> file

4 messages in this thread

list Sergey · Tue, 5 Mar 2013 17:05:16 +0400 ·
Hello.

Can I disable collecting some data in /dev/shm/msg.<hostname> ?
Kernel routing table for examle... 
That would be very useful on host with Quagga/BGP:

# ls -l /dev/shm/msg*
-rw-r--r-- 1 xymon xymon 27890381 Mar  5 17:01 /dev/shm/msg.XXX.txt

-- 
Regards,
Sergey
list Japheth Cleaver · Tue, 5 Mar 2013 13:22:54 -0000 (UTC) ·
quoted from Sergey
Hello.

Can I disable collecting some data in /dev/shm/msg.<hostname> ?
Kernel routing table for examle...
That would be very useful on host with Quagga/BGP:

# ls -l /dev/shm/msg*
-rw-r--r-- 1 xymon xymon 27890381 Mar  5 17:01 /dev/shm/msg.XXX.txt

--
Regards,
Sergey

Compression across the wire becomes possible in trunk, but in terms of
size of the actual message it becomes a bit of a trade-off between size
and what might or might not be useful later on for forensics/diagnosis.

(If there's one specific host that's got a pathological value in there,
you can hack xymonclient-${os}.sh manually to keep from gathering it,
without affecting anything that doesn't depend on that raw data.)

If it's the size of the actual file left on disk after the transmission is
completed... Well, it's kind of left on there for debugging purposes, but
strictly speaking it's not needed between runs. See the tail end of
xymonclient.sh for notes.


HTH,
-jc
list Sergey · Tue, 5 Mar 2013 18:28:44 +0400 ·
quoted from Japheth Cleaver
On Tuesday 05 March 2013, user-87556346d4af@xymon.invalid wrote:
(If there's one specific host that's got a pathological value in
there, you can hack xymonclient-${os}.sh manually to keep from
gathering it, without affecting anything that doesn't depend on
that raw data.) 
 
Thanks, it works I seems.
If it's the size of the actual file left on disk
Size of one file on client's disk is not important... But it is
collected in /var/lib/xymon/hostdata... Is this used for xymon
or is it for manual diagnosis later ?

And it all started with a log messages:

xymonclient.log:
2013-03-05 17:47:37 Whoops ! Failed to send message (write error)
2013-03-05 17:47:37 ->  Write error while sending message to Xymon daemon at 127.0.0.1:1984
2013-03-05 17:47:37 ->  Recipient '127.0.0.1', timeout 15
2013-03-05 17:47:37 ->  1st line: 'client <host>.linux linux'

xymond.log:
2013-03-05 17:47:37 Data flooding from 127.0.0.1 - 1st line client <host>.linux linux

:-)

BTW, ifconfig is obsolete in linux now, what about change it to
"ip -s link" and "ip addr" ?

And /sbin/ifconfig called twice in xymonclient-linux.sh:
echo "[ifconfig]"
/sbin/ifconfig

echo "[ifstat]"
/sbin/ifconfig

-- 
Regards,
Sergey
list Sergey · Sun, 31 Mar 2013 16:27:20 +0400 ·
quoted from Sergey
On Tuesday 05 of March 2013 13:22:54 user-87556346d4af@xymon.invalid wrote:
(If there's one specific host that's got a pathological value in there,
you can hack xymonclient-${os}.sh manually to keep from gathering it,
without affecting anything that doesn't depend on that raw data.)
What about include this patch ? It is not to change behavior by default
but it can enable to disable control of interfaces and routing table.

Text for environment config file:

# A host can contains a huge number of interfaces and
# they can be controled by another statistic system.
# Possible (case sensitive) values "NONE" or interface list
#IFACES="eth0 eth1"

# A host can contains a huge routing table (OSPF/BGP for example).
# So the ability to lock this statistics is needed.
#NEEDROUTES="NO"

-- 
Regards, Sergey