Skip to content

Syslog operations — guia operacional aprofundado

Leia no seu idioma: English · Português · Español

Status do escopo (pós-congelamento de escopo 2026-05-10) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Público: Operadores que executam o TLSStress.Art e precisam investigar falhas de execuções, correlacionar anomalias de métricas com eventos de dispositivos ou estender o pipeline de syslog.

Este documento complementa SYSLOG_CORRELATION.pt-BR.md (introdução + setup). Leia aquele primeiro. Este arquivo é a referência operacional aprofundada — receituário de queries, padrões avançados específicos por fornecedor, orçamentos de performance, modelo de segurança, receitas de troubleshooting.

Pré-requisito obrigatório — syslog somente sobre OOBI

O tráfego de syslog dos elementos do laboratório (Nexus 9000, NGFW DUT, hosts UCS) DEVE trafegar pela rede de gerenciamento OOBI (out-of-band) — nunca pelas VLANs do data plane.

Por quê: - O data plane carrega o tráfego de teste (Synthetic personas 10.1.0.0/16, Cloned personas 10.2.0.0/16, browser-engine agents 172.16.0.0/16, synthetic-load agents 172.17.0.0/16). Pacotes de syslog nessas VLANs seriam medidos PELO test bed como se fossem tráfego de teste — invalidando as métricas por ciclo. - A subnet OOBI (default 192.168.90.0/24, VLAN 99) é reservada por design para tráfego de gerenciamento — scrapes do Prometheus, SNMP, kubectl e syslog vivem aqui. - Todos os elementos do laboratório têm seus IPs de gerenciamento na OOBI; suas interfaces de data plane ficam downstream (em direção ao NGFW pelo lado das personas, em direção aos agentes pelo lado do test-bed).

Enforcement: - Dois recursos NetworkPolicy (`syslog-oobi-only` + `syslog-deny-data-plane`) aplicam isso no nível do cluster — veja platform/observability/syslog-network-policy.yaml - O primeiro permite ingress de syslog apenas do CIDR OOBI (192.168.90.0/24) - O segundo nega explicitamente ingress de syslog dos CIDRs do data plane - Belt-and-suspenders por design — se uma das policies for acidentalmente enfraquecida, a outra ainda impede contaminação

Obrigações do operador: 1. Ao configurar o destino syslog de um dispositivo, SEMPRE use o endereço IP OOBI do destino (não o IP do data plane se houver) 2. Ao configurar source-interface em dispositivos Cisco, SEMPRE especifique mgmt0 / a interface de gerenciamento 3. Periodicamente rode uma query de verificação (no cookbook abaixo) para confirmar que nenhum syslog fora da rede passou 4. Se o laboratório usa um CIDR OOBI não-padrão, sobrescreva via overlay kustomize — não edite o manifesto base

Anatomia do pipeline

                   OOBI network only (192.168.90.0/24)
   ┌────────────────────────────────────────────────────────────┐
   │                                                            │
┌──┴──────────┐  UDP/514   ┌─────────────────────┐             │
│ Nexus 9000  ├───────────▶│                     │             │
│ mgmt0       │            │  Promtail           │             │
└─────────────┘            │  syslog receiver    │             │
                           │                     │  Loki API   │
┌─────────────┐  UDP/514   │  - RFC 3164 + 5424  ├──────────▶┌─┴─────┐
│ NGFW DUT    ├───────────▶│  - port 1514 (pod)  │           │ Loki  │
│ mgmt iface  │  TCP/514   │  - port 30514 (NP)  │           └───┬───┘
└─────────────┘            │  - relabel pipeline │               │
                           │                     │           ┌───▼───┐
┌─────────────┐  UDP/514   │  Drops everything   │           │Grafana│
│ UCS host    ├───────────▶│  not from OOBI      │           └───────┘
│ rsyslog     │            │  (NetworkPolicy)    │
└─────────────┘            └─────────────────────┘

Receituário de queries Loki

Encontre todos os eventos de um dispositivo, últimos 30 minutos

{app="tlsstress", device_hostname="nexus-1.lab.example.com"}

Encontre eventos warning+ em todos os dispositivos NGFW na última hora

{app="tlsstress", device_type="ngfw", severity=~"warning|err|crit|alert|emerg"}

Encontre eventos relacionados a decryption no NGFW (estilo Cisco ASA)

{app="tlsstress", device_type="ngfw"} |~ "(?i)(decrypt|ssl|tls)"

