You can modify settings for maintaining your data model, including aging limits, in the Model Maintenance settings of the user interface.
To configure model maintenance settings:
From the Model section of the Administration tab, select Model Maintenance.
The options on the page are described in the following table.
Field Name |
Details |
---|---|
Directly Discovered Data removal |
Specify the age past which Discovery Accesses and all the related DDD nodes are removed (the default is 28 days). |
Time before destroyed nodes are purged |
Specify the time elapsed before destroyed nodes are purged from the datastore. The default is one year. To change this, choose one of the following periods from the drop-down list. |
Time before history entries are purged |
Specify the time elapsed before history entries are purged from the datastore. The default is never. To change this, choose one of the following periods from the drop-down list. |
Scan optimization timeout |
When an IP address is designated the preferred IP address for a host, Discovery does not perform scans on other known IP addresses for that host. This is referred to as scan optimization. After a specified Scan optimization timeout period, Discovery will scan other known IP addresses for that host to ensure that they are still non-preferred and on the same host. Specify one of the following timeout periods from the drop-down list. |
Host/Network Device/Printer/SNMP Managed Device/Mainframe aging time limit |
Specify the host/network device/printer/SNMP managed device/mainframe aging time limit (the default is 10 days). |
Host/Network Device/Printer/SNMP Managed Device/Mainframe aging access failures |
Specify the number of host/network device/printer/SNMP managed device/mainframe access failures. |
Time to elapse before a software instance/runtime environment/storage can be aged |
Specify the time to elapse before a software instance/runtime environment/storage node can be aged. (the default is 10 days). |
Minimum number of failed accesses before a software instance/runtime environment/storage is aged |
Failed accesses before a software instance/runtime environment/storage node is aged. |
Dark space suppression scheme |
The scheme to use for dark space suppression. Select either Keep Most Recent or Remove All from the list. See #Dark space DiscoveryAccess nodes for a description of this setting. |
Cache Size |
The size of the disk cache. The default is to set it automatically. You must restart the appliance for this change to this setting. The default is displayed in the drop-down list as Automatic (N.n GB). |
Size Warning |
The maximum size of the datastore. When this limit is reached, a warning is displayed in the Appliance Status page. This is a soft limit and does not prevent the datastore growing beyond the specified limit. |
Checkpoint Interval |
The interval between datastore checkpoints. The larger the interval, the more data has to be written to the checkpoint files. The smaller the interval, less data needs to be written to the checkpoint files, though the writing takes place more often. The default is 15 minutes. |
In general, the expectation that BMC Atrium Discovery uses for deriving the default model maintenance settings is based on performing one scan of the estate every 24 hours with a DDD depth of one month. This expectation is also used to derive the sizing data. The default setting for data aging for both hosts and software instances is 10 days, because for most deployments this limit provides the best balance of responsiveness without data thrashing. Putting this in a business example, this gives two weekends plus additional time to detect that a host is aging, investigate why it is doing so, and make changes before the host is destroyed. It gives the software teams the same length of time to sort out any failures in the estate.
Best Practice
BMC recommends that you do not attempt to fine-tune model maintenance parameters. Doing so can make BMC Atrium Discovery highly reactive and have negative consequences, such as causing a dramatic increase in the size of the datastore and putting more load on your target estate. If you do alter the model maintenance parameters, BMC recommends that you do not vary more than half or twice the standard settings detailed in the preceding table.
However, there might be occasions when modifying the defaults are necessary, particularly if you scan your estate at different intervals and need to keep close control on disk consumption. The following table show recommended settings based on your scanning frequency.
Scanning Frequency |
Recommended Aging Limit |
---|---|
Every 2 days |
Maintain DDD at 28 days, and decrease the Host and Software Instance access failures to 4 (to account for half as many expected scans). |
2 times per day |
Decrease DDD to 14 days (to cap how much space it consumes, unless you increase the disk space to more than the sizing guidelines); increase the Host and Software Instance access failures to 12-14 (to account for scanning at twice the expected rate). |
For more information about aging and how it fits in the node removal process, see How nodes are removed.
DDD removal blackout windows should typically only be used on consolidation appliances when you need to achieve maximum discovery throughput. This is only likely to be needed at the Consolidated Enterprise scale, or possibly in the very largest scanning appliances. In virtually every discovery schedule used, the continual aging scheme used by BMC Atrium Discovery can remove "old" DDD at a similar rate as they are created.
You can determine whether scheduling DDD removal blackout windows may be beneficial using the DDD removal statistics page. The DDD removal statistics page shows the total number of DiscoveryAccesses in the datastore and those eligible for removal. If DiscoveryAccess removal is keeping up with DiscoveryAccess creation, then the number of eligible DiscoveryAccess nodes is zero, or near zero, DDD removal blackout windows are not required. If the trend of eligible DiscoveryAccess is rising over a two week period, then DDD removal blackout windows may be a solution. See DDD removal statistics page for more information.
To view existing DDD aging blackout windows:
When you view the DDD Removal Blackout Windows tab, the active blackout window is highlighted. If multiple blackout windows are active, the one with the longest time remaining before it ends is highlighted. This is not automatically refreshed.
DDD nodes are removed in batches which are not interrupted. Once removal starts, it continues to completion. Therefore, if a batch removal is in progress at the beginning of a DDD removal blackout window, it will continue into the blackout until completion. In normal operation this should take no more than a few minutes.
You can schedule a new DDD aging blackout window to occur daily, weekly, or monthly and can specify a start time and duration. To schedule a new DDD aging blackout window:
Enter the information for the blackout window in the fields described below.
Field Name |
Details |
---|---|
Comment |
Enter a descriptive comment for the blackout window. |
Frequency |
Select a frequency for the window to operate. For example, this can be Daily, Weekly, or Monthly. |
Start Time |
Select a time for the window to start. |
Duration |
Select a duration in hours. This is the length of time that the blackout window operates and can be from 1 to 24 hours. For a daily blackout window the maximum number of hours you can select is 23. This prevents you from inadvertently scheduling a 24/7 blackout. |
DiscoveryAccess nodes are created in the datastore for any discovery access attempt, whether or not the attempt was successful. A DiscoveryAccess node is created when an endpoint is scanned, if there is no response, the state is set to NoResponse
. On some estates where IP address space is sparsely populated, a very large number of DiscoveryAccess nodes are created, these predominantly being in the NoResponse
state. On a large estate, the number of these nodes may be large enough to affect the performance of the appliance.
A dark space suppression scheme is provided. You can choose to either keep the most recent, or to remove all DiscoveryAccess nodes in the NoResponse state.
To identify a DiscoveryRun which has been performed with the remove all option set and to indicate to the user why the state counts shown could look misleading, a remove_first_no_response
attribute is set on the DiscoveryRun and displayed as Dark Space Suppression.