Log Formats & Filters Reference

Starter

Professional

Built-in Formats

Glouton includes built-in log formats for common services. These can be referenced by name in file receivers, container configuration, or service definitions.

Naming Convention

Built-in formats follow a naming convention:

• {service} — for parsing host log files (e.g., nginx_access, redis)
• {service}_docker — for parsing container logs (e.g., nginx_docker, redis_docker)
• {service}_both — works with both host files and containers (e.g., nginx_both, apache_both)

Format Reference

| Service | Host Formats | Container Formats | Combined | |---------|-------------|-------------------|----------| | Nginx | nginx_access, nginx_error | — | nginx_both | | Apache | apache_access, apache_error | — | apache_both | | PostgreSQL | postgresql | postgresql_docker | — | | MySQL | mysql | mysql_docker | — | | Redis | redis | redis_docker | — | | Valkey | valkey | valkey_docker | — | | Kafka | kafka | kafka_docker | — | | HAProxy | haproxy | haproxy_docker | — | | MongoDB | mongodb | mongodb_docker | — | | RabbitMQ | rabbitmq | rabbitmq_docker | — | | JSON | json | — | — | | Go slog | json_golang_slog | — | — |

What Formats Do

Each built-in format provides:

• Log parsing — extracts structured fields from log lines (e.g., HTTP method, status code, client IP)
• Timestamp extraction — parses timestamps from log entries into the standard OpenTelemetry timestamp field
• Severity mapping — maps service-specific severity levels (e.g., [error], WRN) to standard OpenTelemetry severity levels

Custom Formats

Define custom log formats using the log.opentelemetry.known_log_formats setting. Each format is a list of Stanza operators.

log.opentelemetry.known_log_formats:
  my_app_parser:
    - type: json_parser
      timestamp:
        parse_from: attributes.time
        layout: '%Y-%m-%dT%H:%M:%S.%L%z'
        layout_type: strptime
      severity:
        parse_from: attributes.level
        mapping:
          debug: 'DBG'
          info: 'INF'
          warn: 'WRN'
          error: 'ERR'
          fatal: 'FTL'
    - type: remove
      field: attributes['some-attr']

In the above example, the timestamp and severity sections are optional settings of the json_parser operator. Similarly, inside the severity setting, the mapping field is optional.

Custom formats do not override the built-in defaults unless they share the same name.

Available Operator Types

Operators are based on Stanza’s operators. The full list of available types includes:

• Parsers: json_parser, regex_parser, csv_parser, syslog_parser, key_value_parser
• Transform: add, remove, move, copy, flatten, retain
• Filter: filter
• Router: router

See the Stanza operators documentation for the complete reference.

Known Log Filters

Log filters control which log entries are kept or dropped based on their content — for example, excluding debug-level messages or only keeping logs from a specific service. They do not modify log entries; they only decide whether an entry is forwarded to the Bleemeo Cloud Platform or discarded.

Define reusable log filters with log.opentelemetry.known_log_filters. These can be referenced by name in service or container configurations.

log.opentelemetry.known_log_filters:
  min_level_info:
    include:
      match_type: strict
      severity_number:
        min: info
        match_undefined: true

Global Filters

Global filters apply to all log sources: auto-discovered services, file receivers, container logs, and OTLP receivers. Configure them with log.opentelemetry.global_filters.

OTTL Drop Filter

Drop matching log records using OpenTelemetry Transformation Language expressions:

log.opentelemetry.global_filters:
  log_record:
    - "Hour(Now()) < 7 or Hour(Now()) > 19"

Include / Exclude Filters

log.opentelemetry.global_filters:
  include:
    match_type: strict
    record_attributes:
      - key: 'container.name'
        value: 'app-01'
  exclude:
    match_type: regexp
    severity_texts:
      - 'debug'
      - 'trace'

Filter Structure Reference

Both per-receiver filters and global filters support the same structure:

| Field | Description | |-------|-------------| | log_record | List of OTTL expressions; matching records are dropped | | include.match_type | strict (exact match) or regexp | | include.resource_attributes | Match on resource attributes (key/value pairs) | | include.record_attributes | Match on record attributes (key/value pairs) | | include.severity_texts | Match on severity text values | | include.severity_number | Match on severity number (min, match_undefined) | | include.bodies | Match on log body content | | exclude | Same structure as include |

Behavior notes:

• All conditions within include or exclude use OR logic
• Entries inside each section are also OR conditions
• When both include and exclude are specified, include filtering occurs first