Interactive hierarchical status display

The invention features a method and apparatus for displaying the status of networked resources, including rendering in a fishbone layout a hierarchy that includes a plurality of resource profiles and a plurality of dependency relationships among resource profiles in the plurality of resource profiles, where the resource profiles represent networked resources. The invention also features a method and apparatus for displaying the status of networked resources, to include rendering fishbone layouts in a snowflake layout. Each fishbone layout features a hierarchy with resource profiles and dependency relationships among the resource profiles. The resource profiles represent networked resources. Hierarchies in the snowflake layout share a common root.

TECHNICAL FIELD

This invention relates to network monitoring, and more particularly to status displays.

BACKGROUND

Network monitoring software aims to detect problems and potential problems with networked resources. The network monitoring software is therefore concerned with how problems can propagate from one resource to the next. The network monitoring software is also concerned with, for a given resource experiencing a problem and having several component resources, isolating the source of the problem to a given component or set of components. One term for this and related goals of network monitoring software is “root cause analysis.” Root cause analysis seeks the origin of a problem, i.e., the first condition that caused a propagation of problems. The paths along which problems propagate can be represented as a dependency relationship between a first resource originating the problem and a second resource to which the problem propagates; the second resource is dependent upon the first not to cause problems. When two resources are involved this way, the dependency relationship is “binary”. More complicated dependency relationships might not be binary but may involve three or more resources. Such relationships can usually be expressed by a set of binary dependency relationships.

Directed Trees

FIG. 9Ashows a directed tree39, a data model known in the computing art. Tree39includes nodes391and edges396. Tree39includes exactly one node391designated as its root392. Each edge396has a direction394and connects two distinct nodes391. A “path” is a sequence of edges396such that each member edge396shares a node391with its neighbor edge396.

Direction394labels one of the two nodes391as the “departure” and the other as the “destination” for a given edge396. A directed path goes “from” the departure node391of the path's first edge396and “to” the destination node391of the path's last edge396, with neighboring edges396in the directed path sharing the departure node391of one neighbor with the destination node391of the other. Directed tree39has direction394determined for each edge396by position relative to root392—in particular, directed trees39for which all edges396“point toward” root392, or for which all edges396“point away from” root392. A more formal definition of “pointing toward” root392is that every edge396in tree39begins a directed path to root392. Likewise, “pointing away from” root392may be defined as every edge396in tree39ends a directed path from root392.

Known properties of trees39include: “connectedness”, meaning every node391is connected to every other node396via some path in tree39; and “path uniqueness”, meaning that a minimal path in tree39between a first node391and a second node396is the only such path between those nodes396. The path is minimal in terms of its length. The “length” of a path is the number of edges it contains.

The “depth” of each node391is the length of the (unique) path that connects node391to root392. The node391designated as root392has depth zero; all other nodes391have non-zero integer depth.

There is another way besides “departure” and “destination” to describe the nodes391of an edge396: the node391with the lesser depth is called the “parent” of the other node391, while the node391with greater depth is called the “child” of the parent. If A is a node391, B is a child node391of A, and C is a child node391of B, then C is called a “grandchild” of A. Nodes391with no children are called “leafs”. The number of child nodes391of a node391is called the “degree” of that node391.

Nodes391having the same depth are said to be on the same “level”, also known as “tier”. A tier is often specified by the number that characterizes the depth of its nodes391. For example, “tier one” includes all nodes391that share edges396with root392. At least two mathematical truths apply to edges396in tree39with regard to tiers (the proofs are known in the art). First, for “n” greater than zero, each tier “n” node391shares exactly one edge396with a node391in tier “n−1”. Second, edges396always join nodes391from different tiers—specifically, tiers that differ in depth by exactly one. A corollary of the second truth is that edges396never join nodes391within the same tier. These truths can be summarized intuitively as follows: edges396in tree39always go “up and down” between adjacent tiers, never “sideways” (within a tier) or skipping a tier; and, all nodes391, except for root node392, have a parent.

A first node391together with all its child nodes391, grandchild nodes391, the child nodes391of the grandchild nodes391, and so forth, together with their connecting edges396form subtree395. The subtree395just described is itself a tree39having the first node391as root392. Because subtrees395have the same structure and properties as trees39, trees39are said to be “self-similar”. Many recursive algorithms work well on trees39because trees39are self-similar, among other reasons.

The “distance” between two nodes391in tree39is the length of the shortest path connecting them. (Recall that because tree39is connected, at least one such path exists. Also, because tree39has path-uniqueness, there is precisely one such path.) Two nodes391sharing an edge396are connected “directly”. Another way of saying this is that their path length is one. Two nodes391connected by a path of length greater than one are connected “indirectly”, i.e. via intermediary nodes391.

The direction from node391toward a node391of lesser depth is called up; toward greater depth is down. To “traverse” tree39means to point to its nodes391one after the other, where successive nodes391are only chosen if they are joined by edges396.

Node391can data structures in addition to those necessary to participate in tree39. Edge396encodes as a data structure that can contain additional data structures, in like manner. Therefore, certain attributes of the data structures for nodes391and edges396may pertain to entities not inherent to tree39itself—for instance, the data structures often contain attributes of the concept being modeled by tree39.

To the degree that hierarchies have the structure of a tree, the same terms apply.

SUMMARY

In general, in one aspect, the invention features a computer-based method for displaying the status of networked resources, including rendering in a fishbone layout a hierarchy that includes a plurality of resource profiles and a plurality of dependency relationships among the resource profiles, where the resource profiles represent networked resources.

Preferred embodiments include one or more of the following. The method includes acquiring a status of a monitored resource that has a monitored resource profile in the fishbone layout, as well as updating the fishbone layout to reflect the status. Acquiring a status includes repeatedly acquiring the status at regular intervals. Acquiring the status includes acquiring information about properties of the monitored resource that have changed in the most recent interval. The monitored resource profile includes a propagation rule for how the acquired status should propagate to dependent resource profiles that are in consumer dependency relationships with the monitored resource profile, while updating the fishbone layout includes updating the rendering of the dependent resource profiles. The rendering first displays the fishbone layout in a display panel, using a first density mode of the fishbone layout, while the method further includes replacing the first density mode with a second density mode. The replacing is in response to a change in the ratio of members of the fishbone layout to a size of the display panel. The first density mode of the fishbone layout is a standard mode that renders a tier-two resource profile as a spine, and the second density mode a mode for rendering components of the fishbone layout at a higher density, relative to the first density mode. The first density mode of the fishbone layout is a mode for rendering components of the fishbone layout at a higher density, relative to the second density mode, and the second density mode a standard mode that renders a tier-two resource profile as a spine. An instance of topological connectivity between the renderings of two resource profiles in the fishbone layout corresponds to an immediate dependency relationship between the two resource profiles, while an absence of topological connectivity between the rendering of two resource profiles in the fishbone layout corresponds to an absence of any immediate dependency relationship between the resource profiles. The second density mode of the fishbone layout is a dense mode that renders a tier-two resource profile as a parallelogram.

The method includes presenting a summary dialog that describes a component of the fishbone layout in response to a sustained mouseover. The method includes displaying a context menu for a component of the fishbone layout in response to a right-click on the component, where the context menu includes a drill-down list offering procedures to invoke on the component. The context menu is customized to the component. A procedure in the drill-down list invokes in response to a selection by the user, a report in a network analysis tool. A procedure in the drill-down list causes re-rendering of the fishbone layout in response to a selection by the user, such that the component becomes the root of the fishbone layout. A procedure in the drill-down list opens in response to a selection by the user, a new display panel having a fishbone layout. The fishbone layout has a root and uses the component as the root. A procedure in the drill-down list opens, in response to a selection by the user, a new snowflake display having a root and using the component as the root.

