Topics

#go #golang #hacktoberfest #metrics #mongodb #pmm #prometheus #prometheus-exporter

Language breakdown

No language data available.

▸ Files click to expand

README

MongoDB exporter

This is the new MongoDB exporter implementation that handles ALL metrics exposed by MongoDB monitoring commands. This new implementation loops over all the fields exposed in diagnostic commands and tries to get data from them.

Currently, these metric sources are implemented:

$collStats
$indexStats
getDiagnosticData
replSetGetStatus
replSetGetConfig
serverStatus

Supported MongoDB versions

The exporter works with Percona Server for MongoDB and MongoDB Community or Enterprise Edition versions 6.0 and newer. Older versions might also work but are not tested anymore.

Info on Percona MongoDB exporter versions

The old 0.1x.y version (ex master branch) has been moved to the release-0.1x branch.

A flag, --compatible-mode, which exposes metrics with 0.1x compatible metric names has been implemented which simplifies migration from the old version to the current version.

Build the exporter

The build process uses the dockerized version of goreleaser so you don't need to install Go. Just run make release and the new binaries will be generated under the build directory.

├── build
│ ├── config.yaml
│ ├── mongodbexporter7c73946_checksums.txt
│ ├── mongodb_exporter-7c73946.darwin-amd64.tar.gz
│ ├── mongodb_exporter-7c73946.linux-amd64.tar.gz
│ ├── mongodbexporterdarwin_amd64
│ │ └── mongodb_exporter <--- MacOS binary
│ └── mongodbexporterlinux_amd64
│ └── mongodb_exporter <--- Linux binary

Running the exporter

If you built the exporter using the method mentioned in the previous section, the generated binaries are in mongodbexporterlinuxamd64/mongodbexporter or mongodbexporterdarwinamd64/mongodbexporter

Docker

A docker image is available on the official percona repository.

Examples

# with podman
podman run -d -p 9216:9216 percona/mongodb_exporter:0.40 --mongodb.uri=mongodb://127.0.0.1:17001
with docker
docker run -d -p 9216:9216 percona/mongodb_exporter:0.40 --mongodb.uri=mongodb://127.0.0.1:17001

Permissions

Connecting user should have sufficient rights to query needed stats:

{
         "role":"clusterMonitor",
         "db":"admin"
      },
      {
         "role":"read",
         "db":"local"
      }

When using the PBM collector to get metrics from Percona Backup for MongoDB, the user should also have sufficient privileges to query the PBM internal collections (in the admin database). One option is to grant find privileges on the admin collection:

privileges: [
        { resource: { db: "admin", collection: "" }, actions: [ "find" ] },
],

