[ZBXNEXT-2365] More flexible auto registration based on HostMetadata sent from the agent and rerun once HostMetadata change Created: 2014 Jul 03 Updated: 2024 Apr 10 Resolved: 2018 Jun 11 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G), Server (S) |
Affects Version/s: | 2.2.4 |
Fix Version/s: | 4.0.0alpha8, 4.0 (plan) |
Type: | Change Request | Priority: | Major |
Reporter: | Natalia Kagan | Assignee: | Vladislavs Sokurenko |
Resolution: | Fixed | Votes: | 34 |
Labels: | autoregistration, metadata | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Environment: |
CentOS 6.4 |
Sub-Tasks: |
|
||||||||||
Team: | |||||||||||
Sprint: | Sprint 33, Sprint 34, Sprint 35 | ||||||||||
Story Points: | 2.5 |
Description |
if auto registration will be rerun every time when HostMetadata change on the agent it will be very useful in large env. and I will no need any more to run many agent checks in network discovery rule in order to assign host to host group and templates Thanks |
Comments |
Comment by Bjarne Offenberg [ 2015 Mar 25 ] |
In a large environment with many different hosts that needs to be checked for many different stuff this feature would be very nice to have. |
Comment by Guzman Braso [ 2016 Jul 14 ] |
Hello @alexei, First thank you and all the community for the best monitoring software ever. One question: there is any plan to implement this feature in the future, its in any future version road map? I'm asking because if there is no plan then hostmetadata it's no fit for a full automated zabbix setup that is able to keep up to date. Best regards from Montevideo, Guzmán |
Comment by Thomas Menard [ 2016 Aug 09 ] |
HI @alexei, That would be a real good option to be able to manage the host definition from the HostMetadata on a large scale setup. I'm a Zabbix User since zabbix 1.4 and I'm really waiting for this feature. The test case in my company is quite simple, thousand of servers (mostly unknowns by the current admins) and having zabbix_agent deployed through ansible and hostmetadata populated when adding new softwares. Having to delete the host in zabbix is not a good option, we loose all the historical data. Using the API is in my opinion overkill for that |
Comment by richlv [ 2017 May 12 ] |
keywords to ease searching : update existing repeated |
Comment by Michael Mol [ 2017 Jun 19 ] |
Here's a useful semantic:
This maintains semantic compatibility with existing environments while supporting the useful feature. It also permits multiple actions to apply to a newly-registered host. |
Comment by Michael Mol [ 2017 Jun 19 ] |
My own use case for this: I want to compose HostMetadata in my Agent configuration from multiple Saltstack pillars, and as a node's role changes or expands, I want additional monitoring applied. I could conceivably do it with the Zabbix API, but then I need to provide network access to the Zabbix front-end from nodes that wouldn't necessarily even have a network path to reach it in the first place. (Especially notable if passing through Zabbix proxies on the way.) |
Comment by Christian McHugh [ 2017 Jun 19 ] |
@mikemol we have a similar need, but satisfy it by raising a salt event and having a reactor run an orchestrate job on the zabbix server which ensures the modified host is in zabbix with all appropriate configurations. create_host_group: zabbix_hostgroup.present: - name: {{ zab_hostgroup }} create_host_{{ zab_host }}: zabbix_host.present: - host: {{ zab_host }} {% if zab_proxy -%} - proxy_host: {{ zab_proxy }} {% endif -%} - groups: - {{ zab_hostgroup }} - interfaces: - {{ zab_host }}: - ip: {{ zab_ip }} - type: 'Agent' - port: 10050 add_zabbix_templates_to_host: zabbix_host.assign_templates: - host: {{ zab_host }} - templates: {{ zab_templates }} |
Comment by Vladislavs Sokurenko [ 2018 Jun 04 ] |
Available in:
|