MongoDB is one of the most widely deployed and relied-upon open source NoSQL databases. With mongo-specific instrumentation, we can reliably track down the source(s) of any slowness or odd behavior in just a few clicks. For example: figuring out the user responsible for most lock % time held.

By consuming Mongo logs, queries off the wire, and system stats and parsing them into structured data, Honeycomb makes it possible to answer deep questions about database operation instantly.

mongodb observability
mongodb observability - log config

Data Collection

The Honeycomb MongoDB log agent–which is honeytail wrapped in an installer–captures logs, structures to JSON, and streams the data into Honeycomb as it’s written. The TCP collector passively looks at traffic between clients and servers to collect query-level detail from the wire without requiring any reconfiguration of database or impacting performance. Finally, the stats helper is a reference implementation of a script for polling stats like active log count and queue length from Mongo instances.

You can also backfill old logs into Honeycomb to look at past data.

Getting Answers

With MongoDB events in Honeycomb, you can ask questions like:

  • What is the read lock percentage on the slowest collection for reads?
  • How many indexes does it have?
  • What is the breakdown of reads to writes, and for the slowest read queries?
  • Is it distributed over many users or just one user’s traffic?
  • Is there an index build in progress, and what percentage complete is it?
  • How many indexes in that collection?
  • Are they getting hit, or are they covered?
  • Which queries scanned the largest numbers of documents?
mongodb observability - query chart example