Encontre eventos relacionados a decryption no Palo Alto

{app="tlsstress", device_type="ngfw"} | json | subtype="decryption"

Encontre port flaps em Cisco Nexus

{app="tlsstress", device_type="nexus"}
  |~ "(?i)(port.*(flap|down|up))|interface.*state.*change"

Conte eventos por minuto por dispositivo, ordenado decrescente

sum by (device_hostname) (
  rate({app="tlsstress"}[1m])
)

Encontre eventos de kernel UCS (OOM, NIC reset, segfault)

{app="tlsstress", device_type="ucs", device_app="kernel"}
  |~ "(out of memory|oom-killer|segfault|nic.*reset|carrier (lost|down))"

Correlacione com métrica — mostre logs de NGFW apenas quando latência p99 > 500 ms

Esta é uma query de dois stores — o lado da métrica filtra quando olhar, o lado dos logs retorna os eventos:

{app="tlsstress", device_type="ngfw", severity=~"warning|err|crit"}
Abra esta query no Grafana Explore split-pane ao lado de: 
histogram_quantile(0.99, sum by (le) (rate(web_agent_request_duration_seconds_bucket[1m])))
Use o seletor de time range para dar zoom no spike de latência. A query de logs vai estreitar para a mesma janela.

Detecção de tráfego fora da OOBI (vigilância do operador)

Se tudo está configurado corretamente, esta query retorna 0 linhas. Linhas diferentes de zero indicam que um dispositivo está enviando syslog de uma interface não-OOBI — tipicamente porque source-interface não foi setado:

{app="tlsstress"} | json | __syslog_message_remote_addr !~ "192\\.168\\.90\\."

Se você vir hits, encontre o dispositivo infrator e rode: - Cisco: show logging | include source → confirme source-interface mgmt0 setado - Palo Alto: GUI → Device → Setup → Services → "Service Route Configuration" — Syslog deve usar a interface de gerenciamento - Fortinet: config log syslogd setting → set source-ip <oobi-ip> confirmado

Deep-dive por fornecedor — o que esperar nos logs

Cisco Nexus 9000 (NX-OS)

Tipos de mensagem comuns para reconhecer:

Pattern Severity Significado
%ETHPORT-5-IF_DOWN_* notice Uma porta caiu. Procure IF_DOWN_LINK_FAILURE (cabo / NIC) vs IF_DOWN_ADMIN_DOWN (iniciado pelo operador)
%ETH_PORT_CHANNEL-5-PORT_* notice Membro de port-channel up/down. Subida no meio da execução = potencial evento de redistribuição de tráfego
%MAC-3-MAC_FLAP_DETECTED error MAC moveu entre portas — tipicamente indica um loop ou um host com múltiplos uplinks. Test bed degradado até resolução
%MTS_NOTIFICATION_AGENT-3-* error Eventos do message-bus interno do NX-OS; raros mas indicam estresse de plataforma
%QUEUING-2-DROP critical Fila QoS dropando tráfego. Execução é inválida para qualquer claim de throughput
%STM-2-LIMIT_REACHED critical Um limite de plataforma (route, MAC, ARP) atingido. Resete o cluster se persistente

Logging level NX-OS recomendado: 5 (notification) para categorias gerais, 4 (warning) para mts e monitor. Veja SYSLOG_CORRELATION.pt-BR.md para o snippet exato de configuração.

Cisco FTD / ASA / Firepower

Pattern Severity Significado
%ASA-3-302014 error Connection teardown — para um test bed TLS, observe o campo Reason:. tcp reset by app-id frequentemente significa intervenção do decrypt-engine
%ASA-6-725001 info TLS handshake iniciado
%ASA-6-725002 info TLS handshake completado com sucesso
%ASA-6-725003 info Sessão TLS resumida (session ticket / ID hit) — interessante para planos que demandam handshakes frescos
%ASA-3-725007 error TLS handshake falhou. Cross-check com o campo Reason:
%ASA-6-302013 info TCP connection construída — útil para análise de connection-rate
%ASA-4-411001 warning Mudança de estado de interface

Classes de logging recomendadas: crypto 5, ssl 5, connection 4. Rates maiores em connection (severity 6) geram eventos demais para o laboratório ingerir confortavelmente.

Palo Alto (PAN-OS)

