my wish list - actions to trig items to trig actions again

[pgin]

When a new host is found (discovered), it would be useful to create an action which will read another value (item) to perform new operations (the one found in action->operation).

The idea behind that is we would like to place newly discovered devices in several groups. Currently, we use the OID to identify the brand and model (and to store them in the group). We use the IP address to identify the provider. But, for other groups, we need to do them by hand because reading other items is required.

[kloczek]

When a new host is found (discovered), it would be useful to create an action which will read another value (item) to perform new operations (the one found in action->operation).

The idea behind that is we would like to place newly discovered devices in several groups. Currently, we use the OID to identify the brand and model (and to store them in the group). We use the IP address to identify the provider. But, for other groups, we need to do them by hand because reading other items is required.

Looking on what happens in last years with monitoring software like zabbix and OPS/CMDB like puppet to be honest I'm more and more convinced that between these two pieces is so close relation that it is more and more reasons to treat them as one area.
Puppet provides kind of inventory tools like facter and in the same time zabbix has integrated this part as well. OK at the moment inventory description is static but I think that sooner or later it would be good to transform current inventory_link in item records which holds integer to char which will hold just inventory name. In such model current host_inventory table definition could be changed to four tables like inventory(,_uint,_str,_text} each one with four columns like hostid, itemid, inventory_name and value.
Such change will allow reorganize current static set of inventory fields to completely dynamic one. In such model inventory name and type of the values can be part of host/template description. It is only matter of some very simple additional page like current item editor page to edit inventory mappings .. or it can be even integrated into item editor page.

Another part of the bigger area where zabbix and pupped can work as one service is collecting all information about operations which may be event based like firing exact trigger.

With integrated CMDB functionality under one tool hood it would be very easy to maintain whole environment definition.
Current edges of SMDBs and OPS software does not allow easy to define some common interface which can be used by replaceable components so at the moment only way is to integrate such software in one package.

Sometimes some CMDBs side changes should automatically cause some actions on monitoring side like by add setup of some new component in CMDB should be automatically added monitoring of this now component.
Change of the OS on some host during next reinstall cycle to another OS should automatically cause change OS specific template used to monitor this host but such change should be taken not on make the change in CMDB but after first boot of such host when from inventory will come event that OS has been changed. OK now it can be done by autodiscovery action where part of condition is OS type but with starting such change on CMDB layer would be possible to check if relinking with new OS template will not cause some conflicts or what to do with some obsolete (on new OS) items (leave them or delete immediately or after some period of time like in LLD) preserving in the same time as much as possible historic data from before switching to new OS.

Very similar scenario is when over CMDB is executed for example use new version of some software on next reinstall cycle or instantly by package upgrade which should automatically cause start using new version of some app template, but this should happen only when this new version will be present on the host.
Again: such change should be checked on the committing change to CMDB stage against some possible conflicts between new and old template on relinking it with host monitoring.

Really I think that it should be long term goal of the zabbix.
Puppet is very good but development of this software started in some idea boiling stage and now is enough details how CMDB/OPS software should be working without thinking how to preserve some legacy bits.
Closer integration monitoring, inventory and OPS/CMDB definitely IMO will bring completely new possibilities.

[mushero]

Very interesting as we struggle with LLD also, and we also have the world's richest and most detailed CMDB (we parse/have every line of every config for every service for the Internet, with rules, parsers, search, comparison, etc.) so we are also thinking of how to drive Zabbix with this.

Especially for file systems, multi-instance Tomcat, and other complex stuff where LLD is not great.