SDR 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. SDR 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 SDR by default for Linux based operating systems. SDR can use SAR by default, if needed.

SDR 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. SDR 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. SDR tries to gather and have a logic between the data collected and follow a path towards capacity planning. As mentioned, SDR is a proof of concept built around GCaP methodologies.

collectd is a fine system performance collector based on plugins. It does support several Operating System platforms, outputting data for different formats: RRD, CSV using output plugins. Some points between SystemDataRecorder and collectd:

• Interface: in general, each recorder is implemented as a command-line interface utility. Exception is Windows where our recorders are done as Winodws services. Simple and easy to use for long and short trend analysis.

• Simplicity: Each recorder must have a manual page and a simple help option which should describe the metrics collected from OS or applications. Each recorder should not deliver complex logic supporting many Operating System interfaces within same recorder. Use one thing at the time, but use it well.

• Modularity: 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.

• Simple Reporting: SDR is trying to deliver a compact and ready to use interface for reporting all collected data intended for Capacity Planning and Performance Analysis.

• GCaP: SDR is designed for performance analysis from recording to reporting, 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. See Faq 6.

Fundamental differences between SDR 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: SDR is trying to deliver a compact and ready to use interface for reporting all collected data intended for Capacity Planning and Performance Analysis.

Monitoring each host as closely as possible means more accurate and complete data. SDR is an agent based monitoring system which runs continously on each host. If needed, SDR 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.

SystemDataRecorder, so it means Recording. However you can have custom made packages for your installation where all recorded data can be displayed and lots of reports are available. The main idea of SDR is to combine the recording side with a light reporting module, based on RRD and Perl.

No. Sensor Data Repository is used by ipmitool. When using ipmitool S-D-R means totally something else. SDR stands for System Data Recorder.

SDR recording part includes several recorders designed to collect data from a particular parts of your systems: CPU, Memory, Disk and Network and additional recorders for different other jobs: JVM, Solaris Zones, applications etc. Instead of having one, two general recorders we tried to design 4 main recorders which can be easily maintained and ported and others specialized for other purposes. Simplicity was the main criteria.

Simplicity was one of the main reasons behind. KSTAT interface in Solaris can be accessed via a Perl or C program. Brendan Gregg, the author of sysperfstat inspired me to keep using the same way, KSTAT scripts. When I was not able to obtain the information from KSTAT I used a simple Ksh script calling basic OS utilities. This last part needs improvement, example here zonerec, jvmrec. The main goal is to use as few utilities as possible and gather all data from OS interfaces.

systemdatarecorder.org is a not-for-profit project, focusing on: performance analysis, visualization and capacity planning.

systemdatarecorder.com is for profit company, called SDR Dynamics Oy, which sells services and products around SystemDataRecorder project. If you are interested in buying support, services please contact them directly.

Yes, we would like to receive help, thank you. We will need support porting our data recorders to FreeBSD and MacOSX. If you are interested please contact us

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. SDR tries to gather and have a logic between the data collected and follow a path towards capacity planning. As mentioned, SDR is a proof of concept built around GCaP methodologies.