How to add a User Defined Polling Attribute in Entuity Network Analytics (ENA)
This article is going to show you the basic concepts of the User Defined Polling functionality and how to add a User Defined Attribute 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
- User Defined Polling Attribute
- Entuity Network Analytics
- Network Management
The user-defined polling option allows you to add new attributes to existing managed objects. This applies to both system objects and extra objects that have been configured using user-defined collectors and attributes. System objects are present in every Entuity installation and represent network devices, ports, modules, processors, fans and many other types of components or concepts. Every different type of object has a number of attributes that each hold a specific piece of data that’s relevant in the context of the component being modeled by the object.
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. Learn how to add a user defiend collector in Entuity through this blog or our tutorial video .
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.
This wizard requires a managed device to be selected to see a full list of all of the devices under management on this server simply click the Search button. if you’d like to limit the scope of the list you can enter a substring first.
The workflow begins with the SNMP MIB browser which shares its MIB repository with the MIB browser used to configure the trap handler within the event management system. There are many industry standard MIBs provided with the system. If you need to add any vendor MIBs to the list, it can be administered via the Manage MIBs facility. Any combination of MIBs can be selected and loaded using this UI, although it’s best to only load those that are needed to optimize the responsiveness of the UI. If I need something to be loaded that isn’t already in this list, it can be uploaded to the system via the web browser using the Import button, which means there’s no requirement to have direct access to the file system or command line of the Entuity server.
As an example, I’m going to add an attribute that will record the number of TCP sessions that a device has opened with other devices. I can quickly locate a suitable section of the MIB structure by searching for the string using the find field. This is the branch I was looking for and here’s the one that I need to poll to see the number of established TCP sessions.
I can see the full description of this OID as it appears in the MIB. I can get its contents from the selected device using the Get button. In this case, there were five currently established TCP connections to create a corresponding attribute.
Name and Display Name
The attribute name has defaulted to use the name of the OID taken from the MID with the “UD_” added to the beginning to indicate that it’s user-defined. You have the option of changing this name if you’d prefer, but the system will always keep the “UD_” on the beginning. There’s also a more readable display name that will be used to identify it in the UI and in the ports. I’ll make a change to this adding TCP in the beginning, so it would be displayed as “TCP Curr Estab”.
The descriptive text was extracted from the MIB but you can modify. This is an example of a metric called a scaler where there’s one per device and rather than limiting it just two routers, which is the default setting based on the fact that the currently selected device is a router.
I am going to broaden the scope to cover all devices and select an object type representing an SNMP managed device called “DeviceEX”, which means an extended device.
The filter setting contains logic that will be used at one time to determine whether there should be an attempt to create an instance of this attribute in the context of each object. In this case, it would be checked for each device while by default is checking to see that the enterprise OID matches the manufacturer of the device that I have currently selected, which is Cisco.
If you want to extend this test to include one or more other vendors, you could simply select them from this list and click Add.In the meantime, if you don’t want to limit the discovery of this attribute just to Cisco devices, you could remove the test for Cisco from the statement. You will notice that several statements include the test simple followed by a semicolon at the beginning of the line and this declares that the syntax is using the simple language supported by the StormWorks data management kernel, which is the heart of the Entuity system. I can check the results of evaluating the statement in the context of the selected device using the Test button. The resulting value of one represents a boolean true, while zero would have meant false.
Display Format and Data Type
The display format and data type automatically default to suitable settings based on the MIB definition and will rarely need to be changed.
Polling Interval and Retention Period
The polling interval and retention period can both be adjusted. Let’s set them to five minutes and one day respectively. That allows us to quickly demonstrate the results. It’s worth making sure that the polling interval isn’t set to an unnecessarily low value as this would increase the load on the devices being polled, the network and the management server, especially if you’ve got a lot of devices on which it’s being polled. It’s also important to make sure that the data samples are not retained when inappropriately long time as this will increase the database size and corresponding disk usage for little benefit.
The OID is defined as a gauge and simply returns an integer that can go up or down. It’s not an enumerated OID where each different value has a specific meaning, so I can ignore the Transform setting.
If you want to declare one or more events that can be raised based on the polling of this attribute, you can select the events tab. However, you can also continue to the definition of the collector and come back to set off any required events later. That’s the end for the definition of the attribute. Next step, we are going to create a suitable collector.
I am going to leave them most of the fields in the collector definition with their default settings as they’ve been appropriately chosen. You’ll notice that the Index is shown as None. This always shows as a scalar which means there’s only one instance of it rather than being a table of instances which would need to be referenced using an Index.
The SNMP polling syntax has been automatically provided. Although it can be edited to perform any required post-processing, it’s possible to have multiple collectors associated with the same attribute and they’ll be evaluated at runtime in priority order with the highest priority being executed first. If the collector fails and returns a null result, which would happen when an snmp_get operation were fail to find the specified OID, the collector with the next lower priority will be executed until the receivers success or the list of collectors is exhausted. It is worth noting that this sequence isn’t performed on every polling attempt, so the runtime overhead is minimal.
Finally, there is another Transform setting. I will ignore it as this is a pure numeric OID. In this case, this transform capability would normally only be used if the status values returned by proprietary MIBs of devices from different vendors need to be converted to a normalized set of values. That’s the end of the procedure.
If you look in the Attributes tab, you will be able to see that attribute that you’ve just created. If further changes are needed, it can be selected and the Edit button clicked. Noticed that the Collector Count is displaying one corresponding to the single collector that I just created.
Here’s that collector being displayed under the Collectors tab.
I have left it polling for a few minutes and using an attributes dashboard. As you can see, there are two instances of the new attribute named “TCP Curr Estab”, the upper one represents the object aspects of the attribute which has no stream name and the lower one represents the stream dimension so this one has history associated with it.
This is the most recent value and if I were to right-click the lower one to show a chart, you can see that the value has fluctuated between five and seven and then back down to five again over the last few minutes.
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.