canonical / canonical/charmlibs

Add a `LogForwarder` component in the `otlp` library

Open
#382 2 comments 1 reaction 2 assignees Claimed by @sed-i View on GitHub
charmlibs-interfaces-otlp needs design
Dominant language
Python
Stars
5
Forks
28
Avg merge
1d 5h
Merged PRs (30d)
24

Description

The [otlp](https://github.com/canonical/charmlibs/tree/main/interfaces/otlp) interface currently lacks a `LogForwarder` class (similar to the one in [loki_push_api](https://github.com/canonical/opentelemetry-collector-operator/blob/3c976e9ddcb44081fa907f768c03a4fd1d9cb3ff/lib/charms/loki_k8s/v1/loki_push_api.py#L361)) 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](https://github.com/canonical/opencti-operator), [paas-charm](https://github.com/canonical/paas-charm), [oauthkeeper](https://github.com/canonical/oathkeeper-operator) 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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.