[Galene] Re: Additional stats

[Stefan Bethke <stb@lassitu.de>]

Hi!

Let me the last point first:

> 1. Do people actually feel that this kind of metrics are useful to include
>   in Galene?  How do people use Prometheus usually, what insights does it
>   give you, and are these insights useful?  Or do people just want
>   Prometheus because it's what everyone does?
> 
>   (As far as I'm concerned, I optimise Galene by running it in production
>   with profiling enabled, then spend some time poring over the profile.
>   I find the output of a profiler much more useful, as it gives me
>   a global view of the behaviour, not just the specific set of statistics
>   that are exported by the monitoring interface.)
> 
> 2. Are you actually using this code in production, and have you found the
>   provided statistics useful for administering Galene?

I am running a test instance and are monitoring that through it. We will use this feature in the production setup December 27th to 30th at the 40th Chaos Communication Congress.

The reason I would like to have statistics, and a Prometheus metrics endpoint in particular:
* We want to understand if the server is running and serving audio as expected
* We want to understand if there are network issues degrading the user experience
* We would like some fancy graphs because they are cool

Information on the WebRTC/ICE performance in particular will be valuable to the NOC that runs the network in the lecure halls. The lecture halls range in size from about 4000 seats down to 500; having a significant amount of people getting on the Wifi and trying to listen to the audio streams requires correctly configured and placed access points. While the APs report on general quality aspects, having the user-visible application-level stats will show issues more immediately. For example, if a large download gets a large-ish number of retried packets, that only slows the download down a bit, but for an audio stream, that could make the difference between usable and unusable. At the past events, we did not have those metrics, so any reports on audio quality were anecdotal, and it was hard to correlate with any network-level metrics.

I do not run Galene outside of this type of event, so I cannot speak to other operators. From my experience running applications, having metrics available in a common format is appreciated quite a bit. But this really depends on the context: if you run a service on a small machine for a limited group of people, then this might not be useful to you at all, since running Prometheus and something like Grafana can take a lot of effort. If you're running it as a production service that many people rely on, and you have the resources and people to run an observability platform, (and you are running many services at the same time), then it can be very helpful.

I'm happy to let others say if they feel this would be helpful or not interesting at all.

> On 30. Oct 2026, at 12:15, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
>> here is my proposal: https://github.com/jech/galene/pull/349
> 
> Thanks, especially for mentioning explicitly that you used Claude to write
> this code.
> 
> Unfortunately, your code has the typical flaws of LLM-generated code:
> 
>  - it's a single commit, with a verbose but useless commit message;
> 
>  - there are a number of changes that are unrelated to Prometheus, that
>    are bundled into the same commit;
> 
>  - the comments are verbose and not useful;
> 
>  - the code is overly verbose, with no clear indication which features
>    are actually useful;
> 
>  - doc strings and comments paraphrase the code rather than providing
>    information that's useful to the reader.
> 
> For now, I suggest you extract the changes unrelated to Prometheus and
> submit them in a separate PR.  Before we decide whether to work on
> improving the code, I'd like to understand two things.

Let me understand how you would like changes to be split up.

My design decision was to integrate the /metrics endpoint into the regular HTTP handler, and extend the authentication setup to control access to it. Other products have the /metrics endpoint on a separate handler (different port), and do not implement authentication, but rely on firewall rules to limit access to it. Running /metrics on its own handler and port would make the changes to the config and authentication redundant. If you would prefer to have it like that, I can certainly do that. Likewise, if the metrics endpoint is configured through command line options, the changes would not touch the config file.

The change in stats.go is to enable reuse of the code block from prometheus.go. If you'd rather have code duplication to keep the code completely separate, that is easy to change.

I'm happy to reword the pull request, commit messages, and coments, I'm happy to do that too. I honestly don't find the comments to be overly verbose?


Thanks,
Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 175 3288861