Read this FAQ:
The scan periods are configurable - in this case (postgres tables), its the service scans that will pick them up - by default its every 24 hours.
Damn, I looked through the docs (including the FAQ) and couldn't find that. I had searched for the word "discovery" rather than "scan".
It makes sense that people would search for the word "discovery" for that type of FAQ so I added the following as the first sentence to that FAQ entry :)
When the agent performs discovery, it does so using two different types of "scans" to try to find resources.
Out of curiosity, seeing as it's opensource, do you think it would be difficult to modify the agent so that certain discovery tasks (in particular the scan for new tables) could be fired more often than others?
I understand why it's once a day...but the inspection for new tables shouldn't be that expensive...
Hmmm, I guess there's two questions here:
1) Would it be difficult to add a specific config item just for that, and get it working?
2) Would the rest of the community be interested in it, or does it break from the design model too much?
It sounds like a good idea.
I can see a new optional attribute on the or tag - something like "discoveryInterval".
The implementation might have to change a bit - I don't think it would be trivial, but I'm sure its doable. Right now we assume that, on this global timer (24h default), we check all existing resources for new children (that's the service scan). What would have to happen is some sort of schedule system needs to be in place to schedule individual resources for scanning. Not quite sure the implementation details, but this is very similar to what we do with the measurement collection stuff.
Of course, once you add a individual discovery interval, you'll likely want to change it from the GUI - which is definitely not trivial to add (because now you have to worry about synchronizing the intervals in the case when the user changes an interval while the agent is down- when the agent comes back up, it needs to synchronize its schedules).
Its doable, but does affect alot of code.
Yeah now that you put it that way, I can see why it's likely to be more trouble than it's worth at this point. Simply knowing how the existing scheduling works is sufficient ATM. Once some other monitor (or two) needs it as well, then it will be worth doing the work I think, but not just for this.