[Xymon] Suggestion: allow compressed client messages

Jeremy Laidman jlaidman at rebel-it.com.au
Thu May 23 04:39:23 CEST 2013


Hiya

We have some servers that get a rapid turn-over of TCP connections, and
consequently the [netstat] section of the client report can be huge.  When
this happens, the ports and procs (because the process list comes after
[netstat]) reports are impacted.

I'm working on reducing the number of TIME_WAIT sockets, as well as
limiting client connections.  But it's not unreasonable for some hosts to
just operate this way.  But the 512kB limit on the client messages also
seems reasonable - I don't want to consume too many Xymon resources
(bandwidth, disk).

So I think it would be really neat to be able to send compressed [client]
messages to Xymon.  If the xymond_client process detected the gzip header,
it could automagically decompress on-the-fly.  A 500kB message would
typically shrink to around 50kB.  Either the whole message could be
compressed, or each [section] could contain optionally compressed data.

Some risks with this include:
1) extra CPU resources required on client and server, potentially leading
to delayed processing - but probably not significantly more than normal
2) a rogue process could send in a gzip bomb - this could be mitigated by
wrapping a timer around the call to inflate*() and limit execution time to
a few seconds.

Thinking more generally, it could allow specifying other filters such as
base64-encoding, authentication or encryption.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20130523/b4e508e0/attachment.html>


More information about the Xymon mailing list