Select Page

How to Use User Defined Polling in Entuity Network Analytics (ENA)

How to use User Defined Polling in Entuity Network Analytics (ENA)

An Introduction

This article is going to show you the basic concepts of the user-defined polling functionality and how to add new attributes and collectors in Entuity Network Analytics to have better control of your network management as you navigate around your network.

What you’ll Learn

  • User Defined Polling
  • Functionality
  • Entuity Network Analytics
  • Network Management


7 min


Entuity is pre-configured to discover network devices and a wide range of their subcomponents including Ports, Modules, Memory  Pools, Processors, Power Supplies and Cooling Fans along with temperature, voltage, airflow and other sensors. Additional aspects such as Routing Piers, VLANs and Port to Port connectivity are discovered and modeled in the database without any extra effort on the part of the administrators or users.

When discovering and monitoring virtual infrastructure, the virtual switches, hypervisors, virtual machines and all the virtual connections between them and the physical network ports are discovered and modeled. Each of these different components or object types is modeled in the database as its own unique object type for which provision has already been made in the standard monitoring system configuration.

Devices VS Ports Attributes

Different types of monitor component required different information and metrics to be gathered. For example, a device has a name, a manufacturer, a model, a serial number along with average CPU utilization, memory utilization and many more items for which there is a one-to-one relationship with the device and each one is modeled in the database as an attribute.

For a port, the required attributes are entirely different and include its description, alias, speed and traffic lights including the bit rate, percentage utilization, percentage faults and percentage discards.

  • Some of these attributes are not expected to change at least on a frequent basis. These attributes are referred to as object attributes and no change history will be maintained for them.
  • Other attributes are used to gather metrics that are expected to change and for which a history of such changes is required. These are referred to as time series attributes. The history is maintained in the database in streams where each stream can have one or more attributes.
  • When new user-defined attributes are added, they behave as both object and time series attributes, so no distinction needs to be made during their definition.

Real-time Events and Incidents

Real-time events and incidents can be raised when the system notices something that users should be aware of. This can be achieved using threshold crossing techniques or by the detection of specific data values. Many such events are already defined for the standard polling attributes and User-defined Attributes can have one or more event generation techniques configured for them.

Entuity Collectors

For each attribute, there needs to be a way to gather the value or values that will be processed in real-time and stored in the database. Entuity uses a concept called a collector to gather and optimally post-process information for storage and attributes.

Furthermore, to support the system with Auto adapt nimbly, to obtain information using different techniques that can not only be determined at runtime but also be multiple collectors assigned to a single attribute, with a way to define how the most appropriate collector is chosen and when the attributes need to be populated. The logic is covering how and where the data is obtained and how it is post-processed, and which collector takes precedence is based on priority defined in the standard configuration files provided with the package.

From time to time, it may be desirable to gather store, model and additional concepts beyond the scope of the standards system configuration. Sometimes the objects and attributes needed to model what’s required are already in place and yet the system isn’t aware of how the appropriate information might be gathered from a particular make or model of device.

User-defined Poling Capability

While Entuity makes expensive efforts to ensure that appropriate definitions are provided to obtain the standard supported metrics from all the devices it supports, there are sometimes instances where items such as fans, power supplies, memory in processors with their status and utilization statistics are overlooked. The image below indicates this device has no memory utilization being monitored.

Adding User-Defined Collectors

Under these circumstances, the Entuity device certification team are usually able given a mib-dump of the device in question to prepare and supply additional configuration files to achieve the desired functionality. However, even though the turnaround for such requests are often as rapid as a day or two, the user-defined poling capability can be used to achieve the same result if the data is available in the device MIBs. The way to access it is understood. Under these circumstances, you’ll need to define a new collector for an object attribute and there’s a tutorial video available to cover the procedure. (Check out our latest blog about “How to add a user defined collectors in ENA“)

Adding User-defined Attributes

If there’s a need to add one or more additional attributes to an existing object such as a compression ratio for a one data compression device, this would require new attributes with their corresponding collectors to be defined. There’s a UI wizard provided for this purpose and the dedicated tutorial video to cover the procedure.

Adding User-defined Object Types

If an entirely new concept needs to be modeled and added to the system:

  • its data is to be gathered from a mib-table;
  • there would need to be multiple instances of this object type,

One of the supplied user-defined object types would need to be used to achieve this.

The system is provided with a number of extra object types for which the only provided attributes would be their name and an index representing their membership of a table. There’s a separate tutorial video provided to explain the procedure for using these extra object types. Once they’ve been configured, the procedure for adding new attributes can be used in the same way as though they were predefined objects provided as part of the standard system configuration.


Unlike the procedure for adding new polling definitions using new configuration files, the user-defined polling mechanism allows new attributes and collectors to be created and used without the need for any system downtime. All the changes are made via the UI by administrators or suitably authorized users and they take effect as soon as they’re defined. The only changes that would require the system to be shut down to be reconfigured during a short maintenance window would be where one or more of the extra object types have been used, and custom names are to be used to describe them in the user interface.

ENA Tips:

The idea of combining multiple sub-reports into a higher-level report can be taken to yet another level if you build sub-reports by combining other sub-reports together. The main point to remember would be that when placing sub-reports side-by-side, their combined widths which are defined. So when you build a sub-report, pay attention to not exceed the width allocated in the final report. Another point you should remember when you build a report and you’re considered to be its owner, which allows you to modify its configuration at a later date via this icon.

Share This