it's an error in calculating trigger and/or, though I too fresh to debug it.

It you leave only one expression, e.g.

last(/Linux by Zabbix agent active/vfs.fs.size[{#FSNAME},pused])>{$VFS.FS.PUSED.MAX.CRIT:"{#FSNAME}"}

and remove second joint of estimated-time-to-disk-fillup and  - The disk free space is less than
{$VFS.FS.FREE.MIN.CRIT:"{#FSNAME}"} - it kicks in.

It's default template, it people relay on it, and drives just got bigger and bigger.

EDIT: Pasted another incorrect attempt of cloning template (DF_Linux..), should be original as I stated previously and as it rwas)

Was your database created from scratch for 6.0 or was it upgraded from the previous versions? If latter, did you convert to the extended double range? What do you see for vfs.fs.dependent.size[{#FSNAME},used] and vfs.fs.dependent.size[{#FSNAME},total] in Latest data?

when I first hit this issue, it was upgrade from 6.0 to 6.2 with failed timescaledb attempt, so I thought (as you suggest) it was a problem with upgrades of some sort or my other misconfigurations. To eliminate this, I've set up brand new installation ) of 6.0 (later 6.2 same results), switched hosts to new instance and got the same result.

As for now from affected host:

The disk free space is less than {$VFS.FS.FREE.MIN.CRIT:"{#FSNAME}"} 

Are you sure? Did you change {$VFS.FS.FREE.MIN.CRIT}? The default value in the standard template is 5GB whereas your remaining free space is 2TB which is well above the trigger threshold.

I did not touch this macro at all.  It's still there.  I was playing with {$VFS.FS.PUSED.MAX.WARN} and .CRIT , which was a bit more natural when migrating from Icinga.

So I guess I hit some kind of border conditions, where at large filesystems VFS.FS.FREE.MIN.CRIT/WARN are never met, as it goes:

1. condition checks whether $VFS.FS.PUSED.MAX.CRIT is met (in my case: yes)
2. next, we have AND with one of two other conditions:
   1. difference between fs.size (total - used) which should be less than VS.FS.FREE.MIN.CRIT/WARN (it is false in my case, still lot of free place, nevermind percentage of use - still more than 5/10GB)
   2. timeleft - let's asume there was not enough data to calculate, or whatever - false

so I got: true AND (false OR false) resulting in false.

If I'm getting this right after your hints - that would explain all my mess.  Still - default values works fine in many other cases (even with my other hosts) with filesystems smaller.  One have to be aware of how the trigger is calculated and enumerate own points for $VFS.FS.FREE.MIN.CRIT/WARN in GB to have it working anytime/anywhere. Since hdd are getting rather bigger than smaller, this problem may surface again.

Just got another branch of this issue:

windows host, drive c: 255GB, 93% full,16GB free space,

{$VFS.FS.PUSED.MAX.CRIT} = 90

{$VFS.FS.PUSED.MAX.WARN} = 80

VFS.FS.FREE.MIN.CRIT/WARN = 5/10GB.

No trigger, no warning, no nothing, no problems. So it not only appears with larger filesystems. It will be too late if I see that trigger on.

This really should let you alert on PUSED.WARN/CRIT only, and disregard the hardcoded GB-values (or at least choose to rely only on the percentages). Those does not make any sense for larger file systems. And the timelimit "the disk will be full in less than 24 hours" is also kinda non-sensical (and it seems it can't be tweaked?), sometimes you need alerting well before 24 hours before a filesystem goes full to plan expansions.