Resumo

  • qlog define níveis Core, Base e Extra, mas as ferramentas não devem esperar todos os eventos Core em cada trace; privacidade e desempenho podem justificar substituições.
  • Uma taxa calculada sobre eventos presentes não é comparável entre fornecedores sem conhecer buffers, filtros, schemas, campos e janelas de captura.
  • Aquisição, operação e automação precisam contratar evidência reproduzível, não apenas compatibilidade nominal com o formato.

O painel de compras mostrava uma vantagem inequívoca. O fornecedor A registrara metade dos “descartes” do fornecedor B durante o mesmo teste. Ambos entregavam arquivos qlog válidos. Ambos diziam registrar o conjunto Core. A conclusão comercial parecia pronta: A tinha a implementação mais estável.

No fornecedor A, porém, o perfil de privacidade removia o evento rico de pacote e emitia um evento Base agregado em certas condições. No fornecedor B, os eventos por pacote permaneciam ativos. O denominador também diferia: um logger havia começado antes da conexão; o outro, depois da negociação. A comparação não mediu descarte. Mediu duas políticas de observação como se fossem uma única realidade.

draft-ietf-quic-qlog-main-schema-14, de julho de 2026, é um Internet-Draft ativo do grupo de trabalho QUIC, destinado a Proposed Standard, ainda não um RFC. Ele fornece uma arquitetura extensível para logs estruturados de protocolos: arquivos, traces, eventos, schemas, tempos e pontos de observação. É um avanço importante para ferramentas reutilizáveis e para análises entre implementações que antes dependiam de formatos proprietários.

Interoperabilidade de formato, contudo, não significa identidade de instrumentação.

Core não significa completo

qlog organiza tipos de evento em três níveis de importância. Core cobre observações fundamentais, como criação e análise de pacotes e métricas básicas. Base acrescenta visibilidade sobre buffers, máquinas de estado e decisões internas. Extra oferece detalhes de depuração mais finos.

A palavra Core convida a uma leitura rígida, mas o texto é cuidadoso. Eventos Core deveriam estar presentes de modo geral; as ferramentas deveriam conhecê-los. Ainda assim, não deveriam esperar todos eles em cada trace. Se detalhes de conteúdo forem caros ou sensíveis, uma implementação pode registrar um subconjunto Base que preserve utilidade. O próprio exemplo é claro: quem não registra um evento de pacote recebido com seus ACKs deveria registrar o evento de pacotes reconhecidos.

Trata-se de uma escolha útil. Um servidor de grande escala, um aplicativo móvel e um laboratório podem ter orçamentos de CPU, armazenamento e privacidade incompatíveis. Obrigar todos ao maior detalhe reduziria adoção ou ampliaria riscos. A classificação cria um idioma comum para negociar prioridades sem impor um único perfil.

O erro começa quando um sistema de comparação traduz “Core” para “conjunto idêntico”.

O numerador também depende do sensor

Métricas derivadas de logs carregam a política do logger. Uma taxa de descarte depende de quais descartes geram evento, se o motivo opcional foi preenchido, se eventos duplicados foram agregados e se o buffer tinha espaço. Uma distribuição de latência depende do relógio, da janela e da presença dos eventos que delimitam cada intervalo. Uma contagem por conexão depende de group_id, tuple e regras de anonimização.

O campo event_schemas não resolve o problema. Ele é uma indicação dos namespaces e tipos que podem aparecer. Um trace pode conter tipos de schemas não listados; schemas listados não garantem a presença de todos os tipos associados. Ferramentas não devem considerar essas situações erro.

Nem a validação estrutural resolve. Ela prova que o evento presente está na forma esperada. Não prova que o evento ausente deveria ou não existir. Um buffer circular pode sobrescrever os primeiros eventos. Outros podem ser omitidos intencionalmente por privacidade ou tamanho. qlog pede que as ferramentas continuem úteis com logs incompletos.

Por isso, a fórmula correta não é “eventos de descarte divididos por pacotes”. Primeiro vem uma pergunta: sob qual política e com qual cobertura ambos foram observados? Sem essa resposta, a precisão decimal é uma propriedade do cálculo, não da comparação.

A política precisa virar dado de primeira classe

Uma organização pode tornar perfis diferentes comparáveis sem exigir que sejam iguais. Para cada execução, preserve a versão do logger; schemas e extensões; eventos habilitados; substituições Core/Base; campos opcionais; regras de RawInfo; amostragem; tamanho e estado do buffer; início e fim da captura; clock e formato temporal; anonimização; contadores de perda na exportação; e transformações da cadeia de processamento.

Em seguida, classifique cada indicador. Alguns aceitam comparação direta porque os dois lados observaram o mesmo fenômeno com cobertura demonstrada. Outros precisam ser normalizados por uma oportunidade de observação comum. Alguns não são comparáveis e devem aparecer como tais.

Esse manifesto de observabilidade é orientação operacional de Daniel Kade, não requisito oculto da minuta. Ele serve para manter a liberdade local que qlog permite sem conceder aos painéis liberdade para inventar equivalência.

Também é preciso separar ausência de zero. “Nenhum evento registrado” pode significar zero ocorrências, zero cobertura, filtro ativo, início tardio, overwrite ou falha de exportação. A interface deve preservar esses estados. Substituir todos por 0 beneficia o fornecedor que mede menos.

A evidência sensível torna o ranking mais difícil

Em protocolos como QUIC e TLS, qlog pode revelar elementos normalmente protegidos pelo wire image criptografado. Dados de identificação, horários precisos, tamanhos, cookies, tokens, chaves e conteúdo podem entrar no arquivo. A minuta afirma que capturar ou ler qlog pode equivaler a acessar comunicações em texto claro.

Logo, o perfil mais detalhado não é automaticamente o melhor. Controles de acesso, auditoria, ativação explícita, retenção e criptografia são partes da qualidade. Um fornecedor que minimiza RawInfo pode ter desenho de privacidade superior, mesmo que certas análises se tornem impossíveis. O julgamento adequado é se ele preserva a evidência necessária ao uso declarado e expõe honestamente o que remove.

A comparação deve incluir risco por unidade de informação, não apenas volume coletado. Um arquivo menor com contadores confiáveis de omissão pode ser mais útil que um arquivo enorme sem autorização e sem procedência. Um evento Base explícito pode ser melhor que um Core rico que ninguém está autorizado a guardar.

Do benchmark à decisão de serviço

Mesmo depois de equalizar os perfis, qlog continua sendo evidência de protocolo. Menos descartes registrados não prova menor latência percebida, maior disponibilidade ou conclusão correta da transação. Para cada promessa comercial, é necessário definir o elo até o resultado: resposta entregue, prazo cumprido, operação aceita, erro visível ao usuário ou custo evitado.

O teste deveria poder ser repetido com um perfil comum mínimo, parâmetros publicados e perguntas predefinidas. Diferenças adicionais de visibilidade podem ser avaliadas separadamente. Os dados brutos permitidos, o manifesto de captura e o código de derivação precisam ser exportáveis. Se apenas o painel do fornecedor consegue reproduzir sua pontuação, qlog foi usado como entrada aberta para uma conclusão fechada.

No caso inicial, a resposta não é declarar empate. É retirar o ranking até que exista denominador comparável, depois relatar duas dimensões: comportamento observado sob cobertura comum e capacidade/risco de observabilidade de cada produto. Essa separação produz uma decisão de compra mais informada do que premiar a menor contagem.

O formato comum faz seu trabalho quando permite descobrir a diferença. Ele deixa de fazê-lo quando o rótulo comum é usado para escondê-la.

Fontes