New CPU Usage Plugin

By Andre Bullet_white Posted in Plugins Bullet_white Comments Comments

Eric Lindvall of Cloudvox has created a CPU Usage plugin for the Scout directory.

The plugin uses the same underlying data that vmstat uses in /proc to give you the CPU usage for the full duration between scout runs.

This means the sampling interval for the plugin is equal to your Scout execution interval -- three minutes for an Ultimate account, etc.

Understanding CPU Usage Metrics

The CPU Usage plugin provides the following:

  • % System: percentage of time spent in the kernel
  • % User: percentage of time in "userland" (your code, apache, mysql, etc)
  • % IO Wait: percentage of time waiting for the disk to return data
  • number of running processes: processes that are being processed by the CPUs
  • number of blocked processes: processes that are waiting for IO (or possibly other things).
  • number of interrupts per second

Eric elaborated on the interrupts metric:

The interrupts per second metric is very interesting because it gives you insight into part of what the kernel is doing in the "System" time. Also, many times a high interrupt rate can be an indication of mis-configured hardware like a NIC.

There isn't a single "good value" for number of interrupts/second, Eric explains:

A lot of it depends on the connected devices, their configurations, and the amount of throughput the device is doing.

... however, you can should watch the int interrupts /sec metric after OS changes:

One nice thing this will show you is if your interrupts/sec spikes after a kernel upgrade, one of the upgraded drivers may be doing something bad that it wasn't doing before.

Different from Server Load

Note that this plugin is distinct from the Server Load plugin. For information on load averages, see our understanding load averages post from last year.

Thanks again to Eric Lindvall of Cloudvox. As always, drop us a note at support@scoutapp.com if you have questions.

 

PostgreSQL Monitoring Plugin

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

Robert Coup of Koordinates has added a PostgreSQL monitoring plugin to the Scout Plugin Directory. It’s about time PostgreSQL got some love from the Scout community!

The PostgreSQL monitoring plugin tracks the basics you really need to know about your PostgreSQL setup (query rates, buffer cache hits, etc).

Don’t forget that you can get alerts when these metrics change dramatically using Scout’s triggers. For example, you could create a trend trigger to alert you of a dramatic drop in the Buffer cache hit rate.

You can view more details about the plugin in our directory.

Like all Scout plugins, using the PostgreSQL plugin is just a button click away – no scripts to install or configure.

If you run into an issue with the plugin, shoot us an email at support@scoutapp.com. We maintain a test suite for the plugin, so we’d love to document and fix your issue.

 

Oink + Request Log Analyzer = Rails Monitoring in one report

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

If you’ve ever had to track down a memory leak in a Rails application (and who hasn’t forgotten to use will_paginate occasionally), you’re probably already familiar with the excellent Oink plugin by Noah Davis. Oink spits out the actions that are leaking the most.

Oink is a huge help when tracking down a memory leak. However, it doesn’t overcome my laziness. Tracking memory usage is extremely important – talk to any dedicated Rails host and they’ll tell you memory leaks are behind many crashed servers. To make monitoring memory usage less involoved, I needed 3 additions to Oink.

Read More →

 

The Page Load Paradox

By Derek Bullet_white Comments Comments

The irony is that, with broadband nowadays more or less everywhere, overall connection speeds have gone up by leaps and bounds, yet the time taken to load web pages seems only to have got longer.

- World Wide Wait, The Economist, Feb. 12 2010

For more than 40 years, a one second response time has been the accepted limit for giving users the feeling they are freely navigating an interface [Miller 1968; Card et al. 1991]. However on the web, we operate with a different set of rules – we’ll hear anything from two seconds to eight seconds as the limits for response time. Even at the most aggressive threshold, it’s 2x the limit for a free-flowing user experience.

ShowSlow, a nice web service for uploading YSlow data, illustrates that many (if not most) of the Alexa Top 100 sites have load times greater than two seconds. If this Forrester study is correct, we’ve got a lot of frustrated people out there (Forrester isn’t the first to relate response times to revenue). Despite the data, we seem to use faster connections to build richer interfaces, not faster ones.

So, do users really care about speed?

My grandma and grandpa used to tell me they got by with very little growing up, but it didn’t matter. Everyone else was poor – they didn’t know they were poor. Have we just accepted poor response times as the norm? If sub-second response times were consistently possible, would we ignore it and just build a richer, slower web page?

 

There's Scout in my Safari

By Andre Bullet_white Comments Comments

The smart folks over at Rails Machine are always quick on the draw. Still, we were impressed when developers Will Farrington and Mike Skalnik had a working Safari 5 extension for Scout within 24 hours after Safari 5 extensions were announced. I pinged Will for the scoop:

What does the Scout extension do?

The extension works in the background to update the toolbar icon with a badge indicating the number of active alerts on Scout. Additionally, if you click on the toolbar icon, it will open up the activities page on Scout.

Active Scout alerts will show a badge:

... which you can then see on your Scout account:

Tell me about building a Safari 5 extension.

Building the extension itself was pretty pleasant. The bulk of it was spent in writing the (asynchronous) cross-site AJAX requests; the actual integration with Safari's Extension APIs was really simple and well-documented.

Overall, the extension APIs are still pretty young, and that does show, but very well-designed too. It ended up clocking it in at just over 100 lines of JavaScript (including comments and my whitespace preferences). The Extension Builder itself is very easy to use when it comes to setting up the extension and building/signing it. I can't speak to how this compares to the development process for Chrome or Firefox, but I'm very happy with the experience I've had and I'm looking forward to seeing what new APIs they end up adding to Safari Extensions.

What are your future plans for the project?

Version 0.2 will probably be out in the next day or two with some minor improvements to various things. I definitely have some itches I want to scratch. The big one for me — which might not be possible with the current APIs without some hacks — is getting a drop-down menu working for the toolbar icon so users will be able to right-click and have access to a quick list of all those active alerts they can use to navigate right to individual alerts. Beyond that, my other goals are working on a better UX; stuff like a first-run alert letting the user know they need to enter account information and offering a nice way to do so without necessarily having to even open up the Preferences window.

The code is open source on GitHub and I certainly welcome contributions: all you need is some JavaScript knowledge and to take a gander at Apple's documentation for the Safari Extension APIs.

Well done, Will! We'll be keeping our eye on the project. Check it out for yourself here.

 

Scaling Illustrated

By Derek Bullet_white Posted in Examples Bullet_white Comments Comments

Last week we added a third web server to one of our reporting applications. We’ve been growing at a steady rate and we wanted to reduce the load across our web tier (losing one of the web servers could put too much traffic on the remaining server).

Before Will Farrington (one of the fine folks at Rails Machine) added the third web server to the load balancer rotation, we setup a couple of charts to watch the magic.

Scout’s charts now refresh as metrics are reported so we could quickly see the impact.

Did the third web server help? Here’s what we saw:

Server Load

Our third web server helped decrease the load across our web tier:

Scout’s Server Load plugin is installed by default on your server.

Request Distribution

We confirmed the change in request distribution across the 3 web servers:

Install either the Apache or Ruby on Rails Monitoring plugin to view request metrics.

We love seeing visual confirmation of a job well done!

 

Older posts: 1 ... 41 42 43 44 45 ... 65