Idea Details

Selectively enable/disable interface polling

Last activity 06-13-2019 09:40 AM
jbreault's profile image
03-08-2017 10:46 AM

Migrating from eHealth to PM. In eHealth you can discover using "router/switch" to load elements, then go enable detailed metrics for each interface that port level reporting is needed. We need to replicate this behavior into PM where there is more control of the interface polling option.


In PM, monitoring profile filtering can be used on interface specific attributes (Name, ifAlias, speed, etc.). The problem we are seeing is where there isn't a specific pattern to match with attribute filters, there is no other way to disable/enable polling.


Use Case:

Need to monitor selective ports for detailed metric reporting on various devices. Could be an uplink, could be a server port, could be even a user (access level) port. Each port could be of various speeds and no specific interface descriptions exist. Out of a total of 1M+ interfaces, only about 45K need to be monitored.


Custom Collections were attempted, but only having interface models in the list,  DA does not pick up or apply monitoring at all. A collection/group whereas a user can add the interfaces and polling starts would be ideal, or something that can be easily accomplished through the UI.


The other option we tried was to use Name Aliases, but these are not shared with DA to be used anywhere to control/filter polling.


03-09-2018 04:48 PM

We're looking at supporting all components though the WS and having a UI option for interfaces.

03-09-2018 10:08 AM

Hi, I think it would be enough. The idea is to allow this update in the

same way that is today, passing the DA id to update the



This could be extended to all kind of sub-components or the plan is to

restrict at this time to qos and interfaces?




Enviado do meu iPhone


Em 9 de mar de 2018, à(s) 12:00, kelch14 <> escreveu:


CA Communities <>

Selectively enable/disable interface polling new comment by Chazz Kellner

<> View all comments on this idea


03-09-2018 10:00 AM

The flag will be persistent across change detection and restarts.

03-09-2018 10:00 AM

For QOS filtering, would WS commend be sufficient to manage without a UI option?

03-09-2018 09:20 AM

this setting would then be persistent across change detection and DA restarts? (the current IsPolled attribute gets reset).

03-09-2018 09:12 AM

Hi Daniel, well for now I'll try to extend the certification to filter out

the QOS queues that are configured on not used interfaces (ifOperStatus and

ifAdminStatus equals to DOWN) directly on the VC. I have around 1300

devices that have around 200 interfaces and on each I have 6 queues, but

for a single device I only have to monitor around 80/90 queues out of 1200

possible queues, because the others are on disabled interfaces and PM is

not considering this at the time to create the sub-components, so disable

the unwanted qos elements is essential!






2018-03-09 10:19 GMT-03:00 Dan_Holmes <>:


CA Communities <>

Selectively enable/disable interface polling new comment by Daniel Holmes

<> View all comments on this




03-09-2018 08:18 AM

What attributes are you using to filter the QoS items - is there something captured from the device or do you require an external data source or have to resort to manual?


Sent from my iPhone

03-09-2018 07:33 AM

Hi, would be very nice if this behavior of enable/disable polling could be

extended to all sub-components.

Recently I'm fighting to disable thousand of QOS sub-components that are

not needed to be monitored.

If I can't disable them this will have a huge impact on Data Collector

total usage.


With this feature developed how the regular Change Detection Rate would

impact this flag? Once it's set it'll change again only with the WS command?








2018-03-08 18:06 GMT-03:00 kelch14 <>:


CA Communities <>

Selectively enable/disable interface polling new comment by Chazz Kellner

<> View all comments on this idea



03-08-2018 04:05 PM


We're currently working on a design for this feature based on the requirements of the customer for the original idea submission. Here's our current thinking:

  • Default behavior remains the same.
  • After discovery, give the users an option to stop polling selected interfaces. Interfaces would have a flag of 'polled' or 'not polled' (or something similar).
  • Expose the flag through a REST services for orchestration.
  • Add a button to interface inventory views to enable or disable polling. The inventory view allows you to scope the interfaces you're looking at to a specific device, to a group, or search for a specific interface.
  • Interfaces with disable polling remain in inventory and any historical poll data is available until it ages out.


Does this sound like a suitable design to deliver on this request?

08-11-2017 07:44 AM

Any update on when is this planned? This is definitely in the list of MSPs especially those using eHealth.




06-08-2017 11:03 AM

I did not there was a discussion for this and I created on idea : Filter out specific interfaces at the DC Level 


But it is essential and capital to get this feature within CAPM. Most of CAP&Perf tools already implement this feature. We have at least 30 tenants and it is very important to have the ability to select or filter out interfaces.

I would like to complement the idea by allowing to select or discard interfaces  at the DC level by providing naming convention to the interface name and/or interface description. We ask to our customers to implement naming convention within the interfaces description and we are using this naming convention to the report level. But, we'd like to not collect these objects from this naming convention. 

Globally, it should not restrict to the interfaces. It would nice to define which network objects are eligible or not to the collecting by CAPM.

03-10-2017 05:02 PM

Changed this to 'Under Review" after talking with Dev.  More to come.

03-09-2017 08:29 PM

