iorestoacasa-work / iorestoacasa.work

Frontend of the video calling platform iorestoacasa.work
https://iorestoacasa.work
GNU Affero General Public License v3.0
35 stars 9 forks source link

Realizzare uno script per esportare le metriche da una installazione autonoma di Jitsi #15

Closed tapionx closed 4 years ago

tapionx commented 4 years ago

https://it.wikibooks.org/wiki/Software_libero_a_scuola/Jitsi-installazione-su-vps Usare questa guida come riferimento

feroda commented 4 years ago

Ok intendi che chiunque abbia un'installazione autonoma di Jitsi possa aggiungere questa funzionalità in modo da poter essere integrato nel nostro progetto mostrando anche le metriche. La prendo!

tapionx commented 4 years ago

come esporre le metriche:

step 1: abilitare il logging tramite API interna di JVB (tramite colibri)

https://github.com/iorestoacasa-work/docker-jitsi-meet/blob/master/jvb/rootfs/defaults/sip-communicator.properties#L17

tapionx commented 4 years ago

step 2: abilitare le API interne di JVB tramite questa variabile d'ambiente del progetto Docker. Bisogna andare ad individuare dove agisce quella variabile d'ambiente nella configurazione dei demoni

https://github.com/iorestoacasa-work/docker-jitsi-meet/blob/master/env.example#L211

JVB_ENABLE_APIS=rest,colibri

tapionx commented 4 years ago

step 3: esporre la porta delle API private di JVB su localhost:8080 e verificare che visitando /colibri/stats si leggano le metriche

tapionx commented 4 years ago

documentazione di Jitsi che riguarda queste API:

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest.md

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-colibri.md

tapionx commented 4 years ago

step 4: trasformare l'endpoint JSON interno in un endpoint pubblico in formato exporter di prometheus

nel progetto Docker l'ho fatto tramite l'immagine sunbird/prometheus-jsonpath-exporter che usa intelligentemente jsonpath, ma anche uno script da poche righe in Python andrà benone.

Punto di debolezza: quell'immagine trasforma tutte le metriche in "Gauge", mentre alcuni sono dei "Counter"

https://github.com/iorestoacasa-work/docker-jitsi-meet/blob/master/docker-compose.yml#L164

è configurato tramite questo file:

https://github.com/iorestoacasa-work/docker-jitsi-meet/blob/master/exporter_config.yml

feroda commented 4 years ago

https://it.wikibooks.org/wiki/Software_libero_a_scuola/Jitsi-installazione-su-vps Usare questa guida come riferimento

Intanto ho seguito questa guida per l'installazione da 0 comprando un VPS Ubuntu 18.04 (piccolo) cui ho assegnato record A befair3.iorestoacasa.work. Ottima guida!

feroda commented 4 years ago

Grazie @tapionx per le preziose informazioni. Appunto di seguito la procedura che si potrà integrare nelle proprie guide e da cui si potrà produrre lo script:

Esportare le metriche Jitsi

Impostare la variabile JVB_OPTS in /etc/jitsi/videobridge/config:

JVB_OPTS="--apis=rest,colibri"

Aggiungere in /etc/jitsi/videobridge/sip-communicator.properties le righe:

org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc,colibri
org.jitsi.videobridge.STATISTICS_INTERVAL=5000

Riavviare il servizio e testare:

systemctl restart jitsi-videobridge.service
curl -v http://localhost:8080/colibri/stats

A questo punto abbiamo le statistiche su interfaccia privata.

Da qui in poi non è necessario per iorestoacasa.work ed è anzi sconsigliato da Jitsi, ma mi interessa a livello didattico... ;-)

Se volessimo esporle pubblicamente dovremmo aprire l'accesso dall'esterno alla porta 8080

ufw allow in 8080/tcp
# o iptables -A INPUT -p tcp --destination-port 8080 -j ACCEPT

e testare da un host remoto a fare la richiesta curl precedente

...proseguo con lo step successivo...

feroda commented 4 years ago

Fixed https://github.com/iorestoacasa-work/iorestoacasa_addmetrics

