When send-nsca send packats, message are truncated to a size ~ 525 chars.
We have the version of Nagios nagios-2.12-5.el5 that has been released with a correction on the size of the service_message struct (8376 bytes)
Is it possible to update the send_nsca and nsca functions in order to be able to exchange larger messages than the one authorized with default settings and to manage coherency with the nagios extended msg processing?
 EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;toto;squid;0;c'est cool | ysquid.version=2.6 cache.req_hit_ratio=1.2 cache.req_mem_hit_ratio=100.0 cache.req_disk_hit_ratio=0.0 cache.mean_object_size=70.91 squid.ds_size=177744 cache.store_entries=13115 cache.total_mem_objects=1904 cache.hot_objects=1903 cache.on_disk_objects=12996 squid.fd_percent=0.036 client_http.requests=1.369999 client_http.hits=0.016667 client_http.errors=0.1240836793 client_http.kbytes_in=0.800000 client_http.kbytes_out=98.586618 client_http.all_median_svc_time=0.070143 client_http.miss_median_
expected message to be sent:
localhost squid 0 c'est cool | ysquid.version=2.6 cache.req_hit_ratio=1.2 cache.req_mem_hit_ratio=100.0 cache.req_disk_hit_ratio=0.0 cache.mean_object_size=70.91 squid.ds_size=177744 cache.store_entries=13115 cache.total_mem_objects=1904 cache.hot_objects=1903 cache.on_disk_objects=12996 squid.fd_percent=0.036 client_http.requests=1.369999 client_http.hits=0.016667 client_http.errors=0.1240843298 client_http.kbytes_in=0.800000 client_http.kbytes_out=98.586618 client_http.all_median_svc_time=0.070143 client_http.miss_median_svc_time=0.070143 client_http.nm_median_svc_time=0.000000 client_http.nh_median_svc_time=0.000000 client_http.hit_median_svc_time=0.000000 server_http.requests=1.339999 server_http.errors=0.000000 server_http.kbytes_in=98.279952 server_http.kbytes_out=0.903333 squid.page_faults=0.000000 cache.swap_outs=1.299999 cache.swap_ins=0.026667 squid.abortedreq=0.000000 squid.cpu_percent=0.389274 cache.cachedir0.store_dir_max_size=1024000 cache.cachedir0.store_dir_size=921532 cache.cachedir0.max_obj_age=360 cache.max_obj_age=360 parent_servers.tomcat1
any update on this request please ?
thanks by advance
Created attachment 354153 [details]
Increase max plugin output size
This is related to https://bugzilla.redhat.com/show_bug.cgi?id=469198, where the max output size increase was backported from nagios cvs.
Attached patch increase the max size to 8192 in nsca, to match what's in nagios.
Wart, are you ok with the patch ?
This looks fine to me. Go ahead and commit it to CVS and rebuild.
nsca-2.7.2-7.el4 has been submitted as an update for Fedora EPEL 4.
nsca-2.7.2-7.el5 has been submitted as an update for Fedora EPEL 5.
nsca-2.7.2-7.el4 has been pushed to the Fedora EPEL 4 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update nsca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-4/FEDORA-EPEL-2009-0094
nsca-2.7.2-7.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update nsca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2009-0108
nsca-2.7.2-7.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.
nsca-2.7.2-7.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
I just had a rather interesting expedition through TFS, and it turns out send_nsca and nsca always work on a static packet whose size is determined at compile time. They send/receive this packet in full, even if most of it is garbage, and compute the CRC32 over the whole of this packet.
This boils down to
1. this patch causes a lot of network traffic for people who don't need it
and more importantly
2. if client and server were compiled with a different MAX_PLUGINOUTPUT_LENGTH, they won't be able to cooperate because the CRC32 will always be wrong
Blame upstream for (2), but IMVHO this variable cannot be changed. Not unilaterally at least, and definitely not without warning everyone in the changelog that their setup just so happened to become incompatible with every other distribution's nagios.
Can packets sent over the network, be limited to the "useful length" and CRC calculated on that length? ( MAX_PLUGINOUTPUT_LENGTH would be only the max exchangeable size) so that using the new version on the nagios side, would be transparent of older agents?
The use of metrics collection in the nagios & send_nsca environnent rapidly reach the max size of the send-nsca packets exchanged over the network. The side effect of the limitation is that there is no return code when packets are truncated when size exceeds 525 char.
I *think* it should be possible to always pad the packet (and probably it would be better to use nulls instead of garbage so we don't give away old memory) to the 525 bytes used on older versions, but allow a larger transmission. That way, if the packet is shorter it's still compatible and will be truncated as before; if it's longer it'll still be cut off.
Of course I haven't stared at the code long enough to figure out whether it's possible to determine packet length simply by reading until data is exhausted. If it's not, we'd need some kind of way to include a length field that doesn't break compatibility.
BTW, I just noticed that nagios.org's 3.x changelog says they did some changes to the MAX_PLUGINOUTPUT_LENGTH too. So either they have a better solution, or they don't care much about compatibility either. (The 2.x changelogs aren't online so I can't check when they started doing that.)
Upstream bug report : http://tracker.nagios.org/view.php?id=78
I think the best to do for now is to revert the patch and push a new version. Wart, Daniel, Thomas, what do you think ?
I agree. Let's remove the patch and rebuild. The original premise of this bug report, that the increased message size is compatible with the latest Nagios in epel5, was incorrect.
If Nagios for epel5 ever really changes to support the larger size, then we can come back to this patch.
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
is no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.