Describe the enhancement
Add support for loki as a backend for frame logs. This can help with scaling instead of relying on a single storage namespace. It will also add more features to the logs with eg. added telemetry per log line.
Implementation suggestion :
The plan is to have the loki configuration live on the cuebot host. Which means each cuebot can have their own loki server attached, this should also help when spanning geographical locations. The rqd daemon will get the loki details from the cuebot it's connected to.
For cuegui it will be the same. When connecting to the cuebot it will fetch if loki is enabled and which url it has to reach it. A seperate logview widget is used to fetch the logs from loki (if loki is enabled on the cuebot)
Alternative suggestion :
Register loki enablement and url on each job.
Workflow :
cuebot has loki enabled and with url of the host
loki enablement and url is fetched by rqd when connecting to the cuebot
rqd streams the log to the loki server using the details from above
cuegui reads the logs from the loki server with the details provided by the cuebot
Describe the enhancement Add support for loki as a backend for frame logs. This can help with scaling instead of relying on a single storage namespace. It will also add more features to the logs with eg. added telemetry per log line.
Implementation suggestion : The plan is to have the loki configuration live on the cuebot host. Which means each cuebot can have their own loki server attached, this should also help when spanning geographical locations. The rqd daemon will get the loki details from the cuebot it's connected to.
For cuegui it will be the same. When connecting to the cuebot it will fetch if loki is enabled and which url it has to reach it. A seperate logview widget is used to fetch the logs from loki (if loki is enabled on the cuebot)
Alternative suggestion : Register loki enablement and url on each job.
Workflow :