Kristina Chodorow's Blog
Posts tagged monitoring
Getting Started with MMS
Sep 28th
Edit: since this was written, Sam has written some excellent documentation on using MMS. I recommend reading through it as you explore 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 python-setuptools $ 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 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.
A Quick Intro to mongosniff
Sep 2nd
Writing an application on top of a framework on top of a driver on top of the database is a bit like playing telephone: you say “insert foo” and the database says “purple monkey dishwasher.” mongosniff lets you see exactly what the database is hearing and saying.
It comes with the binary distribution, so if you have mongod you should have mongosniff.
To try it out, first start up an instance of mongod normally:
$ ./mongodWhen you start up mongosniff you have to tell it to listen on the loopback (localhost) interface. This interface is usually called “lo”, but my Mac calls it “lo0″, so run ifconfig to make sure you have the name right. Now run:
$ sudo ./mongosniff --source NET lo sniffing... 27017
Note the “sudo”: this has never worked for me from my user account, probably because of some stupid network permissions thing.
Now start up the mongo shell and try inserting something:
> db.foo.insert({x:1})
If you look at mongosniff‘s output, you’ll see:
127.0.0.1:57856 -->> 127.0.0.1:27017 test.foo 62 bytes id:430131ca 1124151754 insert: { _id: ObjectId('4c7fb007b5d697849addc650'), x: 1.0 } 127.0.0.1:57856 -->> 127.0.0.1:27017 test.$cmd 76 bytes id:430131cb 1124151755 query: { getlasterror: 1.0, w: 1.0 } ntoreturn: -1 ntoskip: 0 127.0.0.1:27017 <<-- 127.0.0.1:57856 76 bytes id:474447bf 1195657151 - 1124151755 reply n:1 cursorId: 0 { err: null, n: 0, wtime: 0, ok: 1.0 }
There are three requests here, all for one measly insert. Dissecting the first request, we can learn:
source -->> destination- Our client, mongo in this case, is running on port 57856 and has sent a message to the database (127.0.0.1:27017).
db.collection- This request is for the “test” database’s “foo” collection.
length bytes- The length of the request is 62 bytes. This can be handy to know if your requests are edging towards the maximum request length (16 MB).
id:hex-id id- This is the request id in hexadecimal and decimal (in case you don’t have a computer handy, apparently). Every request to and from the database has a unique id associated with it for tax purposes.
op: content- This is the actual meat of the request: we’re inserting this document. Notice that it’s inserting the float value 1.0, even though we typed 1 in the shell. This is because JavaScript only has one number type, so every number typed in the shell is converted to a double.
The next request in the mongosniff output is a database command: it checks to make sure the insert succeeded (the shell always does safe inserts).
The last message sniffed is a little different: it is going from the database to the shell. It is the database response to the getlasterror command. It shows that there was only one document returned (reply n:1) and that there are no more results waiting at the database (cursorId: 0). If this were a “real” query and there was another batch of results to be sent from the database, cursorId would be non-zero.
Hopefully this will help some people decipher what the hell is going on!
Subscribe to all posts