In another aspect, the invention features a computer-based method for displaying the status of networked resources. The method includes providing a hierarchy, which includes a root resource profile and dependent resource profiles in dependency relationships with the root resource profile. A minimal path from each dependent resource profile to the root resource profile, including a sequence of dependency relationships, has a path length corresponding to a tier in the hierarchy for each such dependent resource profile. The resource profiles represent networked resources. The method also includes acquiring a status of a monitored resource profile, which is either the root resource profile or among the dependent resource profiles; associating the status with a severity; and rendering the hierarchy in a fishbone layout. The monitored resource profile is rendered with a visual trait indicating the severity.

Preferred embodiments include one or more of the following. The visual trait includes a color selected from a plurality of colors representing a severity scale. The associating the status with a severity includes using a status metric associated with the monitored resource profile. The method include acquiring notice of a change in the status, updating the severity; and re-rendering the hierarchy in a fishbone layout, to include rendering the monitored resource profile to indicate the updated severity. The severity includes applying an application-wide override to deviate from a behavior indicated by the status metric. The deviation includes suppressing a change in severity. The fishbone layout is included in a snowflake layout.

In still another aspect, the invention features a computer-based method for displaying the status of networked resources. The method includes acquiring a logical hierarchy that includes resource profiles, as well as dependency relationships among the resource profiles. The resource profiles represent networked resources. The method also includes deriving a visual hierarchy from the logical hierarchy, where components of the visual hierarchy correspond to components of the logical hierarchy, such that the visual hierarchy is a tree. The method includes rendering the visual hierarchy in a fishbone layout.

Preferred embodiments include one or more of the following. The visual hierarchy is a directed tree. The fishbone layout is included in a snowflake layout.

In yet another aspect, the invention features a computing apparatus for displaying the status of networked resources. The apparatus includes a computer usable medium having computer readable program code means embodied in it, including a processor, a main memory, a visual display, a storage device, and a network connection. The program code means includes computer readable program code means for causing a computer to represent a hierarchy including resource profiles and dependency relationships among the resource profiles. The resource profiles represent networked resources. The apparatus also includes computer readable program code means for causing the computer to acquire a status of a monitored resource profile among the resource profiles. The apparatus includes computer readable program code means for causing the computer to render the hierarchy in a fishbone layout, including rendering a visual representation of the status of the monitored resource profile.

In another aspect still, the invention features a computer-based method for displaying the status of networked resources, including rendering fishbone layouts in a snowflake layout. The fishbone layouts each feature a hierarchy with resource profiles and dependency relationships among the resource profiles, where the resource profiles represent networked resources. Each hierarchy shares a common root. Preferred embodiments with regards to one or more fishbone layouts in the snowflake layout include one or more of the features already described with regards to a fishbone layout.

In yet still another aspect, the invention features a computing apparatus for displaying the status of networked resources. The apparatus includes a computer usable medium having computer readable program code means embodied in it, including a processor, a main memory, a visual display, a storage device, and a network connection. The program code means includes computer readable program code means for causing a computer to render fishbone layouts in a snowflake layout. Each fishbone layout features a hierarchy with resource profiles and dependency relationships among the resource profiles. The resource profiles represent networked resources. Each hierarchy shares a common root

Advantages of the present invention include the following.

Root cause analysis is a useful application for dependency relationships. System planning also benefits from knowledge of dependency relationships, so that the impact of a change can be anticipated.

As the number of monitored resources grows, an unorganized web of interrelated resources can become difficult for a user to understand. An advantage of the present invention is that if a logical hierarchy is imposed on the web, relative to a root resource, the logical hierarchy is rendered as a visual hierarchy, according to a layout such as a fishbone or a snowflake. An organized presentation of the visual hierarchy, such as occurs in a fishbone or snowflake, makes the meaning of status changes (for instance, the impact of a problem) in the web easily apparent visually, even if the meaning was not easily apparent conceptually before the visual rendering. For instance, viewing the web of resources from the perspective of the root resource can offer insight into the role of the root resource within the web. It often illuminates the role of other resources as well: for instance, if they play intermediary roles in extended relationships. When the relationships are dependency relationships, a hierarchy can represent all of the resources that a root resource depends on, both directly (at the level of the hierarchy immediately below the root) and indirectly (transitively, in subsequent levels of the hierarchy).

Another advantage of the present invention is that multiple logical hierarchies may be defined over the same set of resources, offering a variety of perspectives. Furthermore, the logical hierarchies may be tailored to various user profiles, so that (for instance) some users may be given a high-level view, while users who have responsibility for a narrower subset of the resources may use views that focus exclusively on those users' interests.

DETAILED DESCRIPTION

In the described embodiment, an interactive display shows status information for resources monitored by network monitoring software. A hierarchical status display process arranges the resources for display in a visual hierarchy. The visual hierarchy derives from a logical hierarchy containing resources in dependency relationships with one another. The logical hierarchy is a data model, while the visual hierarchy is a graphical representation of a logical hierarchy. The visual hierarchy includes “fishbone” and “snowflake” layouts. The snowflake layout includes two fishbone layouts. A fishbone layout displays a logical hierarchy as a stylized tree in a plane. The fishbone layout, at a moment in time, shares some visual attributes with an Ishikawa diagram. As will be explained in more detail, however, the fishbone layout differs from Ishikawa diagrams in that a fishbone layout can vary over time as it is dynamically updated and is interactive with a user, among other differences. Also, a fishbone layout can be moved between display modes when its associated logical hierarchy contains too many members for the fishbone layout to represent in a given display area.

The hierarchical status display process can change the visual hierarchy in response to a change in the status of a resource monitored by network monitoring software. The hierarchical status display process renders the visual hierarchy in a display window. A user can interact with the display window to get more information about a resource, including a menu of options tailored to each resource. The options include analysis tools that the user can launch to examine a resource in detail. The analysis tools are external to the application that renders the display. In general, the visual hierarchy displays information at a summary level, while interactive options allow a user to get information at a detail level.

The resources are entities monitored by network management software. Resources include hardware, applications, services, business processes, organizational structures (such as business units within an enterprise, or departments within a university), paths within a network, and other network resources. Hardware resources include clients, servers, routers, switches, and NIC's, as well as peripheral devices (such as disk drives) and networked devices (such as printers and networked storage). Both individual network resources and collections of such resources can be resources. For resources that include collections of resources, the resources may be distributed or heterogeneous or both. The collections may include other collections.

FIG. 1Ashows a hierarchical status display process20including a client application22that accesses a web server60via an HTTP interface601. Client application22retrieves information about a logical hierarchy30stored in a views repository75. Client application22uses a hierarchy representation40to render logical hierarchy30graphically in a display window50to a user23.

Client application22polls web server60for information from a state repository70and views repository75. State repository70is maintained by a monitoring system80, which collects information about the states of resources and places it in repository70.

Display window50is interactive, i.e., responsive to input from user23. Display window50allows user23to apply analysis tools90to resources described in logical hierarchy30.

Computing Platform

Referring toFIG. 1B, hierarchical status display process20contains computer instructions and runs on an operating system631on a computing platform63. For simplicity,FIG. 1Bshows hierarchical status display process20interacting with one operating system631and related hardware, when in fact component processes of hierarchical status display process20may be distributed over multiple computing platforms63interconnected by network connections638.

Operating system631is a set of computer instructions resident in either a main memory634or a non-volatile storage device637or both. A processor633can access main memory634and non-volatile storage device637to execute the computer instructions for operating system631and hierarchical status display process20.

