Unfortunately, the author is pretty vague about exactly what pieces of infrastructure they imagine defining relationships between, and what triggers they might use. On the smaller side, they mention 'I changed a config, I must restart nginx' (micro level dependency between nginx and its config) and 'something changed in my app tier, need to tell my load balancer' (macro-level dependency between a service and its front-end). What kind of dependencies would be useful to define between services in a service oriented architecture, which are usually designed so as to minimize dependencies?
Here is a example of monitoring for a fire in a room, and how one handles it -- similar concepts can be applied to infrastructure components as well ) -- http://blog.athico.com/2009/03/drools-quick-start-stateful-k...
I've personally been very big on trend graphs myself, how are we doing today v's yesterday, this week v's last week. I find you learn a lot more from these than you do any other type of monitoring (unless the issue is dead simple, like something is down)
We've been focused right now on making great monitoring systems, however we're just starting to get the chance to step into prevention. Prevention is a fun area because it starts to include trending.
My hope is that within the next month or two we have a few things. Firstly a means of providing a great downtime prevention tool, but also an end point where data can be sent (or we can pull it on your schedule) and then provide a graph and notifications based on changes in the trending data. Think of it like stock alerts...
So yep...i agree with you, we need graphing and more of it.