snmpcollector - metric family normalization - example HTTPPROXYINFO

[Steffen Neuser]

Hello,

How can we adopt the prirozation of predefined metric definitions to our needs?

Does reload or deactivate/activate reinitialize the metric system from the xml-files at all?
Or is it necessary to recompile the metric system with a different command?

Problem explained In detaill on the example metric family HTTPPROXYINFO:

• Destination Certification: NormalizedHTTPProxyInfo
• Name in device profiles: "HttpConnandRequest " + Index
• Source metric families
  • snmp-bluecoat-http-proxy-conn.xml
  • snmp-cisco-content-engine-http-proxy.xml
  • snmp-cisco-content-engine-wmt-proxy-hc.xml
  • snmp-f5-bigip-http-proxy.xml
  • snmp-f5-bigip-ssl-proxy.xml
  • snmp-fortinet-fortigate-http-proxy-stats.xml
  • snmp-fortinet-fortigate-http-proxy.xml
  • snmp-http-proxy-conn.xml
  • snmp-ironport-proxy-rh-cpu.xml
  • snmp-mcafee-http-proxy.xml
  • snmp-netapp-http-proxy.xml
  • snmp-netscaler-http-proxy-data.xml
  • snmp-sip-server-proxy-statistics.xml

Default: winner=snmp-http-proxy-conn.xml for this metric family with just 3 metrics to can be monitored
Aim: need snmp-bluecoat-http-proxy-conn.xml as the winner for this metric family in our environment with 17 metrics especially most meaningful metrics to can be monitored
Question: How can we achive this?

Despite most of possible source metrics are defined in MetricFamily\normalized-http-proxy-info.xml, only the very few metrics defined in snmp-http-proxy-conn.xml are used in real and will make all other defined metrics unusable. As long snmp-http-proxy-conn.xml is defined as the winner of this metric family system, no other metric of this family could be ever activated for real monitoring, but will be offered in the template editor to generate confusion to the admins of the product for none working opportunities.

Difficult to imagine that this behaviour is intended in snmpcollector containing a lot of work in predefinitions to benefit of just a very little amount of this predefinitions and dropping extensibility of the product. In the end is this no improvement compared to the older snmp probes.

The only real working opportunity to can influence the metric system is the SelfCert portlet. But it can't handle device families. The generated metric definition will be valid to the exact probing device's SysObjID only. In case of bluecoat devices we've got 6 different device models inside the bluecoat proxy device family all supporting BluecoatSgHttpProxyMib but need to be defined 6 times in this product. This multiplied with further 8 device families need to extend will make this opportunity very unhandy.


TryOuts - but didnt improve metric family normalization to can work with.:

Touched following files in Subfolder DeviceSupport

Changing priority from 502 to 499 to be better then 501 in HttpProxyMib definition in alldevices.xml

    <VendorCert>

        <name>BluecoatSgHttpProxyMib</name>

        <priority>499</priority>

        <fileName>snmp-bluecoat-http-proxy-conn.xml</fileName>

        <MetricFamily>NormalizedHTTPProxyInfo</MetricFamily>

        <EnterpriseIDList>

                <Id>1.3.6.1.4.1.3417</Id>

        </EnterpriseIDList>

    </VendorCert>

 

Changing order and removing HttpProxyMib entries in vendorCertSupport.xml

<setup>

    systemObjectId = 1.3.6.1.4.1.3417.1.1.34

</setup>

<MetricFamilies>

    <NormalizedAvailabilityInfo>

        <VendorCertifications>

            <systemMib>

            </systemMib>

        </VendorCertifications>

    </NormalizedAvailabilityInfo>

    <NormalizedIpRouterIpv6StatsInfo>

        <VendorCertifications>

            <Rfc4293IpRouterIpv6StatsV1Mib>

            </Rfc4293IpRouterIpv6StatsV1Mib>

        </VendorCertifications>

    </NormalizedIpRouterIpv6StatsInfo>

    <NormalizedHTTPProxyInfo>

        <VendorCertifications>

            <HttpProxyMib>

            </HttpProxyMib>

            <BluecoatSgHttpProxyMib>

            </BluecoatSgHttpProxyMib>

        </VendorCertifications>

    </NormalizedHTTPProxyInfo>

 

