Na jornada de criar aplicações globais, o arquiteto precisa prover dados que guiem as estratégias de crescimento de qualquer negócio. Esses dados interferem na forma como projetamos disponibilidade, cache, e recursos específicos para atender regiões específicas do globo. Mas e aí, você sabe de onde está vindo o acesso às suas aplicações e serviços? Você já sabe qual o próximo passo?

Hoje eu vou mostrar como aproveitei recursos e dados que já estavam disponíveis para mim, para criar uma visão que me permite entender o tráfego para os meus servidores.

Contexto

O Windows Server me expulsou dele mesmo

Tudo começa do aspecto de segurança. Em 4/JAN de 2014 eu fui obrigado recomeçar do zero meu blog. Motivo: Uma falha de segurança no wordpress que afetava deployments no Windows abria uma porta para a invasão e uso irrestrito do blog e até do servidor. Naquela época meu primeiro Linux server, na iMusica, havia sido criado há alguns meses. Então eu resolvi abandonar a ideia de rodar servidores windows server em VPS’s e resolvi criar de fato meu primeiro VPS Linux na nuvem. Que angústia!

O primeiro contato é sempre traumático. A sensação de impotência, de não saber o que está acontecendo, de sequer saber como visualizar os processos em execução, era frustrante. No linux server não tem essa de listar os programas em um menu de gerenciamento e ver que dados eles apresentam. Você precisa previamente saber o que quer. E esse é a principal dor dos novatos. É por isso que produzi um módulo de Linux para o Docker Definitivo.

Habituando com Linux headless, ELK Stack e primeiro contato com Docker

Bom, e como não passar pelo mesmo problema? Entre 2014 e 2016 eu dediquei uma parte do meu tempo a me familiarizar com Linux, conheci ferramentas como Webmin, testei diversos portais de gerenciamento web. Hoje lembro um nome ou outro só. Nesse meio tempo comecei a me interessar por Docker e logo veio o NGINX. Por conta da experiência de 2013 e 2015 com o RabbitMQ + ELK Stack (ElasticSearch, LogStash e Kibana), em 2016 converti o Enterprise Application Log em um stack pré-montado pronto para uso com Docker-Compose.

Estudando docker, fui esbarrando em perguntas como:

Se eu não consigo expor 2 containers na mesma porta, como lido com isso?

O NGINX

Foi aí que encontrei proxy reverso como solução. E foi por essa época que esbarrei no NGINX. Eu já havia escutado sobre ele, mas não fazia muita ideia de como seria útil. Vindo do mundo Microsoft, era a primeira vez que eu via um webserver que não não rodava algum tipo de código-server side. Não por padrão. Meses depois eu vi como ele trabalha com fastcgi etc, mas antes disso eu estava habituado com o IIS e o ISAPI. Continuei meus estudos sobre o NGINX, eu queria saber:

• Até onde ele iria?
• O que dá para fazer com ele e do que seria capaz?
• Porque estava fazendo tanto barulho assim? O que ele teria de especial?
• Até onde ele seria útil?

Assim desse estudo e dessas perguntas nasceu um projeto github.com/luizcarlosfaria/nginx-pagespeed, um NGINX customizado com plugins incríveis, embora desatualizado, vale conferir.

Juntando as coisas

Em 2017 eu já estava automatizando a configuração do NGINX com NodeJS. Eu narrei isso em NGINX Automation e uma das coisas que fiz ainda no mesmo ano ou no ano seguinte, foi começar a produzir logs do NGINX em formato JSON. Uma vez JSON, eu habilitei mais uma entrada no logstash para fazer input desses logs. E foi aí que comecei a dar vida ao Kibana com os logs do meu nginx em formato json.

Sair do windows não me livrou de novos ataques

Uma vez monitorando esse ambiente eu percebi padrões, e acessos muito esquisitos tentando realizar login no meu wordpress, e também chamadas bem peculiares tentando buscar arquivos .env, arquivos php de plugins específicos que eu sequer tinha, também chamadas com resposta 404 buscando dumps databases com nomes “pobres” no root do site.

Foi aí que entendi que estava consistentemente, dia-e-noite, sendo atacado. Essa era a técnica para buscar padrões no meu servidor que indicassem alguma vulnerabilidade que o atacante conhecesse.

Daí pra frente eu busquei soluções e um dos serviços que me ajuda até hoje é a cloudflare.

Country Block?

Meu conteúdo é todo produzido em Português Brasileiro, prioritariamente para o público Brasileiro. Isso quer dizer que tenho pouquíssimo acesso internacional, a aquele que existe é do público brasileiro. Quando não, é a navegação com bounce muito alto, ou seja, irrelevante para os gringos que chegam aqui.

Curiosidade: Faz algum tempo que recebi um comentário no Youtube me xingando porque eu não havia colocado legenda em espanhol ou inglês, não lembro. Foi engraçado o cara ficou muito chateado!!

Mesmo assim a maior parte das análises e ataques vêm de EUA, Europa Setentrional, Europa Centro-Oriental e Ásia.

Levando em conta que por conta o programa MVP (e a análise dos posts), das principais redes sociais (que enviam requests de análise a cada novo post publicado a partir de servidores dos EUA), e da base de alunos do Docker Definitivo, filtrar tráfego do EUA, Portugal ou Canadá não é uma opção, mas para uma parte da Europa e Ásia, sim. Então essa possibilidade sempre esteve na mesa.

NGINX – GeoIP

