Logging configuration

Tips for printing logs

The different log types, such as access or application logs, can be printed using the kubectl logs as mixed output.

  • For better orientation, filter the printed logs according to your needs:
  • 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.

Access log configuration

Airlock Microgateway includes a default access log configuration sufficient for most use cases. For information on how to further customize the access log, see CR Telemetry.

Access log related options are available in the following CRs:

CR

Available options

CR HeaderRewrites

Logging information for header rewrites can be enabled using the Integration mode. This operational mode is useful for integration tasks to configure exceptions to avoid false positives.

See article Integration mode for more information.

Switching to Integration mode may lead to a significant increase in resource consumption. Use it when additional information is needed for integration purposes.

CR DenyRules, CR Limits

Thread handling modes Block and LogOnly are available. The LogOnly mode does not influence the logging output itself.

See also CR DenyRules and CR Limits.

Engine and Network Manager application log configuration

The application log level for the Microgateway Engine and the Network Manager can be set individually as annotations for the sidecar injection in the deployment template of your application.

Example:

copy
...
 spec: 
  selector: 
    matchLabels: 
      app: example-backend 
  template: 
    metadata: 
      annotations: 
        sidecar.microgateway.airlock.com/inject: "true" 
        sidecar.microgateway.airlock.com/networkManagerLogLevel: "debug" 
        sidecar.microgateway.airlock.com/engineLogLevel: "debug"
...

The configuration files in the Config Map airlock-microgateway-operator-operator-config are only read at startup.

  • The Microgateway Operator must be restarted once the file operator_config.yaml or the referenced template files has been changed.
  • The protected Pods must be restarted when the referenced template files have been changed.
  • The following log levels are available:
  • Engine: trace, debug, info (default), warn, error, critical, off
  • Network manager: debug, info (default), warn, error

The engine application log format is configured in the --log-format argument of the engine container template. For more information, see Envoy log format options.

Operator application log configuration

The application log level for the Microgateway Operator can be set in the operator config file operator_config.yaml.

Example:

copy
apiVersion: config.airlock.com/v1alpha1
kind: OperatorConfig
... 
log: 
  level: info
...

The Microgateway Operator log level is a global setting and the Operator Pod needs to be restarted for the new setting to be applied.
The following log levels are available: debug, info (default), warn, error.