• Loading...
This documentation refers to a previously released version of BMC Atrium Discovery (other versions).

Glossary

Skip to end of metadata
Go to start of metadata
Space Search

Searching TWF 7.2

Table of Contents

This section provides a glossary of terms.

Data Aging

Discovered data is regarded as valid at the time of its last successful scan. The nature of IT infrastructure means that frequent, minor changes to configurations, hosts, and software are common. Consequently, discovered data can be regarded as becoming less current with the passing of time. In Tideway Foundation when data passes a certain configurable aging threshold, it is destroyed.

Datastore

All data used by the Foundation system is held in an object database. The datastore treats data as a set of objects and the relationships between them.

Directly Discovered Data

Data that the Discovery Engine has discovered; it has not undergone any processing beyond simple parsing. Everything that the Discovery Engine finds that may be of interest is stored, regardless of whether it is understood or not. It is stored in a structured form that can be queried and reported on, making it easy to construct certain kinds of discovery reports, and aids in developing new patterns.

Discovery

The part of the Foundation system that communicates with host systems, and obtains information from them. Discovery is driven by Reasoning which infers detailed information about hosts and programs and populates the datastore. See also Reasoning Engine.

Discovery Endpoint

A Discovery Endpoint is the endpoint of a single Discovery Access. Currently this is the IP address of the discovery target.

Discovery Run

A Discovery Run is a scan of one or more Discovery Endpoints, specified as an IP address or addresses or ranges which are scanned as an entity. For each Discovery Run, a Discovery Run Node is created which records information such as the user who started the run, the start and end time, and so on.

Event

The Rules Engine (ECA Engine) executes rules in response to Events.

Host

A node within the model which represents a physical or virtual computer system including information about its operating system and its physical or virtual hardware. A host is sometimes referred to as an OSI (Operating System Instance). See Host Node.

ID

The ID of a node (or Node ID) is a unique identifier for the node itself. If the node corresponding to an entity is destroyed, and a new node is subsequently created for it, the new node will have a different ID, but will have the same key.

Inferencing

This is the act of drawing conclusions based on other data.

Key

The key of a node is a unique identifier for the entity that the node represents. However, the key of a node is persistent unlike the node ID.

Kind

The type of a node, such as Host, Application Version or Person. Also referred to as Node Kind.

Lifecycle

The lifecycle of an entity describes the conditions under which it comes into existence, and the conditions under which it ceases to exist. For Nodes in the Foundation model, the lifecycle stages are:

  • Current – The lifecycle stage used to describe nodes which exist in your model. Foundation has evidence that they currently exist in your environment.
  • Aging – The lifecycle stage used to describe nodes which also exist in your model. However, these nodes represent entities that Foundation has not seen in a certain period of time and has chosen to 'age out' of the model. Note that not all entities that Foundation fails to see evidence for after a certain period of time are aged.
  • Destroyed – The lifecycle stage used to describe nodes which have been specifically marked as destroyed. These nodes are 'destroyed', however, they remain in the model.
  • Purged – The lifecycle stage used to describe destroyed nodes which have been specifically 'purged' from the model. Purging a node means that it no longer exists in the model and has been actually removed from the datastore.
Logical host

A hardware or software host that is contained in a virtual machine (software), a collaborating host in a cluster (hardware) or a blade in a blade server (hardware).

Node

A Node is an object in the Foundation datastore, which represents an entity in the environment. Nodes have a kind, such as 'Host', and a number of named attributes. Nodes can be connected to other Nodes via Relationships. Most Node kinds have a 'key' which uniquely identifies the entity in the environment.

Node ID

See ID.

Node Kind

The type of a node, such as Host or Software Instance. The default set of nodes and their associated attributes and relationships are defined in the Foundation taxonomy.

Ontology

Tideway's Knowledge Library of hardware and software products, vendors, technologies, infrastructure, and so forth.

Pattern

Patterns are written in the Tideway Pattern Language (TPL). Patterns are responsible for creating and maintaining the model. Each pattern in TPL has a corresponding Pattern node within the model, which is related to the nodes that the pattern is maintaining. Patterns are used to extend the functionality of the reasoning engine.

Physical Device

Physical devices are containers for logical hosts such as the backplane of Sun Microsystems "Blade" Servers. They do not represent individual hosts on the network.

Provenance

Meta-information describing how inferred information came to exist. It is generated as Reasoning builds and maintains the model. Provenance information is stored as relationships in the model.

Reasoning Engine

The Reasoning Engine is an event based engine which orchestrates and drives the population of the different parts of the data model through execution of a series of rules that make up the core functionality of the product. It is extensible through the use of patterns. See also

Relationship

The way in which objects are associated with each other. A Relationship is stored in the datastore. Relationships are non-directional, and are defined by the roles played by each object. They are expressed in the following format:
Node:Role:RelationshipLink:Role:Node

Relationship Link

The link between two roles in a Relationship.

Removal

The concept of taking data out of the model using one or more of the Tideway Foundation lifecycle methodologies (Aging, Destroyed or Purged). Removal is the collective term used in this document.

Role

A node with a relationship to another node acts in a Role within the relationship, which indicates which end of the relationship it is. For example, in a 'Dependency' relationship, one node has the Role 'Dependant' and the other has the Role 'DependedUpon'.

Rules Engine

This is another term used to describe the reasoning engine. The Rules Engine processes the rules that are generated from Patterns, in order to maintain the model. The Rules Engine is an Event Condition Action (ECA) engine.

Rules

Rules are small fragments of executable code that run within the Rules Engine. Rules are generated from Patterns when they are activated. Other core rules are distributed with Tideway Foundation.

Session Establishment Duration

The time it took to establish the session, that is, to log onto the host. See also Total Duration and Total Discovery Duration.

Taxonomy

The template defining the nodes, attributes, and relationships used by Tideway Foundation and stored in the datastore. The Foundation taxonomy also defines how much of the data model is represented in the user interface.

Total Discovery Duration

This is the time it took establishing a session and running commands. See also Session Establishment Duration and Total Duration.

Total Duration

The time it took to discover and process the data from the target, that is, the time between the start time and the end time. See also Session Establishment Duration and Total Discovery Duration.

Trigger

The Trigger for a pattern describes the conditions under which the pattern executes. Triggers correspond to the creation, modification or destruction of node.

Unique datastore identifier (UID)

The unique datastore identifier for a node is an internal identifier that is used as an index by the database. It is a binary identifier represented in hexadecimal The unique datastore identifier is not intended to be human readable, it is designed for use by the datastore. An example unique datastore identifier is shown below.
4e4fd2c2ae4ccf123272d8446e486f7374
The unique datastore identifier identifies a stored node, not the item that the node represents.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.