Logs & Tracking
Logs & Tracking is the screen where the records a vService produces and the live tables it keeps on the load balancing side are gathered in a single tab. The tab carries not a single log type but a list of sources: which sources are listed is determined according to the vService's configuration, and the selector is located at the top left of the tab.
The screen presents two different types of data on the same surface. Historical records (Debug and HTTP logs) are fetched from rows written to disk; they are for examining what happened afterwards. Live tables (TCP records, tracking and quarantine tables) show the content the traffic engine holds at that moment, and vService Sessions shows the system's open connections at that moment; they are for seeing who is where right now and for dropping a record from the table when necessary.
No source is a permanent archive: logs written to file drop starting from the oldest when a disk budget allocated per vService fills up, and live tables are limited by their own duration and row caps. If long-term retention is needed, HTTP and TCP records are forwarded to an external log server with a Logs profile; Debug records and the tracking and quarantine tables are not forwarded externally.
All sources share the same skeleton: a common toolbar at the top, below it a filter strip generated from the values of the fetched records, the table in the middle and a preview panel that opens on the right when a row is clicked. What changes from source to source are the columns, the filters and the depth of the preview.
Accessing the Screen
- Left Monitor Panel is opened.
- Load Balancer vServices is selected from the category tabs at the top left.
- The vServices defined on TR7 are listed.
- The vService to be monitored is clicked; the screen opens with the Dashboard tab that carries the vService's name.
- On the screen that opens, the Logs & Tracking tab is clicked and the record source to be displayed is selected from the source selector.
Since the vService Sessions source exists in every vService, the tab is always displayed. The screen itself requires monitoring permission in the Load Balancer area; on a user with only WAF permission, the screen does not open.
Screen Structure
The screen consists of four layers from top to bottom:
| Layer | Content |
|---|---|
| Source selector | The drop-down list at the start of the toolbar. It is filled according to the vService's configuration and is displayed even when there is a single source. When the selection is changed, the records are fetched again. While the vService is stopped, records are not fetched and the Refresh button stays inactive. |
| Toolbar | The controls common to all sources: column selector, source selector, filter switch, Export, Refresh, search box, and regular expression and column-based search buttons. There are two source-specific controls: Line Limit exists only in Debug and HTTP logs, and Remove from Table only in tracking and quarantine tables; in these tables, the same operation is also done for a single record from the row preview. |
| Filter strip | A card strip generated from the values carried by the fetched records. It comes open by default. The number next to a card shows how many distinct values that criterion carries; when the card is clicked, the values open as chips, and next to each chip the number of records carrying that value is written. Filtering does not send a new request to the server; it narrows the fetched records. |
| Table and preview | The columns change according to the source; when a row is clicked, the preview panel opens on the right. The panel carries the Summary / Request / Response tabs in Debug and HTTP logs; in all other sources it has no tabs and is read one below the other in a single column. |
The source list is filled according to the vService's configuration
The list contains only the sources that the vService actually produces:
| Source | Visibility condition |
|---|---|
| Debug Mode Logs | If the vService is running in the Debug Mode state (if a Debug condition is defined, only matching requests are recorded). Only in HTTP vServices. |
| HTTP Logs | If a Logs profile is assigned to the HTTP vService. |
| TCP Logs | If a log profile is assigned to the L7 TCP vService. |
| vService Sessions | Always. Exists in every vService type. |
| Advanced Traffic Inspection (TRACKING) | If an Advanced Traffic Inspection action is defined on the vService; a separate entry for each action. |
| Quarantine (TRACKING) and (QUARANTINE) | If a Quarantine action is defined on the vService; two entries for each action. |
| Advanced Captcha (TRACKING) and (QUARANTINE) | If an Advanced Captcha action with the Captcha Quarantine feature enabled is defined on the vService; two entries for each action. |
Tracking and quarantine entries carry the name and duration of the action they belong to together: <action name> (TRACKING, <duration>) and <action name> (QUARANTINE, <duration>). Since actions are not defined in Network vServices, only vService Sessions is in the list.
How long records are kept
There is no adjustable retention period in any source; each source has its own cap:
| Source | Cap |
|---|---|
| Debug Mode Logs | A disk budget of 128 MB per vService. When the budget fills up, the oldest record file drops entirely. |
| HTTP Logs | A disk budget of 256 MB per vService. Due to rotation, the viewable history varies between half and all of the budget. |
| TCP Logs | At most 1,000 connection records; a record drops after 24 hours. |
| vService Sessions | No permanent record is kept; the list shows the connections open at that moment. In a single read, at most 100,000 rows of the connection table are scanned. |
| Tracking and quarantine tables | A record drops when the tracking or quarantine duration defined in the related action expires. The table capacity is determined by the Max. Table Size field in the Advanced Traffic Inspection action; in the Quarantine and Advanced Captcha actions, the tracking table holds at most 20,000 keys and the quarantine table at most 5,000 keys. |
The two log families written to file rotate by size, not by time: each engine thread keeps its own file pair; when a file reaches half of its share, it is handed over to its backup and the previous backup is deleted entirely. For this reason, in a vService with heavy traffic, the same budget covers a shorter time range.
WAF and Bot/DDoS records are not in this tab
The source selector leaves out WAF and Bot/DDoS records even if they belong to the same vService. WAF event records are on the WAF module's Event Logs screen, and Bot/DDoS event records are on the Bot/DDoS module's Event Logs screen. The common penalty box of the Bot/DDoS protections, the Waiting Room tables and the tables of the AGS bot protection policies are also opened from their own module's surfaces.
This separation is deliberate: each module describes its own decisions on its own screen, while this tab gathers the records on the vService's load balancing side.
The column preference is shared across sources
The hide and show preference made in the column selector is stored as a single record in the user account; it applies to all vServices and all sources in this tab. A user who turns on the Source column in HTTP logs has also turned on the same column in TCP logs and in the session list.
What Is Done Where?
The last column of each row states what must be defined on the vService for that source to appear in the list. When the prerequisite is not met, that entry is not present in the source selector at all.
| Goal | Path | Prerequisite |
|---|---|---|
| Seeing end to end how a request is processed inside TR7 | Debug Logs | The vService is in the Debug Mode state (HTTP) |
| Finding which security module terminated a request | Debug Logs → Security Action column | The vService is in the Debug Mode state (HTTP) |
| Examining the sent and received headers, body and certificate details | Debug Logs → the Request and Response tabs of the preview | The vService is in the Debug Mode state (HTTP) |
| Reviewing incoming requests and returned response codes | HTTP Logs | A Logs profile is assigned to the LOG field (HTTP) |
| Monitoring the connections of a service without HTTP semantics | TCP Logs | A Logs profile is assigned to the LOG field (L7 TCP) |
| Seeing the connections open right now | vService Sessions | None; exists in every vService type |
| Measuring how much traffic a source produces in a given window | Advanced Traffic Inspection (Tracking) Logs | An Advanced Traffic Inspection action is defined |
| Monitoring clients approaching the quarantine threshold | Quarantine (Tracking) Logs | A Quarantine action is defined |
| Releasing a client in quarantine before its duration expires | Quarantine (Quarantine) Logs → Remove from Table | A Quarantine action is defined |
| Monitoring those who fail CAPTCHA verification | Advanced Captcha (Tracking) Logs | Captcha Quarantine is enabled in the Advanced Captcha action |
| Seeing and releasing those put into quarantine because of CAPTCHA | Advanced Captcha (Quarantine) Logs | Captcha Quarantine is enabled in the Advanced Captcha action |
| Exporting the list as Excel, CSV or PDF | Export in the toolbar | None; exists in every source |
Sources are not enabled in this tab
This screen only shows the records that have been produced; the place where it is decided which source will be produced is the vService form. Debug Mode is enabled from the Status field in the vService form or from the Debug box in the Details panel, HTTP and TCP logs by assigning a log profile to the LOG field, and tracking and quarantine tables by defining the related action.
The forwarding of records to external log servers (syslog / SIEM) is also configured not here but through Logs.