User23interacts with the computing platform via one or more input devices632and one or more output devices636including a visual display639. Possible input devices632include a keyboard, a microphone, a touch-sensitive screen, and a pointing device such as a mouse. Possible output devices636in addition to visual display639include a speaker and a printer. Usually, visual display639can display variations of color (i.e., is not a monochrome display).

Non-volatile storage device637includes a computer-writable and computer-readable medium, such as a disk drive. A bus635interconnects the processor633, input device632, output device636, storage device637, main memory634, and optional network connection638. Network connection638includes a device and software driver to provide network functionality, such as an Ethernet card configured to run TCP/IP, for example.

Client application22is written in the Java programming language. Some components of client application22may be written in other languages such as C++, compiled into lower-level code (such as machine code), and incorporated into the main body of software code via component interoperability standards. In the Microsoft Windows computing platform, for example, component interoperability standards include COM (Common Object Model) and OLE (Object Linking and Embedding).

Monitoring System and Resources

Referring toFIG. 4A, monitoring system80monitors resources24in a monitored environment25. The configuration of monitoring system80, including decisions about which resources24to monitor, are beyond the scope of the invention and will not be detailed here. Monitoring system80includes network-monitoring software. A commercial product that is an example of monitoring system80is LiveExceptions, sold by Concord Communications, Inc., of Marlboro, Mass., USA.

Conceptually, resource24is a placeholder for a wide range of things: usually, it performs a function related to networking in monitored environment25or is involved in a dependency relationship78with another resource24. The function itself need not be directly related to networking: for instance, a disk drive in a server may be consider a networked resource24, by virtue of the server's networked role. Another way of defining resource24is in terms of how it is used within hierarchical status display process20: resource24is anything monitored by monitoring system80. For example, resource24can represent a single physical unit to be monitored, such as a personal computer, server, router, switch, link, L3route, or a response path. However, resource24need not be atomic: it can represent a group of resources24, groups within a group, and so forth. Resource24can be a concept: for instance, a business process, or an organizational unit such as a department or project. Resource24can also be a logical construct such as a level-three network route. Importantly, resource24can also be software, such as an application or service. Resource24can be distributed or localized to one computer.

Properties of resource24include a name, a role within a system or domain, and properties appropriate to its context. Each property of resource24has a current state. A resource also has at least one status, which, at a given point in time, has a single value derived from the current states. The range of values for resource24status usually includes values for trouble-free, warning, and error.

For example, there might be a resource named “east campus router”. It has a role of being a router within a network. It has properties appropriate to being a router: for instance, system components such as a CPU, two network interfaces, and at least one IP address (assuming the network uses the IP protocol). The network interfaces may have operational states including “ideal”, “congested”, and “failed”.

Referring toFIG. 4B, resource24is represented in views repository75by a resource representation795. Resource representation795is a software object that refers to resource24and abstracts properties of resource24for manipulation in a computing environment. The correlation between resource representation795and its resource24, therefore, is conceptually very tight.

A resource reference796describes resource24. A property797of resource representation795represents a property on the corresponding resource24. Property797has a property state798. Note that monitored environment25may contain, as shown inFIG. 4B, resource24cnot referenced by any resource reference796. However, every resource reference796describes some resource24.

Resource Profiles

A given resource24may play a variety of roles in monitored environment25. For instance, a given server can support multiple applications and services. Sometimes a problem for resource24in one role is not a problem for that same resource24in another of its roles. For instance, a router experiencing a certain level of congestion may cause a problem in a “realtime” context, such as for an application like videoconferencing that depends on router to provide network service supporting realtime traffic. At the same time, in an “email” context, an email application may depend on the same router, but may have a much higher threshold before a congestion level would create a problem.

In general, a resource profile77offers a way of representing resource24in a context. A given resource24may therefore be represented in more than one context.

Referring toFIG. 5A, resource profile77pairs resource representation795with a status value775. This pairing is encoded by a reference770. Status value775derives from states798of the associated resource representation795; the derivation is given by a status metric776. Since status metric776determines the states that status value775represents and how their values are weighed, status metric776can represent a context through its choice of states798and through the outputs that it assigns. For instance, inFIG. 5A, resource profiles77aand77brepresent two different contexts (“Context A” and “Context B”, respectively) for one resource representation795. Also note that distinct profiles77can draw on the same state798for use by status metric776. In the example shown, resource profile77adraws on states798iand798ii, while resource profile77bdraws on states798iand798iii, i.e., state798iis common to both.

Resource profile77can ignore categories of exceptions that would otherwise affect its status value775by encoding criteria for these categories in an event filter771.

Resource profile77can specify a drilldown list778of analysis functions799exposed by an analysis tool90. Drilldown list778will be presented to user23during certain interactions with a rendering of resource profile77in visual hierarchy40. (See the section “Fishbone interactivity”.) Drilldown list778provides a way of tailoring the analysis methods available to user23to each resource profile77.

A commercial product that offers resource profiles77is NetworkHealth, sold by Concord Communications, Inc., of Marlboro, Mass., USA.

Dependency Relationships

Referring toFIG. 5B, dependency relationship78represents a condition by which events in one resource24(in this example, resource24b) can influence the status of another resource24a. Specifically, resource24bis represented by resource representation795b, which is referenced by resource profile77b. Likewise, resource24ais represented by resource representation795a, which is referenced by resource profile77a. Note the following use of terms. The “direction” of the consumer dependency relationship78is the opposite of the direction in which problems propagate: resource profile77a“depends on” or “is a consumer of” resource profile77b, while problems in resource24bpropagate toward (or impact) resource24a. From the other end's perspective on dependency relationship78, that is, for a provider dependency relationship78where resource profile77b“is a provider to” resource profile77a, the direction of dependency relationship78coincides with the direction in which problems propagate.

Recall that resource profile77represents resource24in light of a context. Dependency relationship78incorporates context by referencing resource profiles77rather than resource entities795.

The number of resource profiles77involved in a given dependency relationship78is called the “degree” of dependency relationship78. A relationship that involves just two resource profiles is called “binary”.FIG. 5Bshows an example binary dependency relationship78. Note that dependency relationships78of degree higher than two can be represented by a set of binary dependency relationships78, as follows. Choose a context that describes the degree-n relationship, make resource profile77for each resource24involved in that context, and add a binary dependency relationship78between each pair of resource profiles77to describe the interaction of the two resources24.

Consumer relationships and provider relationships are common in real world applications. They can model many relationships that one would intuitively describe with the phrases “includes in” or “depends on”. “Depends on” is obviously appropriate to dependency relationships78. “Includes in”, too, is often a good fit for dependency relationships78since a problem in a component often can propagate to the whole. For instance, if a server S depends on three hard drives C, D, and E, we can create resource profiles77for S, C, D, and E and three dependency relationships78: from S to C, D, and E, respectively. Likewise, if the accounting department A depends on two servers S and T, we can create additional resource profiles77for A and T along with two dependency relationships78: from A to S and T, respectively. Situations in which one resource24incorporates or aggregates several other resources24, while also depending on them, are quite important to users of network monitoring software.

An example of a non-binary dependency relationship78is a component of a distributed transaction or service involving three or more resources24.

Logical Hierarchy

Logical hierarchy30offers a tree-based data model describing a web of dependency relationships78between resource profiles77. Views repository75stores each logical hierarchy30in view record752, as shown inFIG. 8. Views repository75provides a central location from which more than one client application22can access the same logical hierarchy30simultaneously.

Logical Hierarchy Meaning

