|
16 | 16 | applications such as pebble, or charmed operators of workloads such as grafana-agent or promtail,
|
17 | 17 | that can communicate with loki directly.
|
18 | 18 |
|
19 |
| -- `LogProxyConsumer`: This object can be used by any Charmed Operator which needs to |
20 |
| -send telemetry, such as logs, to Loki through a Log Proxy by implementing the consumer side of the |
21 |
| -`loki_push_api` relation interface. |
| 19 | +- `LogProxyConsumer`: DEPRECATED. |
| 20 | +This object can be used by any Charmed Operator which needs to send telemetry, such as logs, to |
| 21 | +Loki through a Log Proxy by implementing the consumer side of the `loki_push_api` relation |
| 22 | +interface. |
22 | 23 |
|
23 | 24 | Filtering logs in Loki is largely performed on the basis of labels. In the Juju ecosystem, Juju
|
24 | 25 | topology labels are used to uniquely identify the workload which generates telemetry like logs.
|
|
38 | 39 | - `charm`: A reference to the parent (Loki) charm.
|
39 | 40 |
|
40 | 41 | - `relation_name`: The name of the relation that the charm uses to interact
|
41 |
| - with its clients, which implement `LokiPushApiConsumer` or `LogProxyConsumer`. |
| 42 | + with its clients, which implement `LokiPushApiConsumer` or `LogProxyConsumer` |
| 43 | + (note that LogProxyConsumer is deprecated). |
42 | 44 |
|
43 | 45 | If provided, this relation name must match a provided relation in metadata.yaml with the
|
44 | 46 | `loki_push_api` interface.
|
45 | 47 |
|
46 | 48 | The default relation name is "logging" for `LokiPushApiConsumer` and "log-proxy" for
|
47 |
| - `LogProxyConsumer`. |
| 49 | + `LogProxyConsumer` (note that LogProxyConsumer is deprecated). |
48 | 50 |
|
49 | 51 | For example, a provider's `metadata.yaml` file may look as follows:
|
50 | 52 |
|
@@ -219,6 +221,9 @@ def __init__(self, *args):
|
219 | 221 |
|
220 | 222 | ## LogProxyConsumer Library Usage
|
221 | 223 |
|
| 224 | +> Note: This object is deprecated. Consider migrating to LogForwarder (see v1/loki_push_api) with |
| 225 | +> the release of Juju 3.6 LTS. |
| 226 | +
|
222 | 227 | Let's say that we have a workload charm that produces logs, and we need to send those logs to a
|
223 | 228 | workload implementing the `loki_push_api` interface, such as `Loki` or `Grafana Agent`.
|
224 | 229 |
|
@@ -480,7 +485,7 @@ def _alert_rules_error(self, event):
|
480 | 485 |
|
481 | 486 | # Increment this PATCH version before using `charmcraft publish-lib` or reset
|
482 | 487 | # to 0 if you are raising the major API version
|
483 |
| -LIBPATCH = 29 |
| 488 | +LIBPATCH = 30 |
484 | 489 |
|
485 | 490 | PYDEPS = ["cosl"]
|
486 | 491 |
|
@@ -1539,7 +1544,8 @@ def __init__(
|
1539 | 1544 | the Loki API endpoint to push logs. It is intended for workloads that can speak
|
1540 | 1545 | loki_push_api (https://grafana.com/docs/loki/latest/api/#push-log-entries-to-loki), such
|
1541 | 1546 | as grafana-agent.
|
1542 |
| - (If you only need to forward a few workload log files, then use LogProxyConsumer.) |
| 1547 | + (If you need to forward workload stdout logs, then use v1/loki_push_api.LogForwarder; if |
| 1548 | + you need to forward log files, then use LogProxyConsumer.) |
1543 | 1549 |
|
1544 | 1550 | `LokiPushApiConsumer` can be instantiated as follows:
|
1545 | 1551 |
|
@@ -1728,6 +1734,9 @@ class LogProxyEvents(ObjectEvents):
|
1728 | 1734 | class LogProxyConsumer(ConsumerBase):
|
1729 | 1735 | """LogProxyConsumer class.
|
1730 | 1736 |
|
| 1737 | + > Note: This object is deprecated. Consider migrating to v1/loki_push_api.LogForwarder with the |
| 1738 | + > release of Juju 3.6 LTS. |
| 1739 | +
|
1731 | 1740 | The `LogProxyConsumer` object provides a method for attaching `promtail` to
|
1732 | 1741 | a workload in order to generate structured logging data from applications
|
1733 | 1742 | which traditionally log to syslog or do not have native Loki integration.
|
|
0 commit comments