Classic load-balancer logs often stay at a basic access-log level. Status code, response time, URL, backend, TLS state, WAAP score, geo-IP and user context may end up in separate systems or not collected at all. This forces the operations team to parse logs manually, write separate dashboards or wait for data from other teams just to understand what went wrong.
When WAAP logs and ADC logs are kept in different places, correlation becomes difficult. Seeing both the performance and the security context of the same request requires manually joining request ID, timestamp, IP, path and session data. During an incident, this manual correlation wastes time.
In multi-tenant or multi-vService environments, retention and reporting become a separate problem. One tenant generating heavy logs must not crowd out another tenant's data; applications under critical compliance regimes may need longer retention while public web traffic can be kept for a shorter period.
The right approach is to treat L7 request-level logs and time-series metrics together. Request rate, SSL TPS, status-code distribution, WAAP attack rate, backend response time, dropped logs and health-check metrics should all be observable in the same dashboard family.
The TR7 Layer 7 Reporting Add-on delivers this model: it makes L7 request, WAAP, backend, health-check and QoS data visible in a built-in dashboard and reporting layer.
TR7 L7 Reporting works through enriched log streaming, time-series metrics, built-in dashboards and drill-down variables.
TR7 moves L7 traffic logs and WAAP events into a shared reporting pipeline. Performance, error and attack signals can then be examined in the same vService context.
Request rate, status codes, SSL TPS, throughput, health-check and QoS metrics can be stored over time. This structure supports capacity planning, post-incident analysis and periodic performance tracking.
TR7 ships the core operations panels ready to use through its detailed vService dashboard and global dashboard structure. Operators can observe traffic, SSL, backend, memory, CPU and WAAP metrics from day one.
Dashboard filters can be applied using vService, backend and host variables. Operators can trace from a 5xx spike to a specific URL and then to a slow backend in a few clicks.
The Layer 7 Reporting Add-on makes application traffic observable from the request level to the platform level with 50+ panel items.
The detailed dashboard presents HTTP/HTTPS request rate, new requests, session requests, total connections, SSL TPS, throughput, CPU, memory, SSL cache and error metrics scoped to a single vService. Operators can examine one application's behavior without it being lost in platform-wide noise. This view quickly isolates which vService is affected during an incident. Performance and security signals are interpreted on the same screen.
The global dashboard shows average CPU usage, total vService count, total backend count, uptime and overall HTTP/SSL metrics. This screen gives management and operations teams a concise picture of the platform's status. In multi-vService environments, areas of concentration are immediately apparent. It serves as the first-look screen for capacity planning.
Health Check Status, Health Check Time and Health Check State panels show the availability and response-time condition of backends. States such as UP, DOWN or NOCHECK can be tracked over time. A rising response time can signal performance degradation before a full outage occurs. These metrics make failover and pool behavior easier to understand.
1xx, 2xx, 3xx, 4xx and 5xx response counter panels classify application response behavior. A 5xx increase can point to a backend or application fault; a 4xx increase may indicate client, bot or WAAP influence. Operators can check the error class first, then drill into URL and backend detail. This structure shortens incident triage time.
TR7 can aggregate WAAP attack events and present attack types at a summary level. Instead of individual raw WAAP log entries, attack category, intensity and time distribution are tracked. Security teams see which vService encountered which attack family more quickly. This simplifies daily SOC review and monthly security reporting.
The `tr7_tm_vservice_waf_attack_rate` metric can report WAAP attack speed at the vService level. Sudden spikes may indicate a bot wave, exploit scan or targeted attack. When read alongside traffic volume, attack intensity becomes clearer. The metric carries high value in alerting and dashboard scenarios.
On the backend side, session, new session, response codes, inbound/outbound traffic, connection errors, response errors, queue time, connect time, response time and total time are all observable. This separation helps identify whether a problem originates in the ADC, the network or the backend itself. For example, a rising connect_time may signal a network or acceptance problem, while a rising response_time points to application latency. Incident analysis becomes more precise.
Heavy traffic or a log pipeline problem can cause the dropped-log count to rise. The Logs Dropped panel helps monitor the reliability of observability data. If log loss is present, dashboard readings should be treated with care. Operations teams track not only traffic but also the health of the measurement pipeline.
Compress in/out metrics show compression behavior. Operators can see how much traffic impact compression produces for each vService. These values are weighed alongside WAN cost, user experience and CPU consumption. Compression policies are managed with data, not intuition.
Metrics such as `tr7_tm_vservice_memory_usage` and `tr7_tm_vservice_memory_alloc` can track vService memory behavior. Rising trends over time are valuable for capacity planning and potential leak analysis. Operators can see not just an immediate fault but also future capacity pressure. This enables planned scaling for growing application traffic.
Metrics such as `tr7_tm_qos_cpu_count`, `tr7_tm_qos_cpu_percent_limit` and `tr7_tm_qos_memory_limit` make platform resource limits visible. Watching these alongside traffic metrics clarifies resource pressure. If a vService's error production correlates with approaching a resource limit, detection is faster. QoS visibility supports capacity and isolation decisions.
TR7 can manage interval configuration for the detailed and global dashboards through separate files. This makes dashboard refresh and time-range behavior more consistent. Long-term trend analysis and short-term incident analysis can use different intervals. Operators tune panel timing to match each usage scenario.
L7 reporting is operated together with the metric namespace, frontend and backend metrics, health-check state, QoS fields and dashboard variables.
TR7 metrics are grouped under the `tr7_tm_*` namespace. This structure makes it easy to distinguish frontend, backend, health-check, QoS and device metrics. Dashboard and alerting rules become standardized through this naming convention.
Request rate, total connections, inbound/outbound bytes, request errors, 1xx–5xx responses, SSL connections, SSL rate, SSL cache, compression, dropped logs and memory metrics are observable on the frontend side. These metrics explain the behavior of the user-facing vService. They help determine whether a problem originates from external traffic, TLS handling or response behavior.
On the backend side, session, response codes, traffic, connection errors, response errors and timing metrics can be collected. The queue, connect, response and total time breakdown is critical for performance analysis. Application, network and acceptance problems become visible through different metrics.
`tr7_tm_bservice_hc_state` can express a backend's health as UP, DOWN or NOCHECK. `tr7_tm_bservice_hc_time` can report health-check response time at millisecond resolution. Health-check trends make failover behavior easier to understand.
QoS fields such as CPU count, CPU percentage limit and memory limit can be surfaced in the dashboard. These metrics help understand the effect of resource limits during peak traffic periods. They especially support capacity decisions in multi-tenant or high-density service environments.
Panels can be filtered using variables such as `$vservice`, `$bservice` and `$host`. Operators can drill from a global chart down to a specific vService and then to a specific backend. This drill-down flow accelerates incident investigation.
The operator drills from the 5xx panel to the affected URL and then to the slow backend. The connect_time and response_time metrics help separate whether the problem is network-related or application-related.
The security team can pull SSL metrics and WAAP attack rate values into a periodic report. This data increases the visibility of application security and traffic protection controls.
A longer retention can be applied to a vService under healthcare or regulatory scope, and a shorter retention to public web traffic. This balances storage cost against compliance requirements.
Memory alloc, request rate and throughput trends can be tracked to forecast future capacity needs. Operators make scaling decisions based on time-series data rather than instinct.
When the WAAP attack rate rises, attack categories can be summarized and affected vServices filtered. The SOC team can see attack type and intensity without getting lost in raw logs.
Built-in dashboards, drill-down metrics and WAAP reporting — let us walk you through a live setup.