|
I agree on this one. If anyone has ever worked with McAfee EPO (it is a network management not a monitoring solution) It has some of the most flexible rules possible for taking actions. Basically anything you can do from the interface by hand can be done by rules.
With the API coming in for the more advanced we could probably write scripts that get called to grab host ID etc and run API calls but these are features that built in would be great.
In my case I plan on having hosts setup as well in Amazon that will register only for short durations, it would make it easier if I know they are no longer in the network to just pull them (unreachable for X time) rather then having to write custom API to remove them. Using Zabbix to monitor the load on my always on servers, alert me to the need to increase servers (especially during DoS periods) and then removing them once the need is reduced. So I am very much in the same boat as ZBXNEXT-1385 with hosts coming up and down as needed.
|
|
I clearly see many use cases for this functionality. I think that implementation of the basic basic functions (changing group membership, host status, host removal) would be a good start.
Use of Zabbix API could be a much more flexible approach, yet it requires serious technical knowledge.
|
|
I'm voting for this one. For a couple of (my production specific) environment.
- I'm doing discovery on multiple /16's, while I only need to discover a couple of (know) hosts like .10, .20 and .50-60 for example, I have no choice (yes yes, got a ticket/question open for that
 but to discovery everything. So adding an extra check there can be a litten intensive and slow obviously --> so, not taking the discovery path in this case until that is resolved...
- My standard linux auto-discovery template has the following (standard) item: proc.num[mysqld]
Now, I want to automate the following: every host with mysql ps running (or rather, where it starts) will move to host group 'Database servers' and the right mysql template gets added. (I might couple the template to the host group, doesn't matter for the example).
So next step, a trigger - one that doesn't stay in True/Problem state, it only needs to be done once, one (of many) solutions
Trigger: Mysql process status = changed (install?) and is currently running on {HOSTNAME}
Expression: {HostX:proc.num[mysqld].diff(0)}=0&{HostX:proc.num[mysqld].last(0)}=1]
(note, I might have the expression a little wrong there, just typing this for the example
And there you have it: Now I need an action based on a trigger, that will be able to do pretty much the same as action based to discovery (move to group, add template etc).
I know; I have all my servers under puppet, I have facter (which btw, fills inventory info nicely in zabbix, starting to love that functionality more and more!). Like Alexei suggests, it's quite possible to do all this via an API call...
But that's the thing, I very much like having so many possibilities/solutions that I'm used to and it's quite nice to keep the intelligence in zabbix in this case
Anyway, sorry for the long comment, just my 2ct!
Tobias
|
|
Bump! Would seriously like to see what progress is happening with this. I'd like to see the priority of this, in relation to the Cloud risks associated with ZBXNEXT-17 encryption, raised. As adding adding and removing cloud hosts is inherently with risk.
The agent should, as suggested in ZBXNEXT-17 (http://zabbix.org/wiki/Active_agent_authentication), authenticate to ensure no unwanted hosts are registering. Rules around de-register should consider when an agent gracefully terminates, that is sends a message (zabbix_sender maybe?) to notify of it's status being stopped. Then this, along with some other trigger would be the criteria for de-registration. Without this, we're just making too many assumptions IMHO.
Other alternatives would be to look into using the AWS API a bit like what Daisuke is doing with HyClops. Maybe HyClops will be enough?
|
