Juliusz,

Would it be possible (if it is not already possible) to add these kind of
data/output in a log flat file ?

Similar things have been discussed before, see for example here:

  https://github.com/jech/galene/pull/23

The problem is that nobody seems to have a clear idea what statistics need
to be provided, and how to provide statistics without sacrificing user
privacy -- I administer three instances of Galène right now, and I don't
want to know who is having a discussion with whom, it's none of my business.

What is more, Galène is designed to scale well on multicore systems, and
the patches to add statistics tend to introduce additional points of
contention.  (Since Go doesn't provide either CPU-local or thread-local
data, you'll need to implement sharding at the application level.)

So if you have a clear idea of what statistics are (1) useful to the
administrator, (2) don't impair user privacy, (3) are cheap to compute,
please outline your design, and we'll think together about how to
implement it without creating a point of contention.

(1) The way I see it, useful stats would be to add something that allow an admin to check the hardware/VM load compare to the number of rooms*users.

eg: %%TIMESTAMP%% 4 rooms with a total of 130 users with a mean resolution ... and bandwidth ...

A data with %users{Mic On/Webcam On} would also be useful, as well as % of drop packets.

Those metrics would help an admin to plan an upgrade for the Galène service, locate any bottleneck/problem, scale it at a wider range (linear progression, or ...?), get an alert if a treshold is reached... Some metrics could be found by monitoring the system globally, but metrics from the inside could drastically help to admin Galène.

(2) I do not see any privacy issue with those kind of very general statistics.

Otherwise, currently, those values are either retrieved theoretically from the code, or based on users experiences.

(3) Those computations may then be choosen by an admin : boolean to enable/disable it, interval between each computation (timer ? cron with another binary ?), metrics to monitor (config file or based on options). I think those computations are very basic but if you think it is really cumbersome for the code, just forget it.

Best regards,

-- Juliusz

-- 
Dernat Rémy
Chef de projet SI, CNRS
Infrastructure des Systèmes d'Information ISI
ISEM Montpellier