Am i the only one that gets sentimental when i see that old VNM icon  - now if you could just get a screen shot on SGI IRIX machine and i would feel 23 all over again

03-09-2017 03:15 PM

I know you guys have heard this before, but essentially ALL of the managed service providers who run eHealth have a ton of provisioning and change management automation tied to DCI rules and filters.  I'd also bet that every one of the eHealth admins from the largest customers (not to mention your own Services organization!) have their own tool boxes of utilities that dump out element lists to make simple and mass changes using DCI scripts to modify the configs.  Unless I'm missing something, we are all looking for those tool replacements for PM.

03-09-2017 02:05 PM

This is an extremely important feature to have in CAPM. There is a need in any large environment to be flexible at a moment's notice as to what we need to poll and store data for or not. Along with the ability to pull in filtered lists of items (elements) through DCI rules, there was also the ability to discover everything and allow for polling to be enabled/disabled on the fly from the console. This allowed analysts the ability to turn on data collection for existing elements as needed for a variety of purposes. Discovering an polling the whole world is not an option due to server and storage cost. It make little sense to store data for everything when all you need is a small percentage of it.


Please consider this well known and used feature from eHealth.

03-09-2017 01:25 PM

This is a really important feature to have in Performance Management. In eHealth we have done a project that we need to monitor only the uplink port on DSLAMs and we did not had any pattern that could use as a filter despite the traffic on the interfaces, so we build an script that read the octets on the interfaces to found the uplink. At the end we created DCI files to start the monitoring of those specific interfaces. DSLAMs can have a massive amount of interfaces, so this feature really helped to monitor only what was needed.


In the end, we also use this script to maintain this interfaces updated, because sometimes they change the DSLAM uplink to a faster interface. So with Live Exception we monitor inactivity and after 8h of no traffic this script is executed again to found the new uplink. This allowed the costumer to keep the eHealth database up to date. But all this was possible thanks to the ability of selectively choose the elements I want to monitor.

03-09-2017 12:58 PM

The request is from a migrating eHealth customer. I have been pushing on the use of interface filters but according to the customer there is not logic to support the filtering on the target interfaces. We looked into tokenizing the target interfaces via the alias but changes do not get driven to the DA (CA PC side only). Operationally the customer does not discover interfaces in eHealth and gets a request to bring a few interfaces at a time online via ad-hoc discovery. This will also be how CA PC is to add interfaces s well - a few at a time in most cases. Some server switches will have all interfaces but most routers will have between zero and 5 interfaces monitored. They will have 16K devices - between 1-2 million interfaces on them and monitor about ~40K of the interfaces. We  looked at (explicitly) allowing the interfaces in via an interface filter with these numbers it does not seem tenable.

03-08-2017 01:28 PM

This is a fairly important item for service providers and very large enterprises to have.  They need the capability to easily identify which things should be polled or not polled.  This is a critical provisioning capability for managing huge network environments where only some of the interfaces are going to be "managed" by their NMS tools.  Otherwise, you end up polling the whole planet when you only really need to poll small pieces of it.


We accomplished this in eHealth using DCI and DCI Rules files during both the discovery pass (nhDiscover) and the config pass (nhConfig).  We parsed the discovery results from nhDiscover to present the users with a checklist where they could identify the things that needed to be polled or monitored.  Then we fed the result of the user's checklist into a DCI Rule that was applied during the nhConfig entry for that discovery.  This allowed us eHealth admins to push the control of what got into the databases out to the end users who were responsible for their customers' monitoring needs instead of us admins having to do all this work for everyone!  This was a HUGE positive impact to our ability to manage globally scaled networks. 


So, basically we created a way to give users the ability to pick and choose what they wanted to poll and have monitored in Live Health for their devices.  By doing it this way, it freed us from having to try to figure out pattern matching or any other crazy attribute filtering scheme.  We put the responsibility for that back on the end users and everything they chose got provisioned with detailed polling. 


The methodology that enabled our success was the ability to programmatically separate device discovery from device configuration in eHealth along with the ability to apply DCI filters and DCI Rules files during both of those phases of the device provisioning process.


I'm fixing to get ready to go down this migration path, so here's my chime on this subject.  I have no desire to reinvent this particular wheel again!    It would be nice if it was just in there. 


Hope this is helpful for you as well.

- Chris

03-08-2017 01:06 PM

Frequently, the team that does monitoring is not the same team that controls the network devices.  The reality is that there needs to be a way to drive monitoring configuration from an external source/attribute, whether it’s a CMDB, other monitoring tool (Spectrum Global Collection), or some property/attribute that can be updated via REST and GUI that doesn’t depend on what is configured on the device. 

03-08-2017 11:48 AM

Jeff - Thanks for taking the time to provide a clear description of the problem and the requirement. The requirement as I understand is that cusotmers need a simple way to control what interfaces are polled and which are not for devices they have discovered in CAPM. They need this to be simple at very high scale. They also need a simple way to change this status.


Let me review this request with the R&D team to see first if there is a workaround today and second what chagne would be appropriate to make this more simple/possible.

03-08-2017 11:20 AM

This is an interesting use case, Jeff.   I'd like to see others chime in on these ideas before engaging Dev.