search cancel

Auto change detection didn't pick up a new interface for over 3 months.

book

Article ID: 203124

calendar_today

Updated On:

Products

CA Infrastructure Management CA Performance Management - Usage and Administration DX NetOps

Issue/Introduction

It was brought to our attention that a specific interface was not being monitored in PM, we checked Spectrum and the interface was present and according to the configuration had been added on August 26th of this year. However PM didnt have the interface listed, we tried rediscovering the device, that didn't work, so we rediscovered the interface MFand that finally added the interface into PM. As the interface is part of a monitoring profile that is "12 hour change detection" unsure why this wasnt picked up.

We would like to investigate why this didnt work as we expected, and if possibly we are missing others due to something not working as expected.

Environment

Release : 20.2

Component : IM Reporting / Admin / Configuration

Cause

To get into a state where we disable change detection, the following needs to happen.

When update MF runs (either manually or via change detection schedule), we first discover what VC to use.

We will read the OIDs needed for component discovery.

If we determine that the VC(s) supported changed on the metric family, we kick off a FIRST_VC_Verify stage that runs in 5 mins from the initial read.

After we get back the OIDs needed for component discovery, we compare them to the existing components.

If we determine this will result in Not Present items being created, we do a SECOND_VC_VERIFY stage that runs in 5 mins from the first verify.

If we determine this will still result in Not Present items being created, we disable change detection.  We also do not apply any change/new item info we read during this CD cycle.

Also when this occurs we print to the DA karaf.log. NormalizedPortInfo is an example MF name, and ITEMID will be the device item_id in DA.

 Change detection for NormalizedPortInfo with VC {...}IfXTableMib on device ITEMID is disabled.

Resolution

To correct a situation where critical devices are not being updated by change detection, you can run a manual update metric familie on the device and metric family or you can check a REST endpoint on the DA to monitor and check and correct any devices that are disabled:


Replace DA_HOST with the name of your DA.

POST to:

http://<DA_HOST>:8581/rest/devices/filtered
<FilterSelect xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="filter.xsd">
  <Filter>
    <Device.ChangeDetectionDisabledMFs type="CONTAINS">{http://im.ca.com/normalizer}</Device.ChangeDetectionDisabledMFs>
  </Filter>
  <Select use="exclude" isa="exclude">
    <Device use="exclude">
      <PrimaryIPAddress use="include"/>
      <ChangeDetectionDisabledMFs use="include"/>
    </Device>
    <Item use="exclude">
      <Name use="include"/>
    </Item>
  </Select>
</FilterSelect>

*************************

Returns something like:

<DeviceList>
  <Device version="1.0.0">
    <ID>14005</ID>
    <PrimaryIPAddress>10.1.1.1</PrimaryIPAddress>
    <ChangeDetectionDisabledMFsList>
      <ChangeDetectionDisabledMFs>{http://im.ca.com/normalizer}NormalizedPortInfo</ChangeDetectionDisabledMFs>
    </ChangeDetectionDisabledMFsList>
    <Item version="1.0.0">
      <Name>device A name</Name>
    </Item>
  </Device>
</DeviceList>

This gives us the name, DEVICEID and metric family. So you can run a change detection on the device/MF in the GUI or use CURL to run an update on the device and metric family. 

The CURL is: 

curl -H 'Content-Type: application/xml' -d '<emptybody/>' -X POST http://<DA_HOST>:8581/genericWS/devices/<DEVICEID>/metricfamilies/<MF_NAME>/discovery

example: 
curl -H 'Content-Type: application/xml' -d '<emptybody/>' -X POST http://<DA_HOST>:8581/genericWS/devices/14005/metricfamilies/NormalizedPortInfo/discovery