Alternatively, you can grant the find privilege for each PBM internal collection (see: https://docs.percona.com/percona-backup-mongodb/details/control-collections.html):

privileges: [        { resource: { db: "admin", collection: "pbmBackups" }, actions: [ "find" ] },        { resource: { db: "admin", collection: "pbmAgents" }, actions: [ "find" ] },        { resource: { db: "admin", collection: "pbmConfig" }, actions: [ "find" ] },        ... ],

However, this is not recommended as the list of internal collections may change in future releases.

More info about roles in MongoDB documentation.

Example

mongodbexporterlinuxamd64/mongodbexporter --mongodb.uri=mongodb://127.0.0.1:17001

MongoDB Authentication

You can supply the mongodb user/password direct in the --mongodb.uri= like --mongodb.uri=mongodb://user:pass@127.0.0.1:17001, you can also supply the mongodb user/password with --mongodb.user=, --mongodb.password= but the user and password info will be leaked via ps or top command, for security issue, you can use MONGODBUSER and MONGODBPASSWORD env variable to set user/password for given uri

MONGODBUSER=XXX MONGODBPASSWORD=YYY mongodbexporterlinuxamd64/mongodbexporter --mongodb.uri=mongodb://127.0.0.1:17001 --mongodb.collstats-colls=db1.c1,db2.c2
or
export MONGODB_USER=XXX
export MONGODB_PASSWORD=YYY
mongodbexporterlinuxamd64/mongodbexporter --mongodb.uri=mongodb://127.0.0.1:17001 --mongodb.collstats-colls=db1.c1,db2.c2

Multi-target support

You can run the exporter specifying multiple URIs, devided by a comma in --mongodb.uri option or MONGODBURI environment variable in order to monitor multiple mongodb instances with the a single mongodbexporter instance.

--mongodb.uri=mongodb://user:pass@127.0.0.1:27017/admin,mongodb://user2:pass2@127.0.0.1:27018/admin

In this case you can use the /scrape endpoint with the target parameter to retreive the specified tartget's metrics. When querying the data you can use just mongodb://host:port in the target parameter without other parameters and, of course without host credentials

GET /scrape?target=mongodb://127.0.0.1:27018

If your URI is prefixed by mongodb:// or mongodb+srv:// schema, any host not prefixed by it after comma is being treated as part of a cluster rather then as a standalone host. Thus clusters and standalone hosts can be combined like this:

--mongodb.uri=mongodb+srv://user:pass@host1:27017,host2:27017,host3:27017/admin,mongodb://user2:pass2@host4:27018/admin

You can use the --split-cluster option to split all cluster nodes into separate targets. This mode is useful when cluster nodes are defined as SRV records and the mongodbexporter is running with mongodb+srv domain specified. In this case SRV records will be queried upon mongodbexporter start and each cluster node can be queried using the target parameter of multitarget endpoint.

Overall targets request endpoint

There is an overall targets endpoint /scrapeall that queries all the targets in one request. It can be used to store multiple node metrics without separate target requests. In this case, each node metric will have a instance label containing the node name as a host:port pair (or just host if no port was not specified). For example, for mongodb_exporter running with the options:

--mongodb.uri="mongodb://host1:27015,host2:27016" --split-cluster=true

we get metrics like this:

mongodb_up{instance="host1:27015"} 1 mongodb_up{instance="host2:27016"} 1

Enabling collstats metrics gathering

--mongodb.collstats-colls receives a list of databases and collections to monitor using collstats. Usage example: --mongodb.collstats-colls=database1.collection1,database2.collection2

mongodbexporterlinuxamd64/mongodbexporter --mongodb.uri=mongodb://127.0.0.1:17001 --mongodb.collstats-colls=db1.c1,db2.c2

Enabling compatibility mode.

When compatibility mode is enabled by the --compatible-mode, the exporter will expose all new metrics with the new naming and labeling schema and at the same time will expose metrics in the version 1 compatible way. For example, if compatibility mode is enabled, the metric mongodbsswtloglogbyteswritten (new format)

# HELP mongodbsswtloglogbyteswritten serverStatus.wiredTiger.log.
TYPE mongodbsswtloglogbyteswritten untyped
mongodbsswtloglogbyteswritten 2.6208e+06

will be also exposed as mongodbmongodwiredtigerlogbytes_total with the unwritten label.

HELP mongodbmongodwiredtigerlogbytestotal mongodbmongodwiredtigerlogbytestotal
TYPE mongodbmongodwiredtigerlogbytes_total untyped
mongodbmongodwiredtigerlogbytes_total{type="unwritten"} 2.6208e+06

Enabling profile metrics gathering

--collector.profile To collect metrics, you need to enable the profiler in MongoDB: Usage example: db.setProfilingLevel(2)

|Level|Description| |-----|-----------| |0| The profiler is off and does not collect any data. This is the default profiler level.| |1| The profiler collects data for operations that take longer than the value of slowms or that match a filter.
When a filter is set:

The slowms and sampleRate options are not used for profiling.
The profiler only captures operations that match the filter.

|2|The profiler collects data for all operations.|

Enabling shards metrics gathering

When shard metrics collection is enabled by --collector.shards, the exporter will expose metrics related to sharded Mongo. Example, if shards collector is enabled:

# HELP mongodbshardscollectionchunkscount sharded collection chunks.
TYPE mongodbshardscollectionchunkscount counter
mongodbshardscollectionchunkscount{collection="system.sessions",database="config",shard="rs1"} 250
mongodbshardscollectionchunkscount{collection="system.sessions",database="config",shard="rs2"} 250

You can see shard name, it's collection, database and count.