Table Of Contents

Previous topic

Preface

Next topic

Getting Started Using Reef

Introduction

Abilisoft Reef is a web-based event management platform that collects and manages event data, thereby providing information about the status of an I.T. infrastructure that is being monitored. Basically Reef provides:

  • Event collection and processing. Reef accepts and processes inbound events inserted via an HTTP POST request. When an event arrives, Reef performs automatic de-duplication of events, and correlation with any existing events that have matching criteria. Event de-duplication reduces the number of actual events that need to be maintained by the system by matching events with the same key, and merging them. Event correlation finds matching fault and clear events in order to automatically clear a fault condition, reducing the user’s workload.
  • Event management. Reef serves an Event Management dashboard application that enables logged on users to view, sort, filter and manage events. Additionally Reef serves an Administration UI that can be used to manage users, groups, service and filter definitions and so on.

Reef is shipped as a WSGI application that may be installed behind a standard web-server (e.g. Apache). However for lightweight, engineering or demonstration deployments a simple web-server called ashttpd is shipped and can be used “out-of-the-box”. ashttpd is a fairly capable, multi-threaded web-server however it is recommended you use it behind a more powerful reverse proxy for production deployments.

Architecture

General Architecture below depicts Reef, its event sources and event management clients. On the left are the kinds of event sources which can send events to Reef. These include the Abilisoft Universal Probe (UP) and the Abilisoft Monitoring Agent (MA). In addition, custom event sources can be developed very easily. On the right are the Reef client applications that enable a user to view and manage event data. Events sent to Reef are processed and stored in the Events Database. Reef can be configured use one of a number of supported database technologies including Oracle, PostgreSQL, MySQL and SQLite. Refer to The Reef Datamodel to gain an understanding of the data structures that underpin Reef functionality.

Note

By default Reef is installed to use SQLite as the Event Database.

_images/reef_arch.png

General Architecture

The Reef client is a web browser application that interacts with the Event Management services interface provided by Reef. The client furnishes the user with a set of dashboards that present event information in a variety of ways. Furthermore the client allows a user to browse, take ownership, manually clear and delete events.

Reef Events

A Reef Event is a simple structure that describes a condition that an event source has encountered. Events arrive at Reef via an HTTP POST request, pay-loaded with a simple JSON structure representing one or more events. Some of the event fields are used to help Reef process it, and some are set by Reef during processing and event management via the Reef client. An event has many attributes including a key that uniquely identifies the event with respect to its origin, a severity, label, description and so on. Refer to The Reef Event Datamodel where the event data model is described in detail.

Additional Event Fields

Inbound Reef Events may contain fields that the event processor does not recognise but that’s okay. The event processor will still store these additional attributes and make them available for inspection in the Reef Client.

Event Logs

During an event’s lifetime its attributes might be modified, for example an event source may send a Reef Event with a modified severity. When this happens, the event processor will create an Event Log entry which will be related to the original event. An event’s logs can be viewed in the Reef Client.

Event Ownership

Using the Reef Client a user can take ownership of an events by acknowledging them. Once an event is acknowledged the user’s username is recorded in the event’s owner attribute.

Event De-duplication

Inbound Reef Events with the same key value won’t be recorded in the Reef database separately, rather the existing event’s count will be incremented and any field changes made and logged. This provides a natural de-duplication scheme driven by good practice in defining suitable keys at the event source.

Event Correlation

The Reef event processor will, during event insertion, check if the type of an event constitutes an automatic clear action. This provides an automatic correlation capability. Events can also be manually cleared via the Reef Client.

What’s New

This section contains Reef release notes. It lists important new features, changes and bug fixes. It is recommended that you read the relevant subsections whenever upgrading Reef.

MA 7.2 (donbot.2)

Important
  • Reef is now shipped with ashttpd, a much improved out-of-the-box, multi-threaded web server. It’s behaviour is much the same as asdjango which is no longer available. Please pay careful attention to the instructions for starting and stopping Reef using ashttpd as described in the section running-and-configuring-reef.
New and Noteworthy
  • Events with an unset owner field are displayed in the “By-owner” Summary dashboard event distribution pie chart as belonging to the pseudo user “nobody”. Clicking on this pie-chart segment will navigate the user to an event list dashboard showing all events with an unset owner field.
Fixed Issues
  • An insert-event race condition has been solved with much more robust front-end event processing.
  • On insert, an event’s first and last fields were set to local time instead of UTC, this issue has been fixed.
  • The “By-owner” event distribution pie chart on the Summary dashboard didn’t show the count of events with no owner properly, this issue has been fixed.
  • The “By-age” event distribution click-through didn’t filter events by age correctly, this issue has been fixed.

Versions

During development new versions are referred too with code names, but for final releases a normal version number is used. Sometimes however the code name might be visible (e.g. in tar-balls), in that case this table can help with knowing the versions referred too.

Code name Version
amy.1 2.4.1
amy.2 2.4.2
amy.3 2.4.3
amy.4 2.4.4
amy.5 2.4.5
amy.6 2.4.6
brannigan.0 2.5.0
brannigan.1 2.5.1
brannigan.2 2.5.2
brannigan.3 2.5.3
brannigan.4 2.5.4
brannigan.5 2.5.5
calculon.0 2.6.0
calculon.1 2.6.1
calculon.2 2.6.2
calculon.3 2.6.3
calculon.4 2.6.4
calculon.5 2.6.5
donbot.0 7.0
donbot.1 7.1
donbot.2 7.2