Hello.

Use case:

Template (templateA) for db instance monitoring has LLD for databases.

This LLD is filtered by macros {$DBNAME.MATCHES} and {$DBNAME.NOT_MATCHES} respectively.

This templateA is assigned to host prototype within another template (templateB) and it's LLD.

Specific customer requires predefined set of DBs to always be excluded from the discovery for their whole environment.

Let me name couple of options that I could think of and a desired approach to wrap it up.

Option #1:

Create a customer specific template (templateC) that defines only the {$DBNAME.NOT_MATCHES} macro.

Configure override for host prototype matching customer's domain in templateB and link templateC within that override.

Expectation:

Host prototype from that particular customer has templateA and templateC linked.

TemplateC {$DBNAME.NOT_MATCHES} overrides the macro from templateA because it is linked further down in the chain.

Result:

If two templates define the same macro, effective value is taken from the template with the lowest id, hence this approach fails.

This behavior is not very transparent and it would be more intuitive if it followed the path of conf files, where if you define the same parameter at the top and at the bottom of the file, the latter one will be used.

Option #2:

Create a customer specific template (templateC) that defines context specific macro, such as {$DBNAME.NOT_MATCHES:"override"}.

Alter the filter in the LLD for databases in templateA such that does not match condition is checked against {$DBNAME.NOT_MATCHES:"override"} instead.

Configure override for host prototypes matching customer's domain in templateA and link templateC within that override.

Result:

Works - if context specific macro variant is not found, simple variant is used as fallback - but you end up with two macros doing the same thing which may lead to collision that you need to be aware of, impractical, not transparent.

Option #3:

Create a customer specific template (templateC) that defines macro {$DBNAME.NOT_MATCHES} and also nests the templateA.

In templateB, alter the override for host prototype to either link the templateC which already contains templateA or link just the templateA (when criteria is not met).

Result:

Works but impractical when multiple customers require different macro value leading to multiple templates created to only override single macro.

Option #4:

Mass update macros of hosts in specific hostgroup or run a periodic task that executes API to do so, impractical, not automated or automated but not so transparent.

Desired approach:

Define override for user macros in templateB for host prototype (user macros can be added, updated or deleted).

Already, each override can be named according to the customer's name or similar leading to what I see as more transparent, simplier and straightforward way to achieve the same task without the need to keep track of additional templates.