This is the blog for Scout, Enterprise-grade server monitoring without the bloat.
70+ plugins, realtime charts, alerts, and Chef/Puppet-friendly configuration.

Rails Monitoring Improvement: Ignore Specific Actions

Posted in Plugins | Comments Comments

Sometimes you have actions in your Rails app that you know take a long time. Getting alerts on these actions is just noise.

With the updated Rails Monitoring Plugin, you can filter out any requests on which you don't want to be notified. You supply a regular expression, so you make as simple or complicated as you need to.

Update your Rails plugin

If you already have the Rails plugin installed, you need to update it. Go to plugin->code and click Update:

Then go to plugin->edit and click Update Options:

The new goodness is under "advanced options":

Ignoring Actions

You provide a regular expression for actions you want don't want to be alerted on when they're slow. In the simplest case, don't even worry about it being a regular expression -- just provide a string you want to match. For example, if you don't want to be alerted to any slow actions with admin in the URI, just put admin in the Ignored Actions field.

More Complicated Matches

To ignore all actions under admin and also accounts/new, the regex is(admin|accounts\/new). If you wanted to make sure admin only matches paths starting with admin, just match the beginning slash: (\/admin|accounts\/new)

If you're building a complicated regex, try it out separately to ensure it matches/doesn't match what you expect. I dig on Rubular for quick regex sanity checks. Of course, the plugin will tell you if your regex has a problem, but you'll get faster feedback by running it through Rubular.

Notes

Note that the match is case insensitive -- no need to worry about case.

Finally, note that excluded actions will still be analyzed in the daily Rails Analysis reports, so you'll still get metrics on them -- you just won't get email notifications for actions you already know are slow!

 
 

Rails + Google Analytics = easy goal tracking

Comments Comments

Google Analytics is an indispensable tool as you optimize the business side of your operation. If you haven't already set up goals in Analytics for viewing your pricing information, accessing the sign-up form, and signing up for an account -- go do it! It's vital information.

However, Google Analytics' goals have to be attached to a specific URL. What if there is no URL for an important goal? For example, the New Account goal for Scout is just the account/show page -- there's no specific URL to represent a newly created account.

 

Read more... More

 

Major chart updates - variability, overlays, scaling & stacking

Comments Comments

When debugging performance problems, visualizing server metrics in a variety of ways is a critical part of isolating the cause:

  • Visualizing variance
  • Overlaying metrics to identify correlations
  • Scaling to compare several metrics with different units
  • Stacking graphs to visualize distributed setups

We’ve just released a major update to Scout’s charting functionality that makes it easier to analyze your metrics.

 

Read more... More

 

Part II: We Just Undid Three Months of Dev work. Here's What We Learned.

Posted in Business | Comments Comments

Two weeks ago I covered some of the business lessons learned from a large (~3 months) investment in new features, and the hard decision to roll them back. I discussed how you will underestimate the ongoing cost of complexity in your product, and how cool new capabilities don’t sell themselves.

Continuing this week—more insights gained from undoing development work.

 

Read more... More

 

The MySQL MyISAM and InnoDB engines and a grocery checkout

Comments Comments

There’s no shortage of resources comparing the MyISAM and InnoDB storage engines. You’ll quickly see it isn’t a black-and-white decision after reading through various discussions debating MyISAM and InnoDB.

Why is the decision so hard?

  • Setting up your database is one of the first steps when building a web application. You probably don’t have a good idea on the database activity at this point, so you may have little data to work with.
  • The ordering and number of statements can have a big impact on database performance. It’s difficult to simulate until you have real users.

However, there is a one case where choosing the wrong table type can be crippling.

 

Read more... More

 

First Impressions Count

Posted in Features | Comments Comments

Scout is making a better first impression than ever starting today. When you start monitoring a new server, you'll immediately get a high-level summary of the vital stats:

Scout reports this for you automatically. From there, you choose the deeper metrics you need, like Ruby on Rails monitoring, MySQL Slow Queries, Process memory usage, etc.

 
 

We Just Undid Three Months of Dev work. Here's What We Learned.

Posted in Business | Comments Comments

