Seriously, I said that to myself.  In all reality I had a basic understanding of the concept of CPU load on a Linux server, but there were a few things I learned recently and I figured I’d share with the world.

Our digs here at LogicMonitor are cozy. Being adjacent to sales, I get to hear our sales engineers work with new customers, and it’s not uncommon that a new customer gets a rude awakening when they first install LogicMonitor. Immediately, LogicMonitor starts showing warnings and alerts.  ”Can this be right or is this a monitoring error?!”,  they ask. Delicately, our engineer will respond, “I don’t think that’s a monitoring error. It looks like you have a problem there.”

While most may not see Microsoft as a ‘disruptive innovator’ anymore, they seem to be claiming exactly that role in the enterprise hypervisor space, just as they did in gaming with the Xbox. As noted in “VMware, the bell tolls for thee, and Microsoft is ringing it”, Hyper-V appears to be becoming a legitimate competitor to VMware’s dominant ESXi product.

We use snmp a lot, and know it well. However, not everyone of our customers has spent years working with OIDs in ASN.1, MIBs, Access types, and so on – and nor should they. (As we like to say, “Your monitoring solution should make your life easier, not harder.”) So one question we often get is the difference between the different SNMP versions.

As the new hire here at LogicMonitor brought in to support the operations of the organization, I had two immediate tasks: Learn how LogicMonitor’s SaaS-based monitoring works to monitor our customer’s servers, and at the same time, learn our own infrastructure.

A company started a trial yesterday, added a bunch of windows hosts, and immediately got warnings triggered that their hosts were “receiving 42 datagrams per second destined to non-listening ports…Check if all services are up and running.”

If you have decent NetApp monitoring, you should of course be monitoring the thing that matters  – and (for most applications) that is the latency of requests on a volume (or LUN.)

Recently we rolled out a new release of LogicMonitor. Among the many improvements and fixes that users saw, there were also some backend changes to the Linux systems that store monitoring data. The rollout went smooth, no alerts were triggered – but it was pretty easy to see that something had changed:

A customer contacted us this week and said “Hey, one of my filesystems that was being monitored by LogicMonitor disappeared after I grew it.”  Turns out the filesystem in question was now a bit over 2 terabytes. Some poking around showed that the file system was being filtered out of discovery, as net-snmp was reporting a size for the file system (via 1.3.6.1.2.1.25.2.3.1.5, hrStorageSize) of -1982127408. Yes, that’s a negative value.