log-aggregator

Log Aggregator

Channel Revision Published Runs on
latest/edge 14 13 Apr 2026
Ubuntu 24.04
juju deploy log-aggregator --channel edge
Show information

Platform:

Learn about configurations >

  • always_enable_jaeger_grpc | boolean

    Force-enable the receiver for the 'jaeger_grpc' protocol in OpenTelemetry Collector, even if there is no integration currently requesting it.

  • always_enable_jaeger_thrift_http | boolean

    Force-enable the receiver for the 'jaeger_thrift_http' protocol in OpenTelemetry Collector, even if there is no integration currently requesting it.

  • always_enable_zipkin | boolean

    Force-enable the receiver for the 'zipkin' protocol in OpenTelemetry Collector, even if there is no integration currently requesting it.

  • cpu | string

    K8s cpu resource limit, e.g. "1" or "500m". Default is unset (no limit). This value is used for the "limits" portion of the resource requirements (the "requests" portion is automatically deduced from it). Note that changing this config option will churn the pod. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • debug_exporter_for_logs | boolean

    Add a debug exporter to the logs pipeline of the OpenTelemetry Collector config. WARNING: Using the debug exporter in a production environment is discouraged, as it will write all collected telemetry to stdout, i.e. to syslog, which is likely to cause log flooding. This can be avoided with the correct usage of the path_exclude config option.

  • debug_exporter_for_metrics | boolean

    Add a debug exporter to the metrics pipeline of the OpenTelemetry Collector config. WARNING: Using the debug exporter in a production environment is discouraged, as it will write all collected telemetry to stdout, i.e. to syslog, which is likely to cause log flooding. This can be avoided with the correct usage of the path_exclude config option.

  • debug_exporter_for_traces | boolean

    Add a debug exporter to the traces pipeline of the OpenTelemetry Collector config. WARNING: Using the debug exporter in a production environment is discouraged, as it will write all collected telemetry to stdout, i.e. to syslog, which is likely to cause log flooding. This can be avoided with the correct usage of the path_exclude config option.

  • extra_alert_labels | string

    Comma separated key-value pairs of labels to be added to all alerts. This could be useful for differentiating between staging and production environments.

  • forward_alert_rules | boolean

    Default: True

    Toggle forwarding of alert rules.

  • global_scrape_interval | string

    Default: 1m

    How frequently should instances be scraped. Supported units: y, w, d, h, m, s.

  • global_scrape_timeout | string

    Default: 10s

    How long to wait before timing out a scrape from a target. Supported units: y, w, d, h, m, s.

  • max_elapsed_time_min | int

    Default: 5

    Maximum time in minutes to wait for the storage backend. After this time, data loss will occur.

  • memory | string

    K8s memory resource limit, e.g. "1Gi". Default is unset (no limit). This value is used for the "limits" portion of the resource requirements (the "requests" portion is automatically deduced from it). Note that changing this config option will churn the pod. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • processors | string

    A global opentelemetry-collector "processors" config in YAML format, without the "processors:" top-level key. For example, to represent a "processors" section such as:

    processors:
      batch:
      memory_limiter:
        limit_mib: 4000

    you could use juju config otelcol processors=@processors.yaml, with:

    # processors.yaml
    batch:
    memory_limiter:
      limit_mib: 4000

    The provided processors section will be applied to all relevant pipelines.

    Reference: https://opentelemetry.io/docs/collector/configuration/#processors

  • queue_size | int

    Default: 1000

    Maximum number of incoming batches of metrics, logs, traces the queue can accept. Ref: https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/exporterhelper/README.md#configuration

  • syslog_endpoints | string

    Syslog server endpoints to forward logs to, in YAML format. Each endpoint can have different protocol, network, and TLS settings. If not set, syslog forwarding is disabled.

    Format (YAML list): syslog_endpoints: | - endpoint: rsyslog1.example.com:514 protocol: rfc5424 network: tcp tls_enabled: false - endpoint: rsyslog2.example.com:6514 protocol: rfc5424 network: tcp tls_enabled: true tls_secret: secret:abc123 tls_skip_verify: false

  • syslog_json_transform | boolean

    Default: True

    When true, log bodies are normalized to JSON before syslog forwarding. Map and key-value string bodies are converted via ToJSON/ParseKeyValue. Syslog attribute mapping (appname, hostname, proc_id) is always applied regardless of this setting. Disable this if your SIEM does not require JSON-formatted log bodies or if you prefer to supply your own transform via the 'processors' config option.

  • tls_insecure_skip_verify | boolean

    Flag to skip the validation of certificates from servers we connect to with TLS. If "true", self-signed certs can be used seamlessly; this setting will be applied to all the otelcol exporter configurations and any receivers which actively make requests to servers, e.g. the prometheus receiver scraping metrics endpoints.

  • tracing_sampling_rate_charm | float

    Default: 100.0

    This property defines the percentage of charm traces that are sent to the tracing backend. Setting it to 100 would mean all charm traces are kept, setting to 0 means charm traces aren't sent to the tracing backend at all. Anything outside of 0-100 range will be clamped to this range by OpenTelemetry Collector.

  • tracing_sampling_rate_error | float

    Default: 100.0

    This property defines the percentage of error traces (from all sources) that are sent to the tracing backend. Setting it to 100 would mean all error traces are kept, setting to 0 means error traces aren't sent to the tracing backend at all. Anything outside of 0-100 range will be clamped to this range by OpenTelemetry Collector.

  • tracing_sampling_rate_workload | float

    Default: 1.0

    This property defines the percentage of workload traces that are sent to the tracing backend. Setting it to 100 would mean all workload traces are kept, setting to 0 means workload traces aren't sent to the tracing backend at all. Anything outside of 0-100 range will be clamped to this range by OpenTelemetry Collector.