mongo_exporter

[david....@percona.com]

Hi all,

The team at Percona have taken some time to adapt https://github.com/dcu/mongodb_exporter into something that better support Mongo replication and sharding and not just it's current stand-alone mode. During our work and launching some internal monitoring we have diverged a good deal from the upstream, so we were considering moving https://github.com/dbmurphy/mongodb_exporter/tree/modular_collectors_v2_metrics_cursor to it's on fresh repository given some of the structure changes. My question would be would it be best to have a private repo on your system we can work with everyone here to improve the code quality is up to standards, or should I make a new repo in the PerconaLabs which then you might pull from. After we get past that I would like to start getting feedback on things we can improve with the code as we work to refactor out some of the legacy and un-needed bit from the original source version and then incorporate this group's suggestion for making the code better in general. The long term goal is to help get an exporter that is of substantial quality and can be included more in the official GitHub for exporters.


Thanks
David Murphy
@dbmurphy_data

[Brian Brazil]

On 24 March 2016 at 08:14, <david....@percona.com> wrote:

Hi all,

The team at Percona have taken some time to adapt  https://github.com/dcu/mongodb_exporter into something that better support Mongo replication and sharding and not just it's current stand-alone mode. During our work and launching some internal monitoring we have diverged a good deal from the upstream, so we were considering moving  https://github.com/dbmurphy/mongodb_exporter/tree/modular_collectors_v2_metrics_cursor to it's on fresh repository given some of the structure changes. My question would be would it be best to have a private repo on your system we can work with everyone here to improve the code quality is up to standards, or should I make a new repo in the PerconaLabs which then you might pull from. 

The mongodb exporter is maintained by dcu, so it'd be best to talk to him about integrating your changes.

 

After we get past that I would like to start getting feedback on things we can improve with the code as we work to refactor out some of the legacy and un-needed bit from the original source version and then incorporate this group's suggestion for making the code better in general. 

From a quick peek:

1) Don't do math in exporters. For example instead of oplog_length_sec and oplog_length_sec_now, export the min and max these are calculated from

2) Consistently use "seconds" both as a unit and as part of a metric name. Similarly with "bytes". There's no length limit on metric names, there's no need to abbreviate. You shouldn't presume that people viewing the metrics have anything beyond a passing knowledge of MongoDB.

3) Use ConstMetrics rather than the usual metrics in exporters. This will avoid races and other problems, and is easier to code.

The long term goal is to help get an exporter that is of substantial quality and can be included more in the official GitHub for exporters.

We only put exporters in the Prometheus github organisation that are maintained by one of the Prometheus developers, I don't think any of us do MongoDB but this doesn't prevent you from maintaining it in some other org.

--

Brian Brazil

www.robustperception.io

[David Murphy]

Brain this is what I am saying I am doing a full fork as DCU has applied other things and  we need greater control in maintaining this and making sure its has merges in a  timely manner.  As Percona is actively invested in this I will make plenty of notes as to being based on DCU’s original but merging up is no longer actually something that seems feasible. 

Ben do you want to comment on this? It seems there is a bit of a disconnect with what we were talking about  and Brain state unless actively developed and maintained by prometheus it will not make it into the request Peter and I put toward you.  We can manage this just given we are actively building out monitoring in docker for  mysql and mongo, in addition to internal and future uses it would have been nice to have some kind of  synergy between our companies. 

David Murphy

Practice Manager for MongoDB, Percona

david....@percona.com

Skype: percona.dmurphy

Office: +1 (919) 249 7533

Dublin - IE

Standard Hours: Monday - Friday, 9:00AM - 6:00PM BST (GMT -0)

 

www.percona.com

www.mysqlperformanceblog.com

[Ben Kochie]

Right now, I think Brian is right.  We are only putting exporters in the official prometheus github that are maintained directly by our core team.  Adding mongodb_exporter to the prometheus project on github is not something we can do today.

But as I've seen Percona contribute more to Prometheus, it may be something we can talk about in the future if Percona becomes part of the core Prometheus contributor team.

For now, we're happy to link your new exporter from our official 3rd party exporter list.

http://prometheus.io/docs/instrumenting/exporters/#independently-maintained-third-party-exporters

- Ben Kochie