Checked VS. Unchecked Exporter about mongodbatlas_exporter HOT 5 CLOSED

Here's a macro view of the proposed changes.

1. Registerer: maintains a ledger of all instances, disks, and their collectors. ensures it is up to date.
2. Individual collectors for each instance and disk. These individual collectors have ALL their metrics registered via Describe to maintain a checked collector.
3. Since each collector registers Metadata only for the metrics its instances have this will eliminate the spurious "not_found" errors for mongos (most metrics) and primaries (oplog lag). This will also allow us to eliminate the "no_data" errors for FTS metrics as the Registerer should check if FTS is enabled or not.

from mongodbatlas_exporter.

The main need here being to improve the process collector issues so that gets first focus for Registerer. Disk Collectors should migrate in another PR.

from mongodbatlas_exporter.

OK, some notes here as I start looking at migrating disks onto the Registerer.

Currently collecting disk metrics makes a lot of API calls:

1. List all processes
2. List disks for each process.
3. List the measurements for each disk of each process.

So if we have a project with 20 processes each having 2 disks:

1. 1 API call to list all processes
2. 20 API calls to list disks
3. 40 API calls to get each disks measurements.

A total of 61 API calls.

I think we can move steps 1 & 2 into the registerer and have it only make calls to close differences each time. This brings us down to 40 API calls for the disks which is what the collector is interested in.

from mongodbatlas_exporter.

An initial pass at this design. I think it's a little excessive and we should look at nesting the disk collection into the process collector. The best way to do that is to understand what these partitions are called. Is it constant? I just checked and the only disk we are tracking currently is the data disk.

Seems like you can get other disks...

from mongodbatlas_exporter.

This way is better. Less is more.

Pull the list of disks when registering a collector. Partition name can be a variable label I think. Since the partition names get locked in during registration that will be a problem if new partitions are added, but I don't think Atlas adds new disks...

GET /groups/{GROUP-ID}/processes/{HOST}:{PORT}/disks/{DISK-NAME}/measurements

from mongodbatlas_exporter.