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
or a group of reactors right up to the full system. Being JSON the
transmission, parsing and rendering effort required to access and
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?
Life-cycle events,connections,flows,boundaries and limits and all significant semantic events are recorded.
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 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.