Date: Fri, 29 Mar 2024 10:21:42 -0500 (CDT) Message-ID: <156013248.30334.1711725702835@bmc1-rhel-confprod1.managed.contegix.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_30333_1982170897.1711725702835" ------=_Part_30333_1982170897.1711725702835 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
It is important that the model of your network environment stays= current over time and that it is maintained efficiently. This not only inv= olves creating new nodes to represent recently discovered data, but also th= e removal of existing data that is no longer present in your environment.&n= bsp;BMC Discovery views the environment so that different kinds of nodes ar= e removed in different ways. Different methods are used to remove inferred = nodes and Directly Discovered Data nodes from the model.
Note
For patterns as well as the overall functioning in BMC Discovery, if the= system scans the infrastructure and captures some data but in a subsequent= scan fails to obtain the same data, it does not immediately remove the old= data. For example, a scan in the past may have captured a host and its ins= talled packages. But the latest scan may fail to retrieve the packages. Thi= s does not mean that the host now has no installed packages. The system rec= ords the failure in DDD and leaves the existing data as the best-known info= rmation. In a subsequent scan if the system successfully gets a list of pac= kages, and some packages that were previously present are now absent, then = the system updates the data by removing the relationships to non-existing p= ackages.
The following sections detail the ways in which inferred nodes are remov= ed from BMC Discovery. For more information on inferred nodes, see Inferred nodes.
To remove a node manually, select it in the node list and click
BMC Discovery has inferred the presence of a node from data such as= an interface list, where there is clear evidence that the node exists. Whe= n BMC Discovery cannot see any evidence of this node, it no longer exi= sts. Therefore, BMC Discovery removes the node automatically from the = model. Aging is not applied to this type of removal.
BMC Discovery has inferred the presence of a node from data such as= a process list, where there is clear evidence that the node exists. Howeve= r, in cases when BMC Discovery cannot see any evidence that the node still = exists, it does not necessarily imply that the node no longer exists. There= might be other reasons why the node appears to no longer exist.
For example, a process that relates to a software instance (SI), such as= an Adobe FrameMaker desktop application, might appear to be running during= an initial scan, but not on a subsequent scan. This does not necessarily i= ndicate that Adobe FrameMaker no longer exists; instead, it is possible tha= t the user has stopped running the application during the subsequent scan. = Because it is the nature of IT infrastructure to have frequent minor change= s to configurations, hosts, and software, discovered data becomes less rele= vant over time.
Aging is applied to this type of removal to prevent frequent removal and= recreating of SIs. When the node has been in the aging state for some time= , it is then removed from the model.
Only the following classes of nodes age:
The Software I= nstance, Ru= ntime Environment, and = Storage nodes mentioned above are only automatically aged if they are t= riggered on certain types of DDD. These are described on the individual nod= e pages.
Although there are important considerations before doing so, you can mod= ify data aging limits in the Model Maintenance settings of the user inte= rface.
This type of removal is authoritative, however it is based on different =
criteria than the original evidence for its existence.
An example of this would be a batch process, where a node creation (and th=
erefore existence) is triggered from seeing the job running in the process =
list, but BMC Discovery might check the timestamp of a log file to see=
if it believes it is running regularly.
This type will apply to any removal which involves actively seeking evid= ence about whether something exists.
This type of removal applies when BMC Discovery has inferred nodes = which have a containment relationship to another node. These are generally = nodes which model physical items such as network interface cards. If the no= n-authoritative removal process (Aging) has caused BMC Discovery to re= move a host, then the network interfaces that are contained in that host wi= ll also cease to exist. Therefore, Aging is not applied and the inferred no= de is removed.
This type of removal applies where further inferred nodes are constructe= d from first order or other inferred nodes. Any aging or specific removal w= ill already have taken place at the first order nodes, so there is no need = to apply any further removal strategies. In this case the removal should ca= scade up.
The removal process for DDD= nodes, is a much simpler process than it is for Inferred nodes.
The five removal strategies for Inferred nodes calculate that the entity= in the real-world to which the data corresponds no longer exists and there= fore the node is removed. Each time you run a discovery of DDD nodes, a new= set of data is retrieved. If the data is older than a certain cut-off point= and BMC Discovery discovers more recent data which refers to the same = node, the node is removed.
When patterns construct complicated structures, such as DatabaseDetail n= odes when doing deep discovery of databases, removal must be performed by t= he pattern that creates them. Removal Groups are named groups of nodes whic= h simplify deletion of these complex structures. They are described in Model functions in the TPL Guide.