Trigger with trendsum fires early when not enough trend data is available

[eduardoh.souzah]

Hi everyone,

I'm running into an issue with a trigger using the trendsum function in Zabbix 6.4.2.

I want to monitor the total number of bytes received on a specific port using iptables. If the number of bytes received is less than 1MB over the last 45 days, I want the trigger to fire.

Here’s the trigger expression I’m using:

trendsum(/Monitor de aplicacao Linux/porta.bytes.[{#PORTA}],45d:now/d)<1M

However, the problem is that I only have trend data available for the last 8 days, and the trigger is already firing — even though 45 days haven’t passed yet.

It seems that trendsum() just sums up the available data, even if it’s less than the full 45-day period, and evaluates the trigger based on that partial data. This leads to false positives because it doesn't wait until the full 45-day window is populated.

---

❓ What I need help with:

• Is this the expected behavior of trendsum()?
• Is there a way to delay or condition the trigger so that it only evaluates after 45 full days of trend data are available?
• Has anyone solved this with a workaround (e.g., tracking the monitoring start time)?
• Any native way in Zabbix to check how much historical/trend data is available for an item?

Thanks in advance for any suggestions or ideas!

[cyber]

TBH, it is not possible to say, is it just too few days or just zeroes, if you think about it. sum does not care... If you do a select over time, do you know, how many data points you have there, or how they distribute over that timeframe, without looking it up specifically..?
So, that leads me to a wild thought, that maybe, if you add trendcount clause to your expression, you should be able to avoid false duplicates, if there is not enough values to use...

[eduardoh.souzah]

Hi Cyber,

I followed the guidance you shared and ran some tests. I believe everything is now working correctly.

I configured the main item — which receives the byte values from the ports — to run once per hour, and I created a temporary item of type trendcount to monitor the behavior. I noticed that it increments by one each hour. Since I need data for the past 45 days, I did the calculation: 24 hours × 45 days = 1,080.

Here is the full trigger:

trendcount(/Monitor de aplicacao Linux/porta.bytes.[{#PORTA}],45d:now/d+1) >= 1080
and
trendavg(/Monitor de aplicacao Linux/porta.bytes.[{#PORTA}],45d:now/d+1) < 1M
I tested this on a smaller timescale and it worked well, so I’ve now adjusted it to cover the full 45 days.

After spending nearly a week trying to find a solution, your help made all the difference. Thank you!

[cyber]

TBH, it is not possible to say, is it just too few days or just zeroes, if you think about it. sum does not care... If you do a select over time, do you know, how many data points you have there, or how they distribute over that timeframe, without looking it up specifically..?
So, that leads me to a wild thought, that maybe, if you add trendcount clause to your expression, you should be able to avoid false duplicates, if there is not enough values to use...

[eduardoh.souzah]

Hi Cyber,

I followed the guidance you shared and ran some tests. I believe everything is now working correctly.

I configured the main item — which receives the byte values from the ports — to run once per hour, and I created a temporary item of type trendcount to monitor the behavior. I noticed that it increments by one each hour. Since I need data for the past 45 days, I did the calculation: 24 hours × 45 days = 1,080.

Here is the full trigger:

trendcount(/Monitor de aplicacao Linux/porta.bytes.[{#PORTA}],45d:now/d+1) >= 1080
and
trendavg(/Monitor de aplicacao Linux/porta.bytes.[{#PORTA}],45d:now/d+1) < 1M
I tested this on a smaller timescale and it worked well, so I’ve now adjusted it to cover the full 45 days.

After spending nearly a week trying to find a solution, your help made all the difference. Thank you!