One of the reasons that alerting is a tough problem to solve well iswhat I'll call the dependency problem. It goes like this: imagine thatyou have a nice monitoring system and it's keeping track of all sortsof things in your environment. One day you get a huge string of alerts,reporting that server after server is down. Oh, and also a networkswitch isn't responding.

Of course, the real problem is that the switch has died. It's beingcamouflaged behind

Suppose that you have a Solaris fileserver and a bunch of NFS clients(in this case they're Linux machines, but I don't think it matters).Perhaps one or two of them are Samba servers. Further suppose that yourclient machines start reporting things like ' fcntl() failed: No locksavailable '. What is limiting you, and what do you do about it?

(We'll assume that you use tools like lslk to rule out some process ona client machine holding on to

It's worth saying this explicitly: monitoring systems have two differentpurposes, one of which is sort of a subset of the other (but notnecessarily).

The first purpose of monitoring, and what many people initially installa system for, is alerting, letting you when there are problems. Thesecond purpose of monitoring is tracking, gathering ongoing data forhistorical analysis; this is part of the vital work of gettingstatistics . Put this way, it's clear that these twooverlap (sometimes badly )