Speakerstats warnings in Prosody logs

First of all, thank you so much for creating and maintaining this great software!

Second, I have noticed some strange speakerstats warnings in the Prosody log file and would very much appreciate some guidance how to investigate this further (and preferably stop it to prevent being swamped by irrelevant log file data).

I have installed

jicofo 1.0-549-1
jitsi-meet 2.0.4468-1
jitsi-meet-prosody 1.0.4025-1
jitsi-meet-turnserver 1.0.4025-1
jitsi-meet-web 1.0.4025-1
jitsi-meet-web-config 1.0.4025-1
jitsi-videobridge2 2.1-183-gdbddd169-1

from https://download.jitsi.org stable/ InRelease and

prosody 0.11.5-1~bionic6

from http://packages.prosody.im/debian bionic InRelease on a virtual server running Ubuntu 18.04.

From a user’s perspective everything seems to be working just fine. I have noticed, however, that even when the system is not used at all approximately every 10 seconds the following warnings are logged in /var/log/prosody/prosody.log:

Apr 19 09:52:05 speakerstats.FQDNREDACTED:speakerstats_component warn A module has been configured that triggers external events.
Apr 19 09:52:05 speakerstats.FQDNREDACTED:speakerstats_component warn Implement this lib to trigger external events.
Apr 19 09:52:15 speakerstats.FQDNREDACTED:speakerstats_component warn A module has been configured that triggers external events.
Apr 19 09:52:15 speakerstats.FQDNREDACTED:speakerstats_component warn Implement this lib to trigger external events.
Apr 19 09:52:25 speakerstats.FQDNREDACTED:speakerstats_component warn A module has been configured that triggers external events.
Apr 19 09:52:25 speakerstats.FQDNREDACTED:speakerstats_component warn Implement this lib to trigger external events.
Apr 19 09:52:35 speakerstats.FQDNREDACTED:speakerstats_component warn A module has been configured that triggers external events.
Apr 19 09:52:35 speakerstats.FQDNREDACTED:speakerstats_component warn Implement this lib to trigger external events.
Apr 19 09:52:45 speakerstats.FQDNREDACTED:speakerstats_component warn A module has been configured that triggers external events.
Apr 19 09:52:45 speakerstats.FQDNREDACTED:speakerstats_component warn Implement this lib to trigger external events.

At the same time there are no entries in the Prosody error log, the Nginx access log, and the NGinx error log.

In /var/log/jitsi/jicofo.log there are “INFORMATION” logs every 10 seconds, too, but there is a 5 seconds lag of the timestamps compared to the Prosody log so I am not sure whether this is related:

Jicofo 2020-04-19 09:52:00.418 INFORMATION: [38] org.jitsi.jicofo.health.Health.log() Performed a successful health check in PT0.003S. Sticky failure: false
Jicofo 2020-04-19 09:52:10.418 INFORMATION: [38] org.jitsi.jicofo.health.Health.log() Performed a successful health check in PT0.003S. Sticky failure: false
Jicofo 2020-04-19 09:52:20.419 INFORMATION: [38] org.jitsi.jicofo.health.Health.log() Performed a successful health check in PT0.004S. Sticky failure: false
Jicofo 2020-04-19 09:52:30.419 INFORMATION: [38] org.jitsi.jicofo.health.Health.log() Performed a successful health check in PT0.004S. Sticky failure: false
Jicofo 2020-04-19 09:52:40.418 INFORMATION: [38] org.jitsi.jicofo.health.Health.log() Performed a successful health check in PT0.003S. Sticky failure: false

The timestamps for the following entries in /var/log/jitsi/jvb.log seem to be a better match:

2020-04-19 09:52:05.822 INFORMATION: [19] Videobridge.createConference#319: create_conf, id=fba253eaf049eceb gid=null logging=false
2020-04-19 09:52:05.823 INFORMATION: [19] AbstractHealthCheckService.run#171: Performed a successful health check in PT0.001S. Sticky failure: false
2020-04-19 09:52:15.822 INFORMATION: [19] Videobridge.createConference#319: create_conf, id=9f5ae4d7a3c74d8c gid=null logging=false
2020-04-19 09:52:15.824 INFORMATION: [19] AbstractHealthCheckService.run#171: Performed a successful health check in PT0.002S. Sticky failure: false
2020-04-19 09:52:25.822 INFORMATION: [19] Videobridge.createConference#319: create_conf, id=b57cb72b3af314a7 gid=null logging=false
2020-04-19 09:52:25.824 INFORMATION: [19] AbstractHealthCheckService.run#171: Performed a successful health check in PT0.002S. Sticky failure: false
2020-04-19 09:52:35.822 INFORMATION: [19] Videobridge.createConference#319: create_conf, id=d4f745175c3402b3 gid=null logging=false
2020-04-19 09:52:35.823 INFORMATION: [19] AbstractHealthCheckService.run#171: Performed a successful health check in PT0.001S. Sticky failure: false
2020-04-19 09:52:43.409 INFORMATION: [17] VideobridgeExpireThread.expire#144: Running expire()
2020-04-19 09:52:45.822 INFORMATION: [19] Videobridge.createConference#319: create_conf, id=57528c58b3dbdc5d gid=null logging=false
2020-04-19 09:52:45.824 INFORMATION: [19] AbstractHealthCheckService.run#171: Performed a successful health check in PT0.002S. Sticky failure: false

I do not think that I have tinkered with any settings for speakerstats (I actually didn’t even know that this feature existed before I noticed the log file warnings).

Any ideas whether the Prosody warnings should make me nervous, and how I could stop them to appear in the log file? Thank you!

Exact same behavior on my installation with last jitsi meet update.

I also have the same behavior on 2 different instances, and I’m not convinced that it is a real issue. It sound like a normal (and a bit dumb) warning.

It might be a normal behavior, but can we reduce the healthcheck periodicity ? I also noticed 1% cpu permanently used when idle, it could be the result of these healthchecks…

prosody_1  | speakerstats.meet.jitsi:speakerstats_component warn  A module has been configured that triggers external events.
prosody_1  | speakerstats.meet.jitsi:speakerstats_component warn  Implement this lib to trigger external events.

does this mean that if implement the library the warnings would go away?

Found this explanation

Adds server-side speaker stats handling.

Adds the component which receives the messages from client and a module which enabled on a virtual host will start advertising the component. When clients discover the component they will send message to the component with the name of the room where the dominant speaker event happen.

My question is, why are we getting a warning?

@damencho ?

Because a healthcheck is constantly creating and destroying rooms. We should filter those in the speakerstats. To ignore them … and maybe remove and the message …