tapionx commented 4 years ago

putroppo la modifica alla configurazione di videobridge JVB_OPTS="--apis=rest,colibri" rompe Jitsi.

Quando si collegano due persone in una stanza, si ottiene il messaggio di errore "Unfortunately, something went wrong" e nel log di jicofo:

Jicofo 2020-03-15 18:11:48.738 SEVERE: [29] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant -- no bridge available.

tapionx commented 4 years ago

Ho aperto una issue nel progetto jitsi-meet https://github.com/jitsi/jitsi-meet/issues/5185

tapionx commented 4 years ago

vittoria! https://github.com/iorestoacasa-work/iorestoacasa_addmetrics

nemobis commented 4 years ago

Da https://github.com/jitsi/jitsi-videobridge/blob/45eeb611a8e7634732f73dca92ebe5024641a0a3/src/main/kotlin/org/jitsi/videobridge/stats/config/StatsManagerBundleActivatorConfig.kt#L97 vedo che stiamo usando la "legacy config" https://github.com/jitsi/jitsi-videobridge/blob/e01b2760543cbc0aafb4369ffff380dfaa4d0580/doc/muc.md#legacy-videobridge-configuration ma non mi è chiaro quale sia quella nuova. Del resto il pacchetto ufficiale fa lo stesso: https://github.com/jitsi/jitsi-videobridge/blob/9e64a82087cdbe68b60818a9980f7bb6e19cf9ec/debian/postinst#L104

nemobis commented 4 years ago

Sto cercando di capire la presunta dipendenza da openjdk-8 (su Debian 10 c'è l'11). I pacchetti Debian sono:

dpkg -l | grep jitsi
ii  jitsi-meet                            1.0.4101-1                                   all          WebRTC JavaScript video conferences
ii  jitsi-meet-prosody                    1.0.3729-1                                   all          Prosody configuration for Jitsi Meet
ii  jitsi-meet-web                        1.0.3729-1                                   all          WebRTC JavaScript video conferences
ii  jitsi-meet-web-config                 1.0.3729-1                                   all          Configuration for web serving of Jitsi Meet
ii  jitsi-videobridge                     1126-1                                       amd64        WebRTC compatible Selective Forwarding Unit (SFU)

Quindi dovrebbe essere la versione del 2019-10-03: https://github.com/jitsi/jitsi-videobridge/tree/1126

Questa versione comprende https://github.com/jitsi/jitsi-videobridge/commit/eb7075d2095f4c4f9c71f0955959b9ac90d858e1#diff-5a883c2cde2404251309f64b97f939faL20 che rimuove qualche dipendenza da pacchetti Java ma non https://github.com/jitsi/jitsi-videobridge/commit/7a7f5cfa23ef07aac451492a488f30b2c1685170#diff-5a883c2cde2404251309f64b97f939fa .

Non dovrebbe cambiare niente ma lo segnalo solo perché prima di eventuali segnalazioni di bachi bisognerà probabilmente provare l'ultima versione.

nemobis commented 4 years ago

Da jicofo.log:

JVB 2020-03-25 22:48:05.736 GRAVE: [27] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception.
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not "opens com.sun.management.internal" to unnamed module @24b0f62d
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
        at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
        at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
        at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138)
        at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703)
        at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450)
        at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321)
        at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
        at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
        at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
        at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
        at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

Already filed as https://github.com/jitsi/jitsi-videobridge/issues/1127

nemobis commented 4 years ago

A quanto pare il suggerimento per chi vuole usare JDK 11 è di usare jitsi-videobridge2 dall'archivio unstable di Jitsi, ma non sono riuscito a verificare che una chiamata funzionasse.

NON seguite il consiglio di aggiornare a jitsi-videobridge2 in un'installazione esistente https://community.jitsi.org/t/jvb-2-considered-stable/24314/7 , perché non si può tornare indietro con apt. (Serve ripristinare manualmente come minimo /etc/jitsi/videobridge/sip-communicator.properties e /etc/jitsi/videobridge/config.)