Logs PAN-OS são estruturados (CSV-ish) por padrão; o receiver Loki parseia o wrapping RFC 5424 mas o body permanece comma-separated. Use | pattern ou | logfmt no Loki para extrair campos.

Sinal de campo Significado
subtype="decryption" + category="ssl-protocol-error" Decrypt falhou — root cause no campo info (tipicamente cipher mismatch, versão não suportada, cert chain)
subtype="decryption" + category="successful" Decrypt bem-sucedido — útil para confirmar que a policy realmente dispara
subtype="ssl-error" Especificamente erro do lado TLS sob a perspectiva do firewall
subtype="threat" + category="vulnerability" IPS hit durante o teste — pode interromper conexões legitimamente

Para o test bed TLS, os subtypes mais acionáveis são decryption (sempre) e traffic para eventos action=block.

Fortinet (FortiOS)

FortiOS usa pares chave-valor. O parser logfmt do Loki extrai isso nativamente.

Pattern Severity Significado
logid=0103040045 warning Erro de SSL handshake — campo reason= dá detalhes
logid=0103043200 info Sessão SSL estabelecida
logid=0103040040 error Sessão relacionada a TLS terminou anormalmente
logid=0419016384 warning IPS engine sinalizou tráfego

Filtro FortiOS recomendado: severity notification e set ssl enable (especificamente forwarda eventos de SSL-policy).

Host Ubuntu UCS (rsyslog)

Os sinais host-level mais úteis durante um teste:

device_app O que observar
kernel OOM-killer, segfault, erros de NIC, throttling — procure severity=err+
chronyd Eventos de clock-sync — correlacione com thresholds de TIME_SYNC.pt-BR.md
kubelet Pod evictions, falhas de image pull durante execução
containerd Restarts de container, erros de OCI runtime
iptables Drops de pacote no firewall do host (incomum mas um caminho rápido de diagnóstico)

Performance + retention

Orçamento de event-rate

O receiver Promtail é configurado sem rate-limit por padrão. Capacidade empírica em um node K3s padrão:

Configuration Sustainable events/sec
Single-node, default resource limits (200m CPU / 256 Mi mem) ~5,000
Single-node, bumped to 1 CPU / 1 Gi ~25,000
Multi-node with Promtail per node ~5,000 per node

Para uma única execução de 30 min em um test bed totalmente carregado, espere ~50.000–200.000 eventos totais. Dentro do orçamento para a config padrão.

Se events/sec sustentado exceder o orçamento, o Promtail aplica backpressure e o cliente syslog do dispositivo ou faz buffer (Cisco IOS), dropa (UDP) ou segura conexões (TCP). Drops UDP são silenciosos — overflow TCP loga um erro no dispositivo.

Retention do Loki

Retention padrão neste stack: 15 dias. Configure via os Loki Helm values ao montar o stack de observabilidade.

Para execuções cujos resultados precisam de retention permanente além de 15 dias, duas opções: 1. Exporte logs ao final da execução via Loki API → archive para seu próprio object storage 2. Aguarde o Test Run Report Phase 4 (planejado) — trechos de log selecionados serão embedados no PDF assinado para registro forense permanente

Sizing de storage

Tamanho médio de linha de log ~250 bytes incluindo labels. 50.000 eventos/execução × 250 bytes ≈ 12 MB/execução. Com retention de 15 dias e ~5 execuções/dia, espere ~900 MB / 15 dias. O chunked storage do Loki comprime isso ainda mais (tipicamente 4-6× compression).

Modelo de segurança

O que o syslog stack FAZ

  • Recebe syslog sobre UDP/TCP 514 apenas da rede OOBI
  • Forwarda para Loki com labels estruturados para query
  • Indexa labels (pequeno, rápido); NÃO indexa bodies completos das mensagens (grande, lento)
  • Carrega os mesmos labels de license/audience que o Prometheus, então tooling downstream license-aware vê a mesma proveniência

O que o syslog stack NÃO faz

  • NÃO autentica o sender (UDP e TCP unauthenticated). Qualquer pessoa na rede OOBI pode enviar eventos. Mitigação: NetworkPolicy restringe à OOBI; a OOBI em si deve ser controlada por acesso no nível do switch
  • NÃO criptografa syslog em trânsito. RFC 5425 (syslog-over-TLS) é suportado pelo Promtail mas não habilitado por padrão — setup requer certs compartilhados. Se sua compliance demanda encryption, abra uma issue e priorizaremos a config RFC 5425
  • NÃO redige conteúdo sensível. Muitos dispositivos logam detalhes de sessão, ARP tables, etc. que não são estritamente secretos mas podem exceder sua policy de operator audience. Audite antes de exportar dados do Loki para fora do laboratório
  • NÃO integra com SIEM. Esta é uma camada de TEST FORENSICS, não de security operations

