Logs and Metrics

Logs about Core WAAP's http request / response processing and possible security policy violation events are crucial for the visibility of the target web application or API operation. Core WAAP Operator logs allow to monitor configuration change events. Besides logs, metrics offer quantitative data on aspects like traffic volume, response times, and blocked threats, enabling the monitoring of Core WAAP effectiveness over time and identifying trends or anomalies.

All Core WAAP components log to standard error in either JSON or text format. To process logs via a dedicated log stack for further processing and visualization, it is recommended to use the JSON format. Metrics are exposed in Prometheus format via a dedicated Kubernetes service which is named after Core WAAP CRD with metrics- prefix. The port of this service can be configured in spec.operation.metrics section of the CRD (see API Description for it). The URL is /metrics.

Note that the Auto-Learning CLI can process logs in either format.

How the log and monitoring stack can look like is beyond the scope of this documentation.

Log format

The log format is selected with spec.operation.startup.logFormat and applies to all Core WAAP components.

Core WAAP emits two kinds of log lines: regular component logs and access logs.

Component logs

Component log lines start with a series of bracketed fields, followed by the message and, optionally, additional key=value attributes providing context for the message.

In text format:

[<time>][<level>][<worker>][<logger>][<source>][<component>] msg="<message>" <key>=<value> ...

In JSON format:

{"time":"<time>","level":"<level>","workerId":"<worker>","logger":"<logger>","source":"<source>","component":"<component>","msg":"<message>", ...}

The bracketed fields are:

The message follows in msg. Depending on the component, additional attributes may be appended as key=value pairs (text format) or as extra fields (JSON format).

Access logs

Access log lines describe a single processed HTTP request / response. They are identified by the access component and, instead of a message, carry a fixed set of request, response, upstream and client fields.

In text format:

[<time>][access] request.id="<...>" request.protocol="<...>" ... client.direct_address="<...>" hostname="<...>"

In JSON format:

{
  "time": "<time>",
  "component": "access",
  "request": {
    "id": "<...>",
    "protocol": "<...>",
    "method": "<...>",
    "path": "<...>",
    "total_duration": <...>,
    "body_bytes_received": <...>,
    "headers": {
      "referer": "<...>",
      "forwarded_proto": "<...>",
      "forwarded_host": "<...>",
      "forwarded_for": "<...>",
      "useragent": "<...>"
    }
  },
  "response": {
    "status": <...>,
    "details": "<...>",
    "flags": "<...>",
    "body_bytes_sent": <...>
  },
  "upstream": {
    "connection_id": "<...>",
    "duration": "<...>",
    "host": "<...>",
    "route": "<...>",
    "cluster": "<...>",
    "bytes_sent": <...>,
    "bytes_received": <...>
  },
  "client": {
    "id": "<...>",
    "address": "<...>",
    "local_address": "<...>",
    "direct_address": "<...>"
  },
  "hostname": "<...>"
}

The fields are:

Core WAAP filter metrics

The following metrics are exposed to help you monitor and observe the behavior of several filters. Each metric captures a specific aspect of traffic processing giving you full visibility into both allowed and blocked transactions across all policy layers.