2020-04-25 10:22:22 +02:00
|
|
|
[supervisord]
|
|
|
|
|
logfile=/var/log/supervisord.log ; (main log file;default $CWD/supervisord.log)
|
|
|
|
|
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
|
|
|
|
|
logfile_backups=10 ; (num of main logfile rotation backups;default 10)
|
|
|
|
|
loglevel=info ; (log level;default info; others: debug,warn,trace)
|
|
|
|
|
nodaemon=true ; (start in foreground if true;default false)
|
|
|
|
|
user=root
|
|
|
|
|
|
implement active srs sync and celery
reworks the entire logic how active streams are being tracked.
instead of keeping a counter by listening only to srs callback
hooks, portier will now actively scrape the http api of known
srs nodes to retrieve information about all currently existing
streams on a srs node. this prevents portier from being wrong
about active stream counts due to drift, and allows us to show
more information about stream data to users in the future,
as the srs api will also expose information about used codecs,
stream resolution and data rates as seen by srs itself.
to implement this, the previous remains of celery have been
made active again, and it is now required to run exactly one
celery beat instance and one or more celery workers beside
portier itself. these will make sure that every 5 seconds all srs
nodes are actively being scraped, on top of the scrape that is
triggered by every srs callback hook.
this keeps the data always superfresh.
the celery beat function allows us to implement cron-based
automation for many other functions (restream, pull, etc) in
the future as well, so it's okay to pull in something more heavy
here rather than just using a system cron and executing a
custom management command all the time.
2024-02-29 18:33:52 +01:00
|
|
|
[program:celery_beat]
|
2020-04-25 10:22:22 +02:00
|
|
|
directory=/app
|
implement active srs sync and celery
reworks the entire logic how active streams are being tracked.
instead of keeping a counter by listening only to srs callback
hooks, portier will now actively scrape the http api of known
srs nodes to retrieve information about all currently existing
streams on a srs node. this prevents portier from being wrong
about active stream counts due to drift, and allows us to show
more information about stream data to users in the future,
as the srs api will also expose information about used codecs,
stream resolution and data rates as seen by srs itself.
to implement this, the previous remains of celery have been
made active again, and it is now required to run exactly one
celery beat instance and one or more celery workers beside
portier itself. these will make sure that every 5 seconds all srs
nodes are actively being scraped, on top of the scrape that is
triggered by every srs callback hook.
this keeps the data always superfresh.
the celery beat function allows us to implement cron-based
automation for many other functions (restream, pull, etc) in
the future as well, so it's okay to pull in something more heavy
here rather than just using a system cron and executing a
custom management command all the time.
2024-02-29 18:33:52 +01:00
|
|
|
command=/usr/local/bin/celery -A portier beat -l INFO --scheduler django_celery_beat.schedulers:DatabaseScheduler
|
2020-04-25 10:22:22 +02:00
|
|
|
autostart=true
|
|
|
|
|
autorestart=true
|
|
|
|
|
priority=5
|
|
|
|
|
stdout_events_enabled=true
|
|
|
|
|
stderr_events_enabled=true
|
|
|
|
|
stderr_logfile=/dev/stderr
|
|
|
|
|
stderr_logfile_maxbytes=0
|
|
|
|
|
stdout_logfile=/dev/stdout
|
|
|
|
|
stdout_logfile_maxbytes=0
|
|
|
|
|
user=portier
|