7th August 2011

Abilisoft release the first version of its Universal Probe technology

Today Abilisoft announced the first formal release of its unique collection layer technology, the Universal Probe.

The Abilisoft Universal Probe (UP) is a highly scalable, highly configurable, multi-protocol collection layer probe. It is an integration technology that is able to perform high volume data collection, customised processing and data dispatch to one or more destinations.


  • UP decouples ITSM layers liberating you from vendor lock-in.
  • UP consolidates and simplifies complicated, heterogeneous environments.
  • UP reduces cost by replacing cumbersome, hard-to-manage, over-utilised or over-engineered system components.
  • UP is quick and easy to install.
  • UP can be installed on multiple platform architectures.
  • UP scales - it can process very high data volumes.
  • UP supports high-availability configurations.
  • UP is versatile, a single instance can fulfil multiple roles.
  • UP sets no limitation on routing collected data to multiple destinations simultaneously.

How is UP used?

UP data sources include servers, network devices and telecommunications equipment. Data collected can be:

  • Performance and availability data from managed servers and devices e.g. Abilisoft MA or a network switch
  • Data from another vendor’s ITSM system
  • Network performance data

Once processed, transformed data can be dispatched to:

  • Another vendor’s ITSM system
  • Abilisoft’s own availability and performance data managers
  • E-mail recipients
  • Any database

UP is the perfect ITSM component to implement:

  • Performance and availability data triage
  • Noise suppression
  • Flood protection
  • Fulfilment of requirements not supported by the incumbent ITSM system

Additionally UP provides a plethora of data routing opportunities due to its capable rule processing engine. UP is a small footprint, easy to install daemon. Logically, UP consists of:

  • Listeners. Listeners collect data and a single UP instance can be configured with different listeners for various protocols. Examples include SNMP-Trap, SysLog, Netflow, Performance and SystemX. A Listener is configured with an entry-point Rule Chain.
  • Rules Engine. The rules engine executes Rule Chains, an ordered sequence of rule definitions expressing the processing logic for inbound data collected by a Listener. The rules language is based on Python; a rich general-purpose, reflective, high-level programming language whose design philosophy emphasizes readability and testability. It supports multiple paradigms, including object-oriented, imperative and functional styles. It features a dynamic type system, automatic memory management and has a large and comprehensive standard library. This makes the rule processing possibilities almost endless. Rule processing is simplified and enhanced by the UP Chain-API, a set of features that ease rule development. Rules within a chain can call other chains or pass control to them entirely. At any point within a rule chain, data can be propagated using a Dispatcher.
  • Dispatchers. Dispatchers propagate data to a destination and a single UP instance can be configured with different dispatchers. Examples include Netcool, BEM, Abilisoft Reef, Abilisoft Performance Data Manager, SMTP and a number of databases like Oracle, DB2, Sybase, PostgreSQL and No-SQL databases like MongoDB.

Other Features
  • Web API. UP exposes a REST-ful API that enables remote management of the UP daemon. This includes UP status, the ability to examine listeners, rule chain and dispatcher status, data throughput and resource usage; Rule chain, listener and dispatcher management.
  • High Availability. UP can be configured in high-availability pairs. A primary UP is configured to send a "heartbeat" to a failover UP. Both UP instances are configured to listen to the same data sources and as long as the failover UP detects the primary UP heartbeat, it will discard all data it receives. If the failover UP fails to get a primary UP heartbeat after a specified time it will stop discarding data and start processing and dispatching, as if it were the primary instance. It will continue to do this until heartbeats from the primary instance resume. When they do, the failover will once again discard received data. There is no loss of data and no runtime “change of role”, the primary is always the primary and the failover is always the failover. Because multiple dispatchers can be configured further high availability options are available using redundant data destinations.
  • Platforms. UP can be installed on a wide range of platforms including Red Hat Enterprise Linux, Debian, Ubuntu and Solaris (x86 and SPARC)