Estatísticas da APNIC voltam; arquivo ainda perde 92 horas

Resumo

A captura do JSON de WHOIS e RDAP da APNIC às 08:38 UTC cobre 27 de outubro, das 05:00 às 06:00 UTC; o MD5 publicado ao lado confere com o arquivo baixado. A publicação horária já havia sido retomada.
O arquivo de outubro não tem relatórios para 92 horas consecutivas, de 23 de outubro às 04:00 a 26 de outubro às 23:00 UTC. O aviso de 16 de outubro segue sem hora final, duração ou relação de intervalos corrigidos.

O feed voltou. As horas que sumiram não vieram junto.

Quem acompanha uma série horária precisa escolher como tratar cada lacuna. Às 08:38 UTC, o JSON da APNIC cobria a hora encerrada às 06:00 UTC de 27 de outubro. O MD5 conferia com o arquivo baixado. O diretório mensal trazia relatórios até 04:00–05:00 UTC. A publicação horária já havia sido retomada.

O arquivo conta outra história. O último relatório antes do buraco cobre 23 de outubro, das 03:00 às 04:00 UTC. O próximo começa à meia-noite do dia 27. Entre os dois, 92 inícios de hora não têm arquivo correspondente. O relatório mais recente voltou; o calendário continua com quatro dias em branco.

A conta vem das próprias regras da APNIC. O README diz que cada relatório cobre uma hora UTC em intervalo semiaberto. Quando um novo relatório é publicado, ele substitui o arquivo mais recente e o anterior vai para o arquivo mensal. O nome 20261023-0300 representa 03:00–04:00; o próximo deveria começar às 04:00. O diretório reaparece em 20261027-0000. São 92 horas sem registro.

O aviso de serviço de 16 de outubro marca o início às 10:00 UTC+10, ou 00:00 UTC. O serviço afetado é “Whois and RDAP stats”. A APNIC atribui o problema ao processamento de logs, diz que as estatísticas ficaram incompletas a partir daquele horário e que a geração foi desativada. Prometeu republicar os arquivos afetados depois da correção. Os campos de término e duração continuam vazios.

O arquivo oferece uma pista de recuperação: o relatório de 23 de outubro, 03:00–04:00, foi regravado em 27 de outubro às 03:12 UTC. Novos relatórios aparecem depois dele. O registro público mostra uma hora atual e um arquivo antigo republicado, mas não identifica quais intervalos foram reconstruídos, quais seguem incompletos e quais continuarão indisponíveis. A página de avisos ainda exibe a notificação original, sem fechamento.

Em uma série temporal, esse vazio vira uma escolha de cálculo. Um programa pode excluir a hora, interpolar entre as vizinhas ou preencher zero. Cada opção altera médias e alertas. Os relatórios da APNIC trazem totais de consultas, distribuição por tipo e contagem de IPs de origem distintos por ASN de origem. Horários e checksums permitem conferir cada arquivo; um estado de completude e um histórico de correção por hora explicariam a série inteira.

Um checksum confirma os bytes. Não mantém o livro de reparos.

A APNIC já tem os ingredientes para um registro de recuperação preciso. Para cada hora corrigida, pode publicar o intervalo UTC, o estado, o primeiro horário de publicação, a hora da correção, o checksum atual e o checksum do arquivo substituído. Um manifesto enxuto poderia marcar cada hora ausente como republicada, indisponível ou retida e apontar para o arquivo correspondente. Pesquisadores guardariam a versão antiga, identificariam a nova e recalculariam a série sem fazer arqueologia no diretório.

As peças cumprem funções diferentes: o checksum confirma que o download corresponde aos bytes publicados pela APNIC; o nome do arquivo indica a hora; o aviso fixa o início da incompletude em 16 de outubro, 00:00 UTC. O manifesto ligaria esses fatos hora por hora.

O aviso trata da geração de estatísticas e dos arquivos estatísticos. O relatório de 27 de outubro comprova que a publicação foi retomada. A próxima atualização útil deve listar as horas afetadas, os checksums dos arquivos corrigidos e o encerramento do aviso do dia 16. O relógio voltou à parede; o arquivo ainda deve 92 linhas aos leitores.