We’ve been deleting a lot of code from Scout. We’re ripping out major infrastructure, and in doing so, pulling the plug on functionality which, just six months ago, we believed would be crucial to our business. Most importantly, we’re simplifying the most complex, error-prone, and poorly-performing parts of the application. At the same time, our revenue and sales pipeline is growing at a faster rate.

How did this happen? How did we get to a place where we can remove code and functionality and see our business will grow because of it?

As they say, “mistakes were made.” You don’t get the satisfaction of throwing out a bunch of cruft and performance-degrading features without having gone through the pain of:

  1. Building those features in the first place.
  2. Fighting the performance problems for a few months before you realize its all untenable and come up with alternatives.

So yes, mistakes were made. But also, lessons were learned.

 

Read more... More

 

Simplify. Get an order of magnitude speedup.

Posted in Updates | Comments Comments

Have you noticed Scout feels snappier lately? We made some major simplifications that sped things up a lot. Here’s the CPU load on one of our DB servers:

(and yes, we use Scout to monitor itself!)

Even better, the response time for users improved dramatically.

Scout’s longest actions before and after the speedup:

The simplification

What yielded such a dramatic speedup? Earlier this year, we implemented a very generic datastore and reporting system. It could handle all sorts of data, relationships within the data, etc.

Unfortunately, we never got to demonstrate all the benefits of this cool system. It wasn’t viable from either a maintenance or a performance standpoint.

So we rolled it back. And we got back a ton of performance, as you can see.

The lessons …

I will be writing up some business lessons we learned from this experience—stay tuned!

 
 

Cloud Monitoring in one line of code

Posted in Features | Comments Comments

UPDATE – Cloud Image Monitoring has been replaced by Server Roles

The greatest roadblock to monitoring is monitoring itself – installing software, tweaking scripts, remembering how to reload scripts, etc makes it painful process. It’s even more of an issue when setting up monitoring for cloud deployments – running a large configuration script or installing a lot of software with a saved image makes your environment very fragile, especially when deploying new servers is a frequent task.

We’re debuting a new feature in Scout that makes monitoring your cloud servers a single crontab entry – no scripts to setup, edit, reload, or coordinate across multiple instances.

 

Read more... More

 

In-depth Rails Monitoring using only a production log file

Posted in Plugins, Features | Comments Comments  | no trackbacks

No Rails plugins to install. No performance hit during the request cycle. Nothing to break your application code. Nothing to restart. With just the path to your production Rails log file, Scout’s new Rails monitoring plugin alerts you when your Ruby on Rails application is slowing down and provides detailed daily performance reports.

First, an open-source shoutout: thanks to Willem van Bergen and Bart ten Brinke (the Rails Doctors) for their Request Log Analyzer gem, which we built upon for this functionality.

Rails analysis made easy

  1. Easy setup. All we need is a path to the log file of your production Rails application. That’s it. There’s nothing to configure in your Rails application. Unlike our previous Rails analyzer, you don’t have to install a Rails plugin or even redeploy your Rails application. There are zero changes to your Rails code base.
  1. In-depth analysis. Get rendering time and database time on a per-action basis. Know your error code rates, HTTP request types, cache hit ratios, and more.
  1. No performance impact. Since the analysis happens out the request-response cycle, there is no performance impact on your running Rails app.
  2. Alerts. Like all Scout plugins, you can get alerts based on the flat data the plugin produces. Get alerts on requests/minute, number of slow requests, and average request length.

How it works

The plugin performs a combination of incremental and batch processing on your application’s logfile. Every time the Scout agent runs (3min-30min, depending on your Scout plan, it parses new entries in your log file since the last time it ran. This provides key metrics for near-realtime graphs and alerts.

Once a day, the Analyzer runs to crunch the numbers for more in-depth metrics. This is what provides the breakdowns among all your actions, analysis of most popular actions, most expensive actions, etc.

Try it out!

Install the Rails Analysis plugin. If you don’t already have a Scout account, all of our accounts have a 30 day free trial.

 
 

Older posts: 1 ... 17 18 19 20 21 ... 28

comments powered by Disqus