1 of 1 people found this helpful
It would take a total of 10 days. The Host will be aged upon the scan when both conditions are met:
- The Host was not discovered successfully in the 7 last scan attempts (age_count will decrease to -7)
- At least 10 days have elapsed since the last successful scan (last_update_success)
So in you case, on day 10 all conditions will be met.
Okay, thank you for clearing that up! It makes sense.
I had a look at the following documentation and, at least for me, "two weekends plus additional time" definitely means more than 14 days. Maybe this text should be changed a bit?
Modifying DDD, host, and software instance aging limits
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.
Let me explain why this is the logic.
Imagine a host is offline at the moment (or the network is broken). I scan the host and see that it fails. I immediately scan it again, and again, and a few more times. If there was no time element to the aging, then the Host node would be deleted, even though the host has only been offline for 5 minutes.
Imagine another host that I stop scanning for a couple of weeks. If there was no element of number of scans in the aging, then the Host node would be deleted just because it hasn't been seen for 10 days. That can't be right, because there is no evidence either way about whether it is still present.
So, for a host to age out, there has to be a number of scans, and an amount of elapsed time.
If the DDD Removal is set to 28 days, Then Wouldn't the Host remain in ADDM for 28 days even if below conditions are met ?
Host aging access failures = 7 failures
Host aging time limit = 10 days
I am expecting that the Host will be aged out on 29th Day of first Discovery Failure. Please correct me If my assumption is wrong.
No. DDD Removal is completely separate from Host Aging.
Thanks for your explanation.
My question is if CI is not scanned for last 10 days and last successful scan was before 15 days.
Later it was not scanned by scanner due to change in scanning schedule.
In this case 10 days criteria was met but 7 scan failure will not met.
In this case does CI will not be removed at all rite ?
Does it always show as "host is approaching its removal threshold" and this entry will exist in CMDB.
Is it correct ?
And this CI aging setting should be set in scanner or consolidator. which one is more valid to use and it should be same in both scanner and consolidator ?
1 of 1 people found this helpful
No that is not correct. It needs to be approaching both the 10 days since last successful scan and 7 failed scan before it will show the Host as approaching the removal threshold.
The Host will only be removed from the CMDB when it has aged out. So if you do not scan it then it will still be in the CMDB.
You can set it in either.Both will age independently. However, you probably want them to be the same in both so that Hosts appear consistently on both scanner and consolidator.