latest trunk

Having the same issue with 1.9.3.

I think the current logic of keeping auto-generated resources around after they disappear from discovery is the way to go.

However, these items must be able to be removed manually and not auto-removed.

It would be great if there was an option to choose what to do when discovered item is no longer present.

I can think of two possible scenarios: delete that item automatically or disable it and allow for manual removal. That would certainly decrease resources usage on rapidly changing monitoring environment.

I'd really like to see an option to auto remove discovered items. For things like file system or net interfaces this might not be critical, and we might want to continue seeing these items after we remove them. But other use cases like for monitoring instances of a process on a system that spawn new processes based on some external input (rapidly changing system) there should be an option to automatically delete the discovered items after they disappear.

A new global (Administration->General->???) configuration parameter will define life time of lost items. If an item exceeds the period, it will be removed and a new record for housekeeper will be added as well.

maybe do better not global? host level or discovery?

lld rule level would seem to be most appropriate. for example, we might have a host which has network interfaces quite rapidly changed, thus we know that interface going down would allow us to mostly safely remove it after 3 days. on the other hand, disk volumes going away would be less frequent, and data would be more important in the long term, thus we would like to have those items only removed after 2 weeks have passed

Sure, it's better to keep it on lld level with support of user macros (template, host, global).

New field "lifetime varchar(64)" is added to "items" table. Allows usermacro or number in days.
New input field is added to discovery rule form before "status".

(1) GUI
I think we should replace the maximum (and, maybe, minimum) lifetime with constants in the CDiscoveryRule::checkSpecificFields() and CDiscoveryRule::validateLifetime() methods and try to avoid using literal constants in the future.

Same for validatePortNumber()

<Vedmak> RESOLVED

<pavels> CLOSED.

(2) GUI
Shouldn't the clearValues() method in CItemGeneral::checkInput() and CHostInterface::checkInput() be called before the validation is performed? What's the point of cleaning up values, if they are already OK?

<Vedmak> RESOLVED

<pavels> CLOSED.

(3) GUI
Please review my changes in r23788 and r23789.

<Vedmak> CLOSED

(4) DOC
The docs should also be udpated
http://www.zabbix.com/documentation/internal/database_2.0/items
http://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery

<Vedmak> I'll update db and api docs, and put separate paper on the board for it.

<pavels> Db and API docs are ok. CLOSED.

(5) [DB] DB patches
upgrades/dbpatches/2.0/postgresql/patch/hosts.sql:64 - incorrect SQL statement delimiter
upgrades/dbpatches/2.0/oracle/patch/hosts.sql:64 - useless constraint 'NOT NULL'

<Vedmak> RESOLVED
<sasha> CLOSED

(6) GUI
When cloning a discovery rule or full cloning a host an error occurs:
"Discovery rule "lld22-2:lld2" has incorrect lifetime: "". (min: 0, max: 3650, user macro allowed)"

<Vedmak> RESOLVED

<pavels> CLOSED.

(7) [GUI] when creating/updating a discovery rule with 'Keep lost resources period (in days)' = 0 an error occurs:
Discovery rule "vfs.fs.discovery:vfs.fs.discovery" has incorrect lifetime: "". (min: 0, max: 3650, user macro allowed)

<Vedmak> RESOLVED

<pavels> CLOSED.

(8) api docs (to avoid overloading (4))
a) having http://www.zabbix.com/documentation/2.0/manual/appendix/api/discoveryrule is great, but to be consistent i guess there shouldn't be space in the page title (not sure about capitalisation)

b) also should be listed at http://www.zabbix.com/documentation/2.0/manual/appendix/api/changes_1.8_-_2.0

<Vedmak> RESOLVED

<richlv> do we have a rule on class naming ? because now we have "TemplateScreen" and "Discoveryrule" - would be nice to settle on either camelcase or something.
hmm, changes page actually says "DiscoveryRule" - which one is correct then ?

<zalex> last question moved to ZBXNEXT-1058
CLOSED

GUI is TESTED.

A server side is ready to test!

<dimir> Great! Please review my changes that allow it to work without graph prototypes in r23965 .

I could not to not test the dev branch ASAP
Server side tested. Seems it works.
A part of the debuglog attached.

>>> 15557:20111208:010525.923 poller #1 spent 2.178640 seconds while updating 1 values
it's ok because tested SNMP device is partially slow:

1. time snmpwalk -c scarysecret -v 1 10.20.0.5 IF-MIB::ifAlias
   .....~40 result records ....

real 0m1.965s
user 0m0.344s
sys 0m0.016s

(9) An item, has been not passed through the filter but doesn't deleted yet, still continue to be monitored:

mysql> select i.lastclock, d.lastcheck from items i, item_discovery d where i.itemid=25905 and i.itemid=d.itemid;
----------------------+

----------------------+

----------------------+

Is it ok by design?

added:
For instance, how an user can understand that after he changed the Regexp previously discovered and added resources currently are not passing by filter?
So if a gathering the data will be stopped then it could be some "indicator" that the resources are not discovered anymore an they going to be deleted in N days.

How is else the user can understand that some resources are not discovered anymore?

<zalex> some part moved to the ZBXNEXT-1058, some to the ZBX-4475
CLOSED

(11) I would suggest to change default value 0 days for "Keep lost resources period (in days)" to for instance 1 day when an user creates new discovery rule.
Try to imagine the case when the user creates discovery rule and forgot to change 0 to the value>=1.
Later he or someone else wrongly changes Regexp of discovery rule and all historical data can be unexpectedly lost in one moment (when discovery will be performed by the zabbix_server next time).

It's danger behavior. The user has to set 0 day only when he is understanding what he doing.

<zalex> moved to ZBXNEXT-1058
CLOSED

Hi.
the method I suggested in ZBXNEXT-925 could be an answer :
you could add a 'layer' between discovery and actual item creation, where user could see with some kind of status

• the currently discovered ressources
• the previously discovered ressources no longuer present, both with the date of last discovery
• and eventualy the manualy added ressources.( wich was the main request for the ZBXNEXT-925)

That way the user can choose between automatic and manual creation / deletion,
see what's going on with the discovery, manage the ressources by disabling / removing ressources.

That could allow some nw use cases like :
deactivate after an initial run the discovery and keep it's ressources ,
use the lld structure with manualy entered ressources etc.

Note, until ZBX-4425 is merged into trunk the server side will not work in this development branch. Meanwhile you can apply this patch:

svn diff svn://svn.zabbix.com/branches/dev/ZBX-4425 -c r23945

in order to test it.

merged: svn://svn.zabbix.com/trunk 24129

Additional improvements will be implemented in ZBXNEXT-1058

Reopened to close (move) some comments;
to remove 2.0 from Fixversion.

Closed again.

I've been looking around on the forums and whatnot and it seems like there is still no way to manually delete discovered resources, it would be great to see that added.

At least in my case, many (nearly 30) unnecessary network interfaces are added via the discovery rule and even though it is possible to disable the new items as a whole, I find this rather "polluting" to my setting.

I see no reason to leave those items there and I can't just recreate the host since I want to keep its historical data. Besides, those items won't get scheduled for auto cleanup because they're still discovered, I simply don't want them around anymore.