Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

September 28 2011

Getting Started with MMS

Telling someone “You should set up monitoring” is kind of like telling someone “You should exercise 20 minutes three times a week.” Yes, you know you should, but your chair is so comfortable and you haven’t keeled over dead yet.

For years*, 10gen has been planning to do monitoring “right,” making it painless to monitor your database. Today, we released the MongoDB Monitoring Service: MMS.

MMS is free hosted monitoring for MongoDB. I’ve been using it to help out paying customers for a while, so I thought I’d do a quick post on useful stuff I’ve discovered (documentation is… uh… a little light, so far).

So, first: you sign up.

There are two options: register a company and register another account for an existing company. For example, let’s say I wanted to monitor the servers for Snail in a Turtleneck Enterprises. I’ll create a new account and company group. Then Andrew, sys admin of my heart, can create an account with Snail in a Turtleneck Enterprises and have access to all the same monitoring info.

Once you’re registered, you’ll see a page encouraging you to download the MMS agent. Click on the “download the agent” link.

This is a little Python program that collects stats from MongoDB, so you need to have pymongo installed, too. Starting from scratch on Ubuntu, do:

$ # prereqs
$ sudo apt-get install python easy_install
$ sudo easy_install pymongo
$
$ # set up agent
$ unzip name-of-agent.zip
$ cd name-of-agent
$ mkdir logs
$
$ # start agent
$ nohup python agent.py > logs/agent.log 2>&1 &

Last step! Back to the website: see that “+” button next to the “Hosts” title?

Designed by programmers, for Vulcans

Click on that and type a hostname. If you have a sharded cluster, add a mongos. If you have a replica set, add any member.

Now go have a nice cup of coffee. This is an important part of the process.

When you get back, tada, you’ll have buttloads of graphs. They probably won’t have much on them, since MMS will have been monitoring them for all of a few minutes.

Cool stuff to poke

This is the top bar of buttons:

Of immediate interest: click “Hosts” to see a list of hosts.

You’ll see hostname, role, and the last time the MMS agent was able to reach this host. Hosts that it hasn’t reached recently will have a red ping time.

Now click on a server’s name to see all of the info about it. Let’s look at a single graph.

You can click & drag to see a smaller bit of time on the graph. See those icons in the top right? Those give you:

+
Add to dashboard: you can create a custom dashboard with any charts you’re interested in. Click on the “Dashboard” link next to “Hosts” to see your dashboard.
Link
Link to a private URL for this chart. You’ll have to be logged in to see it.
Email
Email a jpg of this chart to someone.
i
This is maybe the most important one: a description of what this chart represents.

That’s the basics. Some other points of interest:

  • You can set up alerts by clicking on “Alerts” in the top bar
  • “Events” shows you when hosts went down or came up, because primary or secondary, or were upgraded.
  • Arbiters don’t have their own chart, since they don’t have data. However, there is an “Arbiters” tab that lists them if you have some.
  • The “Last Ping” tab contains all of the info sent by MMS on the last ping, which I find interesting.
  • If you are confused, there is an “FAQ” link in the top bar that answers some common questions.

If you have any problems with MMS, there’s a little form at the bottom to let you complain:

This will file a bug report for you. This is a “private” bug tracker, only 10gen and people in your group will be able to see the bugs you file.

* If you ran mongod --help using MongoDB version 1.0.0 or higher, you might have noticed some options that started with --mms. In other words, we’ve been planning this for a little while.

January 31 2011

A Short eBook on Scaling MongoDB

I just finished a little ebook for O’Reilly: Scaling MongoDB. I’m excited about it, it was really fun to write and I think it’ll be both fun and instructive to read. It covers:

  • What a cluster is
  • How it works (at a high level)
  • How to set it up correctly
  • The differences in programming for a cluster vs. a single server
  • How to administer a cluster
  • What can go wrong and how to handle it

So, why would you want to get a copy?

  • It’s a succinct reference for anything that’s likely to come up and covers the common questions I’ve heard people ask in the last year.
  • I heard some grumbling about my post on choosing a shard key (“Ugh, a metaphor,” -an IRC user). People who don’t like metaphors will be pleased to hear that this book has a straight-forward, serious-business section on choosing a shard key that not only lacks a metaphor but also goes much more into depth than the blog post.
  • It’s a quick read. There are code examples, of course, and it can be used as a reference, but after banging out 15,000 words in a couple of days, I took the next couple weeks to make them all flow together like fuckin’ Shakespeare.
  • It can be updated in real time! After MongoDB: The Definitive Guide becoming out-of-date approximately 6 seconds after we handed in the final draft, I’m delighted that new sections, advice, and features can be added as needed. Once you buy the ebook, you can update to the latest “edition” whenever you want, as many times as you want. O’Reilly wants to do automatic updates, but so far the infrastructure isn’t there in traditional ebook readers so you’ll have to update it manually.

You can also get a “print on demand” copy if you’re old school.

I hope you guys will check it out and let me know what you think!

To promote the book, Meghan is forcing me to do a webcast on Friday (February 4th). It’s called How Sharding Works and it’s a combination whitepaper and Magic School Bus tour of sharding. It should cover some of the interesting stuff about sharding that didn’t really fit into the 60 pages I had to work with (or the more practical focus of the book).

