Idea Details

Don't model interfaces in status notPresent(6)

Last activity 11-18-2019 07:40 AM
Hilmar Preuße's profile image
06-24-2016 03:52 AM

What is the use case of the new feature?

----------------------------------------

Less items in the PM 2.0 DB. Filter out these, not representing existing logical or physical hardware.

 

Describe the new feature in detail

----------------------------------

Currently in CA PM 2.0 interfaces having Operational status notPresent(6) are modelled. This status means: "it should remain in the notPresent(6) state if the interface has missing (typically, hardware) components.", i.e. these entries do not represent existing hardware. CA PM should not collect performance data for these interfaces.

 

Describe how you envision this new feature being implemented.

-------------------------------------------------------------

PM 2.0 should by default filter out these interfaces, i.e. not only set them to poll off, but not even model them.

 

What business problem will be solved by adding this new feature?

----------------------------------------------------------------

Currently there are more items in the DB than needed. If the useless ones would be filtered out by default less (useless) data would be polled into the database.


Comments

06-24-2016 10:07 AM

Got it, I understand now.  Voted up.  :-)

06-24-2016 09:47 AM

Not sure if you get the point. The interface items in the DB do not have the status "Not Present". By default they have the normal status "Active" and are polled.

For now I build a filter Custom "Monitoring Profile" like this: "Administrative Status does not equal down(2) and Operational Status does not equal notPresent(6)". This turns polling off for these items. Now they are in Status "Filtered", but not "Not Present".

06-24-2016 09:26 AM

There is a script you can use to remove the "Not Present" items from the database:  $IMROOT/scripts/remove_not_present_items.sh

 

I found it useful to schedule this script to run routinely, configured to delete "Not Present" items 30 days old (using the "-t 30" command-line argument)

 

If this Idea is accepted, I would strongly stress it be configurable, as I disagree with this being normal behavior.  If the "Not Present" Item were to come back shortly after, you would no longer have any historical data.  Keeping the Item for a short time (ie: in my case 30-days via the script) keeps historical data intact in the event the Item does return.

 

Also, if you are seeing a large number of "Not Present" items, you may want to open a ticket with Support as this may indicate Item Discovery & Reconciliation is not working properly.