prometheus: Revive the prometheus plugin

[cdecker]

I also added myself as maintainer in the CODEOWNERS file.

[chrisguida]

Excited to see this PR! Will try it out soon :)

[daywalker90]

Tests are flaky, i saw some "address already in use" in one of them.

[chrisguida]

Interesting, looks like this is only broken on 23.11

[chrisguida]

Gonna update the CI to add 24.08 and remove 23.11, then this should be good to go

[chrisguida]

@cdecker any suggestions on how to use this? I'm not familiar with the prometheus protocol.

I think this is fine to merge since this plugin was already in the plugins repo, just archived due to failing tests, which this PR fixes.

ACK 78b17da

[cdecker]

Sure, the plugin just exposes the /metrics URL on a given port (concurrent tests are causing the flakiness), and then you configure your prometheus server to scrape that endpoint, which puts the metrics in its timeseries DB. It's a very lightweight way of collecting metrics in a scalable way.

[mikemoniker]

Taking a look at this, I have a raspiblitz running cln, going to clone the prometheus plugin branch in and run prometheus and point it at the endpoint.

[mikemoniker]

I was able to install prometheus and get it to ingest the metrics and display them on port 9100. I had some difficulties with poetry and raspiblitz.

Since raspiblitz does everything with pip install --user, but I did not find an equivalent for poetry, I had to edit the shebang of the prometheus.py to use the venv python executable. @cdecker, I am curious how you run this on your system. Is there a more reproducible way? So it can be easier for future users.

[cdecker]

We have been playing with a number of possible python installation options:

• Using the system python install. This quickly leads to version conflicts for multiple python projects and often lags severely behind in it's version often going over EOL
• Using the env helper to find the python virtualenv: #!/user/bin/env python3 picks up the python env from the $PATH envvar. However that envvar comes from lightningd so it is shared between plugins, potentially causing multiple plugins to cause a version clash. The advantage is that it is very flexible and doesn't require additional setup, but plugins share an env.
• Using uv to manage both python interpreter as well as python dependencies. Setting a shebang of #!/ist/bin/env -S uv run will pick uv from the env, have it read the script (see how dependency declaration can be embedded in the script), create a virtualenv (cached), download a matching interpreter (cached), install any missing dependency (cached) and run the script with the env. Requires some setup so that uv is available, but provides the best env isolation and the least headaches I think.

Ideally we'd have something that works everywhere. Maybe a runner script that analyzes the env, adjusts it and then runs the interpreter could be useful, but at that point why not use uv directly?

[chrisguida]

Hmm uv sounds interesting! Will research...

[chrisguida]

re-ACK 7c565dd