[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: File zabbix-1.8.2-zabbix_sender_exitvalue.patch    
Issue Links:
Duplicate

 Description   

zabbix_sender outputs like this:

Info from server: "Processed 1 Failed 0 Total 1 Seconds spent 0.001593"
sent: 1; skipped: 0; total: 1

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.
2) an exit value would be great, just "return (skipped+failed)" or so.... would help me not to parse output now (which will break once you fix the output)



 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.
2. "seconds spent" is debuggin info and reveals info about zabbix server performance - probably can be discarded;
3. sender usually is interested "did any of the values actually fail", thus failed values is the main thing that matters.

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.
Attached patch zabbix-1.8.2-zabbix_sender_exitvalue.patch works for me.

Comment by richlv [ 2010 Oct 16 ]

other issues related to sender output :

ZBXNEXT-38
ZBXNEXT-246
ZBXNEXT-506

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 $?
info from server: "Processed 1 Failed 0 Total 1 Seconds spent 0.041822"
sent: 1; skipped: 0; total: 1
0

root@Lain:/opt/zabbix/bin$ ./zabbix_sender -z 127.0.0.1 -s lain -k missing.key -o 'bleh'; echo $?
info from server: "Processed 0 Failed 1 Total 1 Seconds spent 0.000023"
sent: 1; skipped: 0; total: 1
0

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:

  1. server response will have improved formatting (note that this will affect ZBXNEXT-1942 and all users who are parsing the response)
  2. zabbix_sender will return failure code also if processing of at least one value failed
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:
0 - success
1 - general failure (communication, data parsing)
2 - processing of at least one of values failed

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."
i'm unsure about mixing were/are, i'd replace "are" with "were" (check with maartinjsh )

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:
pre-2.1.7 r39150

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.

Generated at Fri Mar 29 07:21:50 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.