That link is broken.

A scenario that I’ve seen relates to orphan agents. I’m not sure why the management processes don’t pick this up, but I do see hosts running *only* agents. Initially this tripped up idle host identification, but it would be helpful to pick up unuseful connectivity for investigation and possible retirement of the host. The time over which this information needs to be collected varies by customer, but I have seen set up and tear down delays of several months, especially for blades: the host is physically installed, but does not have any useful work to do for some months, or it’s in the decommissioning process, and had all useful software removed but does not get physically removed for several months.

For infrastructure monitoring it would be useful to understand which servers were missing key management agent technology such as that for : AV, Backup, Software Distribution, Performance monitoring, closed-loop change management, understanding the relationsips between these agents and their management servers would likely allow these ‘unmanaged’ servers to be identified.

It would be interesting further to understand which agents were installed but were either broken (not exchanging data) or disabled (service stopped etc) but I’m not sure if this is possible.

Client server relationships would also be interesting to model but care must be taken if any tracing of relationships is performed based upon client configuration files as in a mature environment for resilience and performances purposes the local config may well be pointing to a fully qualified DNS alias which might be using round robin with virtual IPs and which might be passing through hardware load balancers before getting any where near a host, again I’m not sure how Tideway works so this may not be a problem for you.

Identifying servers missing partcular expected monitoring agents is a pretty simple Foundation reporting task.

Identifying client-server relationships in the presence of load-balancers is quite a challenging area, but with the Tideway Pattern Language, it’s possible to define patterns that identify those kinds of situations. Our data model includes clusters that can be used for clustered servers, and also includes multi-level Software Instances (SIs). A service can be modelled as one SI for each instance running on the individual servers, plus one higher-level SI representing the load-balanced group. The clients would then have communication relationships to the higher-level SI.

The only real difficulty is spotting the situation and understanding what the load balancer is doing. I suspect it’s often something rather product specific, but we are always looking for common situations that can be hangled in a more generic fashion.

I think it’s often oing to be more deployment specific than product specific.

We use load balancers with applications whenever we either need more resilience or capacity than we can satisty with a single server instance, interestingly most of the products we use with load balancers have no understanding of either load balancing or even that they are part of a resilient environment.

One other interesting point to note is that many software solutions (such as MS Windows load balancing) is incompatible with layer 3 networks, requiring hardware content switches to be used anytime we want to make IIS scale.