GuidesAPI ReferenceSupportArticles

MongoDB Add-ons

Suggest Edits

Overview

Our MongoDB deployments support the following add-ons:

Syslog-NG

Configuration instructions for the syslog-ng add-on can be found on the Syslog-NG Setup page.

Logs are forwarded continuously from all the capsules present on your deployment; so you will see database logs, system logs, and haproxy logs in chronological order. For easier parsing, Compose adds a header to each log message that contains a timestamp, hostname, and process information.

As a result, the raw messages that arrive at your service will vary.

Papertrail

Raw Message: <timestamp> <hostname>: <binary[pid]>: <type info> | <syslog, haproxy, or MongoDB log>

Loggly

Raw Message: <hostname> : [<customer [email protected]>] <binary[pid]>: <type info> | <syslog, haproxy, or MongoDB log>

NB: In addition to just displaying the raw information from syslog-ng, Loggly also applies some parsing by default. It does not recognize the format of our logs, so you may want to implement your own parsing or derived fields to make more effective use of the logs there.

Logentries is no longer available for new deployments or as a new add-on for existing deployments. The format is here for deployments where it is already configured.

Logentries

Raw Message: <timestamp> <hostname>: <binary[pid]>: <type info> | <syslog, haproxy, or MongoDB log>

Telegraf

The telegraf plugin gathers MongoDB stats exposed by db.serverStatus() and aggregates them so you get a total value for any particular statistic across all the databases in the deployment. More information on the statistics is provided in the telegraf MongoDB plugin README

Installing the telegraf add-on to your Compose deployment allows the statistics to be forwarded to either metrics service: Datadog or Librato.

Configuration instructions for the Telegraf add-on can be found on the Telegraf Setup page.

Oplog Access

The oplog is a special capped collection that keeps a rolling record of all operations that modify the data stored in your databases. The oplog is not accessible from the mongo routers that are provided for your deployment, so the add-on opens a portal specifically for oplog access.

Configuration instructions for the oplog access add-on can be found on the Oplog Access Setup page.

The add-on provides access through the following steps:

  • It creates a user (oploguser) in the admin database, since the admin database controls all user access across your databases on this deployment. This user will have read access to all databases in the deployment.
  • It then provisions a new haproxy portal with access to the primary shard, specifically pointing to the collections in local. Each replica set member stores its own copy of the oplog in the local.oplog.rs collection, so access is still possible whichever shard is primary.
  • You are given connection string/URI and a self-signed SSL certificate to connect with.

This configuration set up is reflected in the connection string supplied by the new portal. The /local indicates where the oplog data is coming from and the ?authSource=admin indicates where the oploguser is authenticated.

Still Need Help?

If this article didn't solve things, summon a human and get some help

Updated over 3 years ago