If you have devel, you could probably scan the query log for a close guess. As for the "launch a missle" scenario, consider simple things like Throttle, which will disable certain things - possibly even your monitoring.
 

Nancy

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.




From: James Benstead <james.benstead@gmail.com>
To: development@drupal.org
Sent: Sun, January 9, 2011 3:36:27 PM
Subject: Re: [development] An automated way of locating unused modules?

Thanks Gábor, that answers my question - looks like it might be an interesting and potentially useful project; I'll post back if and when I get some time to work on it.

--Jim
--
My IM and Skype details are at http://state68.com/contact


On 9 January 2011 20:18, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
On Sun, Jan 9, 2011 at 8:58 PM, James Benstead <james.benstead@gmail.com> wrote:
> Although I agree with Carl that this is an administrative rather than a
> technical issue, I think that the module I have in mind would still be
> useful for site auditing purposes: for example, when taking over a site that
> has been put together by another Drupal shop.
> Assuming that such a module would be desirable, the question remains: would
> it be technically possible to build such a module?

It is probably technically possible to write monitoring which gets to
**a close guess**. Whether a module is used or not can only be
determined in runtime environments. You can monitor the use of modules
(eg. inclusion of their files, last access time of their include
files, use of the module's strings for translation, etc.).

However, assume a module's job is to launch a missile in case of
nuclear attack. That module will not be used / useful until a nuclear
attack happens, but then its value would be essential. So you can
monitor its use but whether in the given time sample the module should
have done something or not depends on its role. (Replace missile
example with sending mail notifications only under certain rare
circumstances, automated blocking of spammers on the site, things that
kick in when on high load, things that kick in when running site
updates but not on the runtime site, etc).

Gábor