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:
- extra CPU resources required on client and server, potentially leading to delayed processing - but probably not significantly more than normal
- 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