Auto-Registration "catch-all" for non-standard hostnames

[DevonK]

Hello, looking for some ideas regarding Auto-Registration...
Zabbix 2.4.4

Background...

I am monitoring datacenters where Zabbix agents are deployed to newly provisioned hosts using Chef. When a new VM comes online, Chef will install an agent within 15 minutes of this new VM becoming live. VMs are provisioned all the time as part of the datacenter operations.

I have Auto-registration rules set up to assign hostgroups/templates based on the VM naming convention (eg. Auto-Registration events have conditions such as: "Host Name like: LON" (to assign to hostgroup: London); and "Host Name like: SNG" (to assign to hostgroup: Singapore)). This works great, and as hosts come online with these naming conventions, they are Auto-Registered properly.

The issue is...

Sometimes the datacenter team does not follow the new host naming convention <groan>. As such, a non-standard hostname will not be seen by the defined Auto-Registration rules, and will not be added to Zabbix. For example, if a new host is named "LDN" instead of "LON," the Auto-Registration rules I set up will not add this host to Zabbix.

Question...

Is there a way to set up an Auto-Registration "catch-all" action that will run only after the other Auto-Registration actions have been applied?
- I want to avoid creating duplicate hosts in Zabbix.
- I want this to be automated (not dependent on running Auto-discovery and then manually assigning hostgroups/templates).
Any other ideas?

Thank you,
Devon

[jan.garaj]

Catch-all = no conditions. Create this catch-all action as a generic action for adding host into Zabbix. And then use your existing actions to add hosts to the corrects group based on the hostname.

[kloczek]

Hello, looking for some ideas regarding Auto-Registration...
Zabbix 2.4.4

Background...

I am monitoring datacenters where Zabbix agents are deployed to newly provisioned hosts using Chef.

Why not add such things in chef recipe?
You can scrip it over zabbix API.
You can create over zabbix API exact host with exact templates, and place it in exact group(s) with exact monitoring interface.
If your host is member of some group with dynamic number of hosts (auto scaled) you can register over API autoregistration action as well.

In last years i see that many people are using CMDBs as package managers.
Software like monitoring agent should be installed everywhere so it should be installed with all packages installed with base OS packages set.
If zabbix is in common set of packages it starts working after without delays when it is started by initscripts/systemd/SMF/whatever.

Sometimes the datacenter team does not follow the new host naming convention <groan>.

Things like assigning hostnames should integrated in OS provisioning service(s) with spreading some necessary bits to DNS, DHCP, kickcstart profiles or other like AI profiles/manifests (in case of Solaris).

With enough good and well integrated install infrastructure it should be possible to add new host which should cause:
- allocate VM/bare metal HW, allocate IP(s), register in DNS
- generate install resources like kickstart profiles on Linux or AI profiles/manifest on Solaris. Here it can be generated all PXE menu files as well with by default fire installation process
- if it is single host with exact profile such host can be added to monitoring service like zabbix in enabled state under maintenance
- provision host using kickstart/AI over the network using for example PXE
- end of install process shpuld change PXE menu from boot over networt to boot from local disk (to not have stuck whole pipeline in infinite install process)
- after first boot of the host it can be automatically confirmed over monitoring that host is up so additional set of tests can be fired as next stage on such new host
- when those tests are OK host can be removed from maintenance and flagged as ready to use or passed to next stages of pipeline or moved to dev/prod/pat usage.

Don't try to do all those things over CMDB because it is pointless .. this software should not be used as universal hammer.

Instead accepting someone messy behavior on assigning some stupid hostnames such process should be formalized and well defined/documented.

Managing of something is only about pure physics. If you are thinking that you can make some order by accepting growing entropy all what I can tell you is that it is wrong approach. All what you must do is do whatever is possible to keep entropy on as low level as it is possible.
As physics says .. on lowering entropy of some isolated system you must spend energy/do some work

[DevonK]

Thank you, jan.garaj, and kloczek for the good ideas.

To jan: I can look into this option of using no conditions. It still may be a challenge to create rules to assign to hostgroups if the host naming is not standard (doesn't fit into a rule.

to kloczek: Entropy! I'm with you my friend. Physics applies everywhere.

I haven't used the API before, but this sounds like a good opportunity. This fits my criteria of full-automation and reducing complexity. I appreciate the sequence you provided.

Ideally, I would get this into the base image build, but those guys are changing their images/OS/etc frequently. I'm left with Chef, which is the 2nd best thing.

I will look into the API to get something into the Chef recipe to assign the teplates/hostgroups to any newly provisioned hosts.

Greatly appreciate the insight.
Thank you,
Devon