Threat model

Threat Mitigação
Atacante na OOBI envia syslog falso Acesso à OOBI é a superfície de ataque — fora do escopo deste produto
Dispositivo comprometido envia syslog malicioso NetworkPolicy + dashboards baseados em label limitam blast radius ao log-store; sem exec a partir do conteúdo do log
Dado sensível logado acidentalmente Problema do lado do operador — revise as classes de logging do dispositivo em SYSLOG_CORRELATION.pt-BR.md antes de habilitar
Origem fora da OOBI bypassa NetworkPolicy NetworkPolicy é enforçada pelo CNI; se seu CNI não implementa NetworkPolicy (alguns CNIs bare-metal), teste com kubectl describe networkpolicy e confirme que a policy reporta como enforced

Audit trail

Cada evento syslog no Loki carrega: - O hostname do dispositivo originador (campo RFC 5424, validado contra o estado de NTP-sync do dispositivo no momento do recebimento — mas apenas frouxamente) - O receive time (lado Promtail, setado a partir do clock do cluster) - Os labels incluindo app=tlsstress, license, audience

Se o clock da origem está errado por mais de alguns segundos (conforme TIME_SYNC.pt-BR.md), os timestamps dos eventos são enganosos. Cruze os alertas de time-sync antes de tratar timestamps de syslog como forenses.

Runbooks operacionais

"Vejo um spike de p99 às 14:32"

1. Open: TLSStress.Art — Syslog Correlation (Lab Elements) dashboard
2. Set time range to 14:30–14:35
3. Look at the side-by-side panel — note any log volume spike
4. Click into the live syslog stream panel
5. Look for warning+ events from any device in that window
6. Drill into the per-device deep-dive panel for the noisy device
7. If NGFW shows decryption errors → check TLS Decrypt Probe state
   (TLSStress.Art — TLS Decrypt Mode dashboard)
8. If Nexus shows port flaps → check Topology Correlation dashboard
9. If UCS shows kernel/OOM → check Test-Bed Infrastructure Health

"Quero confirmar que nenhum syslog está vazando fora da OOBI"

1. Run the off-OOBI detection query in Grafana Explore (cookbook above)
2. If any rows return:
   a. Identify the device by __syslog_message_hostname
   b. Run "show logging | include source" (Cisco) or equivalent
   c. Reconfigure source-interface to mgmt0
3. Re-run the query — should return 0 rows

"Promtail está dropando eventos"

Sintomas: spikes em métricas promtail_syslog_target_* OU query Loki retorna menos eventos do que esperado.

1. kubectl logs -n observability deploy/promtail-syslog --tail=100
   Look for: "syslog target full" / "channel buffer full"
2. If buffer full:
   - Increase Promtail resource limits (default 200m CPU / 256Mi mem)
   - Or shard: run Promtail per-node with stable hash on device_hostname
3. If a specific device floods:
   - Check the device's logging level (lower from 7=debug to 5=notice)
   - Add a `drop` action in the relabel pipeline for that hostname

"Query Loki está lenta"

1. Query MUST start with a label matcher (e.g. {app="tlsstress"})
2. Avoid free-text grep on multi-day ranges — use device_type/severity to narrow
3. Use logfmt/json parsers AFTER label filtering, not before
4. Time range > 7 days requires the chunk-cache to be hot;
   first-query-of-the-day is slow, subsequent queries are fast

Melhorias futuras

Acompanhadas para iteração futura:

  • RFC 5425 syslog-over-TLS (encryption) — geração de cert controlada por operador + chrony do cert com cert-manager
  • Syslog autenticado via shared key (Cisco IOS suporta isso via logging server <ip> mac) — combina com o modelo de relay
  • Redação seletiva no ingest (ex.: mascarar strings com formato de cartão de crédito antes que cheguem ao Loki)
  • Discovery LLDP/CDP de neighbors → auto-gerar labels device_role (planejado, módulo separado)
  • Test Run Report Phase 4 — embedar trechos de log selecionados no PDF assinado

Relacionados