What does Debug Mode record; how long should I keep it on?
Short answer
For every request coming to the HTTP vService, or for the requests that match the defined condition, Debug Mode records, in addition to the fields of the HTTP log, millisecond timings, the termination state (Termination State), the retry count, the request and response headers, at most 16 KB of the request and response body, TLS and certificate details, and the Bot/DDoS and WAF decision (Debug Logs). The records are kept in a disk budget of 128 MB per vService and are not sent to the log server. Debug mode has no duration setting that turns it off automatically; it stays on until it is turned off. For this reason, it should be kept on only long enough to reproduce the problem, limited with a condition if possible, and Status should be set back to Enabled when the examination is finished.
How Does It Work?
In an HTTP vService with Debug mode on, a record is produced in the groups below for every request (if a condition is defined, only for the requests that match the condition); the records are read in the Debug Mode Logs source of the Logs & Tracking tab of the vService screen.
| Group | Content |
|---|---|
| Connection | Client and vService addresses, host, method, path, status code, the Backend Service and Backend Group that gave the response |
| Timing | Request, queue, connection, server response and total times (The site is slow; how do I tell whether the problem is in TR7 or in the backend?) |
| Termination | Termination State and Retries (How do I find out from the logs why a request failed (termination state)?) |
| Headers | Request and response headers; the headers that TR7 added, removed or changed are shown separately |
| Body | The first 16 KB of the request and response body |
| TLS | TLS version, cipher suite and certificate information on the client and Backend Service side |
| Security | Bot/DDoS and WAF decision, bot score and class, IP reputation, Security Action |
| Custom fields | Name and value pairs added with Custom Debug Log Entries under Debug; they appear under Custom Entries in the preview |
How Long Should It Stay On?
- Debug mode does not turn off on its own; if it is forgotten on, the body is buffered and the headers and body are captured in every request, which means additional CPU, memory and disk load (how it is enabled).
- When the 128 MB budget fills up, the oldest records are deleted; Debug turned on without a condition deletes the record being looked for in a short time under heavy traffic.
- In practice: it is kept on long enough to reproduce the problem, narrowed to a single client or path with a condition, and turned off as soon as the examination is finished. If permanent retention is needed, the records are downloaded with Export.
How Is It Enabled in TR7?
- If recording is to be limited with a condition, the condition is first created with Load Balancer → Conditions → Add (e.g. Source IP or Path).
- On the Load Balancer → Load Balancer vService List screen, the HTTP vService is right-clicked and Edit is selected.
- Debug Mode is selected in the Status field, or Debug is checked in the Details panel; the two options are the same setting. This option does not exist in L7 TCP and Network vServices.
- Under heavy traffic, the condition from step 1 is selected in the condition field under Debug; only the requests that match the condition are recorded (conditional debug).
- Save is clicked; the records are seen in the Left Monitor Panel → vService → Logs & Tracking → Debug Mode Logs source. In a cluster, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
- When the examination is finished, Status = Enabled is selected in the edit form and Save is clicked.
Common Misconceptions
- "Debug mode turns off after a certain time." It stays on until it is turned off.
- "Debug records also go to the log server." Debug records are kept only on the device.
- "Debug mode also exists in the L7 TCP vService." Debug mode exists only in the HTTP vService.
- "When Debug is turned on, earlier requests are also visible." Recording starts from the requests that arrive after Debug is turned on.
How it is done in the documentation
