StableNet® Blog
Regular posts on all things StableNet® from a sales, techie, or marketing perspective

Network Automation Insights

Stay tuned and keep informed with our blog series about the future of automation in network and service management

Automation Series – Part 6a

Network Automation – Monitoring and Tagging (Part 1 of a 3-Part Series)

November 24th 2021, Würzburg

It’s autumn. As days become shorter and evenings longer, it is the perfect time to issue another series of blog posts. This is the first of a set of three posts that will look at – amongst numerous closely related things – StableNet® implementations for monitoring automation. Such wording sounds probably a bit strange, because monitoring is automatic anyways you might rightfully say. Events come in, monitor thresholds get triggered and alarms are raised. What else could one expect from fault monitoring automation?

Well, a lot. It definitely starts here, but there are way more capabilities and significant differentiators when looking at the StableNet® toolkit you have at hand to collect data, leverage the available options for surveilling and finally create specific visualizations for scenarios that matter most to you.

configuration management

Measurements and Monitors

Unlike many other network management systems, StableNet® provides a unique concept in regards to measurements and monitors.

A measurement in StableNet® is a recurring job executed by the StableNet® agent which collects data from network devices in a fixed time interval. It can be used for monitoring, performance analysis, visualization, reporting etc. A single measurement may contain multiple values at once.

Each recurring measurement execution creates a new data entry that is added to the StableNet® database periodically with a timestamp and the measured values.

StableNet® measurements are a prerequisite for monitors that control for predefined value ranges and compare them to configured thresholds. The monitor triggers an alarm once the condition is violated or exceeded. Measurements are grouped into different categories named Runtime, Application, SNMP, Flow and Fault.

All supported measurement types are located within those categories. Although they use different technologies and methodologies, what they provide is a fully-fledged data gathering toolkit for network operators. Some of these measurement types include: ping, IP SLA, wmi, tcp, script, external, SNMP, flow, syslog, trap, derived and status measurements.

Measurement concepts provide the foundation of data collection and form the baseline for “how” use cases can be implemented and automatically monitored by StableNet®. It is, therefore, worthwhile to explore a subset of the ones with “not-so-obvious names” and explore how they work.

SNMP (Template/Interface) Measurement

The Simple Network Management Protocol (SNMP) is supported by almost every networked node and many other devices that allow for SNMP data collections. Query parameters are defined in the Management Information Base (MIB). In addition to some general standard definitions (e.g. MIB-2), many vendors provide enterprise-private MIB definitions that contain more specific information or more precise data.

With an SNMP template measurement, it is possible to query arbitrary values from a device by using that protocol. An SNMP template tells StableNet® what specific SNMP values to read, the corresponding units, the semantic meaning and eventually what further calculations should be done with them.

Each StableNet® deployment ships with predefined SNMP templates that allow out of the box usage. StableNet® facilitates template handling (create, import, export, and delete) with an inbuilt SNMP Template Manager. The entire template syntax is documented in detail with examples to develop new or customize existing SNMP measurements.

An SNMP interface measurement is a more specialized version of the SNMP template measurement. All important MIB variables of network interfaces are queried by them. These include number of packages, bandwidth usage, and error counts to have them readily at hand.

Note: SNMP measurements require the correct SNMP read community of the respective device. If access lists are configured, the StableNet® Agent must be allowed to query the SNMP device.

Derived (Rule) Measurement

A derived measurement is a logical operation and translates to a combined monitor whose overall state depends on its associated monitors. A Boolean expression calculates the overall derived monitor state whenever one of the referenced monitors changes.

Supported Boolean Operators are:

  • AND = &
  • OR = |
  • NOT = ~
  • XOR = ^
  • X of Y = :Xof{Y} e.g. translates to :2of{a,b,c,d}

Let’s look at a derived rule measurement (DRM) by a simple use case example:

Two redundant access routers are connected to different service provider uplinks. The agreed SLA for uninterrupted connection is 99.9% availability during business hours. A violation occurs if both routers fail. That SLA logic is easily represented by a DRM, which combines various router reachability and interface monitors for the entire setup.

Any monitored KPI can be used as component for logical evaluations within a DRM. This provides great flexibility for SLA and business process validations within StableNet®.

The end … for now

That’s it for the first part of this continuing blog post. In the next posts I will continue to look at different unique measurement concepts (including syslog and DRG), I will explore in greater detail the relationship between monitors and measurements, and will end with a discussion on how tagging can facilitate workflows. So stay tuned…

Cookie Consent with Real Cookie Banner