Broadly speaking, logical hierarchy30is a flexible structure (as will be described in more detail) for collecting resource profiles77and their relevant dependency relationships78under one or more conceptual frameworks. Because its flexibility allows a wide variety of designs, logical hierarchy30is susceptible to bad design. For instance, user23may perceive less meaning in an alphabetical organizing scheme than in an organizing scheme based on functional analysis. More subtly, a first user23may perceive less meaning in a functional analysis based on business processes than in a functional analysis based on network hardware. And, a second user23may disagree, perhaps because the second user23has a different role or objective within monitored environment25than the first user23. Techniques for shaping the meaning of logical hierarchy30to the requirements of users23, including the choice of resource profiles77and dependency relationships78to include in logical hierarchy30, are beyond the scope of the invention. Instead, this description assumes views repository75has been configured to contain logical hierarchies30useful to user23.

Logical hierarchy30often models some single aspect of monitored environment25for consideration by user23. Multiple logical hierarchies30can therefore be necessary to model all aspects of monitored environment25. Also, multiple logical hierarchies30can be provided to suit different users23.

Tree Basis

Logical hierarchy30draws on the prior art data model shown inFIG. 9Ato represent elements shown inFIG. 9Bin a tree-based structure. Each resource profile77corresponds to one node391, while each dependency relationship78corresponds to one edge396, such that edge396connects two nodes391only if its corresponding dependency relationship78connects the corresponding resource profiles77. Root node392is associated with one resource profile77at the “top” or “center” of the meaning represented by logical hierarchy30. Levels of logical hierarchy30correspond to tiers in tree39.

For example, by using its tree-based data model, logical hierarchy30can organize information into tiers, with parent-child relationships between entities of adjacent tiers. The parent-child relationships are based on dependency relationships78: for instance, parent resource profiles77can be dependent upon child resource profiles77, as with a corporation that depends upon business units, each of which depend upon data centers. Alternatively, parent resource profiles77can provide to multiple child resource profiles77, as with a server that provides multiple networked services, while each of the networked services (for instance, DNS, file sharing, and network security) provides its features to multiple software applications.

Recall fromFIG. 9Athat directed tree39has a path-uniqueness property. Uniqueness of path need not exist in the modeled world, i.e., monitored environment25. For instance, resource profiles77A, B, and C may be interrelated such that A relates to B, B to C, and C to A. In this case, the path from A to B may be either direct or via C. This would violate the path-uniqueness requirement of directed tree39. To deal with this, one can introduce a new resource profile77A′ as a duplicate of A, then use A′ to replace A in its direct relationship with C. A′ is a resource profile having the same resource as A, but with a context especially for C. The relationship that formerly joined C to A now joins C to A′. Thus, after the introduction of A′, all paths on A, B, C, and A′ are unique. One can apply this approach in general to eliminate any multiple in the graph.

In general, a given resource24may be represented in multiple places in logical hierarchy30, via multiple resource profiles77, each having its own context. Furthermore, the status of resource24may differ between the multiple resource profiles77, since each status is dependent upon the context represented by resource profile77. For instance, suppose a router supports traffic for two customers of a service provider, and that customer A has contracted for higher quality-of-service (QOS) than customer B. The router is a resource24that will be modeled by two resource profiles77, one for A and one for B. Certain congestion levels on the router may endanger the QOS of A without endangering B's lesser standard. Therefore, the resource profile77corresponding to the router in the context of customer A might be in a warning severity, even while the same resource24in another context (namely, B's context) would have a trouble-free severity.

Hierarchy of Dependant Profiles

FIG. 9Bshows logical hierarchy30including a resource profile77designated as the root profile32. For simplicity of explanation, this description andFIG. 9Buse example hierarchies having three levels, though more levels are possible. The example hierarchies are aggregation hierarchies, meaning that parents are collectives that aggregate their children. When using this three-level approach, the root is called the “group list”, level one contains “groups”, and level two contains “elements”. InFIG. 9B, root profile32represents the group list, group profile33represents a group, and element profile34represents an element on level two.

Example Sources of Logical Hiearchies

Note that several analysis techniques produce tree-based data models to model an environment such as monitored environment25. Logical hierarchy30supports such techniques via its tree-based data model. Examples include top-down analysis and bottom-up analysis: for instance, a top-down analysis could investigate how status changes propagate toward a given resource profile35, while a bottom-up analysis could investigate how status changes escalate from localized situations to wider scope. The particular analysis techniques to apply to monitored environment25, as well as the details of such techniques, are beyond the scope of the present invention. As a broad example, though, logical hierarchy30can support a model hierarchy produced by a top-down analysis of monitored environment25from the perspective of a single resource24, as follows. Given resource24, designate a corresponding resource profile77as root profile32. Use top-down analysis of monitored environment25to identify one or more resource profiles77that root profile32depends upon; designate these resource profiles77as group profiles33joined to root profile32by binary dependency relationships78. Repeat recursively to populate successive levels of logical hierarchy30tree.

Alarms

Monitoring system80associates alarm35with resource profile77. More specifically, as shown inFIG. 4Ausing dotted arrows, monitoring agent82detects event26for resource24. Event26can be a change in the state of one or more properties of resource24. Monitoring agent82informs monitoring server81of event26. Monitoring server81consults views repository75(not shown inFIG. 4A; seeFIG. 8) to find one or more resource profiles77representing resource24. Resource profile77(as shown inFIG. 5A) contains event filter771which may instruct monitoring server81to ignore event26; otherwise, monitoring server81can invoke the resource profile's77metric776to evaluate status value775. Monitoring system80is configured such that certain settings of evaluated status value775cause monitoring system80to create alarm35for resource profile77. In other words, certain designated settings of status value775have severity sufficient to create alarms35. Monitoring system80writes each alarm35to state file71corresponding to resource profile77that evaluated event26. Note that one event26may cause alarm35on more than one resource profile77. One event26may also cause more than one alarm35on a given resource profile77: for instance, a first alarm35may be designated to propagate differently than a second alarm35.

Alarm35includes a severity351, a grade352(which groups severity levels into broader categories such as failure versus warning), a text description353, and an active/inactive flag354.

Display

The next sections describe components and techniques of the visual display of logical hierarchies30.

Display Window

Display window50is presented to user23on output device636(shown inFIG. 1B), usually visual display639such as a CRT monitor or flat-panel display.FIG. 3Bshows that display window50contains certain GUI objects and techniques known in the art, including title bar511arranged along the top edge of display window50, menu bar512arranged immediately beneath title bar511, status bar513arranged along the bottom edge of display window50, and display panel515which occupies the remainder of display window50.

Title bar511contains text identifying client application22as the owner of display window50among the (possibly several) applications running on operating system631(shown inFIG. 1B). Title bar511provides other functions specific to operating system631. Usually the functions include the ability to relocate, resize, request the close of, or restore the size of, display window50.

Menu bar512is responsive to keystrokes and mouse actions by user23to select dropdown items519on a dropdown menu518on menu bar512. Dropdown items519of a menu518are hidden until user23interacts with the menu518. Usually some of the menus518and dropdown items519are dictated by a GUI standard of operating system631. For instance, a “File” menu518(shown inFIG. 6B) usually contains dropdown items519for opening and closing application files, as well as quitting client application22.

A second sort of menu, context menu514, is also hidden until user23positions the mouse pointer51over display panel515and right-clicks or performs some other designated action via input device632. (For instance, in Microsoft Windows there can be a dedicated key on the keyboard for the purpose of raising context menus514.) In this discussion, “right-click” shall refer to this action generically. The right-click causes context menu514to appear near the location of the mouse pointer51. Similar to a dropdown menu518, context menu514contains a list of drilldown items516for the user to select. The context menu514, however, is usually tailored to the current state of the application and to the location of the mouse pointer: hence the term “context”. Particularly, if the mouse pointer51is located over a rendering of resource24, the drilldown items516may be tailored to the identity of that resource24or resource profile77and its current state.