We performed all tryouts with same steps:

• Deactivate snmpcollector
• Action
• Activate snmpcollector
• Rediscover device profile
• Check device profile = >proxy

What method will work?

regards, Steffen

[David Michel]

The snmpcollector probe utility has a callback load_device_cert_files which can be used.
Also list_vendor_cert to see what's there.

On a side note the latest are available from the archive in the Device_Certification_Deployer package.
documented here:
https://docops.ca.com/ca-unified-infrastructure-management-probes/ga/en/alphabetical-probe-articles/snmpcollector-snmp-data-monitoring/snmpcollector-snmp-data-monitoring-release-notes/update-vendor-certifications

------------------------------
Support Engineer
Broadcom
------------------------------

[Steffen Neuser]

Thx David for your answer,

list_vendor_cert - the output list is very long in a scrolling list (not searchable by F5) and not sorted - so its difficult to find what you looking for. Is there a posibility to can sort after names?
should the callback load_device_cert_files  be used to renew the metric system after changes in xml-files in place of deactivation/activation of snmpcollector?  How can I double check that my last changes in xml-files will be realy active in the current running snmpcollector. Is there a cache snmpcollector-folder or table in H2DB?

Also one mystic thing with SelfCert portlet is if you redeploy your generated metric-extension xml in the last step of the wizard with all your SysOBJ-Ids containing all used devices in the intended device family, the distributed xml-file under SubDir CustomVendorCertifications will be overwritten each time you reploy with the last entered SysOBJ-Id. The mystic thing is: you can extend the intended MIB-support for all devices in that device family very easely with this method - its working in reality, even though the distributed xml just contain the last excact SysOBJ of the last deployed device model overwriting the previous device model. So the expected behavior should be that all previously deployed device models should lose the extended metrics - but these keep it.

What mystic things more does the SelfCert portlet, that you can straight forward extend your metrics compared to writing your xml's directly or correct bad vendor pre choosen metric priority in existings xml's? I would  prefere the direct method in place of selfCert portlet, because of keeping transparency, control and the possibility for backup and restore your metric extensions in case you need to move or for desaster recovery your UIM.

[Steffen Neuser]

Thx David for your answer,

list_vendor_cert - the output list is very long in a scrolling list (not searchable by F5) and not sorted - so its difficult to find what you looking for. Is there a posibility to can sort after names?
should the callback load_device_cert_files  be used to renew the metric system after changes in xml-files in place of deactivation/activation of snmpcollector?  How can I double check that my last changes in xml-files will be realy active in the current running snmpcollector. Is there a cache snmpcollector-folder or table in H2DB?

Also one mystic thing with SelfCert portlet is if you redeploy your generated metric-extension xml in the last step of the wizard with all your SysOBJ-Ids containing all used devices in the intended device family, the distributed xml-file under SubDir CustomVendorCertifications will be overwritten each time you reploy with the last entered SysOBJ-Id. The mystic thing is: you can extend the intended MIB-support for all devices in that device family very easely with this method - its working in reality, even though the distributed xml just contain the last excact SysOBJ of the last deployed device model overwriting the previous device model. So the expected behavior should be that all previously deployed device models should lose the extended metrics - but these keep it.

What mystic things more does the SelfCert portlet, that you can straight forward extend your metrics compared to writing your xml's directly or correct bad vendor pre choosen metric priority in existings xml's? I would  prefere the direct method in place of selfCert portlet, because of keeping transparency, control and the possibility for backup and restore your metric extensions in case you need to move your UIM.

[David Michel]

Yes the list is not in order, there is no search, or copy if using IM, if using Admin Console there is at least the ability to copy past. 

Yes, use the callback to reload any changes to the certs. 

No way to check to see what's loaded and verify a change in a specific cert is in effect. 

The local db has the profiles only. 

An Idea requesting exactly what is wanted is the way to address the request on customization.

------------------------------
Support Engineer
Broadcom
------------------------------