Kronometrix lets you have a numbers of light recorders specific for certain purpose: monitor CPU, DiskIO, NetIO, or some application. At some point of time you want to add or modify certain metrics from your recordings. You are restricted to do that using SAR, unless you are a kernel developer or you plan enhancing the tool. Kronometrix on the other hand can easily be modified and enhanced in matter of minutes.
For example, lets say you plan to monitor the number of file descriptors per process. You cant use SAR for such thing, so most likely you will need to write your own probe, script or use another standard OS utility. Instead of these you can easily use procrec and if you are not happy with the results change the recorder as you please.
SAR still remains a very useful monitoring tool, which ships with Kronometrix by default for Linux based operating systems. Kronometrix can use SAR by default, if needed.
Kronometrix tries to stay simple and follow GCaP methodologies and help you build a capacity plan for your IT infrastructure. Majority of the current commercial IT performance monitoring solutions are complex and large. They include application performance monitoring, end to end monitoring modules along with event alerting. These make them good for certain goals, bad for the other purposes. You need to dedicate a lot of time to learn and administer such systems. Kronometrix focuses on: performance monitoring, analysis and forecasting. At the end you should have a simple Capacity Planning model for your site or application, with minimal time spent and investment.
They are all good for their job. Some started as network monitoring solutions, some measuring clusters and grids, majority showing plots about data all over. Kronometrix tries to gather and have a logic between the data collected and the way to show it and it follows a path towards capacity planning. As mentioned, Kronometrix is a proof of concept built around GCaP methodologies.
What's better in Kronometrix:
It's simple: in general, each recorder is implemented as a command-line interface utility. Exception is Windows where our recorders are done as Windows services. Simple and easy to use for long and short trend analysis. As well our data recorders are simple to install and setup across a large number of hosts.
The documentation: from manual pages to a simple help option which should describe the metrics collected from operating systems or applications. We are listing all our system metrics what we collect and we try to explain why would they matter.
It's modular: we believe one tool cannot do all jobs. So we have assigned different tasks to different recorders, making easy and simple to update a recorder without to break others.
The descriptive analytic: Kronometrix is trying to deliver a compact and ready to use user interface for reporting all collected data intended for basic monitoring and Capacity Planning and Performance Analysis.
We love GCaP: Kronometrix is designed for performance analysis from recording to data analytics, built on top of principles from Guerrilla Capacity Planning class by Performance Dynamics Prof. Dr. Neil Gunther.
Zabbix delivers a native, binary agent for each operating system it supports. The recording system is developed in C and the reporting backend in PHP. We dont want to develop yet another monitoring daemon based system in C, but in fact we want the opposite: we want to extract various metrics from OS's interfaces using simple recorders developed in a dynamic language, which can be easily customized, changed, modified.
Fundamental differences between Kronometrix and Zabbix:
Raw Data: there is no such concept in Zabbix. This is also valid for other performance monitoring tools: Munin, Zenoss, Ganglia, Cacti.
Language: Our recorders are implemented in a dynamic language.
Simple Reporting: Kronometrix is trying to deliver a compact and ready to use interface for a real-time data anlytic appliance, designed for IT computer performance analysis.
Monitoring each host as closely as possible means more accurate and complete data. Kronometrix is an agent based monitoring system which runs continously on each host. If needed, Kronometrix data recorders can be used as an agent-less system as well.
Because it is the human experience behind the performance analysis process not a specific software package. Majority of the IT companies simple buy software to replace people or their competence. That's wrong. And GCaP really helps you understand this and correct it. In addition, GCaP has all needed pieces to understand performance analysis and help you build a capacity plan for a site or a specific application without using any software package nor selling you one.
Kronometrix data recording module includes several light Perl5 based processes designed to collect data from particular parts of the system: CPU, Memory, Disk and Network components, and additional for different other jobs: JVM, Solaris Zones, process statistics, or applications. The decision is based on our long experience observing different type of operating systems and workloads, from production to test bed systems.
We selected this approach because:
Flexibility: easily configure different recorders to run on different time resolutions. It is simple to run or stop some data recorders , if required, without affecting the others.
Modularity: 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 a critical error within a data recorder will not cause a total failure on all the other data recorders.
Simplicity: we can add or change a data recorder within minutes. Having data recorders based on Perl5 is allowing us to change or add new functionalities quickly and simple.
Simplicity was one of the main reasons behind it. Perl5 is a mature programming language with a very rich support of extracting data from any system: Solaris, Linux, FreeBSD, Windows. Perl5 as well has a very powerful regular expression engine which is allowing us to process data very simple.
Another important reason was customer's environment, for example in the financial and banking sector. Usually such customers do not allow easily to add or install certain Perl5 modules on top of the operating system. Even more they have very strong requirements what operating system packages they manage.
In early times, Kronometrix was around 400KB in size. After approaching large bank customers we needed to re-tink and adopt another mechanism to deploy Kronometrix in such networks.
We support a large number of operating system releases, which are using different versions of OpenSSL. For example for CentOS/RedHat based systems we support from CentOS 5 to latest 7. CentOS 5 uses OpenSSL 0.9.8 and latest CentOS 7 release uses 1.0.1 OpenSSL.
In order to minimize the need to install extra libraries and depend on different packages, we have decided to include OpenSSL directly in Kronometrix. This makes things simple and ensures Kronometrix uses the correct OpenSSL libraries without interfering with the main operating system.
Currently we are supporting Linux, FreeBSD, Windows as the tier 1 platforms. This means we are using these, types of operating systems to develop and test all our new features on. Tier 1 platforms for Kronometrix: FreeBSD 10, Debian 7, CentOS 5 32/64bit, Windows 2008 64bit. Tier 2 platforms: Solaris, MacOSX, HP-UX, AIX.
This is Kronometrix's footprint in terms of cpu, memory and disk:
CPU: on an idle host, Kronometrix utilization is less than 0.5%. On a busy system 95-100%, the data recorders use up to 3%.
Memory: All default data recorders use up to 64MB RAM including the transport utility. Windows data recorders use 128MB RAM.
Disk: the default installation, without raw data uses up to 75MB disk space and the data recorders are not disk IO iintensive applications.
Kronometrix uses the data source id, (dsid) concept to identify a source where one or many data messages are coming from. For IT, Computer Performance data, a dsid identifies to a host or computer system, physical or virtual.
Make sure your virtual machines are not cloned using a similar machine-id file, used by the DBus service. If your virtual machines are cloned including the machine-id file, then sender will always report that.
Please correct the machine-id file on all your virtual machines, before running Kronometrix transport utility. DBus service, depending on the distribution release, will keep a machine-id under /var/lib/dbus or /etc, as an UUID to identify each host. If you clone a virtual machine with an existing machine-id file, then all your clones will have a similar host UUID.
Yes, we would like to receive help, thank you. We will need support to continue our work on MacOSX, HP-UX and AIX. If you are interested please contact us.