Os logs clássicos de balanceador de carga ficam, na maioria das vezes, apenas no nível básico de access log. Status code, response time, URL, backend, TLS, pontuação WAAP, geo-IP e contexto de usuário podem ficar em sistemas diferentes ou nem chegar a ser coletados. Nesse caso, a equipe de operação é forçada a fazer parse de logs, escrever um dashboard separado ou pedir dados de equipes diferentes para entender o problema.
Quando os logs de WAAP e os logs de ADC são mantidos em lugares separados, a correlação fica difícil. Para ver tanto o contexto de desempenho quanto o de segurança da mesma requisição, é preciso correlacionar manualmente request ID, timestamp, IP, path e informação de session. No momento do incidente, essa correlação manual faz perder tempo.
Em estruturas multi-tenant ou com muitos vServices, a retenção e o relatório também se tornam um problema à parte. Enquanto um tenant gera logs intensos, os dados de outro não devem se perder; as aplicações sob regulação crítica devem ser mantidas por mais tempo, enquanto o tráfego web público pode ser mantido com uma retenção mais curta.
A abordagem correta é tratar os logs de nível de requisição L7 junto com métricas de série temporal. Request rate, SSL TPS, distribuição de status code, WAAP attack rate, response time de backend, dropped log e métricas de health check devem ser monitorados na mesma família de dashboards.
O Complemento de L7 Reporting da TR7 oferece este modelo: torna visíveis os dados de requisição L7, WAAP, backend, health check e QoS em uma camada de dashboard e relatório integrada.
O L7 Reporting da TR7 funciona com fluxo de logs enriquecido, métricas de série temporal, dashboards integrados e variáveis de drill-down.
A TR7 leva os logs de tráfego L7 e os eventos WAAP para uma linha de relatório comum. Assim, os sinais de desempenho, erro e ataque podem ser examinados no mesmo contexto de vService.
Request rate, status code, SSL TPS, throughput, health check e métricas de QoS podem ser armazenados ao longo do tempo. Esta estrutura pode ser usada para planejamento de capacidade, análise pós-incidente e acompanhamento periódico de desempenho.
A TR7 oferece prontos os painéis operacionais básicos com a estrutura de dashboard detalhado de vService e dashboard global. O operador pode monitorar desde o primeiro dia as métricas de tráfego, SSL, backend, memória, CPU e WAAP.
Com as variáveis de vService, backend e host podem ser aplicados filtros de dashboard. Pode-se investigar desde um aumento de 5xx até uma URL específica e, a partir daí, até um backend que está ficando lento.
O Complemento de L7 Reporting torna monitorável o tráfego de aplicação com 50+ painéis/elementos, do nível de requisição até o nível geral da plataforma.
O dashboard detalhado mostra no contexto de vService as métricas de request rate HTTP/HTTPS, novas requisições, session requests, total connection, SSL TPS, throughput, CPU, memória, SSL cache e erro. O operador pode examinar o comportamento de uma única aplicação sem se misturar ao ruído geral da plataforma. Esta visão separa rapidamente, no momento do incidente, qual vService foi afetado. Os sinais de desempenho e de segurança são interpretados na mesma tela.
O dashboard global mostra o uso médio de CPU, o número total de vServices, o número total de backends, o uptime e as métricas gerais de HTTP/SSL. Esta tela resume às equipes de gestão e operação o estado geral da plataforma. Em ambientes com muitos vServices, entende-se rapidamente quais áreas estão sob mais carga. Pode ser usado como tela de primeira olhada para o planejamento de capacidade.
Os painéis Health Check Status, Health Check Time e Health Check State mostram o estado de acessibilidade e o tempo de resposta dos backends. Estados como UP, DOWN ou NOCHECK podem ser monitorados ao longo do tempo. Um aumento no tempo de resposta pode indicar degradação de desempenho antes de uma falha completa. Essas métricas facilitam entender o comportamento de failover e de pool.
Os painéis de contadores de resposta 1xx, 2xx, 3xx, 4xx e 5xx classificam o comportamento de resposta da aplicação. Um aumento de 5xx pode indicar erro de backend ou de aplicação, e um aumento de 4xx, efeito de cliente, bot ou WAAP. O operador pode examinar primeiro a classe de erro e depois o detalhe de URL e backend. Esta estrutura encurta o tempo de triagem de incidentes.
A TR7 pode resumir os eventos de ataque WAAP e mostrar os tipos de ataque em nível de agregação. Em vez de logs WAAP brutos individuais, são monitorados a categoria de ataque, a intensidade e a distribuição no tempo. A equipe de segurança vê mais rapidamente qual vService enfrentou qual família de ataque. Isso facilita a revisão diária do SOC e o relatório mensal de segurança.
A métrica `tr7_tm_vservice_waf_attack_rate` pode mostrar a taxa de ataque WAAP no nível de vService. Aumentos súbitos podem ser sinal de onda de bots, varredura de exploits ou ataque direcionado. Esta métrica, interpretada junto com o volume de tráfego, faz entender com mais precisão a intensidade do ataque. Tem alto valor em cenários de alarme e dashboard.
No lado do backend podem ser monitoradas métricas como session, new session, response code, tráfego inbound/outbound, connection error, response error, queue time, connect time, response time e total time. Essa separação ajuda a entender se o problema está no lado do ADC, na rede ou no backend. Por exemplo, um aumento de connect_time pode ser problema de rede ou de aceitação do serviço, e um aumento de response_time, atraso da aplicação. A análise de incidentes é feita com mais precisão.
Quando ocorre tráfego intenso ou problema no pipeline de logs, o número de dropped logs pode aumentar. O painel Logs Dropped ajuda a monitorar a confiabilidade dos dados de observação. Se há perda de logs, as interpretações do dashboard devem ser tratadas com cuidado. A equipe de operação acompanha não apenas o tráfego, mas também a saúde da linha de medição.
As métricas de compress in/out mostram o comportamento de compressão. O operador pode monitorar em quais vServices a compressão produz quanto impacto de tráfego. Esses valores são avaliados junto com o custo de WAN, a experiência do usuário e o consumo de CPU. As políticas de compressão são gerenciadas com dados, não por intuição.
Métricas como `tr7_tm_vservice_memory_usage` e `tr7_tm_vservice_memory_alloc` podem monitorar o comportamento de memória do vService. As tendências de aumento ao longo do tempo são valiosas para o planejamento de capacidade e para possíveis análises de vazamento. O operador pode ver não apenas a falha instantânea, mas também a pressão de capacidade futura. Isso proporciona um escalonamento planejado para o tráfego de aplicação em crescimento.
Métricas como `tr7_tm_qos_cpu_count`, `tr7_tm_qos_cpu_percent_limit` e `tr7_tm_qos_memory_limit` tornam visíveis os limites de recursos da plataforma. Esses valores são monitorados junto com as métricas de tráfego para entender a pressão de recursos. Se a geração de erros de um vService está relacionada à aproximação do limite de recursos, isso é detectado mais rapidamente. A visibilidade de QoS apoia as decisões de capacidade e isolamento.
A TR7 pode gerenciar as configurações de interval para o dashboard detalhado e o global em arquivos separados. Isso torna mais consistente o comportamento de atualização e de intervalo de tempo do dashboard. A análise de tendência de longo prazo e a de incidente de curto prazo podem ser feitas com intervalos diferentes. O operador ajusta o tempo dos painéis conforme os diferentes cenários de uso.
O L7 reporting é conduzido junto com o metric namespace, as métricas de frontend/backend, o health check state, os campos de QoS e as variáveis de dashboard.
As métricas da TR7 são agrupadas sob o namespace `tr7_tm_*`. Esta estrutura facilita distinguir as métricas de frontend, backend, health check, QoS e dispositivo. As regras de dashboard e alarme tornam-se padronizadas com base nessa nomenclatura.
Request rate, total connection, byte inbound/outbound, request error, resposta 1xx-5xx, SSL connection, SSL rate, SSL cache, compression, dropped log e métricas de memória podem ser monitorados no lado do frontend. Essas métricas explicam o comportamento do vService voltado ao usuário. Separa-se se o problema é originado do tráfego externo, do TLS ou do comportamento de resposta.
No lado do backend podem ser coletadas métricas de session, response code, tráfego, erro de conexão, erro de resposta e de tempo. A separação de queue, connect, response e total time é crítica na análise de desempenho. Problemas de aplicação, de rede e de aceitação do serviço tornam-se visíveis com métricas diferentes.
`tr7_tm_bservice_hc_state` pode expressar o estado de saúde do backend como UP, DOWN ou NOCHECK. `tr7_tm_bservice_hc_time` pode mostrar o tempo de resposta do health check em nível de milissegundo. As tendências de health check facilitam entender o comportamento de failover.
Campos de QoS como número de CPU, limite de percentual de CPU e limite de memória podem ser levados ao dashboard. Essas métricas permitem entender o efeito dos limites de recursos em momentos de tráfego intenso. Apoiam a decisão de capacidade especialmente em serviços multi-tenant ou de alta intensidade.
Com variáveis como `$vservice`, `$bservice` e `$host` os painéis podem ser filtrados. O operador pode descer do gráfico global para um vService específico e, a partir daí, para um backend específico. Esse fluxo de drill-down acelera a investigação de incidentes.
O operador pode descer do painel de 5xx para a URL relacionada e, a partir daí, para o backend que está ficando lento. As métricas de connect_time e response_time ajudam a separar se o problema é originado da rede ou da aplicação.
A equipe de segurança pode incluir as métricas de SSL e os valores de WAAP attack rate no relatório periódico. Esses dados aumentam a visibilidade dos controles de segurança de aplicação e de proteção de tráfego.
Para um vService sob saúde ou regulação pode ser aplicada uma retenção mais longa, e para o tráfego web público, uma retenção mais curta. Assim, o custo de armazenamento e a necessidade de conformidade são equilibrados.
Monitorando as tendências de memory alloc, request rate e throughput, pode-se prever a necessidade futura de capacidade. O operador toma a decisão de escalonamento com dados de série temporal, não por intuição instantânea.
Quando o WAAP attack rate aumenta, as categorias de ataque podem ser resumidas e os vServices afetados podem ser filtrados. A equipe de SOC pode ver o tipo e a intensidade do ataque sem se perder no log bruto.
Dashboard integrado, métricas de drill-down e relatório WAAP — vamos percorrer tudo em uma instalação ao vivo.