Recently at work I got myself involved in revamping our monitoring system. This got me thinking about all of of the things a monitoring system should do for you and the needs of systems people for internal tools. Basically, for each type of system you want to monitor (os, jvm, webserver, etc) certain aspects should be defined on both the front-end and back-end of the app.


Reporting

entity	Collection	Storage	Thresholding	Alerting	Display	Trending
OS	SNMP	RRD	disk too full? CPU too high?	snmp traps, email	RRD for cpu, disk, net	Monthly rollup/curve extrapolation
Apache httpd	curl/mod_status	RRD,csv	values out of whack?	snmp traps, email	apache-specific template	Monthly rollup
JVM	JMX	RRD	GC too long? Old Gen too full	snmp traps, email	increase heap?

And that doesn't even start to get into the front-end needs for OLAP-style reporting needed for all of this stuff, a wiki to document everything, an admin interface to define new templates and collections, etc etc etc.

Another important aspect is a decent live console for 24/7 operations to watch for all of those Alerting things.

Labels: project ideas

This is how I compiled openldap once. It allowed me to have all the dependencies available when I tar-ed up the openldap dir and distributed it around.

export LDFLAGS="-L/usr/lib/lwp/64 -L/lib/64 -L/usr/lib/64
-L/usr/sfw/lib/sparcv9 -Wl,-R/usr/lib/lwp/64 -Wl,-R/lib/64
-Wl,-R/usr/lib/64 -Wl,-R/usr/sfw/lib/sparcv9
-L/usr/local/openldap64-ol2.3.23-bdb4.2.52/lib
-Wl,-R/usr/local/openldap64-ol2.3.23-bdb4.2.52/lib -m64"


export CPPFLAGS="-I/usr/local/openldap64-ol2.3.23-bdb4.2.52/include"


export CFLAGS="-m64 -O2"

Labels: c programming, ldap