-
Notifications
You must be signed in to change notification settings - Fork 3
Modules
This page lists the various components and their constituent modules.
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.
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
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.
- Network/Node discovery and monitoring
- Monitoring (Sensors)
- Event subscription and delivery
The dxdb component provides an API for storing the user and subscription records which the rest of the system relies heavily upon.