Octavia Logging

The default logging configuration will store the logs locally, on the amphora filesystem with file rotation. Octavia Amphorae can offload their log files via the syslog protocol to syslog receivers via the load balancer management network. This allows log aggregation of both administrative logs and also tenant traffic flow logs. For all the information and configuration visit Octavia Amphora Log Offloading documentation. Log Offloading is not enabled by default and can be configured.

Logging Configuration

apiVersion: yaook.cloud/v1
kind: OctaviaDeployment
...
spec:
  networking:
    managementSubnetCIDR: 172.17.0.0/22
    logSubnetCIDR: 172.18.0.0/22 # Must not overlap with managementSubnetCIDR
  octaviaConfig:
    amphora_agent:
      log_protocol: TCP
      admin_log_targets:
      - 172.18.3.252:10514

• logSubnetCIDR: Yaook octavia operator will provision a static Neutron network based on logSubnetCIDR. All Amphorae will be connected to that network. It will create exactly 3 Neutron ports with fixed IPs. Fixed IPs will always be last 3 usable IPs from logSubnetCIDR (in this case 172.18.3.252, 253 and 254). Also, it will configure security groups for the amphorae, to allow udp/tcp traffic over the port 10514.

• octaviaConfig.amphora_agent: In this example we want to use TCP syslog protocol (by default UDP) to send logs to the 172.18.3.252:10514 target. See upstream openstack documentation for all available options (e.g., tenant_log_targets or forward_all_logs).

With provided logSubnetCIDR, Yaook octavia operator will also create Statefulset called octavia-logging by default with 1 replica. This logging Statefulset contains init container, which configures k8s node with everything necessary to be able to receive syslog messages. Pods created by this Statefulset are restricted to run only on nodes with octavia.yaook.cloud/octavia-logging label and 2 pods can never run on the same node. After this, a process can bind to 172.18.3.252:10514 on the ‘logging’ node and see amphorae logs. Also, maximum number of replicas for this Statefulset is 3 (because of 3 static Neutron ports). So one can set e.g. 2 replicas and configure 2 log_targets (.252 and .253 in this case) in the octavia config. Logging Statefulset configuration could look like this:

apiVersion: yaook.cloud/v1
kind: OctaviaDeployment
...
spec:
  logging:
    replicas: 1 # max 3
    containers:
    - args:
      - -c
      - /fluent-bit/etc/fluent-bit.yaml
      env:
      - name: LISTEN_PORT
        value: "10514"
      image: cr.fluentbit.io/fluent/fluent-bit:5.1.2
      name: fluent-bit
      volumeMounts:
      - mountPath: /var/run/logging
        name: logging-env
      - mountPath: /fluent-bit/etc/fluent-bit.yaml
        name: fluent-bit-config
        subPath: fluent-bit.yaml
    volumes:
    - configMap:
        name: fluent-bit-yaook-config
      name: fluent-bit-config

By containers and volumes one can configure custom container to handle syslog messages from amphorae. Configmap called fluent-bit-yaook-config in this example could look like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-yaook-config
data:
  fluent-bit.yaml: |
    service:
      parsers_file: parsers.conf # built-in parsers
    env:
    - name: LISTEN_IP
      uri: file:///var/run/logging/listen_ip
    pipeline:
      inputs:
      - name: syslog
        mode: tcp
        listen: ${LISTEN_IP} # or 0.0.0.0
        port: ${LISTEN_PORT}
        parser: syslog-rfc3164
      outputs:
      - name: stdout
        match: '*'

This is very basic fluent-bit container to receive amphorae syslog messages and send them to the stdout, so user can use e.g. kubectl logs -n yaook octavia-logging-0 to see the logs. As you can see, LISTEN_PORT has to be always 10514 and LISTEN_IP is mounted from logging-env volume created by init container (it writes listen ip to the /var/run/logging/listen_ip). You don’t have to use LISTEN_IP at all and instead of it use 0.0.0.0.