O NGINX possui um plugins para lidar com GeoIP. Ele precisa de um database que você baixa do MaxMind e disponibiliza para o NGINX. O database possui uma lista de IP’s e seu respectivo país. Embora você tenha de baixar de tempos em tempos, já é um bom começo.

Embora funcione bem, era uma tarefa burocrática e manual baixar esse arquivo (Acabei de descobrir que já existe um utilitário para isso, mas antigamente baixávamos direto do MaxMind).

A doc para fazer isso com NGINX Plus está aqui. A lógica para o NGINX community é a mesma.

Tutorial

Tudo que vimos até então visa contextualizar sobre as possibilidades e o que já foi tentado no passado. Mas agora vamos lidar com a ideia de trazer o dado de country code para nosso log de acesso, visando que 100% dos requests que recebemos passe pelo CloudFlare e por sua vez nos ajuda e monitorar os acesso às nossas api’s.

CloudFlare

A CloudFlare é canivete suíço quando se fala de Proxy Reverso. Ele é um serviço com uma camada gratuita muito generosa.

Ele é:

• Proxy reverso
• CDN
• WAF
• Terminação TLS (ele coloca TLS para você, enquanto seu servidor poderia não ter)
• Acelerador out of the box
• além de ser um DNS com uma interface muito amigável.

É um serviço incrível, onde nível gratuito oferece já oferece muito recurso interessante.

Voltando ao tema principal, sobre a CloudFlare vou isolar somente uma funcionalidade: Adicionar um cabeçalho com o Country Code do IP original do Request.

Delegar pra a CloudFlare não só elimina a necessidade de um plugin, mas elimina a necessidade de gestão sob o database da MaxMind.

Na medida que habilitamos a flag “IP Geolocation Header” no dashboard da CloudFlare, passamos a receber no NGINX a variável $http_cf_ipcountry, com o Country Code, com 2 letras.

Bom, para que isso funcione para você, é necessário usar a CloudFlare como DNS dos teus serviços. Hoje a maioria dos meus domínios é gerenciado pela CloudFlare. Poucos são os domínios que ficam na GoDaddy, hoje serviço que mais tenho domínios.

Enterprise Application Log + NGINX Json Log

Uma vez com o cabeçalho é hora de configurar o LogStash para carregar nossos dados para o ElasticSearch. Mas antes disso precisamos formatar o log para que ele vire um json válido.

Transformando o log em json:

Usando o LogStash para ingerir o log no Elastic

Depois é só configurar o LogStash para ler e publicar esses logs no elastic.

Habemus data!

Agora enfim, temos dados. Se você:

• No teu serviço de hospedagem
  • Alterou o DNS para apontar para a CloudFlare
• Na CloudFlare
  • Criou sua conta
  • Configurou a CloudFlare como seu DNS
  • Habilitou o proxy
  • Adicionou a entrada IP Geolocation Header nas suas configurações de regra
• No NGINX
  • Alterou o formato do log
• No LogStash
  • Criou a nova entrada para fazer a ingestão do log do NGINX

Se tudo isso rolou, então cada request que passe pelo teu proxy reverso, chega no teu ElasticSearch. E melhor, chega lá com o cabeçalho que define o country code. E o que é melhor ainda. Sem nenhuma necessidade de gestão.

O que é possível fazer com isso?

Agora que você monitora cada request, sua imaginação pode ir longe. Cada um vai tirar proveito de uma forma diferente. Mas estão aqui algumas possibilidades:

Prever demandas por CDN

Seus serviços em geral estão em um ou no máximo 2 datacenters espelhados pelo globo. Mas será que a latência é realmente boa? Será que teu budget está bem dimensionado para a galera que mais acessa teu site ou recurso?

Ainda vejo diversos serviços hospedados nos EUA mas sua base de usuários é toda no Brasil. Será que a latência está legal? Quanto é investido em entregar pelo menos um CDN global ou regional?

Previsão de crescimento por região do globo

Talvez você não saiba como anda o crescimento do tráfego em suas API’s oriundo de determinado país. Monitorar é relevante para entregar uma boa experiência para seus usuários.

Não necessariamente seus clientes estão onde deveriam estar. E essa dinâmica fica pior quando falamos de contratos B2B. Onde boa parte do tráfego não vem de pessoas, mas de outras aplicações que não necessariamente estão perto de você.

Como montar o board no Kibana com o Mapa-múndi?

Agora é hora de mostrar isso visualmente. O Kibana, parte do Enterprise Application Log (e antes demais nada, parte do ELK stack) será o responsável por nos trazer uma visão dos nossos dados em um formato de mapa. Isso ajuda demais no entendimento dos dados.

Sobre como lidar com isso no Kibana, eu não tinha muita opção a não ser detalhar isso com imagens. Ao final temos um mapa do globo como mostra a imagem abaixo:

Passo-a-passo em Imagens

Siga o passo-a-passo.

Como eu recriei meus índices quando troquei as versões do Elastic e do Kibana, acabei abandonando o histórico de 60 dias. Ainda pretendo avaliar quanto tempo vou manter histórico aqui.

Conclusão

Você escolhe o que fazer com esse dado, talvez a origem ideal para você sequer seja produzida pelo seu log de acesso aos serviços, mas talvez pela sua base de usuários.

De qualquer forma aqui eu ajudo a elucidar algumas possibilidades.

O que importa no contexto desse post é a capacidade de usar mapas e dados que já existem, ou que mesmo que não existam mas podem ser produzidos, para ajudar na tomada de decisão e estratégia.