Skip to content
hyperthunk edited this page Apr 17, 2011 · 3 revisions

This page lists the various components and their constituent modules.

Project Overview

Nodewatch is split across three main submodules: dxweb, dxkit and dxdb. Each submodule is implemented as an OTP Application and packaged into a release using rebar's release handling support.

DxWeb

This is the nodewatch web application. The application is structured into two main parts: the HTTP Server and the Event Bridge. The HTTP server handles all the webby stuff, including:

  • Handling basic HTTP requests for
    • static resources
    • dynamic resources (backed by a controller module)
  • Handling websocket connections
  • Maintaining session state

Note that because we use session state, nodewatch is a standalone application and is not (currently) designed to be clustered in any way. The HTTP Server is housed beneath a one_for_all supervision tree, ensuring that a restart of the misultin web server will flush all session data and associated websockets.

  • dxweb_http_server
    • Supervisor for the HTTP Server part of the application
  • dxweb_http_handler
    • Misultin callback routines for standard requests and websocket connections

DxKit

This is the diagnostic toolkit on which nodewatch relies for monitoring your application(s) and nodes. The Abbreviation DX is commonly used for diagnostic (i.e. diagnosis), which seemed fitting. This application is also split into several parts.

  1. Network/Node discovery and monitoring
  2. Monitoring (Sensors)
  3. Event subscription and delivery

DxDb

The dxdb component provides an API for storing the user and subscription records which the rest of the system relies heavily upon.

Clone this wiki locally