In some operating systems631, for instance Microsoft Windows, menu bar512or status bar513, or both, may be expandable, customizable, or hideable altogether. User interfaces employing title bars511, menu bars512, status bars513, central display panels515, and context menus514are known in the art. Such user interface elements, per se, are not central to this invention (although their specific content and the techniques that provide it, including the content of dropdown items519in menu bars512and drilldown items516in context menus514, are central to the invention), so those GUI techniques will not be further explained here.

One form of hierarchical status display is fishbone layout45(FIG. 2A), which displays logical hierarchy30as a stylized tree in a plane. Another form of hierarchical status display is snowflake46, as will be explained later. Fishbone layout45is so named because it is evocative of the backbone of a fish. Fishbone layout45, at a moment in time, shares some visual attributes with an Ishikawa diagram, which is a layout in the field of manufacturing quality control. Fishbone layout45, however, can be dynamically updated and is interactive, among other differences from Ishikawa diagrams.

Fishbone layout45shows a tree having root icon/label421, which is associated with root profile32in logical hierarchy30. Fishbone layout45also features root line422running substantially the length of fishbone layout45. Usually, root line422approximately divides fishbone layout45into halves.

In general, the rendering of each resource profile77includes a line anchored by a label or icon, or both (or perhaps none if the rendering engine is constrained for space, as will be explained later). The term “icon/label” refers to this possible icon or label or pair.

A resource profile77in a direct dependency relationship78with the root resource profile77is a group; each group has its own icon/label424, together with its own line423connecting the group icon/label424to root line422. A group line423(and in general the line of any non-root resource profile77) is referred to as a “spine”. In general, for a level “n” resource profile77directly related to a level “n−1” resource profile77, the level “n” resource displays as an icon/label and a line connecting the icon/label to the line for level “n−1”, producing a fanned-out tree. Spines can have arrowheads at one end to indicate directionality from or toward root profile32with regard to dependency relationships78. The direction on a spine usually indicates a “provider” direction of dependency relationship78, though legend427may override that.

The spines that connect directly to root line422are angled relative to the root line by an angle434, usually (but not exclusively) in the range of 70–80 degrees. These spines to either side of root line422share substantially the same angle434relative to root line422, as shown inFIG. 2A. Thus, all sloped spines on a given side of root line422are substantially mutually parallel.

A recursive similarity renders subsequent levels of visual hierarchy40: spines that connect directly to the sloped spines are parallel to root line422, spines that connect directly to spines parallel to root line422are sloped, and so forth. Thus, all spines fall into three categories, members of each category being substantially mutually parallel. One category is for spines parallel to root line422(representing resource profiles77which are an even number of hierarchy levels removed from the root profile77). We shall call this the “even” group, since they correspond to resource profiles77in even-numbered levels of logical hierarchy30. (For these purposes, zero—the number of the root level—is considered an even number.) A second category contains spines not in the even group and rendered above root line422in display panel515; we shall call this the “upper” group. Spines in the upper group are either directly connected to the main line422(and thus at level one) or are an even number of hierarchy levels removed from such spines (and thus at an odd-numbered level). A third category includes spines not in the first two groups and rendered on the other side of root line422from the upper group; we shall call this the “lower” group. As with the upper group, spines in the lower group are either directly connected to root line422or are an even number of hierarchy levels removed from such spines.

Note that if root line422is vertical, and since no other spine is collinear with root line422, no spine is above it. In this case, the upper group can be the non-even spines to the right of root line422. As before, the lower group collects the uncollected spines on the other side of root line422from the upper group.

User testing indicates that the fishbone alignment scheme is a visually “clean” way of rendering logical hierarchy30as visual hierarchy40. Users23can generally perceive the approximate level of resource profile77within logical hierarchy30easily, especially when there are just three levels on display.

Modes

Fishbone layout45may be displayed in multiple modes. In this embodiment, the modes include a default mode42(shown inFIG. 2A) and a high-density mode43(shown inFIG. 2B). High-density mode43handles situations in which the number of elements to be displayed is too high for the default mode42to handle effectively with the current size of display panel515. The crossover point between modes varies, since it depends on the number of elements in the display, the degree (number of children) of the nodes, the size and resolution of the current display panel515, and possibly the rate of change of the membership of the hierarchy (since users23may consider it undesirable to see the display rearrange more frequently than a certain period), among other factors. For instance, the crossover point further depends on the density achievable in each mode, which depends on such choices as font and icon size as well as other choices to accommodate properties of the display device itself, such as poor contrast or low resolution. Broadly generalizing, though, a 1024 pixel by 768 pixel window can usually yield a crossover point of around 700 to 1000 fishbone components.

Both the default mode42and high-density mode43share most objects and behaviors. The visual conventions (such as layout, display behavior, coloring schemes, and so forth) can be different within each mode. In particular, high-density mode43usually represents an element resource profile77differently than the default mode42does. The default mode42(shown inFIG. 2A) usually uses element icon/labels426, element lines425, and a region for element separation429. Element separation429allows the background of display panel515to be perceived between one element rendering and its neighbor. High-density mode43(shown inFIG. 2B), however, represents an element resource profile77with a dense parallelogram430having one side touching the group line423and possibly having other sides touching neighboring dense parallelograms430. Neighboring dense parallelograms430can be visually differentiated from one another by a variety of graphical techniques, such as alternating luminescence, but as density increases (and the parallelograms430necessarily become smaller) it becomes hard for human vision to distinguish between contrasts (in color, luminescence, texture, etc.) over small areas, especially given the limited resolution of most visual displays639. Mouseover techniques (as will be explained) can be used to allow user23to distinguish tightly packed parallelograms430.

Spines in fishbone layout45are layered at least two layers deep (i.e. group line422and a group line423) and usually three layers deep. There is no upper limit inherent within the technique, though there are practical limits for a given visual display device639due to finite size and resolution. Also, there can be limits to the amount of information the typical user can easily comprehend visually. Preliminary user testing indicates that most users are comfortable with the information presented by a three-tiered hierarchy at with a visual display device639capable of 1024 pixels by 768 pixels.

Fishbone layout45also features a legend427having a legend entry435. A legend entry435includes a legend graphic436and a legend explanation437. The legend graphic436is a graphic exemplifying a graphical convention used in fishbone layout45. The legend explanation437contains text that explains the intended meaning of the graphical convention.

Fishbone Visual Conventions

This section describes some of the conventions that affect the visual appearance of fishbone layout45. Other conventions are described elsewhere, including those relevant to layout or interactivity.

Display panel515has a black background over which renderings are luminescent, which gives good visual contrast and prominence to the renderings. Typically, renderings are not shown at their maximum luminescence by default, so that luminescence may be increased for special emphasis when needed.

Arrowheads on spines indicate directionality of dependency relationships78.

When layout density permits, topological connectivity (renderings that touch or overlap) is meaningful within the fishbone. By default, renderings are spaced enough apart within display panel515, using separations429, to allow background to appear between them. The only exception (while this default setting is in force) occurs if there is a direct dependency relationship78between the components that the renderings represent. Thus, connectivity indicates dependency relationship78. This visual convention is the default in default mode42.

The display device639is capable of displaying color. Fishbone layout45uses color in its display, but the colorings are designed, both individually and in comparison to one another, to be perceivable by users23who are red-green colorblind. Colorings are also designed to work acceptably with monochrome displays639.

Fishbone Layout Techniques

This section describes techniques that govern how components of the fishbone are laid out in display panel515.

By default, the root icon/label321is located near the middle of the right border of display panel515, but any location in display panel515is permissible. Note that in the absence of other items to render in display panel515, root icon/label421located near a border of the display panel will maximize the space available to for the rest of the fishbone.

