# Working with Filter Node Logs This article guides you on how to find the log files of a Wallarm filtering node. Log files are located within the `/opt/wallarm/var/log/wallarm` directory. Here is a breakdown of the log files you will encounter and the type of information each contains: * `api-firewall-out.log`: the log of the [API specification enforcement](https://docs.wallarm.com/api-specification-enforcement/overview.md). * `appstructure-out.log` (only in the Docker containers): the log of the [API Discovery](https://docs.wallarm.com/api-discovery/overview.md) module activity. * `wstore-out.log` (`tarantool-out.log` in the [NGINX Node 5.x and earlier](https://docs.wallarm.com/updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)): the log of the postanalytics module operations. * `wcli-out.log`: logs of most Wallarm services, including brute force detection, attack export to the Cloud, and the status of node synchronization with the Cloud, etc. * `supervisord-out.log`: logs of the Supervisor's process management, including service startups, status changes, and warnings. * `go-node.log`: [Native Node](https://docs.wallarm.com/installation/nginx-native-node-internals.md#native-node) logs. ## Configuring Extended Logging for the NGINX‑Based Filter Node NGINX writes logs of the processed requests (access logs) into a separate log file, using the predefined `combined` logging format by default. ``` log_format combined '$remote_addr - $remote_user [$time_local] ' '"$request" $request_id $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" '; ``` You can define and use a custom logging format by including one or several filter node variables (as well as other NGINX variables if needed). The NGINX log file will allow for much faster filter node diagnostics. ### Filter Node Variables You may use the following filter node variables when defining the NGINX logging format: |Name|Type|Value| |---|---|---| |`request_id`|String|Request identifier
Has the following value form: `a79199bcea606040cc79f913325401fb`| |`wallarm_request_cpu_time`|Float|Time in seconds the CPU of the machine with the filtering node spent processing the request.| |`wallarm_request_mono_time`|Float|Time in seconds the CPU spent processing the request + time in the queue. For example, if the request was in the queue for 3 seconds and processed by CPU for 1 second, then: | |`wallarm_serialized_size`|Integer|Size of the serialized request in bytes| |`wallarm_is_input_valid`|Integer|Request validity
`0` - request is valid. The request has been checked by filter node and matches LOM rules.
`1` - request is invalid. The request has been checked by filter node and does not match LOM rules.| | `wallarm_attack_type_list` | String | [Attack types](https://docs.wallarm.com/attacks-vulns-list.md) detected in the request. Types are presented in text format:If several attack types are detected in a request, they are listed with the symbol `|`. For example: if XSS and SQLi attacks are detected, the variable value is `xss|sqli`. |`wallarm_attack_type`|Integer|[Attack types](https://docs.wallarm.com/attacks-vulns-list.md) detected in the request. Types are presented in bit string format:If several attack types are detected in a request, the values are summarized. For example: if XSS and SQLi attacks are detected, the variable value is `6`. | | `wallarm_attack_point_list` (NGINX node 5.2.1 or later) | String | Lists request points containing malicious payloads. If a point is sequentially processed by multiple [parsers](https://docs.wallarm.com/user-guides/rules/request-processing.md), they are included in the value. Multiple points containing malicious payloads are concatenated using `|`.
Example: `[post][json][json_obj, 'data'][base64]` indicates a malicious payload detected in a base64‑encoded `data` body parameter in JSON.
Note that this log data may differ from the simplified, user‑friendly view presented in the Wallarm Console UI. | | `wallarm_attack_stamp_list` (NGINX node 5.2.1 or later) | String | Lists internal Wallarm IDs for each attack sign detected in a request. Multiple sign IDs are concatenated using `|`. If the same attack sign is detected at multiple parsing stages, the IDs may repeat. For example, a SQLi attack like `union+select+1` could return `7|7`, showing multiple detections.
Note that this log data may differ from the simplified, user‑friendly view presented in the Wallarm Console UI. | |`wallarm_block_reason` (NGINX node 6.4.0 or later)|String|Blocking reason (if applicable). Reasons are presented in text format: