prometheus-community / community Goto Github PK

Hello everyone, I'd like to propose moving uwsgi_exporter to this org.

Do we want to offer anything specific?

What immediately comes to mind is access to infrastructure for testing and such.

Up until 2018 Freshtracks.io, was pioneering analytics and performance tooling built on top of prometheus. After Freshtracks shut down in November 2018, the collection of prometheus related tools hosted within its repository were left without owners; https://github.com/open-fresh.

This is a proposal to fork or move the four public repos that belonged to FreshTracks, and move them under the prometheus github organization. It is my belief that these repos still continue to serve the prometheus community, as shown by the issues and PRs that continue to be raised in repos without maintainers.

@stanhu's fork of the pgbouncer_exporter is now in our community repos. He would like to continue being a maintainer.

I would like to move https://github.com/inuits/hazelcast_exporter/ to this community.

@frodenas is interested in transferring the stackdriver_exporter to the Prometheus Community.

prometheus-community/stackdriver_exporter#72

We have two "management" projects now. prometheus-community/community and prometheus-community/prometheus-community`.

I think we should consolidate things to just this project.

hi!

the bind exporter is in fairly good shape in terms of contributions, but upstream seems to be struggling with issuing proper releases (see prometheus-community/bind_exporter#55). it seems @digitalocean is not really supporting it, so maybe it could be moved here.

@Nexucis and others from Amadeus built PromQL support for the Monaco code editor (the editor component of VS Code): https://github.com/AmadeusITGroup/Monaco-language-PromQL

We are both interested in moving this to prometheus-community. If we want to do this, Amadeus is only asking to fork the original repo to here, mark the original repo as obsolete, and mark the fork as authoritative (but not break the fork status).

@RichiH @SuperQ should we just do this or does there need to be a discussion?

I would like to propose moving https://github.com/free/jiralert to prometheus-community. It is a quite alert manager webhook created by @free that creates tickets from alerts.

Happy to sponsor it as well, despite that, we currently don't use it in my new job (: Still, I think it would be awesome to have it here in community space.

@free are you happy with this? I think we initially discussed this offline couple of months ago.

The unifi_exporter seems to be the only reasonable Prometheus exporter for Ubiquiti Unifi.

I would like to see development continue, as I use Ubiquiti stuff in a couple places.

@mdlayher Do you think it would be useful to bring your code into the Prometheus Community projet to see if we can get some new contributors?

I am happy to sponsor adoption of this exporter.

I have written a lightweight ECS exporter that is positioned to run as a sidecar container on tasks to publish ECS infrastructure metrics in the Prometheus format. There is substantial interest from the community and the existing customers to be able to export ECS metrics in the Prometheus exposition format.

I would like to open source the sidecar and maintain it on behalf of the ECS team and wondering if this organization is a better place for it. I'd like to kick of the process to contribute to here if there is any interest. Complimented by the discovery contributions (prometheus/prometheus#9310), the ECS exporter will make it easier for ECS users to adopt Prometheus.

since almost all of the metrics exposed via http(s), how about we create a proxy_exporter which supports all kinds of service if we want.
just wrap the other exporter, and call them via service=xx arg.

here's my previous repo: https://github.com/mxlxm/exporters

The PromQL language server is a back end for providing IDE like features for PromQL.

Currently there exist two Plugins that integrate the PromQL language server with a text editor.

• https://github.com/redhat-developer/vscode-promql (for VS Code)
• https://github.com/nevill/lsp-promql (for Sublime Text)

For consistency reasons it would make sense to have both of these projects somewhere in promtheus-community. This also likely would simplify the legal situation around using Prometheus trademarks and branding.

The current owners of these projects seem to be willing to donate those to prometheus-community.

To move these projects to prometheus-community there are basically two options:

• Moving the repos to the prometheus-community org.
• Putting everything in the promql-langserver repo. This mono repo approach would provide the advantage of simplifying the release process, changes that need to happen both on the extension and on the server side and the creation of integration tests.

cc @krasi-georgiev @brancz @squat @juliusv @sym3tri @ant31 @nevill @Nexucis

We would like to move https://github.com/justwatchcom/elasticsearch_exporter here

It was previously maintained by justwatchcom, but as we currently do not have the capacity to work on it, the repo is kinda abandoned.

@metalmatze and @SuperQ offered to sponsor this transfer and from our side I am happy to help where I can.

Let's give it some love and get it into a good shape again. Looking forward to your insights.

cc. @zwopir @falschparker82

The upstream pgbouncer0 exporter is abandoned. But we have an active fork at https://github.com/stanhu/pgbouncer_exporter. I think this would be a good candidate for the Prometheus community.

@brian-brazil says he has less time to maintain PushProxy

Let's adopt https://github.com/RobustPerception/PushProx

I can serve as the maintainer sponsor.

add @dongjiang1989 to team @prometheus-community/community

See:

1. @dongjiang1989 is maintainer. like: https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-pingmesh-exporter
2. @dongjiang1989 is contributor. like: prometheus-community/helm-charts#3337 prometheus-operator/prometheus-operator#5449

The maintainers of wmi_exporter (me and @martinlindhe) would like to propose adopting the wmi_exporter into prometheus-community.

At the same time, the project also should be renamed, to reflect that we are now not only using WMI as a datasource. Proposed new name is simply "windows_exporter", but open for suggestions.

Good day,

A somewhat popular exporter doesn't appear to be taking many contributions and I'm wondering if we could move those community contributions to a fork under this org.

https://github.com/tomcz/openldap_exporter

If this can happen, I would happily leave a comment on the recently closed Github PRs for that repo to offer contributions be made to the fork here. Ideally we could include some build infrastructure to publish docker images.

What do you think?

I suspect we will end up using Prometheus governance as a starting base.

Two obvious questions:

• What, if any, is the level of involvement we would mandate to join this org as a member? We should strive to avoid vanity memberships to keep everything running smoothly.
• Does prometheus-team feel the need to retain final call in case of disagreements or should we be on completely equal footing?

As to the latter, I think there needs to be a backstop in case of hard technical disagreements, but else, it should be equal. I don't expect we would ever need the backstop.

The kitefactory project is used to automate the build of BuildKite agent nodes for the node_exporter's non-Linux/non-x86 build pipelines.

https://github.com/derekmarcotte/kitefactory

@derekmarcotte would like to bring this into the community so we can collaborate on maintaining the node_exporter builds.

CC @paulfantom, who might be interested in collaborating on some more Ansible. 😁

The Jenkins Prometheus plugin (https://github.com/jenkinsci/prometheus-plugin) gets infrequent updates and frequently has bugs and integration issues.

I just returned from KubeCon, and it's clear that Jenkins is widely used by many as their CI/CD solution.

As of this writing, the latest version of the Jenkins Plugin (2.0.6) crashes on many installations, and in spite of multiple requests to the maintainer, there has been no resonse.

We can do better.

There is some interest in adopting the systemd_exporter.

I'd be willing to sponsor this.

prometheus-community/systemd_exporter#47

CC @povilasv

I'd like to propose / offer moving https://github.com/inovex/prometheus-libvirt-exporter to prometheus-community.

Libvirt is likely the most widely used VM hypervisor on Linux.
Be it to run some VMs on a single server or managed by orchestrators the likes of OpenStack (Nova), Proxmox or others.
There are/were other exporters, namely Tinkoff's which was in turn based on Kumina's. Development of all of them has stalled unfortunately, even though https://github.com/prometheus/prometheus/wiki/Default-port-allocations still links to them and e.g. Debian still creates packages (https://packages.debian.org/sid/prometheus-libvirt-exporter).

Apart from the lack of recent development activity, the most important difference is the used library to communicate with libvirt. While @kumina and @Tinkoff use https://github.com/libvirt/libvirt-go, which is a C-library, the proposed prometheus-libvirt-exporter (https://github.com/inovex/prometheus-libvirt-exporter) uses go-libvirt (https://github.com/digitalocean/go-libvirt) native Golang lib (auto-)created by DigitalOcean. This allows the exporter to be much more portable between libvirt versions and distros. There was even some discussion about refactoring (Tinkoff/libvirt-exporter#25), but those efforts never materialised. Additionally the libvirt-go library is now deprecated and has itself been replaced by https://github.com/libvirt/libvirt-go-module.

At @inovex we have been using the prometheus-libvirt-exporter, initially written by @zhangjianweibj for quite a while for our OpenStack environment. But since June 2021 there have been no more commits or releases. And while the exporter already does have support to extract OpenStack Nova metadata from libvirt domain, some changes that were merged (e.g. exporting OpenStack instance flavorName - inovex/prometheus-libvirt-exporter@28296e3) never made it to a binary release.

There were some forks, the most recent / active likely being https://github.com/Ferlab-Ste-Justine/prometheus-libvirt-exporter/ who started to refactor some things. Unfortunately but there were no efforts to update and maintain the exporter outside of individual installations or to become the new default source for it.

We believe having a common and well maintained libvirt-exporter makes sense and went ahead to clean and modernize the existing code:

• Use the official Prometheus exporter toolkit and built-in landing page
• Update all modules to their latest versions
• Update logging to use go-kit
• Update to Go 1.21
• Add CI for build, linting
• Add Dependabot config
• Add releases via goreleaser
• Export arch and machine attributes via info metrics

We also cleaned up the exported metrics, causing breaking changes in https://github.com/inovex/prometheus-libvirt-exporter/releases/tag/v1.4.0):

• Change the label names to follow best practices and be snake-cased (similar to Ferlab-Ste-Justine)
• Move all informational labels to dedicated info metrics to avoid an ever growing list of labels, with more domain metadata being exported.
• Clean up the metric naming (in regards to the subsystems)

All the changes we did are listed here: inovex/prometheus-libvirt-exporter@start_of_fork...v1.4.0

We hope you agree with our reasoning to start yet another fork and that someone from the prometheus-community sponsors this move. Certainly we will continue to contribute to this exporter also under the prometheus-community umbrella.

I'd like to start a new prometheus community project for exporting SMART metrics. I've created some prototype code in my personal repository (https://github.com/pgier/smartmon-exporter). There seems to be some demand for smart metrics to be added to node_exporter (prometheus/node_exporter#473, prometheus/node_exporter#782), but due to some of the constraints of node_exporter (no root priveledges, using external binaries, etc) it might make more sense for this to be a separate exporter.

prometheus-community/elasticsearch_exporter#349

This document could be part of governance, or it could stand alone. It should lay out what is expected of any maintainer and some common baselines of how to work with their own repos. For example, working through pull requests instead of pushing directly to master ensures that we always have some review and that no single-person projects exist; per definition, at least two people will need to take an interest to make PR-based workflows work.

Hello 👋

Problem

Helm stable and incubator repos are EOL on Nov 13, 2020 (See support plan and Deprecation Timeline). The community (chart OWNERS, organizations, groups or individuals who want to host charts) are moving charts to new Helm repos, and will list these new repos on the Helm Hub before stable and incubator are de-listed there.

Proposed solution

• Please create a new git repo for prometheus-community helm charts: https://github.com/prometheus-community/helm-charts
• Invite collaborators to the new prometheus-community/helm-charts git repo with to help move over prometheus-related community charts from the stable helm repo (to properly retain git history), and set up CI/CD for automated chart testing and releasing. You can invite me, and I'll invite the others

From there, these remaining checklist items can move to an issue in the new repo. I'm listing them here so everyone can see the end-to-end plan:

• Invite existing prometheus community chart maintainers as collaborators with write access
• List new chart repo at https://hub.helm.sh/ and https://artifacthub.io/
• Deprecate the moved charts in the stable repo
• Work with prometheus developers and community to properly refactor charts within the new prometheus-community/helm-charts repo to refactor, and deprecate/rename as needed according to ongoing discussion about more appropriate architecture/naming

Additional context

Open question about prometheus-operator chart

Update: it was decided that the prometheus-operator chart should move to the prometheus-community org, per prometheus-operator/prometheus-operator#3169 (comment)

@paulfantom pointed me to the open issue at prometheus-operator/prometheus-operator#3169 and I have commented there.

Relevant notes from IRC

From chat in Freenode #prometheus-dev IRC today

I'm part of the Helm team, focusing largely on charts, repos and related tooling. Just caught up on the "Helm charts home" mailing list topic https://groups.google.com/g/prometheus-developers/c/Gh8GMscELao/m/2zZFPwdLBwAJ?pli=1 and would like to help however I can to get questions resolved for the new home(s) for stable prometheus charts before the current repo deprecation.

@brancz and I had an earlier Slack thread with Naseem in February/March about this. I think the mailing thread covered most of the topics we discussed.

In general, an idiomatic approach for an org hosting multiple Helm charts is a monorepo. If on GitHub, Helm has created Actions for consistent chart testing during CI and chart packaging releasing for CD (listed in the mail list thread). For history sake, we normally recommend preserving git history (using filter-branch) when moving charts, so that it's clear to future devs why past changes were made, and to credit those who made them.

That thread bike-shedded a bit on details like naming (really just keep it simple, no prefixes or suffixes needed etc). But there were two other points that I think are legit potential blockers to discuss:

1. how the prom charts should be ideally structured vs how the stable ones people depend on now are structured
2. whether there should be several categories of charts, clearly separated somehow for end users (example: a. charts owned by prometheus to be better architected and named, b. charts maintained by the community moved from stable as-is and refactored over time, c. charts focused on external projects like the prom jira-alerts. Or maybe b and c should be combined etc)

My suggestion to keep things as simple as possible is to take a multi-stage approach:

• First ask a Prometheus GitHub admin to create a new git repo https://github.com/prometheus-community/helm-charts. And invite a few collaborators as repo admins to help set it up (I'm happy to help), as well as write access for current chart maintainers (we can follow up about github usernames)
• Then we can bring in the existing charts as-is, with a goal of refactoring, and deprecating/renaming as needed from there according to ongoing discussion about more appropriate architecture/naming

☝️ This would still allow specific refactored charts to later be moved to https://github.com/prometheus/helm-charts if prometheus developers prefer an easier to distinguish charts maintained internally vs those maintained by the community. But they could also remain in prometheus-community if this isn't desired. My main goal is to unblock the 17 stable community prometheus-related Helm charts currently in use by end users today. Here is an issue we're using to track progress on moving all existing stable charts https://github.com/helm/charts/issues/21103

@SuperQ said:

The first step for that is to open an issue on https://github.com/prometheus-community/community/issues

@brian-brazil said:

I don't think it should ever be in the main prometheus org

Personally I agree. Some people in the mailing list suggested that so I just want to clearly note that the community repo wouldn't preclude individual charts moving elsewhere later, for any technical reasons related to helm repos, hub aggregation etc.

Let's adopt the postgres_exporter.

• Add maintainer team to GitHub.
• Add @wrouesnel to team
• Transfer project
• 🎉

See: prometheus-community/postgres_exporter#475

@kawamuray is interested in moving kawamuray/prometheus-json-exporter to the prometheus community.

prometheus-community/json_exporter#24

Hi there,

I'd like to get the ball rolling on moving the IPMI exporter into this org. I would like to continue maintaining it, the main purpose would be to consolidate the setup for CI builds and Docker images, which we cannot do in our current org (see prometheus-community/ipmi_exporter#70).

@SuperQ has some access to that repo already, but might not be sufficient for the move. I'll take a closer look at our options there. Maybe @matthiasr might also be able to help out here?

I'm using rsyslog_exporter (specifically @aleroyer's fork at https://github.com/aleroyer/rsyslog_exporter, thank you for your work!). I was originally using soundcloud's fork at https://github.com/soundcloud/rsyslog_exporter and consulting its network of repositories there seem to be quite the activity in terms of forks, which is great.

Though as an end-user I find it hard to follow multiple upstream repositories for a given exporter, would there be interest in adopting rsyslog_exporter in this repo and also link it from https://prometheus.io/docs/instrumenting/exporters/ ? In my opinion that would help users find and use a single exporter for rsyslog

thank you !

Hi @hh, let's make some coop-mode via httsp://cloudnative.coop

I'd like to propose moving the popular apache exporter to this community. I bluntly brought up the question with the creator @Lusitaniae in issue Lusitaniae/apache_exporter#145 and seems to like the idea.

With this being the de-facto standard exporter for Apache (see https://prometheus.io/docs/instrumenting/exporters/#http) already and Apache still being all over the place I believe it would be great addition.

We would like to move/donate the prom-label-proxy project we have created originally to build light tenancy/isolation mechanisms in OpenShift for Prometheus and Alertmanager APIs. This component is entirely independent from OpenShift though, and there have been various mailing list threads with people interested in mechanisms like this, so we would love to make this available for more people.

@s-urbaniak @lilic @paulfantom @pgier @simonpasquier and myself are happy to continue to be maintainers for the project.

@simonpasquier and I are obviously happy to sponsor this, but don't want to just push this through within our group, so we'd love to hear other people's opinions as well :)

https://github.com/openshift/prom-label-proxy

As detailed in githubexporter/github-exporter#85, the Github Exporter is no longer actively maintained and the previous maintainers are happy for it to be adopted by this community.

Whilst I don't know GO, I am willing to undertake the work required to get the repo to a point where it is building within the Prom Community's CI/CD platform and see where we can take it from there.

Similar to #19, @Nexucis built PromQL support for the CodeMirror editor (which might be a candidate for usage in Prometheus itself potentially), and we are interested in transferring this repo to prometheus-community. This one doesn't have to be a fork, but can be a direct repo transfer.

@RichiH @SuperQ should we just do this or does there need to be a discussion?

I'd like to invite @dswarbrick as a maintainer of node-exporter-textfile-collector-scripts. They have done a number of good contributions and reviews of the various scripts.

I would like to move https://github.com/roidelapluie/octopush_exporter to this community.

What projects do we want to accept? Do we want to exclude anything?

Please add @cstaud to team @prometheus-community/helm-charts-maintainers

See prometheus-community/helm-charts#456 (comment)