SIGAR - System Information Gatherer And Reporter

Overview

The Sigar API provides a portable interface for gathering system information such as:

• System memory, swap, cpu, load average, uptime, logins
• Per-process memory, cpu, credential info, state, arguments, environment, open files
• File system detection and metrics
• Network interface detection, configuration info and metrics
• Network route and connection tables

This information is available in most operating systems, but each OS has their own way(s) providing it.
SIGAR provides developers with one API to access this information regardless of the underlying platform.
The core API is implemented in pure C with bindings currently implemented for Java, Perl and C#.

The following platforms are currently supported:

Operating System	Architecture	Versions	Binary Included
Linux	x86	2.2, 2.4, 2.6 kernels
Linux	amd64	2.6 kernel
Linux	ppc	2.6 kernel
Linux	ppc64	2.6 kernel
Linux	ia64	2.6 kernel
Windows	x86	NT 4.0, 2000 Pro/Server, 2003 Server, XP, Vista, 2008 Server
Windows	x64	2003 Server, Vista, 2008 Server
Solaris	sparc-32	2.6, 7, 8, 9, 10
Solaris	sparc-64	"
Solaris	x86	8, 9, 10
Solaris	x64	"
AIX	PowerPC	4.3, 5.1, 5.2, 5.3
HP-UX	PA-RISC	11
HP-UX	ia64	11
FreeBSD	x86	4.x
FreeBSD	x86	5.x, 6.x
FreeBSD	x64	6.x
OpenBSD	x86	4.x
NetBSD	x86	3.1
Mac OS X	PowerPC	10.3, 10.4
Mac OS X	x86	10.4, 10.5

While SIGAR only depends on the Linux kernel version, the following distributions have been certified:

To test drive run the following command:

% java -jar sigar-bin/lib/sigar.jar
sigar> help

The shell and commands are implemented in Java, the source code is located in
bindings/java/src/org/hyperic/sigar/cmd/.
Including implementations of well-known commands such as:

• df

• du

• free

• ifconfig

• iostat

• netstat

• ps

• route

• top

• ulimit

• uptime

• who

Perl and C# interfaces are still a work in progress.

To try the Perl examples:

% cd bindings/perl
% perl Makefile.PL && make
% perl -Mblib examples/ifconfig.pl

License

SIGAR is licensed under the GNU GPL

Binaries

The SIGAR binary distribution contains the following files in sigar-bin/lib:

* == Required to run on listed OS + Architecture combo For example, minimal requirements to use the SIGAR Java API on Windows would be sigar.jar and sigar-x86-winnt.dll

Versions

SIGAR uses a common versioning scheme: major.minor[.revision[.build]]
The revision number is incremented when binary compatibility is broken between the .jar and the native libraries. This can happen if a new API function is added or a field is added to an existing one. The build number is incremented for bug fixes or enhancements specific to the .jar or a specific native library. For example, an issue where memory metrics were incorrect on Solaris machines with 8GB of RAM. Such as change does not impact the interaction between sigar.jar and the native library.

Download

SIGAR binary and source packages are available from sourceforge.
You can also browse SVN or checkout the stable branch via:

% svn co http://svn.hyperic.org/projects/sigar/branches/SIGAR_1_5

The development/unstable code is available in the trunk:

% svn co http://svn.hyperic.org/projects/sigar/trunk sigar

Building SIGAR

The native library, Java JNI bindings and Java classes are built using the same build system which has the following requirements:

• JDK 1.4 or higher
• Ant 1.6.5 (Ant 1.7.0 is not currently supported)
• Perl 5.6.1 or higher
• C compiler

Perl is required to generate much of the JNI code as well as many of the Java classes. The ant build system uses a modified version of
cpptasks which works on all platforms supported by SIGAR. The native library can be used by the following:

• Pure C/C++ applications
• Java applications (sigar.jar auto-loads the native library)
• Perl applications (requires bindings/perl compilation of XS code)
• .NET C# applications (requires bindings/csharp compilation)

Note The native library includes Java_org_hyperic_sigar_* functions, however there are no JRE dependencies for pure C/C applications using SIGAR. The Java JNI interface uses runtime linking and a function-pointer interface which allows us to combine both the sigar_ C API and JNI implementations into a single library. If this is not desirable, it would be trivial to have your own project build system simply compile src/*.c and src/os/$osname/*.c, then link the object files directly into your library or application.

Example build:

% tar -zxf hyperic-sigar-1.5.0.1-src.tar.gz
% cd hyperic-sigar-1.5.0.1-src/bindings/java
% ant

Results in:

% ls -1 sigar-bin/lib
libsigar-universal-macosx.dylib
sigar.jar

Test using:

% java -jar sigar-bin/lib/sigar.jar test

Bugs

SIGAR bugs are tracked using JIRA and issue numbers are included with svn commits and the ChangeLog.
Note that SIGAR started using JIRA to track issues after the 1.1.29 release. Consult the ChangeLog if you wish to see issues resolved in older versions.

Forums and Mail Lists

• SIGAR Users Forum | sigar-users-subscribe@hyperic.org
• SIGAR Developers Forum | sigar-dev-subscribe@hyperic.org
• SIGAR SVN Commits | sigar-svn-subscribe@hyperic.org

History

SIGAR was designed and implemented by Doug MacEachern at Covalent Technologies starting in September of 2002 and has continued with Hyperic as a core component of the HQ product.
SIGAR is not the first attempt to provide a cross-platform API to collect system information. In fact, SIGAR was inspired by libgtop which has been around since 1998 or so and was at version 1.90 when the SIGAR project was started. Doug released a Perl interface to libgtop in December of 1999 upon which Stas Bekman implemented Apache::VMonitor.
Based on that experience, Doug had become a big fan of the libgtop concept, but in practice only had success using it on Linux and with some struggles on Solaris. At the time the SIGAR implementation decision was made, libgtop had become a GNOME component for which there only appeared to be ongoing support for Linux and did not have implementations for other required platforms such as Windows, HP-UX, AIX and Mac OS X. Another requirement was a thread-safe Java interface and the ability to ship a single package containing binaries for all supported platforms. Long story short, libgtop was not the right fit for the requirements but the concept was: An abstract interface defined by C structures and function prototypes with an underlying implementation for each platform to gather the data. So that concept was borrowed, but the implementation was done from scratch and has continued to evolve over the years with broader platform support, more features and language bindings.