Kronometrix

The TV Series ... Night Shift ? Nope, this is Kronometrix appliance for night workers, operators, sleepless system administrators and for the rest of us, working late. An appliance ? What do you mean ? To be serious about monitoring you better have an application running on a cloud platform, right ? Public or private, whatever that is, Google, Amazon, Azure or on a internal network powered by OpenStack, VMware ...  preferable deployed over a large number of nodes, using large memory configurations and offering advanced dashboards to keep track of hundreds of metrics collected from machines, storage, network devices, applications all available and ready to be ... read and digested by anyone. The duty admin is confused, what dashboards will be needed for basic performance monitoring and SLA and what metrics these dashboards should include ? We took a simpler approach with Kronometrix, which can be deployed on a cloud computing platform if really needed, which was designed to be:

Data Recording Module -  Five default, main, data recorders, written in Perl 5, responsible to collect and report: overall system utilization and queuing , per-CPU statistics , per disk IO throughput and errors , per NIC IO throughput and the computer system inventory data: sysrec, cpurec, diskrec, nicrec and hdwrec. But why not having a single process, simple to start and stop, and operate ? Does it matter, anyway ? One tool cannot perform all jobs. We believe that. We have assigned different tasks to different recorders, making easy and simple to update a data recorder without breaking the others. As well, we wanted to separate functionality based on the main 4 system's resources: CPU, Memory, Disk and Network. Additional we think it is very important to have a description of the hardware and software running on that computer system, sort of the inventory, that everybody understands easily what are we looking at. Saying these, we ended up using the fol

Kronometrix Data Recording Module , ships with a transport utility called sender , which ensures all raw data is shipped to one or many data analytic appliances over HTTP or HTTPS protocols.  sender,  a Perl5 citizen, checks all raw data updates and relies on a host uuid identifier from the operating system to deliver that raw data. If such host uuid is found will use that for the entire duration of its execution. If no such host uuid is found it will generate a new one and store that on its configuration file, kronometrix.json. The analytics appliance, relies that each data source is unique and valid, properly checked or generated by the transport utility, sender.  But what's happening if this really does not work ? Data Source Id Kronometrix uses the data source id concept, ( DSID ), to identify a data source point, from where one or many data messages are received. For example for IT, Computer Performance data, a DSID identifies to a computer system host, physic