Interfaces

Nodewatch is intended to be extensible, providing a simple API for adding new (data and event) sources and destinations. The key concepts used to realise this extensibility are described here.

Publication and Subscription

All the mechanisms we will describe here, are based on a very simple pub/sub model that exists within the dxkit application.

The core API involved in mediating between participants in this model, is defined by the dxkit_event_bridge module. Incoming events are published simply by calling dxkit_event_bridge:publish_event/1. Subscriptions (to events) are managed using OTP’s gen_event mechanism, and can be created by adding a handler (callback module) to the event manager process registered as dxkit_event_handler (or by calling temporary_subscriber/2). Durable subscriptions (i.e., those that wish to be restarted if during a handle_event call they cause the calling process to exit abnormally) can be created with the dxkit_event_bridge:permanent_subscriber/2 call.

Sensors

A "sensor", in Nodewatch parlance, is an inbound interface. How a sensor goes about collecting relevant data is implementation dependant, but all sensors will make this data available by calling dxkit_event_bridge:publish_event/1.

Nodewatch comes with the following, pre-defined sensors:

Sensor	Module	Description
System	dxkit_sensor	OS-level stats, such as disk, memory and cpu
Network	dxkit_sensor	Network stats
Process	dxkit_sensor	Erlang (erts) process stats
Counter	dxkit_counter	Custom app/node performance counter

Interface Administration