Manageability

Visibility of an Archipelago based system or subsystem is unusually pervasive, every component reports its state when prompted in a simple composable form. The unit of reporting is a JSON fragment, these fragments are hierarchically composed into full reports for a single reactor or a group of reactors right up to the full system. Being JSON the transmission, parsing and rendering effort required to access and present live system detail is substantially reduced.

We dedicate reporter components to request, harvest and collate report content asynchronously; this allows us to decouple report requests from their collection and generation, reducing the demand on components, allowing them to ignore requests, when under load or where no new changes have been recorded. The overhead for reporting status is surprisingly low.

Accessing status information, component configuration and structure definitions is not limited to our REST based reporting interface, we can broadcast over JMS for example, open direct socket based access or even support a shell based console.

We are not big fans of copious logging output, understandably; log files have recently been the focus of many data analytics and machine learning studies and projects. Handling and processing huge volumes of informationally meagre data is not fun for a machine let alone for an engineer on a support call.

So what do we propose?

• Event logging
  

  Life-cycle events,connections,flows,boundaries and limits and all significant semantic events are recorded.

• Rolling in memory log buffers
  

  We capture log output in cyclic line buffers which only output following a logged warning or error to provide context, trailing context is output for a period of time.

Our suggestions maybe don't provide the same guarantees that recording everything endlessly does but we believe in logging should be performed by necessity not unconsciously, however we can accept that clients may have more conservative views and our strategy for logging is optional and traditional logging is simply enabled.

We harness our status output to drive dashboards, we have previously developed our own dashboard designs complete with rich graphical output and system control and configuration functionality using REST, HTML5, WebSockets, CSS and obviously JavaScript but we prefer to delegate the design of dashboards to our web development partners or defer back to our clients for their consideration.

We will propose protocols and APIs for communication between dashboards and our systems but will match and comply to any protocol or API you require.

Due to our ability to aggregate hierarchical data we can support dashboards presenting and controlling any structural grouping or hybrid collection of systems.

Beyond the basic process level monitoring of our JVM processes we can supply system data via JMX by defining suitable MBeans to augment the default MBeans published by all JVM processes.

We generate heartbeat messages internally and can expose these or variants on demand via any reasonable interface. These are a basic guarantee of health and can be analyzed to provide detailed health reporting and loading indications.

We publish resource consumption figures via our status reporting mechanism and also by default via JMX (if enabled).

Our unit of deployment is the JAR file. We bundle configuration and resources in the deliverable. Site configurations are not typically overridden and are merged at process startup. Similarly preferences are not overridden and survive version upgrades. We adapt our deployment scripts to your requirements and aim to hand over to our processes as soon as possible for all deployment phases and tasks beyond initial invocation.

Deployment requires site configuration in terms of the plant, network, security and other unpredictable factors, we try hard to provide detailed reporting and monitoring data from our systems when running in a pre-enabled state during this challenging phase to assist the configuration efforts.