DX NetOps

 View Only
  • 1.  Duplicate elements in CA eHealth OneClick

    Posted Sep 28, 2022 06:24 PM
    Hello All,

    I am new to this community and have recently joined a project where CA eHealth is still used to monitor servers.
    Now i know it is well beyond EOL but I really need to find cause of 2 issues related to elements till we migrate! 

    So, in CA ehealth, i see multiple element entries for single element. This is happening for so many devices during rediscovery and when I did rediscover them manually i found it is assumed as a different element by ehealth because of some index value !
    Elements keep on adding for such change like elementX, elementX -A, elementX -B and so on....

    Similar thing also happens when patching activity happens on the servers, causing ehealth to throw alarms for "mount point not available". When i rediscover it shows updated elements and post saving results everything goes back to normal AND it does NOT add them as duplicate elements !! I wonder why it creates duplicate elements in above case ??


    Can anyone point me to the right direction please ! What are these index , index1, index 2 values or how can i solve these issues permanently.

    Thanks
    AK




  • 2.  RE: Duplicate elements in CA eHealth OneClick

    Broadcom Employee
    Posted Sep 29, 2022 02:39 AM

    Hi Anmol,

    Indices are something standard in SNMP to uniquely refer to one component when multiple exist. Typical examples are the interfaces and disk partitions 

    SNMP MIB uses numeric indices and not the component names to index components in MIB tables. 

    When the SNMP agent starts it assigns an indices to each component and it is expected they are persistent during the existence of the component and survive to agent restarts.

    Some agents requires specific configuration to make indices persistent, but I have never seen with disk partitions.

    If the agent restarts or a reconfiguration of the system changes the indices (/tmp was index 35 and not it is 36), the NMS (in this case eHealth) will identify a conflict because a new component with the same resulting name already exists with a different index.

    I recommend you to explore the SNMP agent documentation to check if there is any configuration to force the persistence of the indices or maybe a bug.

    I hope this helps
    Regards




  • 3.  RE: Duplicate elements in CA eHealth OneClick

    Posted Sep 30, 2022 01:27 PM
    Thanks jose. Will look into the agent part to find more on this.


  • 4.  RE: Duplicate elements in CA eHealth OneClick

    Posted Dec 08, 2022 05:58 PM
    Hi Jose,

    regarding the indexing thing, can you guide if sysedge agent is responsible for changing these indexes ? or Do we need to involve linux support for fix this ?
    Thanks
    AK


  • 5.  RE: Duplicate elements in CA eHealth OneClick

    Posted Sep 29, 2022 02:40 AM
    You need to put a clear path on the questions that you have.

    First of all, elements are named Element-A, Element-B, Element-C, whenever the discovery process results for an element with the same name as an existing element. The second scenario that eHealth names element like this, is whenever the name exceeds 64 characters. If you have a device with a longer name, that is discovered and the result is names for elements longer than 64 characters, the names of the elements are trimmed down automatically to less than 64. Is there are multiple elements in this situation, you end up with Element-A, Element-B, the one mentioned above. Usually this is solved during the discovery process with DCR rules and some custom DCI/DDI files.. Using of DCR rules are described in the documentation.  

    eHealth has an internal system to decide if an element is monitored or not already, so it won't create a duplicate element. This again can be mangled during the discovery process using DCR rules. There's a field discovery_key which should uniquely identify elements. That and a combination of element type. So If you create a Disk element type, that one should have a unique discovery_key that is created based on some default criteria (index1+Index2+name). If those do no suite your need you'll need to change. I came across similar problems some time ago, when discovering some IPSLA tests.

    The alarm that you're referring to is normal, as the mountpoint most probably disappears with restart. What you need to do is to configure the SNMP agent on the server to have persistent indexes on the disks that it displays. If the index changes over restart, you'll need to re-discover the server, to update the disk information.

    ------------------------------
    Cătălin Fărcășanu
    Senior Consultant
    SolvIT Networks
    ------------------------------



  • 6.  RE: Duplicate elements in CA eHealth OneClick

    Posted Sep 30, 2022 01:27 PM
    Thanks for your response. In our case monitoring is done using CAsystemEDGE agent. Any reference document you can guide me to help with the configuration of these ?


  • 7.  RE: Duplicate elements in CA eHealth OneClick

    Broadcom Employee
    Posted Sep 29, 2022 02:41 AM
    Hi Anmol,

    Indices are something standard in SNMP to uniquely refer to one component when multiple exist. Typical examples are the interfaces and disk partitions 

    SNMP MIB uses numeric indices and not the component names to index components in MIB tables. 

    When the SNMP agent starts it assigns an indices to each component and it is expected they are persistent during the existence of the component and survive to agent restarts.

    Some agents requires specific configuration to make indices persistent, but I have never seen with disk partitions.

    If the agent restarts or a reconfiguration of the system changes the indices (/tmp was index 35 and not it is 36), the NMS (in this case eHealth) will identify a conflict because a new component with the same resulting name already exists with a different index.

    I recommend you to explore the SNMP agent documentation to check if there is any configuration to force the persistence of the indices or maybe a bug.

    I hope this helps
    Regards