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 <https://docs.openstack.org/octavia/latest/admin/log-offloading.html>`_ documentation.
Log Offloading is not enabled by default and can be configured.

Logging Configuration
---------------------

.. code-block:: yaml

    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:

.. code-block:: yaml

    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:

.. code-block:: yaml

    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.