Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Um log de acesso cheio de endereços IP tem informações geográficas reais escondidas, mas só depois que cada endereço é resolvido em coordenadas que uma ferramenta de mapas consegue realmente plotar.
Extraia primeiro os endereços IP únicos do seu arquivo de log, em vez de consultar cada linha individualmente, já que o mesmo endereço de visitante costuma aparecer muitas vezes ao longo de uma sessão e não há motivo para pagar pela mesma consulta repetidamente.
sort logfile.txt | awk '{print $1}' | sort -u > unique_ips.txtEnvie a lista de endereços únicos como um array em POST em lote para /v1/ip.
POST /v1/ip
Content-Type: application/json
["203.0.113.10", "198.51.100.25", "192.0.2.44"]{
"status": "ok",
"results": [
{"ip": "203.0.113.10", "version": 4, "found": true, "country": "Germany", "country_code": "DE", "region": "Berlin", "city": "Berlin", "postcode": "10115", "lat": 52.5300, "lon": 13.3800, "timezone": "Europe/Berlin", "asn": 1111, "org": "Example ISP"},
{"ip": "198.51.100.25", "version": 4, "found": true, "country": "Spain", "country_code": "ES", "region": "Madrid", "city": "Madrid", "postcode": "28001", "lat": 40.4168, "lon": -3.7038, "timezone": "Europe/Madrid", "asn": 2222, "org": "Example Networks"},
{"ip": "192.0.2.44", "version": 4, "found": false}
]
}Associe cada lat e lon retornados à contagem de ocorrências do endereço original no seu log, para que um visitante que aparece cem vezes no log tenha um peso proporcionalmente maior do que um que aparece uma vez. Alimente a lista resultante de pontos de coordenadas ponderados na ferramenta de mapas ou de gráficos que você usa para gerar o mapa de calor.
Se um mapa de calor preciso, ponto a ponto, tem mais detalhes do que você precisa, agregar por country_code em vez de coordenadas brutas produz uma visualização mais simples no estilo coroplético, um valor por país em vez de uma nuvem dispersa de pontos. Isso usa exatamente a mesma consulta em lote, apenas agrupada de outra forma quando os resultados chegam, então não custa nada a mais criar as duas visualizações a partir dos mesmos dados resolvidos.
Uma entrada com found: false, como o terceiro resultado acima, deve simplesmente ser excluída do mapa de calor, em vez de ser plotada em uma localização padrão, já que incluí-la concentraria de forma enganosa o tráfego não resolvido em um ponto do mapa que não tem nada a ver com a sua origem real.
Não deixe de filtrar o tráfego obviamente não humano, como verificações internas de integridade ou serviços de monitoramento que acessam o seu servidor constantemente a partir de um endereço fixo, antes de montar a lista de endereços únicos. Um serviço de monitoramento que consulta a cada minuto pode acumular um número desproporcional de linhas de log sem nenhuma relação com a geografia real dos visitantes e, embora a remoção de duplicatas já o limite a um único ponto resolvido, esse ponto ainda pode dominar visualmente um mapa de calor de forma desproporcional a qualquer padrão de tráfego real que ele represente.
O campo org de um endereço resolvido muitas vezes revela quando o tráfego vem de um data center ou de uma faixa de hospedagem em nuvem, e não de uma conexão residencial ou móvel, o que é um sinal razoável para filtrar tráfego de bots ou scrapers antes que ele distorça um mapa de calor que deveria representar as localizações reais dos visitantes.
Resolver os endereços únicos, e não cada linha do log, é o que mantém isso acessível, já que o custo é de uma requisição por endereço único, e não por linha do log. Um log com um milhão de linhas, mas apenas alguns milhares de endereços de visitantes únicos, custa alguns milhares de requisições, e não um milhão, algo perfeitamente administrável com crédito pré-pago ou com um pacote Unlimited para um site grande, e muitas vezes dentro da cota gratuita para um site menor. Acompanhar o cabeçalho X-Quota-Used durante um trabalho em lote grande é uma forma simples de confirmar que o uso está dentro do esperado antes de o trabalho terminar.
Remover duplicatas antes de resolver é a maior alavanca para manter acessível um mapa de calor baseado em logs. A documentação da consulta IPv4 descreve o formato completo da requisição em lote.