Root line422is horizontal by default, but any angle434is permissible. For instance, as will be explained regarding snowflake layout46, more than two fishbone layouts45may share a root profile32. In this case, the first two fishbone layouts45to be rendered can have horizontal root lines422, but subsequent fishbone layouts45might have non-horizontal root lines422. The slope of spines is usually in the range of 70 to 80 degrees relative to root line422; spines to either side of root line422share the same angle434relative to root line422, as shown inFIG. 2AandFIG. 2B.

The principle that spines are straight and substantially mutually parallel with similar spines has a special exception for branches of a spine. Spines may “branch” or “wrap” to overcome limits of a finite display region. For instance, there may be so many child resource profiles77to connect to a given parent that the parent's spine cannot continue in the same linear direction within display panel515. Thus, a spine (such as a branched group line428, shown inFIG. 2A) may branch into multiple sub-segments446that are substantially mutually parallel except for additional sub-segments (branch connectors445) needed to keep the spine topologically connected. The multiple parallel sub-segments446can be oriented so that the spine uses less space along a given linear direction than a single segment would use. Branching therefore allows viewer64(shown inFIG. 8, as will be explained) to adapt the fanned-out fishbone layout45to finite bounds for display.

The algorithm for wrapping a spine aims to use the minimum number of branches. It assumes that viewer64has already detected the need to wrap. A “length-first” approach leaves room for the branch connectors445but then fills (i.e., renders resource profiles77from the branch's subtree, connecting them to a sub-segment446) the first sub-segment446to its farthest permissible length before beginning to fill the additional sub-segments446.

By default, components within a hierarchy tier are laid out alphabetically by name, starting nearest root icon/label421and moving away. (Other static schemes are possible and can be specified in layout preferences754of view record752, shown inFIG. 8, paired with logical hierarchy30. For instance, one may designate regions of display panel515relative to fishbone layout45in which to layout similar level-one spines: a region for servers, another for routers, a third for services, and a fourth for applications.) Standardizing a layout for each fishbone layout45allows user23to develop familiarity with that fishbone layout45, forming a positional memory for its components. Familiarity can speed the communication of information to user23. For instance, familiarity can eliminate the need for user23to investigate a component to learn the identity or context stored in its resource profile77, allowing user23to interpret a change in the component's rendering more quickly. While it is possible to sort fishbones45dynamically (for instance, sorting by severity of the current status value775of each resource profile77), in this embodiment, the default scheme is to sort on a non-dynamic property.

Display panel515is finite, so there is not always room to render every element, regardless of mode. In this case, when room runs out, an ellipsis or other truncation symbol433is displayed, as shown inFIG. 2A.

By default, coloring schemes for severity are retrieved from (or, when designing logical hierarchy30, chosen to suit) the monitoring engine80which may have global coloring schemes, or schemes designed for particular uses. Matching the coloring schemes makes the integration of the status display with the monitoring engine80more seamless, especially for users23who are experienced with the monitoring engine80, as is often the case.

In general, coloring schemes for severity include mappings that associate a given severity with a color. The given severity has a ranking on a severity scale. A severity scale provides a full ordering on severities that allows severities to be compared: for any two severities appropriate to the scale, their severity rankings will indicate whether the first is of lesser, equal, or greater rank than the second. Shorthand for explicitly saying “severity rank” is simply to say that one severity is less than, equal to, or greater than another. The colors in the coloring scheme for severity are typically chosen so as to be highly visually distinct from one another, to minimize ambiguity. Also, colors chosen to represent high severities are often more prominent (such as having stronger saturation, or are displayed with more luminescence) than color representing lesser severities. A common example of a rudimentary color scheme is green for default or problem-free severities, yellow for warning severities, and red for failure or urgent severities, with gray indicating absence of severity data or off-line.

Icons (in an icon/label) can be inflected by size, color, luminescence, shape, or animation such as blinking or quivering. Blinking is usually done only for a short period of time before returning to a non-blinking rendering: for instance, blinking to indicate a recent change of status, then stopping the blinking once the change is no longer recent.

This section describes ways in which fishbone layout45can respond to user actions.

A left-click on a group line423or element line425selects it. Selection is indicated visually by highlighting the spine. Selecting a group icon/label highlights the whole subtree for that group. Selecting the root icon/label highlights the entire hierarchy tree.

A mouseover event occurs for a rendering of resource profile77when user23causes the mouse pointer51(shown inFIG. 3B) to pass over. During a mouseover of an element line425or element icon/label426, the display process enlarges the font of the label and the size of the icon in the element icon/label426, in part to make icon/label426easier to click on. The display process can also enlarge element line425, especially when fishbone layout45is in high-density mode43, since high-density mode43sometimes omits element icon/labels426to save space. Enlarging the target of a potential click makes it easier to see what the mouse would select if user23were to click. Even if user23does not plan to click, enlarging also makes it easier for user23to see the color and other traits that identify the target.

A sustained mouseover of any rendering of resource profile77opens a mouseover dialog517. The mouseover is “sustained” if it lasts longer than a small, predetermined interval (usually on the order of a second, as opposed to, for instance, a millisecond). The mouseover dialog517contains text information about resource profile77, including the resource name, its status, and aggregate information about events affecting it. For instance, the mouseover dialog517may cite:Router13Congested11 alarms over the last 30 minutes

Referring now toFIG. 2A, in the legend427, legend graphic436in a legend entry435exemplifies a graphical convention used in fishbone layout45. One use of a legend entry435is to explain a coloring or other graphical convention that represents a severity level. A sustained left-click on a legend graphic436in such a legend entry435dims the renderings of all spines except those of resource profiles77whose status value775corresponds to the severity level. This dimming emphasizes the rendering of the corresponding resource profiles.

A right-click on the rendering of resource profile77in fishbone layout45raises context menu514, shown inFIG. 3B, containing drilldown items516specified by drilldown list778of resource profile77. Drilldown items516can open reports in the analysis tools software90(shown inFIG. 1A) specific to resource profile77. Drilldown items516can also include navigation options, such as opening fishbone layout45in a separate display window50, or re-centering the current fishbone layout45to use the selected resource profile77as root. Another navigation option is to view the children of the selected resource profile77, especially since for elements at the lowest displayed level of visual hierarchy40, there may be additional levels of logical hierarchy30not currently shown in fishbone layout45. Viewing the children may be done in a separate display window50, or via a hierarchical menu520(one which opens a submenu of context menu514specific to a given drilldown item516, as shown inFIG. 3B). Hierarchical menus520may contain drilldown items516that present further hierarchical menus520.

Fishbone layout45can raise a provoked redraw event, as will be explained in more detail. A provoked redraw event causes the rendering engine to redraw the display panel. A provoked redraw event occurs during the initialization of client application22, after a resizing of display window50, or when client application22detects that logical hierarchy30has be redefined, necessitating a change in visual hierarchy40. If the redrawn fishbone layout45cannot fit in the current display panel515, user23is presented with a warning dialog about the truncation.

When more than one display window50is open, the frontmost display window50is called “current”.

Menu Bar

Menu bar512commands include the following dropdown menus518and dropdown items519, as shown inFIG. 6B.

The “File” dropdown menu518includes dropdown items519for “New”, “Open”, “Delete”, “Connect to server”, “New window”, “Recent list”, and “Exit”. “New” allows user23to select logical hierarchy30to open in a new display window50, while “Open” allows the same selection but uses an existing display window50. “Delete” allows the user to close such display window50. “Connect to server” opens a login dialog (not shown) so that user23may present credentials to web server60. “New window” opens a redundant version of the current display window50. “Recent list” is a flexible list of several dropdown items519, each dropdown item519corresponding to a recently used logical hierarchy30. Menu separators521can bracket the “Recent list”. “Exit” starts a process to close client application22.

The “View” dropdown menu518offers dropdown items519affecting display, including dropdown items519for changing the current display window50.

The “Run” dropdown menu518offers dropdown items519related to analysis software90. The dropdown items519include an item that opens a snowflake diagram46of the currently-selected resource profile77. The dropdown items519also include: performance reports, fault management reports (such as a list of all the alarms for the currently-selected resource profile77), reports on the configuration of the resource24associated with resource profile77, and external analysis tools90such as (but not limited to) ping, telnet, or management systems for the resource24. Additionally, the user23can extend the list of analysis tools90. A dropdown item519, in its interaction with analysis tools90, can pass information about the resource profile77and resource24. Examples of this information include name of the resource profile77, its network address, and so forth.

The “Help” dropdown menu518follows interface standards for operating system631on which client application22is running, e.g., Windows or Unix. For instance, for Microsoft Windows, the “Help” dropdown menu518includes items for “intro”, “using”, and “about”.

Snowflake

Referring toFIG. 3A, snowflake46is another form of display for visual hierarchy40. Snowflake46displays root icon/label442(representing root profile32) at the top of multiple simultaneous logical hierarchies30, each such logical hierarchy30shown as fishbone layout45sharing the root icon/label442. Note that each fishbone layout45may have its own rendering conventions as expressed in the associated view record752. For example, as shown inFIG. 3A, a first fishbone layout45ais rendered in default mode42while a second fishbone layout45bis rendered in dense mode43.

Snowflake layout46can display both consumer and provider dependency relationships78simultaneously. In particular, snowflake layout46can display root profile32both in terms of resource profiles77it consumes and provides. In the example ofFIG. 3A, snowflake layout46includes left fishbone layout45aarrayed to the left of root icon/label442and right fishbone layout45barrayed to the right. The left fishbone layout45adisplays resource profiles77consumed by root profile32. A right fishbone layout45bdisplays resource profiles77consuming root profile32. In this case, fishbone layout45acan be labeled “causes” and45b“effects”. Snowflake46, in this configuration, graphically displays two trees of dependency relationships78between resource profiles77, with root profile32positioned on a critical path for indirect dependency relationships78between any resource profile77in the “cause” fishbone layout45aand resource profiles77in the “effect” fishbone layout45b. By viewing snowflake layout46, user23can quickly identify the probable causes of a problem by inspecting the cause fishbone layout45a. User23can also identify the potential impacts of a problem by inspecting the effect fishbone layout45b, for instance so user23can fix the most important problem first.

Although not shown inFIG. 3A, snowflake layout46can include third and subsequent fishbone layouts45, possibly with non-horizontal root lines422.

Client Application

This section describes the software code of client application22. In general, it covers the main features of: presenting to the user a GUI that includes visual hierarchy40; responding to user actions; communicating with web server60to access status information and logical hierarchy30; and communicating with analysis tools90to enable drilldown lists778for resource profiles77in logical hierarchy30.

Client application22(shown inFIG. 7A) is a Java software application. The internal architecture of client application22draws on object-oriented design techniques recommended for Java applications. One of these techniques is known as the Model-Delegate architecture. The Model-Delegate architecture recommends that code for user interactions be functionally separated into a Model component for modeling the data structures that will be rendered, and a Delegate component for rendering the user interface and receiving user actions, as well as for controlling program flow and execution around the Model-Delegate architecture. As will be explained, the viewer model class69(shown inFIG. 7B) acts as a Model component, while the viewer class64acts as a Delegate component.

App Class

App class61, shown inFIG. 7B, is the top-level class in the client application. App class61is the first class to run when client application22is started. Initially after startup, app class61launches instances of other classes, including data manager65, synch manager66, and main UI class67.

Data Manager

Data manager65parses objects used for communicating with web server60to extract the information that may be multiplexed inside the object, i.e. the object may contain multiple pieces of information bound for different destinations in client application22. A primary function of data manager65is to notify synch browser manager68(as shown inFIG. 7B) of alarms35as they come in.

Synch Manager

Referring now toFIG. 8, synch manager66caches data locally in hash tables661for all current-displayed logical hierarchies30. The cached data includes logical hierarchies30themselves and other information from a view record752. Synch manager66communicates with web server60to ensure that the data in the cache stays current, i.e. synchronized with the authoritative version of the data residing in the state repository70and views repository75.

The hash tables661can store properties for each resource profile77including: database ID662identifying resource profile77in views repository75; name663; and a list of children and parents664, each representing resource profiles77that are in direct dependency relationships78with the specified resource profile77. By maintaining a local cache, synch manager66provides quick lookups of the data from a centralized place in client application22. For instance, synch manager66offers a quick way to get name663associated with database ID662. Name663is needed, for example, during a mouseover on element icon/label426(shown inFIG. 2A, for instance). The mouseover needs to raise a mouseover dialog517(shown inFIG. 3B, for instance) that includes the name of the element's resource profile77. Rendering object691(as will be explained) that represented resource profile77has only rendering database ID692. (Name663is not stored directly in rendering object691because name663can change; only the hash tables661have a local authoritative value for name663). Note also that name663is needed fairly quickly so that user23will not feel that client application22is unresponsive. The cache is a quick way to find name663, and it eliminates a query across the network to web server60.

Synch manager66also offers quick lookups of the children or parent of a resource via list of children and parents664.

Synch manager66is a singleton class within client application22, meaning that there is only ever one instance of synch manager66per instance of client application22. Thus, the synch manager22is unambiguous within client application22.

When logical hierarchy30is opened, synch manager66gathers all configuration data. Synch manager66performs the default ordering in which the profiles will be rendered (see the section on fishbone layout techniques) as needed, by alphabetizing resource profiles77by name.

After the initial configuration of logical hierarchy30is complete, synch manager66goes into a maintenance loop in which it uses a configuration poll668(shown inFIG. 8) to poll periodically web server60for configuration changes to logical hierarchies30. The configuration changes are retrieved incrementally. Configuration poll668does not need to retrieve the entire logical hierarchies30and related configuration information during every cycle. Instead, synch manager66retrieves complete information during initialization and subsequently uses configuration poll668to retrieve information that has changed since the last poll. The period of the configuration poll668is usually five minutes but can be adjusted by user23.

A connection poll669is independent poll of the configuration poll668. The connection poll669checks network communication with web server60to make sure the connection is still working. The connection poll669occurs frequently; every minute is the default.

When web server60responds to a configuration poll668with a change, the synch manager requests objects from web server60that describe the change.

Main UI

Main UI class67presents display window50that is the first interactive window presented by client application22at startup. When user23chooses dropdown item519(shown inFIG. 6B) such “New” or “Open” that opens logical hierarchy30for display, an instance of Main UI class67manages the displaying. As shown inFIG. 7B, Main UI class67launches objects including synch browser manager68, viewer model69, and viewer64.

Synch Browser Manager

As shown inFIG. 7B, synch browser manager68receives notification of alarms35from data manager65and maintains the alarms in events cache682. Recall that each instance of synch browser manager68is associated with an instance of Main UI class67, which is associated with a given logical hierarchy30. Each instance of synch browser manager68therefore launches filter server681, which can distinguish alarms35for its associated logical hierarchy30from alarms35for other logical hierarchies30.

When synch browser manager68gets alarm notifications from data manager65that have been passed through filter server681, synch browser manager68puts alarms35in the events cache682into a Java vector object and passes the vector object to viewer model69.

Viewer Model

Viewer model69is the Model component in the Model-Delegate architectural scheme. In its control capacity, viewer model69contains the logic that handles events raised by user23interacting with display window50. More specifically, the events are detected in viewer64but are passed to viewer model69for processing. In its model capacity, viewer model69contains rendering objects691(shown inFIG. 8) that represent resource profiles77to be displayed by viewer64; the purpose of rendering object691, therefore, is to contain information about the rendering, separate from the referenced resource profiles77. For instance, rendering object691for resource profile77contains information such as: rendering database ID692specifying its referenced resource profile77; severity level693; positional information694; and other attributes necessary to specify the rendering.

Rendering object691includes redraw-ready method696or other means of notifying viewer64that rendering object691is ready to be redrawn.

Viewer model69receives a batch of alarms35from synch browser manager68, packaged in a Java vector object. Viewer model69iterates over the vector to examine each alarm35. Viewer model69locates resource profile77associated with alarm35, using hash tables661in synch manager66. Viewer model69adds alarm35to alarm list773(also a vector object in Java) of resource profile77. After processing all alarms35, viewer model69uses metric776of resource profile77to recalculate status value775. Knowing status value775, viewer model69can then set severity level693that the relevant rendering object691should associate with resource profile77. Each such rendering object691uses its redraw-ready method696to notify viewer64that rendering object691is ready to be redrawn. Viewer model69also consults the cache of synch manager66to find associated resource profiles77, such as parents, for the profiles77that received alarms35. Viewer model69notifies these associated resource profiles77of alarms35; this allows an associated resource profile77to update its own status value775.

Viewer model69processes events raised by user interaction with renderings, including drill-downs and mouseovers. Viewer model69also processes application overrides. Drill-downs and mouseovers have already been explained. Application-wide alarm overrides697, shown inFIG. 8, allow client application22to suppress certain types of alarms35, overriding propagation rules772(shown inFIG. 5A) of resource profiles77. Specifically, in the present embodiment, the CPUs of routers are not rendered as; only the router itself is rendered. This feature is added for simplicity, to reduce the amount of information present to user23. It also allows room for more renderings of other objects. Since CPUs are not rendered, viewer model69aggregates router CPU alarms35onto the router itself. Options in drilldown list778of the router's resource profile77(shown inFIG. 5A) can still allow the user to get details about each router CPU.

Another override697occurs for RAS (remote access services) groups containing modems. In this case, no rendering is suppressed: both the modems and the RAS group are displayed. However, when alarm35occurs for a modem within a RAS group, viewer model69automatically associates alarm35with both the modem and its RAS group, regardless of the settings on the relevant resource profiles77.

Viewer model69receives notice of changes to the structure of logical hierarchy30. This causes viewer model69to ensure that associations of rendering objects691to resource profiles77are still accurate, and to create new rendering objects691for any new resource profiles77added by the changes. Viewer model69also instructs viewer64to redraw display panel515if any resource profiles77are added or deleted from logical hierarchy30.

Viewer

Viewer64is the Delegate component in the Model-Delegate architectural scheme. Viewer64presents a GUI to user23and responds to user actions in the GUI.

Viewer64renders logical hierarchy30as visual hierarchy40, such as fishbone layout45or snowflake46, laying out visual hierarchy40according to an order defined in logical hierarchy30. For this, viewer64uses a viewer layout class641, shown inFIG. 8. Viewer64positions branches (also known as spines) within display panel515, the branch having been rendered by a viewer branch class642. The viewer branch class642wraps, truncates, and may rescale the rendering of the branch.

Viewer64receives user interaction events and passes them to viewer model69. User interaction events include clicks, right-clicks, mouseovers, menu bar choices, and window re-sizings.

Client-side poller62communicates with web server60. Specifically, as shown inFIG. 8, client-side poller62uses HTTP serialization facility621for passing Java objects over a network; passes the serialized objects over the network via HTTP protocol601; and web server60uses HTTP serialization facility602to receive the objects. The process runs similarly in reverse, for communication from web server60to client-side poller62.

Client-side HTTP serialization facility621and server-side HTTP serialization facility602may multiplex multiple messages into one serialization object, for instance to reduce network traffic or communication overhead.

Server

Web server60presents an HTTP-based interface to client application22. Via the interface, web server60allows client application22to access the state repository70and views repository75. State files71in the state repository70contain information on alarms35and on configuration changes to logical hierarchies30. Logical hierarchies30are stored in view records752in views repository75, as shown inFIG. 8.

Web server60includes a CGI process in a web server. Web server60has default list603of logical hierarchies30to show, so that when user23of client application22chooses the “connect to server” dropdown item519from the “File” dropdown menu518(shown inFIG. 6B) and connects to web server60, the default list603can be presented to client application22.

State files71are maintained by monitor engine80. State file71contains information on states of resources24, including alarms35and configuration changes such as name changes. State file71also tracks changes to the structure of logical hierarchy30, including additions, deletions, and rearrangements (which include changes to relationships, and the designation of a different root profile32). State file71also indicates whether status information is flowing freely between resource24and its monitoring agent82, shown inFIG. 4A. Interruptions of status information include administrative suspension of the monitoring service (i.e., deliberate interruptions) and problems or failures in the communications channel (inadvertent interruptions).

Views repository75contains both resource entities795(shown inFIG. 4B) and their resource profiles77(shown inFIG. 5A). Views repository75also contains logical hierarchies30, which reference resource profiles77and dependency relationships78. Views repository75offers editing facilities by which the contents of views repository75may be created and maintained by user23. Views repository75may have additional features and purposes beyond those required by this embodiment. One example of a product that provides a view repository is NetworkHealth, sold by Concord Communications, Inc., of Marlboro, Mass., USA.

Monitor engine80writes and maintains the state files71, and allows web server60to search on behalf of client application22. Monitor engine80collects information for the state files71from monitoring agent82(shown inFIG. 4A), which are distributed agents that gather data on network resources24. Monitoring agent82collects data about resource24, puts the data in an ASCII file (not shown), and sends the file to monitoring server81. Monitoring agents82can stop sending data for a variety of reasons, including: intentional reasons (such as for maintenance, or if monitoring is only required during business hours) or a failure or crash. If monitoring agent82is working, it determines, based on resource profiles77, if a condition exists for which it should raise alarm35. When alarm35occurs, monitor engine80writes it to state file71corresponding to resource profile77.

Analysis Software

Analysis software90lets user23browse monitoring data gathered by monitor engine80. Analysis software90provides snapshots that detail individual events or aggregate them, such as by sort, sum, etc. Analysis software90also provides live dynamic reports and historical trends.

Examples of commercially available analysis software90include LiveExceptions, LiveTrend, and NetworkHealth. All three are products sold by Concord Communications, Inc., of Marlboro, Mass., USA

Alternate Embodiments

A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, monitor engine80need not collect data from monitoring agents82in order to maintain the state files71; it could have some other source of information. Client application22need not poll the web server80to download or “pull down” data; data could be sent from web server60using a “push” architecture, i.e., one in which data is sent to client application22without client application22having to poll for it. Display panel515containing fishbone layout45or snowflake46could allow scrolling rather than truncating the display; this could be accomplished via scroll bars. AlthoughFIG. 3Ashows snowflake layout46including two fishbone layouts45, snowflake layout46can contain more than two fishbone layouts45.

At least two approaches exist for wrapping a spine using the minimum number of branches. The length-first approach has been described. Another embodiment uses a “balancing” approach that distributes the sub-segments446, shown inFIG. 2A, so that each sub-segment446is roughly the same length.

As suits the underlying logical hierarchy30, spines within a fishbone layout45may be uniformly directed toward root icon/label421, may be uniformly directed away from root icon/label421, or may be arranged with a variety of directions within a given fishbone layout45, with respect to root icon/label421.

In the described embodiment, client application22is written in the Java programming language, in part because Java offers portability of applications onto a wide range of operating systems and computing platforms. However, other programming languages could be used instead of Java.