possibility to create own VARIABLES

[dsipe]

When creating trigger, we often use constant.

For example, {server1:vfs.fs.size[/opt,pfree]}<20

When many triggers are using the same test constant, il will be very find to be able to create inside Zabbix some king of "user" variables that can be then use like zabbix macro.

The previous example then become
{server1:vfs.fs.size[/opt,pfree]}<{MIN_FS}

The main idea is to be able the change from one point the behaviour of hundreds of items

What do U think about Alex' ?

[Alexei]

Well, actually it can already be accomplished by creating a "fake" host which would contain all constant as trapped values. In this case your trigger may look like:

{server1:vfs.fs.size[/opt,pfree]}<{consts:MIN_FS.last(0)}

Obviously your solution is nicer, but this would allow you change the constants remotely (zabbix_sender) on the fly

[dsipe]

ok Alex'

don't know that such expression could be used inside trigger defs.

but, trying to do it your way, i've got the error message [ see attach image ].

So what can i do ?

[Alexei]

I forgot about this. If a trigger is defined for a template, it cannot have references to a different host.

You may create the constant inside of eram_ux_t. I know this is not perfect solution, but still better than nothing.

[Alexei]

But in this case scope of the constant will be this host only... Hmm... Sorry, no better solution at this time.

[dsipe]

is it complicated for U to add "user variables/macros" inside zabbix ? or may be [if more simple] use Unix environment variables that be "published" inside Zabbix

[Alexei]

I added your idea to TODO, yet I cannot give you ETA.

[dsipe]

ok nice!

so happy to have answers to my questions, i want to ask U one more about triggers.
In my company, i am in charge with a lot of server. one a the first ressource which need accurate monitoring is disk space left on filesystems/drives/volumes.

how can we avoid creating, for each item which monitor free space for a given filesystem, a specific trigger where the only thing that change is the name of the filesystem ?

The idea of some kind of template for trigger will be great!

[Alexei]

Does it mean that every file system will be checked against same value, for example, 2G (2 gigabytes)? I believe that normally different filesystems have different requirements for free disk space, so the feature will not be used frequently. Did I miss something?

[jeff.showers]

In the case of file system free space, setting the value as like a '10' when checking for a trigger against a key like vfs.fs.size[/var,pfree] would be really helpful and fairly universal.

[dsipe]

that is exactly what i mean!

when working on a production system inside a company, you often use "standard" values for monitoring same king of items.

in case of % free space on filesystems, that is the ONLY value on witch you can work as many different filesystem = different disk space = different %freespace.

BUT the ONLY thing that is not different is the time that you want to be warn that the filesystem is going to be full!
So having [ in PERCENTAGE of course ] the same value for all filesystems is good approach.