You can query Jicofo about how many Jibris it sees and what is their status:
curl -s http://localhost:8888/stats | jq .jibri_detector
curl -s http://localhost:8888/stats | jq .jibri
Check which of the two works for you, because I got the example from different jicofo versions and I can’t check now if all is correct. Or better just check the full stats
curl -s http://localhost:8888/stats and see what is available on your setup.
Another way is to use netstat to see what IP addresses are connected to TCP 5222 and check them all if they reply on
curl -m 2 -s http://$jibriip:2222/jibri/api/v1.0/health - to see if it’s idle, recording, healthy, etc. You can automate this in a script. It is not as good as querying Jicofo directly, because on 5222 there connect all other MUC participants (JVB, etc.) and checking each IP for jibri health will take longer - but if for some reason Jicofo stats don’t work for you, it can help.
What I do generally is make the launch config with instance termination protection. Then, from inside the Jibri itself I do a cron check and if it has been idle for more than a pre-defined period, I remove the protection termination. I also add a cloudwatch alarm that checks if the number of jibris is more than the running recordings and tries to scale them in - if the termination protection has been removed from a particular instance, this kicks in and it is terminated. This way I try to make sure AWS doesn’t terminate a recording jibri. It is not perfect, because there are time differences between the checks, but with some fine tuning it works ok.
Of course, if you can make all the checks from one place and do them in one run, preferable from the cloud and not from within the jibri instances - then you’ll have no such time difference and scaling will work better. Try using the Jicofo and Jibri stats for this.