Without L7 visibility, the cause of a 5xx surge becomes guesswork.
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.
Our approach
TR7 L7 Reporting works through enriched log streaming, time-series metrics, built-in dashboards and drill-down variables.
ADC and WAAP logs are consolidated under a single reporting roof
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.
Time-series metrics make long-term trends visible
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.
Built-in dashboards provide visibility at global and vService level
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.
Drill-down variables narrow a problem to a URL and backend
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.
Capabilities
The Layer 7 Reporting Add-on makes application traffic observable from the request level to the platform level with 50+ panel items.
Detailed Dashboard shows per-vService L7 traffic in depth
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.
Global Dashboard provides a health overview of the entire platform
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.
Backend health-check panels track state and response time
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.
Status-code group panels make error distribution instantly visible
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.
WAAP summarization turns attack events into an operational report
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.
WAAP attack rate metric tracks an attack burst at per-second granularity
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.
Backend metrics separate connection time from application response time
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.
Logs Dropped panel makes log-overload conditions visible
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.
Compression panels make bandwidth savings measurable
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.
Memory usage and alloc panels support capacity planning
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.
QoS metrics expose CPU and memory limits in the dashboard
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.
Dashboard interval files standardize time-range behavior
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.
Operational depth
L7 reporting is operated together with the metric namespace, frontend and backend metrics, health-check state, QoS fields and dashboard variables.
Metric namespace
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.
Frontend metrics
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.
Backend metrics
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.
Health-check 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 metrics
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.
Dashboard variables
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.
When to use it
Finding the source of a morning 5xx surge
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.
SSL and WAAP report for a PCI periodic review
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.
Separate retention planning for a sensitive tenant
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 and traffic trend for capacity planning
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.
Quickly summarizing a WAAP attack burst
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.
Frequently asked questions
Which logs and metrics does the Layer 7 Reporting Add-on cover?
How many built-in dashboards are there and what do they show?
How are WAAP logs and ADC logs combined?
How do the drill-down variables work?
How is per-tenant retention managed?
Is a separate observability infrastructure required?
See L7 traffic visibility in your own environment
Built-in dashboards, drill-down metrics and WAAP reporting — let us walk you through a live setup.