[ZBXNEXT-935] zabbix_sender output/return readability Created: 2010 Jan 26 Updated: 2014 Oct 30 Resolved: 2013 Nov 19 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | 2.1.7 |
Type: | Change Request | Priority: | Trivial |
Reporter: | svenw | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 5 |
Labels: | exitcodes, patch, sender | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | zabbix-1.8.2-zabbix_sender_exitvalue.patch | ||||
Issue Links: |
|
Description |
zabbix_sender outputs like this: Info from server: "Processed 1 Failed 0 Total 1 Seconds spent 0.001593" 1) the only way to see unknown hosts is the "info from server" line, and this is hard to read. "processed: 1; Failed: 0; Total: 1" would be much clearer. |
Comments |
Comment by richlv [ 2010 Jan 26 ] |
another ideas floating around : 1. no need to return full text like "processed", "failed" etc - just return amounts. as a result, server response could be greatly simplified by simply returning failed value count. in that case zero response means success, nonzero - that many values failed. trivial to parse, easy to read and much less data sent across the wire for each zabbix_sender value |
Comment by Simon Matter [ 2010 Jun 11 ] |
I just came around this issue and implemented the missing exit value. My very basic approach is to exit with 0 only if no error has happened. That way I can easily use zabbix_sender in scripts and only check exit value to know if the data has been accepted. Because I'm using a script to feed queued data to zabbix I want to make sure zabbix has stored the value before removing it from the queue. |
Comment by richlv [ 2010 Oct 16 ] |
other issues related to sender output : |
Comment by Raymond Kuiper [ 2013 Apr 18 ] |
A commandline tool, meant to be used in scripts that doesn't output a proper exit code? Really? — root@Lain:/opt/zabbix/bin$ ./zabbix_sender -z 127.0.0.1 -s lain -k existing.key -o 'bleh'; echo $? root@Lain:/opt/zabbix/bin$ ./zabbix_sender -z 127.0.0.1 -s lain -k missing.key -o 'bleh'; echo $? |
Comment by Andris Zeila [ 2013 Oct 02 ] |
Currently zabbix_sender exits with failure code only if the server response contains failure code - "response":"failed". So basically only if there was a network error or the data was malformed (the latter not likely). What will be changed:
|
Comment by Andris Zeila [ 2013 Oct 02 ] |
Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-935 |
Comment by richlv [ 2013 Oct 02 ] |
i believe response code should be different when there's network error and when one or more values failed to be sent - is that the case ? if yes, what error codes are used ? |
Comment by Andris Zeila [ 2013 Oct 02 ] |
We had a discussion about that and decided to stick to standard exit codes. So zabix_sender will exit with EXIT_SUCCESS (0) when sending and processing of all values succeeded and EXIT_FAILURE (1) otherwise. |
Comment by Andris Zeila [ 2013 Oct 02 ] |
So... after more discussion was decided to have the following exit codes: |
Comment by Raymond Kuiper [ 2013 Oct 03 ] |
Happy days! \o/ this will help a lot when writing Zabbix trapper scripts |
Comment by Andris Zeila [ 2013 Oct 03 ] |
(1) Documentation update:
Please review martins-v Reviewed, with some minor grammar improvements. Looking good overall. <richlv> let's include both response code and formatting changes both in whatsnew and upgrade notes - both are considered to be improvements and both are functional changes that might affect how users parse/handle output <richlv> let's also mention changed exit codes for -h -v or whatever wiper included both (response code and formatting changes) in whatsnew and upgrade notes. Updated exit status changes. martins-v Reviewed. CLOSED. |
Comment by richlv [ 2013 Oct 03 ] |
(2) manpage currently has : "The exit status is 0 if the values were sent and all of them are successfully processed by server." martins-v Fixed. Can be closed. wiper CLOSED |
Comment by Aleksandrs Saveljevs [ 2013 Oct 04 ] |
(3) [G] In the comment to check_response() function, it says: * Return value: SUCCEED - processed successfully * * FAIL - an error occurred * * >0 - the number of failed values * The last part does not seem to be true: it returns either SUCCEED, FAIL or SUCCEED_WITH_INFO. Also, we return SUCCEED_WITH_INFO if some of the sent items failed to process on the server: if (1 == sscanf(info, "processed: %*d; failed: %d", &failed) && 0 < failed) ret = SUCCEED_WITH_INFO; Maybe something like SUCCEED_PARTIAL would be a better name for the return code? wiper right, the comment leftover from the initial function version. About naming - I was thinking it's a return code from the sending operation, which can have additional information about failed items. If we treat it as a return code from sending operation + value processing - then SUCCEED_PARTIAL would be better fit. RESOLVED in r39007 asaveljevs Looks good, CLOSED. |
Comment by Aleksandrs Saveljevs [ 2013 Oct 04 ] |
(4) [G] If no hostname, key or key value is specified, the exit status is zero: $ src/zabbix_sender/zabbix_sender -z 127.0.0.1 -s trapper -o 1 -vv; echo $? zabbix_sender [16481]: Warning: Key required sent: 0; skipped: 1; total: 1 0 wiper RESOLVED in r39008, also changed the exist status from 255 to 0 for -h, -v options asaveljevs Unfortunately, r39008 breaks stuff even more. With ret being initialized to FAIL, sender is never going to enter the reading-from-file loop. REOPENED. wiper RESOLVED in r39013 asaveljevs Now it enters the loop, which is better, but it does not read more than one line from the file. REOPENED. wiper RESOLVED in r39033 asaveljevs Suppose we are reading from a file and, after VALUES_MAX values are gathered, we send the first batch successfully and variable ret becomes SUCCEED. Now, we start reading badly formatted lines that have a value missing. The value of ret will not be changed and we will exit with status 0. asaveljevs After some discussion in the office, we decided that if there is a bad line in the input, we should exit immediately with the fatal status. In my opinion, the best solution seems to revert most of the latest changes and simply replace "continue;" with "ret = FAIL; break;" in relevant places. REOPENED. asaveljevs RESOLVED in r39052 wiper CLOSED |
Comment by Aleksandrs Saveljevs [ 2013 Oct 04 ] |
(5) [G] Please take a look at r39009. It is mostly about formatting and style, but is also fixes a bug where "sent: 1; skipped: 0; total: 1" line was printed if there was no connection to the server. wiper Thanks, reviewed and CLOSED. |
Comment by Aleksandrs Saveljevs [ 2013 Oct 04 ] |
(6) [G] Please also take a look at r39010. It fixes a bug where specifying multiple -v arguments to sender was alternating between "warning" and "debug" log levels: $ zabbix_sender -v log level = 3 $ zabbix_sender -vv log level = 4 $ zabbix_sender -vvv log level = 3 $ zabbix_sender -vvvv log level = 4 $ zabbix_sender -vvvvv log level = 3 wiper Thanks, reviewed and CLOSED. |
Comment by Andris Zeila [ 2013 Oct 09 ] |
(7) [G] When failing to open input file (either not exist or no read access) sender exists with proper exit status (1), but gives no error message. It should tell that sending failed and suggest to use -vv option. asaveljevs RESOLVED in r39141. wiper CLOSED |
Comment by Andris Zeila [ 2013 Oct 09 ] |
Successfully tested |
Comment by Andris Zeila [ 2013 Oct 09 ] |
Released in: |
Comment by richlv [ 2013 Oct 09 ] |
all subissues have not been closed yet - (1) to be reviewed & closed still |
Comment by Aleksandrs Saveljevs [ 2014 Oct 29 ] |
All subissues seem to be closed. |