Service models, nodes, and graphs

With Service Impact, service modeling is simple. In your service model, you only define the main members of the service infrastructure, such as an application server and a database server. You do not need to specify or even be aware of the infrastructure entities on which the service model members depend.

Resource Manager automatically discovers and actively maintains the remaining infrastructure entities, such as hosts, operating systems, storage, network, compute, and other dependencies. In cloud and converged infrastructure environments, dependencies can be very complex and highly dynamic.

In the following figure, the top node of the graph is a the service context (root) node, which represents a dynamic service that you create. The second tier contains the child nodes of the root node, which represent the service model members that you identify when you define a dynamic service. In tiers three to n are the service model member's descendant nodes, the supporting infrastructure entities that are automatically discovered and maintained.

Service model members can be devices, components, component groups, logical nodes, organizing groups, or even other dynamic services, such as Impactor_d78 in the figure.
  • Device nodes represent resources that are monitored by Resource Manager, such as a Linux server. Additionally, ZenPacks that model a device can extend the model to include other members. (For more information about Service Impact ZenPacks, contact Zenoss Support.)
  • Component nodes represent resources that are monitored by Resource Manager. Components and component groups usually represent device entities, such as an Ethernet port.
  • Logical nodes are customizable and serve as filters against Resource Manager or external event sources. For events that match the logical node filter, the logical node identifies the state as a "placeholder" for the semantic meaning that is derived from the event filter definition. For example, events from an external application performance management (APM) source might be filtered to match events with a transaction that represents the health of the service. If events occur for that transaction, the logical node represents that negative state in the dynamic Service Impact graph, and propagates the impact as if the logical node were a device.
  • Organizing group nodes represent the current definition of an organizing group's devices and all child organizing group hierarchies. For more information about organizing groups, see Organizers and organizing groups.
Service models can consist of a single monitored resource and its child dependencies. In the following example, the top node, CRM, is the dynamic service. The second node, CRM-App, is a service model member. The third tier, (/dev and /dev) are descendents of the CRM-App node.
Figure 2. Service model: Single monitored resource Single monitored resource and its child dependencies

Service models can consist of multiple service models that are connected in a hierarchy to show their inter-dependencies. In the following example, the top tier, Network, and the second tier, WWW and CRM Netw nodes, are all dynamic services.

Figure 3. Service model: Hierarchy of service models

A node can be used in multiple dynamic service contexts as a service model member or as an infrastructure entity node to other service model members. For example, network-related nodes, such as switches or routers, are usually shared and appear in multiple service models in the service model hierarchy. In the following example, the node example is shared by txrt12 and txrt23.

Figure 4. Dynamic service context: Shared nodes

A node can also exist as both a parent and a child within the same service model, creating a cyclic dependency. In the following example, node A is both a parent and a child in the service model, as indicated by the lighter arrow on the right.

Figure 5. Node with cyclic dependency