The otlp interface currently lacks a LogForwarder class (similar to the one in loki_push_api) for K8s charms to automatically configure their pebble to consume the endpoint received in the otlp relation and forward logs to the endpoint.
If the goal of the new otlp interface is to replace loki_push_api and metrics_endpoint interface, we should ideally have this LogForwarder class. A lot of charms currently use the loki_push_api interface, especially the LogForwarder class. Some examples are : opencti-operator, paas-charm, oauthkeeper etc.
If we want these charms to be able to transition to the new otlp interface easily, providing some support to automatically configure sending logs to the provider charms would be useful.
One thing to consider is that the otlp interface can be used by both the machine and k8s charms, so we might need to have some gatekeeping logic on preventing machine charms from using this class?
The otlp interface currently lacks a
LogForwarderclass (similar to the one in loki_push_api) for K8s charms to automatically configure their pebble to consume the endpoint received in theotlprelation and forward logs to the endpoint.If the goal of the new
otlpinterface is to replaceloki_push_apiandmetrics_endpointinterface, we should ideally have thisLogForwarderclass. A lot of charms currently use theloki_push_apiinterface, especially theLogForwarderclass. Some examples are : opencti-operator, paas-charm, oauthkeeper etc.If we want these charms to be able to transition to the new
otlpinterface easily, providing some support to automatically configure sending logs to the provider charms would be useful.One thing to consider is that the
otlpinterface can be used by both the machine and k8s charms, so we might need to have some gatekeeping logic on preventing machine charms from using this class?