7 Replies Latest reply on Sep 26, 2018 9:38 AM by Andrew Waters

    Explanation of ADDMs aging process

    Ludvig Cassel
      Share This:

      Hi,

       

      I am trying to wrap my head around a specific detail in this process that I have not seen clearly documented anywhere.

      So I figured I would ask here

       

      Model maintenance settings:

      Host aging access failures          = 7 failures

      Host aging time limit                    = 10 days

       

      Assuming a server is scanned once every day, how many days does it take for the host to be aged out once it is no longer possible to scan it?

      My understanding of the process is that it would take 17 days. 7 days with access failures and then a grace time period of 10 days would start.

      I discussed this with a collegue of mine whose understanding was that it would instead take a total of 10 days.

       

      Which one is correct?

        • 1. Re: Explanation of ADDMs aging process
          Nicolas Bamberski

          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)

          AND

          - 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.

          HTH,

          Nicolas

          1 of 1 people found this helpful
          • 2. Re: Explanation of ADDMs aging process
            Ludvig Cassel

            Hi Nicolas,

             

            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.

            • 3. Re: Explanation of ADDMs aging process
              Duncan Grisby

              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.

              • 4. Re: Explanation of ADDMs aging process

                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.

                • 5. Re: Explanation of ADDMs aging process
                  Chris Hughes

                  No.  DDD Removal is completely separate from Host Aging.

                  • 6. Re: Explanation of ADDMs aging process
                    Naveen Kumar N C

                    Hi NIkolas

                     

                    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 ?

                     

                    Please assist.

                    • 7. Re: Explanation of ADDMs aging process
                      Andrew Waters

                      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.

                      1 of 1 people found this helpful