sshikov / jsendnsca

Automatically exported from code.google.com/p/jsendnsca
0 stars 0 forks source link

Increase message size to 4096 characters #37

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Would be good to send longer messages to nagios. Since nsca 2.9.1 it supports 
up to 4096 characters. This will brake the compatibility to older versions.
Please find attached a patch for 4096. Maybe it would also be good to have a 
compatibility switch for older versions of nsca?

Regards,
Matthias

Original issue reported on code.google.com by Matthia...@gmail.com on 22 Feb 2012 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for letting me know about the larger packet size

looking at change log 
http://nagios.svn.sourceforge.net/viewvc/nagios/nsca/trunk/Changelog?revision=18
76&view=markup

seems like it supports message size of 4000 chars. Is this correct or is it 
indeed 4096 chars?

Original comment by rajneeshpatel on 22 Feb 2012 at 11:56

GoogleCodeExporter commented 9 years ago
Just checked source code on 
http://nagios.svn.sourceforge.net/viewvc/nagios/nsca/trunk/include/common.h?revi
sion=1911&view=markup

Seems like it is 4096 as per #define MAX_PLUGINOUTPUT_LENGTH 4096

Going to have a think about how we can differentiate/switch to support larger 
plugin output

Original comment by rajneeshpatel on 22 Feb 2012 at 12:12

GoogleCodeExporter commented 9 years ago
I also checked with the source code of nsca. I would just force people to use 
the latest version of nsca. Version 2.7.2 is the first version that wouldn't 
support the long messages and this was released in 2007.
You could add useShortMessage(bool) to NagiosSettings and also 
withShortMessage(bool) in to SettingsBuilder. The PassiveCheckSender could then 
call either a message to set the flag for the PassiveCheckBytesBuilder or you 
change the constructor of PassiveCheckBytesBuilder to take NagiosSettings as 
parameter (the latter would be better I think...)

Original comment by Matthia...@gmail.com on 22 Feb 2012 at 10:24

GoogleCodeExporter commented 9 years ago
OK, initial thought is to create a LargeMessagePayload class as a type of 
MessagePayload

Then, push the max message size in number of chars into both of these so they 
encapsulate this information and remove the PLUGIN_OUTPUT_SIZE from the  
PassiveCheckBytesBuilder. The PassiveCheckBytesBuilder will then ask the 
message payload whats the max number of chars and use this.

So the behaviour will be as follows

- If you use the MessagePayload and have a message longer than 512 chars, it 
will be truncated to 512 chars as it is today
- If you use the LargeMessagePayload and have a message longer than 4096 chars, 
it will be truncated to 4096 chars

Hopefully, this way, people using pre 2.9.1 versions of NSCA dont need to 
change anything

For those who want to leverage the larger message size, all they need to do is 
use LargeMessagePayload

Any thoughts?

Original comment by rajneeshpatel on 24 Feb 2012 at 8:31

GoogleCodeExporter commented 9 years ago
Tried to implement as above but resulted in a lot of extra classes being 
created.

Therefore, instead, to switch on support for large messages, use 
MessagePayloadBuilder withSupportForLargeMessages() method as shown below

MessagePayload messagePayload = new MessagePayloadBuilder()
    .withSupportForLargeMessages()
    .withHostname("localhost")
    .withLevel(Level.CRITICAL)
    .withServiceName("test service")
    .withMessage("test message")
    .create();

Zips and tars for 2.1-RC1 available from downloads page if you want to give 
this a try and see if it works for you

Original comment by rajneeshpatel on 24 Feb 2012 at 2:31

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
unable to upload so will do later, source checked in though

Original comment by rajneeshpatel on 24 Feb 2012 at 2:36

GoogleCodeExporter commented 9 years ago
right, thought about this some more and think this does need to be on 
NagiosSettings as you suggested earlier.

You typically create settings once where with the switch on the 
MessagePayloadBuilder, you would need to do this for every point you construct 
messages

Putting on NagiosSettings and NagiosSettingsBuilder instead

Original comment by rajneeshpatel on 24 Feb 2012 at 2:57

GoogleCodeExporter commented 9 years ago
Source code committed, withLargeMessageSupportEnabled() added to 
NagiosSettingsBuilder and enableLargeMessageSupport() added to NagiosSettings

NagiosSettings nagiosSettings = new NagiosSettingsBuilder()
            .withLargeMessageSupportEnabled()
            .withNagiosHost(HOSTNAME)
            .withPassword(PASSWORD)
            .withEncryption(XOR)
            .create();

Will upload 2.1-RC1 to downloads this evening

Original comment by rajneeshpatel on 24 Feb 2012 at 4:29

GoogleCodeExporter commented 9 years ago
2.1 RC1 Zip and TGZ available in download area

Original comment by rajneeshpatel on 26 Feb 2012 at 8:18

GoogleCodeExporter commented 9 years ago
Will test it. Thank you. I would prefer a shorter method name though than 
withLargeMessageSupportEnabled. Something like withLongMessage. Another 
suggestion... What you think about having a boolean parameter for that? Like 
"withLongMessage(false)". This would result in a code which is backward 
compatible, and you could change the default over time to long messages.

Original comment by Matthia...@gmail.com on 26 Feb 2012 at 10:26