For organizations on AWS looking for a monitoring solution, CloudWatch is an attractive choice. EC2 instances and services come with built in CloudWatch monitoring, and via SNS alerts can be routed to email or text messages. I recently had the opportunity to set up a new monitoring system for a client that backed into CloudWatch. It provided an interesting challenge since the project called for monitoring both application and system metrics.
My goal was to route all monitoring information through the same medium and store it in the same backend. While it is possible to provide application monitoring via statsd but system monitoring through something like collectd, I felt like it would be a cleaner solution to send all data over statsd and store it all in CloudWatch.
Developers really like working with statsd. It provides an easy, well supported way to write metrics out to a plugable backend. For example, the python pip module for statsd allows you to log metrics like this:
A colleague was showing me a compiler flag that needed to be included when compiling a program for Linux x86 Xen hosts: -mno-tls-direct-seg-refs. Being the curious person that I am, I googled around trying to figure out exactly what this directive was and why is was needed. From the gcc man page: -mno-tls-direct-seg-refs Controls whether TLS variables may be accessed with offsets from the TLS segment register (%gs for 32-bit, %fs for 64-bit), or whether the thread base pointer must be added. Whether or not this is legal depends on the operating system, and whether it maps the segment to cover the entire TLS area. For systems that use GNU libc, the default is on. But why Xen? Well, according to this thread, x86 systems (32-bit, *not* 64-bit x86_64!) use a weird trick to handle negative segment references. Xen is forced to emulate this behavior, which is slow. Normally, disabling tls-direct-seg-refs would incur a performan…
My home router is running a Linux firmware that uses Optware for package management. For various reasons I needed to get Transmission 2.42 running on it. The only pre-built packages I could find were for versions 2.41 and 2.61, so I decided to embark on the grand adventure of compiling C programs on my router.
For anyone not familiar with Optware, it's essentially the Debian packaging system set up to install all packages into the /opt directory. This is useful for embedded systems (such as routers) where the root filesystem is backed by nvram. The /opt directory can be placed on a flash or hard drive to avoid writing to nvram too often.
Setting Out For GCC
Understanding how C/C++ development is done under UNIX systems is a key piece of knowledge for systems administrators. The finer points of C programming are not as important in practice, but it behooves nerdlings embarking on the great UNIX Odyssey to know how thing…