Look at the teeth on that guy! (He'll bite you if you make any webscale jokes.)

June 29 2010

Notes from Sinatra, Heroku and MongoHQ deployment

For previous projects I never used Heroku, sometimes because I needed tools not available on the platform, other times because I had other options that were more interesting, price-wise.

My last side-project sounded like a perfect fit to trial Heroku though. My conclusion as you may have guessed is that Heroku is really addictive and sweet to use, I encourage you to give it a try.

Disclaimer: this is not a sponsored post for Heroku or MongoHQ – I’m just really happy with my current experience.

The site itself is ToutPourMoniPad.com – housses et étuis pour iPad – a place that aggregates the cases, sleeves and protections we have found for the iPad, from vendors that ship to France without international shipping costs. Currently 100+ references and counting.

This post is not intended to be a nice layed-out article, rather a repository of links and code snippets I’ve been using and found practical.

Overall impression

The deployment was absolutely quick (less than 30mn apart from DNS config) and flawless. The site is quite snappy as well, and the uptime has been wonderful.

Technical overview

  • I used the new Bamboo stack which allows Ruby 1.9.1
  • the app itself is based on Sinatra with HAML and SASS
  • I struggled a bit to get the DNS to work but it went ok (see docs here) – maybe I should have tried using Zerigo as suggested
  • I used Bundler for the gems, as advised
  • the database started with Sqlite then we moved to MongoDB 1.4, hosted on MongoHQ (free plan)
  • I could not get exceptional to work (but that’s probably linked to how my app is configured), so I used custom email
  • the data aggregation system is built on TinyTL, ActiveWarehouse-ETL unreleased tiny brother, just like my ruby/rails screencasts aggregator previously
  • as I used a lot of data (html, xml, csv) caching locally, I used api-cache which works wonders
  • image resizing is done on my dev machine using imagemagick via command line, then pushed via git

Exceptions notifications

For some reason, I could not get Exceptional to work with my Sinatra setup. Here’s what I used (see below for email setup):

  error do
    e = request.env['sinatra.error']
    msg = ... 
    send_email('Exception!',msg)
    haml :'500'
  end

Graphical tips

I used Google web fonts, jQuery corners, Compass and SASS to finetune the blueprintcss-based layout.

Notes on MongoDB

This site relies heavily on a ETL process in the background.

I’ve been playing a lot with ETL and MongoDB recently and I find that this database is very convenient to munge data coming from different sources and in different formats (html, xml, csv).

Being able to add any number and variety of columns on the fly as you integrate the data sources is a big win: MongoDB is very interesting for that matter.

MongoHQ offers a free plan to get started so I took the plunge. The internal aws connection between Heroku and MongoHQ seems to work fast enough.

Data caching

Api-cache is worth a look to cache just about anything. Quick snippet:

require 'moneta/basic_file'

preprocess {
  # setup the cache store, here using file storage
  folder = File.dirname(__FILE__) + '/cache'
  FileUtils.mkdir(folder) unless File.exists?(folder)
  APICache.store = Moneta::BasicFile.new(:path => folder)
}

def some_cached_operation(xxx...)
  APICache.get(the_key, :cache => 60*60*24*10, :valid => 60*60*24*4, :period => 2) do
    process_some_heavy_download_with_polling_limits
  end
end

each_row { |row|
  row[:data] = some_cached_operation(xxx...)  
}

Heroku tips

Migrating stack to MRI 1.9.1

I started with the wrong stack but this can be easily changed:

$ heroku stack:migrate bamboo-mri-1.9.1

Database setup

By default the database uses a locally running MongoDB instance. I update the production database from the developer workstation (no heroku worker so far, although that may come), by using env vars for setting up the connection:

if ENV['MONGOHQ_HOST']
  puts "Running on MongoHQ" 
  MongoMapper.connection = Mongo::Connection.new(ENV['MONGOHQ_HOST'], ENV['MONGOHQ_PORT'])
  MongoMapper.database = ENV['MONGOHQ_DATABASE']
  MongoMapper.database.authenticate(ENV['MONGOHQ_USER'],ENV['MONGOHQ_PASSWORD'])
else
  puts "Using local database" 
  MongoMapper.database = 'tout-pour-mon-ipad'
end

On traditional hosting you would put a config.yml path in the Capistrano shared folder, here you use vars that are managed by Heroku itself, and kept between deployments.

$ heroku config:add MONGO_HOST=flame.mongohq.com ....

These variables are then set in the application ENV.

Email setup

I use smtp for the contact form and simple exception notifications. As suggested by Heroku docs, I used Pony and the free sendgrid add-on.

require 'pony'
TPMI_SMTP_OPTIONS = {
    :address        => "smtp.sendgrid.net",
    :port           => "25",
    :authentication => :plain,
    :user_name      => ENV['SENDGRID_USERNAME'],
    :password       => ENV['SENDGRID_PASSWORD'],
    :domain         => ENV['SENDGRID_DOMAIN'],
}

def send_email(subject,html_body)
  Pony.mail(:to => '...', :from => '...',
    :subject => subject,
    :html_body => html_body,
    :via => :smtp, :via_options => TPMI_SMTP_OPTIONS)
end

Conclusion

I’m very happy with the setup and overall experience so far, and it has been very nice to have no hosting cost at all to trial the idea. I will definitely switch to a paid plan at some point, and will try to experiment with larger sites.

I intend to work more on the site and will blog about the technical aspects here, so stay tuned.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl