Question to author/community - Changes and improvements

[aholiveira]

Hello @romainsi and all,
First of all let me thank you @romainsi for your great work on this. It was very useful and prompted me to give back to the project in the spirit of open source, sharing the changes I had done to it.

I have two questions regarding future changes on this template:
1 - There could be a possibility to completely remove the need to manually alter the script to adjust the configuration. Instead this configuration could be done using macros on the template, which would then send the values to the script.
This way both the template and the script would not need to be modified on each installation.
However, this would make the "master items" look really ugly (veeam.info[JobsInfo,{$VEEAM_DB_SERVER},{$VEEAM_DB_INSTANCE},{$VEEAM_DB_USERNAME},{$VEEAM_DB_PASSWORD},{$VEEAM_DB_INTEGRATED},{$VEEAM_DB_VEEAMDB}]) and would also require that at least the password to be base64 encoded on the macro (because of the characters Zabbix accepts on an item key).
Do you see value in making this change to the script/template?

2 - On the macro {$VEEAM_JOB_HOURS_WARN} the last version (2.8) of the template is using JOBNAME as context ({$VEEAM_JOB_HOURS_WARN:"{#JOBNAME}"} instead of JOBID (which was used in the previous version).
JOBID is in GUID format and only available on the database (you can't see it on Veeam's GUI). You can obtain it from the trigger expression on the host, but when you're looking at the macros on the host you can't really tell which job each macro relates to.
However, the job ID does not change if the job is renamed.
Using JOBNAME on the context macro, makes it easier to identify the job that the macro is associated to but if you rename the job, you also need to rename the context macro.
Which one do you think should be used for the context macro, JOBID or JOBNAME?

Please comment with your thoughts on this. Thanks.

Regards,

[thmcon]

Hello @aholiveira and @romainsi ,

thanks for your effort for this project!

my thoughts to it:

1- it's always good to have as little number of configuration information locations as possible. It's easier to deploy a new version of the script to the veeam server if you do not have to adjust the script (for configuration parameter values).

2- I would prefer the name, because nobody can see the IDs from within the veeam gui. A far as I have it in mind: as soon as you would change the name of the veeam job, zabbix would find a new job/create new items and trigges for this host and would mark the items and triggers of the job's old name as no longer existing and would automatically delete those after some days. For me this is fine like this.

[aholiveira]

Hello @thmcon,
Thank you for your comments.
1 - That was one of the main reasons for proposing this, so that configuration could be done in a single place. This would make some "ugly" items in the template, but would make the whole configuration independent both from the template and the script.

2 - Job IDs are used on the items keys as this makes them tolerant to name changes on the jobs. The change I'm proposing is using the job name on the macros that are used on the trigger expressions, since these are more probable to be changed by template users.
Macros are not changed when jobs are renamed on Veeam, so if a job is renamed and there is a context macro ({$VEEAM_JOB_HOURS_WARN:"Backup job name"}) already defined this will not be automatically renamed. Since the item keys use the job ID and not the name they would still be valid (and not deleted/recreated), but the macro would not change. The user would have to rename the macro manually.
However, if the job id was used on the context macro ({$VEEAM_JOB_HOURS_WARN:"43eeb34a-2a9d-4efc-8b39-c0e15a7fc3ee"}), it would still be valid even if the job was renamed. However, it is not immediately apparent to the user which job this ID corresponds to and would require the user to check it on the trigger itself.
The current version (v2.8) of the template uses the job name on the context macro. The question is if this should be maintained or changed to job ID.