The Library of Monitoring Objects, part 2
To process data from different industries and businesses we need to have a way to define and describe such data in a manner the analytic software will understand it. Kronometrix uses a simple and powerful concept for object definition, called the library of monitoring objects.
Suppose we want to handle data coming from Information Technology or Healthcare. Within these domains, we might have different sub-domains describing different types of analytic business. See how different domains and sub-domains map to LMO:
|The Library of Monitoring Objects|
For each industry we are interested in we need to develop and write a simple formal definition how data will be expected from devices and sensors from that field. Example:
We plan to gather information regarding Information Technology, System Performance domain. For that we need to define and describe all messages expected from this field. Example computer_performance.it.json filename. This file describes all needed metrics from this field.
When we know what we plan to do, and from where our data will come from, we need to define a number of host types, which describe where data is generated from. For example fetching data from a number of computer systems, we need to define each type of system we plan to collect from: a Linux or Windows computer system or a FreeBSD server:
These are the host types, linux, freebsd, sunos and windows. If, for example, we plan to collect data from a new type of server, lets say AIX, we should add it as well into LMO.
Knowing the hosts will allow us to get finally to the metrics, to the parameters we plan to monitor and observe. A host, for example FreeBSD, can have one or many types of metrics we plan to records. We organize these metrics into messages, a group of metrics coming from data source.
A host can have one or many data messages, FreeBSD for example having 5 data messages: sysrec, cpurec, diskrec, nicrec and hdwrec.
For each message type, for example cpurec, we define a number of metrics, which we want to monitor. Field 0 and 1 are metadata fields required for handling the authentication and host range definition. The next one, field 2 is the defined timestamp followed by a device_id field describing what part of the system we plan to monitor, in this case each CPU, cpuid.
Below a complete message definition for cpurec:
|cpurec data message|
Next time, we will talk about summary statistics within LMO.