Maintenance period and deferring lookup of hostid's to within the actual window

[staoooott]

Dear,

During the creation of a script that schedules maintenance periods¹ in a Zabbix installation, using the maintenance.create()² API method, we have a concern with relation to passing a list of hosts (of which notifications are to be suppressed during said maintenance).

The API requires these hosts to be passed by identifying them with their (Zabbix interal) numeric hostid.
A potential problem arises: since maintenances are scheduled days/weeks/months in advance, it seems that the mapping between hosts (identified by their unique hostname/FQDN) and Zabbixes internal hostid's might change when hosts are added/altered/renamed/...
And thus might result the situation in which the wrong host's notifications are suppressed during a maintenance window.

Is there a way to defer the translation of hostname to hostid to the moment the latter is needed (which is during the actual maintenance period).

In general, this would apply to any Zabbix object which is referred to internally by a (unique) numeric ID (as in an ORM sense).

Secondly, are internal Zabbix identifiers like hostid's guaranteed to be unaltered between multiple API calls in one API connection? (For example: one call to look up hostid's for a list of hosts with host.get(), a second call to create a maintenance period referring to these hosts with maintenance.create())

Thanks for the help,
ST
Zabbix version: 7.4.11

1 https://www.zabbix.com/documentation...al/maintenance
2 https://www.zabbix.com/documentation...tenance/create

[cyber]

Hostid is fixed, it cannot be changed. It is created during host creation and it will die with host deletion. So yes, if you look it up once, then it will not be changed by the time you want to use it in other call. And if you change a hosts name, it will change also in that maintenance config, as it does the same kind of lokup towards hostid.
If you are afraid that there can be a case, when new hosts are added after maintenance is in place and those hosts might be skipped, Then maybe you can try tag based maintenance. Maintenance suppresses problems, if you suppress them by tags (and values), then only these problems will be suppressed, where specific tag (or value) exists. But tags can be inherited from many levels, also host level, so adding a tag to host in correct moment will keep all problems from that host from being escalated. Later, you can remove tag, or change its value. All problems from that moment forward will be escalated again.