Logging configuration and output formatting

Access log

All requests handled by Airlock Microgateway Engine are logged in the access log. Each filter (deny rules, header rewrites, limits, etc.) may provide additional information. Some filters have settings like threatHandlingMode or operationalMode, directly influencing how much information is logged.
For further information, see the corresponding CR documentation of the specific filter.

The CR Telemetry can be used to customize the default log format of Airlock Microgateway. Customization of the access log is described in CR Telemetry.

Application log

The access log of the Microgateway Engine contains the user requests and is of central importance. Nevertheless, the application log might also be interesting for troubleshooting:

  • Application log of the Engine
  • Application log of the Operator

CNI plugin log

By default, the CNI plugin logs directly to the Node under /var/log/airlock-microgateway-cni.log with log-level info.

The plugin name and log-level can be customized in the CNI Helm chart.

Log output from the command line

The different log types, such as access or application logs, can be printed using the kubectl logs as mixed output. You may filter the printed logs according to your needs for better orientation.

  • Use kubectl logs <POD> -c airlock-microgateway-engine to print the logs for the engine container in a pod. For more options, see kubectl logs reference.
  • Use grep <query> to filter the log-message output according to your requirements.
  • With the jq-JSON processor (or equivalent) installed, you may pipe the logs output to the processor for better formatting and readability. See JQ for further information.