Looking for new collectd_exporter maintainer

[Julius Volz]

Hi everyone,

I just noticed that I'm still listed as the official maintainer for the Prometheus collectd exporter (see https://github.com/prometheus/collectd_exporter/blob/master/MAINTAINERS.md). Now to be honest, I've never done anything with collectd in my life, haven't touched this exporter in years, and don't even fully remember how I got to be the maintainer for it (I think just because it was there and nobody else took it).

Would anyone be interested in taking over its maintainership? This would include reviewing occasional incoming PRs, perhaps doing minor maintenance or feature work on the code base (if you like), and doing releases once in a while after some changes have been made.

In case there's nobody interested in picking up maintainership, it may otherwise make sense to archive or mark the exporter as deprecated.

Cheers,

Julius

[Ben Kochie]

A while ago we talked about deprecating it and archiving it. Maybe it's time to do this?

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowWFrsHTDb3BdwrzKvz3SHBJ%3DnJj3p%3DLxmXzJaPQUnrYQ%40mail.gmail.com.

[Julius Volz]

Yes, if nobody is interested in taking it over in a week or so, I'd say let's do that.

[George McGinley Smith]

The conversation here started because the community is wanting up to date images for this exporter (see: https://github.com/prometheus/collectd_exporter/issues/86#issuecomment-545463428). What would deprecation mean here? Perhaps consider reaching out to a wider audience than this group before deciding to deprecate it?

CONFIDENTIALITY NOTICE:

This message (including any attachments) has been sent as a part of discussion between the sender and the addressee whose name is specified above.  This message contains confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above, as authorised. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited..

[Julius Volz]

Deprecation would likely mean that we'd publish one last image and then either make it clear in the README.md that the repo is abandoned and won't receive further updates, or we could even archive it on GitHub.

In terms of a wider audience, if you have a better channel in mind, let me know. I could share it on -users as well, although it's a bit off-topic there.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/5be686ab-d815-41e5-82c8-7ef0f326714bn%40googlegroups.com.

[Julius Volz]

It turns out that we already wanted to deprecate the exporter in favor of native collectd Prometheus support in 2020, but there were still concerns about the native support being slower and not having TLS: https://github.com/prometheus/collectd_exporter/pull/96

But if there's no maintainer, we should still deprecate it (at least until someone volunteers). Will give it a few more days...

[George McGinley Smith]

Yeah, I think the collectd_exporter is a much better fit for how we are using CollectD. Rather than figuring out how to configure Prometheus to scrape metrics from any instance running CollectD we fire all the metrics to a central collectd_exporter and scrape there instead.

 

In practice this has worked well for us, but perhaps there’s a better way to configure Prometheus to scrape arbitrary collections of EC2 instances across multiple accounts in AWS? Or some way for EC2 nodes to register themselves to be scraped by Prometheus?

 

Error! Filename not specified.

Error! Filename not specified.

 

CONFIDENTIALITY NOTICE:

This message (including any attachments) has been sent as a part of discussion between the sender and the addressee whose name is specified above.  This message contains confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above, as authorised. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited..

[Julius Volz]

On Mon, Aug 12, 2024 at 10:51 AM George McGinley Smith <geo...@mukuru.com> wrote:

Yeah, I think the collectd_exporter is a much better fit for how we are using CollectD. Rather than figuring out how to configure Prometheus to scrape metrics from any instance running CollectD we fire all the metrics to a central collectd_exporter and scrape there instead.

I would generally advise against one big exporter that aggregates the world, in favor of many individual endpoints that Prometheus can pull from and record automatic health information for. See this last section of my Prometheus Best Practices and Pitfalls talk: https://www.youtube.com/watch?v=gGvQmiub4OM&t=1679s

In practice this has worked well for us, but perhaps there’s a better way to configure Prometheus to scrape arbitrary collections of EC2 instances across multiple accounts in AWS? Or some way for EC2 nodes to register themselves to be scraped by Prometheus?

I mean, Prometheus definitely has EC2 service discovery (https://prometheus.io/docs/prometheus/latest/configuration/configuration/#ec2_sd_config) and you can add as many of these discovery sections as you need for different regions, accounts, or filtering of returned targets by various attributes (not just via the "filters" section, but also via relabeling rules on meta labels). That's more in line with how Prometheus-based monitoring is meant to work.