Terminology and concepts
Service Impact and this document use the following terminology and concepts.
- dynamic service
- A Service Impact entity that is used to monitor the status of a service. A dynamic service has a name and attributes, and is defined by the 0 or more members (devices, components, component groups, logical nodes, organizing groups, or other dynamic services) that you add to its service model.
See also service.
- dynamic service context
- A dynamic service's context includes all nodes in the dynamic Service Impact graph and the set of that service’s context-specific policy configurations that are applied to nodes. These configurations override each node's global policy. The service context includes policies and rules that are specific to a dynamic service and global policies and rules that govern the operational decisions and actions on that service. For example, the conditions under which events propagate to eventually generate service events. An entity such as a device or component can participate as a node in multiple service contexts. When propagating an entity event, the rules and policy decisions being made can differ depending on each service context. For example, device D participates in service context X and Y. An entity event on D might propagate to generate a service X service event but not propagate in service Y’s context.
- dynamic Service Impact graph
- Visual display of all entities that directly or indirectly impact a service. It is the
combination of all service model members and each of their service model member impact
graphs. On the Resource Manager
SERVICES page, the Impact View provides a
visual representation of a Service Impact graph.
Each unique entity exists only once in a Service Impact graph, even if the entity affects other service model members. For example, a database and an application server might depend on the same file system. However, in each dynamic Service Impact graph, the file system exists only once.
- dynamic service model
- Sometimes shortened to service model, it defines the service model members
(devices, components, component groups, logical nodes, organizing groups, and other
dynamic services) that are manually associated with a dynamic service by using the
Member View on the Resource Manager
For each service model member, the set of installed ZenPack use domain knowledge to automatically identify dependencies for each member and recursively for each of the member’s dependent entities. For example, a ZenPack that manages an application server identifies that it depends on the Linux operating system. The Linux ZenPack identifies that the OS depends on file systems and a virtual machine, and that those entities depend on other entities an application server depends on the operating system, file systems, and virtual machine, and those members depend on other members, and so on until the entire impact graph for the service model member is modeled.
The set of impact graphs for all service model members is combined to generate the dynamic Service Impact graph. The Service Impact graph is displayed on the Impact View of the Resource Manager SERVICES page.
The service model and the generated Service Impact graph are different but related. You can manage the set of members in the service model. However, the dependencies and the Service Impact graph are managed by the ZenPacks that are specific to each entity.
- dynamic service model member
- Any Resource Manager entity that is part of a dynamic Service Impact graph. An entity can be a device, component, component group, logical node, organizing group, or another dynamic service.
See also node.
- entity event
- Any event that is related to a Resource Manager entity and displayed on the EVENTS page.
- entity impact graph
- The set of infrastructure entities that impact another entity's performance and availability. For each infrastructure entity, the graph includes their impact dependency entities and so on. Resource Manager internal processing automatically generates and maintains entity impact graphs. You cannot manually define or adjust impact graphs. However, you can manage the impact policy gateway rules for any node both globally and in individual dynamic service contexts.
- Sometimes shortened to impact graph.
- impact chain
- See service event impact chain.
- Any entity and its position, dependencies, and entities that depend on it within a Service Impact graph, including the dynamic service context itself, service model members, and member impact graph infrastructure entities.
- root cause analysis (RCA)
- See service event root cause analysis.
- Any business activity or interface that is provided to users to accomplish a goal. Examples include systems that represent specific functions like payroll processing, a customer relationship management (CRM) tool, departments in a company, such as Finance or Marketing, and a company website. These logical entities can be represented as dynamic services by Service Impact in Resource Manager.
- service event
- A Service Impact-created event against a dynamic service. They are created in reaction to the propagation of one or more availability or performance entity events through nodes in the Service Impact graph. Service events contain a list of all impact chains and the relative probability of being the root cause.
- service event impact chain
- The propagation path from the entity that had an event through the Service Impact graph, applying node impact propagation policy gateways, until it reaches the dynamic service context node. The impact chain is generated for each originating entity event and displayed in the details of a service event.
- service event root cause analysis
- Displayed in the details for each service event to show the list of originating entity events and their impact chains that resulted in an impact to the dynamic service. Each event has an associated confidence value to help you identify the most likely root cause of the service problem.
- service model
- See dynamic service model.
- Service Impact graph
- The impact graph for an individual service model member.
- targeted graph update
- When Service Impact receives information about a device that is needed for an event, it targets modeling of just the device's subgraphs. To allow the modeling workflow to complete, a "placeholder" is immediately created. This process enables Service Impact graphs to be quickly refreshed without waiting for remodeling of all Service Impact graphs.
- The visual representation of any entity or node that participates in a Service Impact graph. The tile presents a node's status and other details and actions.