6 Replies Latest reply on May 22, 2017 5:43 AM by Andrew Waters

    Host Near Removal Threshold

    Martin Wenger

      Dear Community,

       

      Can anyone explain the results from Discovery -> Discovery Reports -> Model Health -> Hosts Near Removal Threshold:

       

      1. Why the hosts below have not "aged" out even though it appears the default criteria for removal of 7 consecutive scan failures and 10 days have been met?
      2. What does the "Removal Eligibility" value of "FALSE" mean and why would it not be eligible for removal?

       

        

      Last Successful ScanConsecutive Scan FailuresRemoval Eligibility
      8 months ago10FALSE
      6 months ago10FALSE
      3 weeks ago10FALSE
      3 weeks ago10FALSE
      3 weeks ago9FALSE
      14 days ago10FALSE
      11 days ago10FALSE
      11 days ago10FALSE
      11 days ago10FALSE
      11 days ago10FALSE
      10 days ago8FALSE
      10 days ago10FALSE
      10 days ago20FALSE
      10 days ago20FALSE
        • 1. Re: Host Near Removal Threshold
          Andrew Waters

          Not from the information you have provided. In order to eligible when the device is scanned it needs to have failed 7 consecutive scans and been over 10 days since the success. Just going past the 10 days within a scanning will not have it removed.

           

          Running the report gives me a string describing the reason in removal eligibility rather than FALSE.

          • 2. Re: Host Near Removal Threshold
            Martin Wenger

            In our case, on the report in the UI, some of the 'Removal Eligibility' reasons show "No" which turns into a "False" when you export the report into a CSV. I don't understand why some hosts would not be eligible given both the 'Last Successful Scan' (over 10 days) and 'Consecutive Scan Failures' (failed 7 consecutive scans) conditions are met. One thing I noticed is that each of these hosts appear to have duplicate host records but the record that's approaching its removal threshold does not have any Discovery Access information. Maybe these records need to be destroyed manually?

             

            • 3. Re: Host Near Removal Threshold
              A B

              One thing I have faced in my environment is:

              We were facing some issues due to which we were not able to run discovery for a long time ultimately discovery access for some hosts have been aged out according to the DDD Removal Policy but host node remains in the datastore because it didn't meet aged out policy yet.

              Once we back in production we started running discovery but that time duplicate host got created for some host. Because when you will run discovery, identification algorithm will first try to search in a data store for existing node with IP. If yes it will update if no it will create a new node. At this point of time, your old node will never get deleted because Discovery will never try to attempt on that old node as the IP is pointing to new Host node now.

              At this point of time, your old node will never get deleted because Discovery will never try to attempt on that old node as the IP is pointing to new Host node now.

              You have to delete these old nodes manually if you have the same situation.

              • 4. Re: Host Near Removal Threshold
                Andrew Waters

                The last DA for an endpoint is not aged out (except if it is marked as darkspace).

                 

                That is not correct. All recent (10.1 and later) use Endpoint nodes not DiscoveryAccess chains, for ageing. Hence it does not matter is a change of identity has cause the Host to end up without an associated DA chain.

                • 5. Re: Host Near Removal Threshold
                  A B

                  Thanks for the clarification Andrew,

                  But can you please tell me that is there any way of checking whether the endpoint is marked as darkspace or not?

                  • 6. Re: Host Near Removal Threshold
                    Andrew Waters

                    Either there is no DiscoveryAccess containing the IP or dark_space is set on the DiscoveryAccess. This is covered in the docs.