Linux (CentOS), don't think this is environment dependent

related to ZBX-1911

ZBX-4645 has a patch

That's another use case for bar graphs as requested in ZBXNEXT-1819

The great thing about zabbix_trapper is the fact that I do not need to overload zabbix servers. All my scripts can run in another location and I send traps only if something wrong happens. If zabbix_trapper item plots "nodata" I am forced to send "ok" to zabbix every time to avoid blank graphs. Then, I overload zabbix server with unecessary traps ("ok"). There could be a possibility create this zabbix_trapper item telling it how long should it wait for a new trap to consider the item as "nodata". And, also, the possibility to leave the last value being plot indefinitely (which has been considered here as counter intuitive, but, in my case, it's what I expect). I want the graph's line to keep plotting in position "1" indefinitely until I send it a trap telling it to go to "0", no matter how long it takes. And no "nodata" in between!

ZBXNEXT-1819 might help here too.

I've recently run into this issue, and have a probably incomplete suggestion, but one that's working for me so far. Actually two related suggestions though I'm not up for programming the first yet:

(1) At the item level, have three possible item definitions for trapper: (a) no gaps in graphs, (b) calculate gaps, and (c) expect a delay of NNN seconds. This latter is for trapper items that still run on a regular basis of polling, and so with respect to data expectation work like regular items.

(2) Changed the line graph to, before filling in missing points, calculate the average delay for the data shown (if enough points). Pass it in as though it were a defined delay on a regular item (this is basically (1b) above) . At least in some brief testing it yielded decent results, though I think it might be better to calculate some of "normal" based on throwing out the excessively long gaps, or perhaps using a median instead, as a couple big gaps tends to artificially increase the average where it might miss smaller gaps.

I can see where this sort of "expected" interval is not valid for people using it for randomly generated data, with no regular interval, which is why (1) as a defined option may be better to be able to allow the user to control it, then use either (a) or (b) as the default (probably (a) for backwards compatibility).

I'm going to continue to refine the calculation as I use it for real, but wanted to post the thought here in case I am treading an old path and could get some feedback, or perhaps to prompt others to consider it.

Hello everyone, any user patch available for this problem for recent versions? 2.4 - 3.2

Hello, I have been experiencing this problem in version 3.0.2. Is here any patch available ?
Thanks

I am not recommending this as a real solution, but as a quick remediation for those who want a starting point to play with fixing the issue. See inline comment.

I've attached a file that I have been using. I did this some time ago and did not prepare it as a real patch file, so take the line numbers with a grain of salt and look at the code surrounding.

The idea is to, first, determine an average delay based on how frequent trap data items are (over the time frame of the graph), then separately to decide based on a gap's delay relative to that average delay if it should be skilled.

For me I was doing very regular trap transmissions, so it acted more like polling. For more randomized timing and gaps between data, it is not clear what the appropriate criteria is for a gap vs. connection. One thought was, in the initial code, to use a somewhat more statistical approach to calculate what gaps are outliers, indeed even if using averages it may make sense first to sort the gap data and throw out the top (few?) gaps that are large and small just in calculating an average.

So again, this is not a path to just apply, but maybe a starting point if you want to work on the code a bit. I kept meaning to come back to it, but it worked well enough for me I never did.

This was 3.0.4 by the way. And sorry for the double comment – I see now that attaching a file also attaches a comment. The file I attached (in case more appear) is kludgy_patch.txt

The effect in ZBX-17683 could help a bit.