From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=lassitu.de header.i=@lassitu.de header.a=rsa-sha256 header.s=dkim header.b=p8SstMl0; arc=none (Message is not ARC signed); dmarc=none Received: from jan.hanse.de (jan.hanse.de [IPv6:2a00:14b0:f001:100::fc]) by mail.toke.dk (Postfix) with ESMTPS id 7AD16194EFBA for ; Fri, 30 Oct 2026 12:55:07 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id D11F0EEA87B; Fri, 30 Oct 2026 12:55:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lassitu.de; s=dkim; t=1793361306; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=ePpNqwAlNd/0UPctMpp0yczRh1dDhbDSJTJ5L8cLp98=; b=p8SstMl045ox6QpYllJ6+fsPu9bNKB96G7GtYlyAo2vL6U8L07nUEbK1W2XLQxzVUbkOUN s90SbFXZGLAHZiQ2+9zCYU+THh60rb4xkavV2Fu44tLGO7SBrYiDXJdvucSpMjijMc6vZ7 eYSKDuke84apgJcQtZ3YYxeDKyL3XLZDAOAlWvC4pKK68JbHMzSp70gUwGUh7Pucbxucl/ PG6YuHlvdEJfhur3H8mHGxSi5294ldzDU7THW1xBBoKopU7Y+FEKxRzCm5/UNQSiVAHUVg yP0GgScJOKPXi4hcvxAwAqjfEpg9IVfPC9QSa+ClLkhe52LXwbktXnmrdJmsXg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3901.200.71.1.16\)) From: Stefan Bethke In-Reply-To: <87tsm3e8wh.wl-jch@irif.fr> Date: Fri, 30 Oct 2026 12:55:04 +0100 Cc: galene@lists.galene.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <988C59EA-3721-46A7-A301-908CC8BCB960@lassitu.de> <87qzhkmpa4.wl-jch@irif.fr> <121CCD01-E105-4A60-8BAA-1FDC7865F5C6@lassitu.de> <87tsm3e8wh.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3901.200.71.1.16) X-Last-TLS-Session-Version: TLSv1.2 Message-ID-Hash: PH62BIZ7DRWDNVVWQJN5QJ5THX7DX5RU X-Message-ID-Hash: PH62BIZ7DRWDNVVWQJN5QJ5THX7DX5RU X-MailFrom: stb@lassitu.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Galene] Re: Additional stats List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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? >=20 > (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.) >=20 > 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. =46rom 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 wrote: >=20 >> here is my proposal: https://github.com/jech/galene/pull/349 >=20 > Thanks, especially for mentioning explicitly that you used Claude to = write > this code. >=20 > Unfortunately, your code has the typical flaws of LLM-generated code: >=20 > - it's a single commit, with a verbose but useless commit message; >=20 > - there are a number of changes that are unrelated to Prometheus, = that > are bundled into the same commit; >=20 > - the comments are verbose and not useful; >=20 > - the code is overly verbose, with no clear indication which features > are actually useful; >=20 > - doc strings and comments paraphrase the code rather than providing > information that's useful to the reader. >=20 > 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 --=20 Stefan Bethke Fon +49 175 3288861