Confesso que pra escrever o script pra lers os logs do servidor web, aquele que mostrei em acessos de robôs nos logs web, foi algo próximo do vudu. Tudo porque o formato gerado não é lá muito amigável.
Idem pras máquinas do trabalho. Então hoje eu resolvi dar uma olhada se tinha como escrever esses mesmos logs em json.
E tem.
O primeiro que olhei foi no nginx. E é bem fácil de fazer.
log_format logger-json escape=json '{"source": "nginx", "time": "$time_iso8601", "resp_body_size": $body_bytes_sent, "host": "$http_host", "address": "$remote_addr", "request_length": $request_length, "method": "$request_method", "uri": "$request_uri", "status": $status, "user_agent": "$http_user_agent", "resp_time": $request_time, "upstream_addr": "$upstream_addr"}';
[...]
server {
listen 443 ssl;
server_name api.company.com;
...
access_log /var/log/nginx/access.log logger-json;
...
}
Eu segui a receita desses dois links aqui:
https://www.velebit.ai/blog/nginx-json-logging/
https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
Pro Apache não tem um módulo que já gera tudo meio mastigado como no nginx. Mas você pode criar o formato do log como quiser.
LogFormat "{ \"time\":\"%{%Y-%m-%d}tT%{%T}t.%{msec_frac}tZ\", \"process\":\"%D\", \"filename\":\"%f\", \"remoteIP\":\"%a\", \"host\":\"%V\", \"request\":\"%U\", \"query\":\"%q\", \"method\":\"%m\", \"status\":\"%>s\", \"userAgent\":\"%{User-agent}i\", \"referer\":\"%{Referer}i\" }" combined
ErrorLogFormat "{ \"time\":\"%{%Y-%m-%d}tT%{%T}t.%{msec_frac}tZ\", \"function\" : \"[%-m:%l]\" , \"process\" : \"[pid %P:tid %T]\" , \"message\" : \"%M\" ,\ \"referer\"\ : \"%{Referer}i\" }"
E esse veio de dica do stack-overflow:
Eu não segui os mesmos parâmetros entre apache e nginx. Por enquanto estou só testando e estar com os campos bem definidos já é o suficiente pra mim.
> tail -1 /var/log/apache2/linux-br-access.log | jq .
{
"time": "2025-08-20T09:38:59.369Z",
"process": "241797",
"filename": "/var/www/linux-br.org/index.php",
"remoteIP": "54.36.149.72",
"host": "linux-br.org",
"request": "/date/2024/03/page/3/",
"query": "",
"method": "GET",
"status": "200",
"userAgent": "Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)",
"referer": "-"
}
Agora ficou fácil de filtrar e pegar só os campos que interessam. E usando "jq".
> tail -1 /var/log/apache2/linux-br-access.log | jq ".userAgent"
"Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)"
> tail -3 /var/log/apache2/linux-br-access.log | jq ".userAgent"
"Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)"
"Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)"
"Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)"
E no fim de 2024, porque não fechar o ano com um ataque de DoS? Aparentemente alguém achou isso uma boa ideia. Ao menos o site não foi afetado.
Claro que também podem ter sidos acessos legítimos. Principalmente no https://linux-br.org mas eu particularmente não boto muita fé nisso.
Se você nunca ouviu falar de DoH além do Homer reclamando que fez alguma bobagem, então não está na Internet tempo o suficiente. E talvez não esteja protegendo sua privacidade como poderia.
DNS, de Domain Name Service (serviço de nomes de domíno), é o que traduz um nome de domínio como helio.loureiro.eng.br pra um endereço IP. No caso de helio.loureiro.eng.br o nome é resolvido tanto pra IPv4 quanto pra IPv6.
Por mais inocente que seja essa tradução, esse dado não tem criptografia ou qualquer outro tipo de proteção. Pode e provavelmente é usado por seu provedor de Internet pra conhecer seus hábitos de navegação e até vender esse dado pra alguém.
Pra coibir tal uso de sua informação pessoal foi criado o protocolo DoH, ou DNS over HTTPS, que é a requisição de DNS enviada por HTTPS. A vantagem desse método é que ninguém consegue diferenciar seu tráfego HTTPS como sendo uma requisição DNS ou acesso a uma página web, que é protegida por uma camada de SSL de criptografia. O firefox permite a configuração de forma bastante fácil.
Mas claro que em alguns lugares o acesso pode ser barrado pra dificultar seu acesso ao DoH e forçar o uso de um serviço de DNS local. Por padrão o firefox permite usar o serviço do Cloudflare ou do NextDNS. O que fazem alguns provedores é bloquear requisições pra esses destinos. Mesmo o serviço de DoH do OpenDNS é bloqueado.
Pra previnir isso eu habilitei um DoH relay que recebe as requisições e envia para https://doh.opendns.com/dns-query pra resolver. Então para usar o serviço, basta configurar como fiz acima no Firefox e usar o destino:
E claro que esse artigo não é só pra dizer que esse serviço está habilitado. É pra mostrar como montar o seu.
Eu usei o binário de um doh-relay escrito em Go e disponível no github aqui:
https://github.com/tinkernels/doh-relay
A compilação foi um simples comando, assumindo que tenha o Go pra fazer a compilação:
macOS in ~
✦ ❯ cd /tmp
macOS in /tmp
✦ ❯ git clone https://github.com/tinkernels/doh-relay.git
Cloning into 'doh-relay'...
remote: Enumerating objects: 461, done.
remote: Counting objects: 100% (192/192), done.
remote: Compressing objects: 100% (136/136), done.
remote: Total 461 (delta 127), reused 117 (delta 56), pack-reused 269
Receiving objects: 100% (461/461), 180.87 KiB | 3.17 MiB/s, done.
Resolving deltas: 100% (307/307), done.
macOS in /tmp
✦ ❯ cd doh-relay
macOS in doh-relay on master via 🐹 v1.22.0
✦ ❯ make linux-amd64
mkdir -p release
GOOS=linux GOARCH=amd64 go build -ldflags "-extldflags=-static -w -s" -o release/doh-relay_linux-amd64 .
go: downloading github.com/ReneKroon/ttlcache v1.7.0
go: downloading github.com/miekg/dns v1.1.54
go: downloading github.com/buraksezer/connpool v0.6.0
go: downloading github.com/gin-gonic/gin v1.9.0
go: downloading github.com/oschwald/geoip2-golang v1.8.0
go: downloading github.com/sirupsen/logrus v1.9.1
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading golang.org/x/sys v0.8.0
go: downloading golang.org/x/net v0.10.0
go: downloading github.com/gin-contrib/sse v0.1.0
go: downloading github.com/mattn/go-isatty v0.0.18
go: downloading github.com/go-playground/validator/v10 v10.13.0
go: downloading github.com/ugorji/go/codec v1.2.11
go: downloading github.com/pelletier/go-toml/v2 v2.0.7
go: downloading github.com/oschwald/maxminddb-golang v1.10.0
go: downloading github.com/leodido/go-urn v1.2.4
go: downloading golang.org/x/crypto v0.9.0
go: downloading github.com/go-playground/universal-translator v0.18.1
go: downloading golang.org/x/text v0.9.0
go: downloading github.com/go-playground/locales v0.14.1
macOS in doh-relay on master via 🐹 v1.22.0 took 9s
✦ ❯ mv release/doh-relay_linux-amd64 release/doh-relay
No servidor truta.org, copiei o binário pra /usr/local/bin. E criei grupo e usuário.
root@truta /u/l/bin# addgroup --system doh-relay
Adding group `doh-relay' (GID 135) ...
Done.
root@truta /u/l/bin# adduser --system --gid 135 doh-relay
Adding system user `doh-relay' (UID 129) ...
Adding new user `doh-relay' (UID 129) with group `doh-relay' ...
Not creating `/nonexistent'.
Em seguida adicionei um serviço ao systemd e habilitei.
root@truta /# cd /etc/systemd/system
root@truta /e/s/system# vim doh-relay.service
root@truta /e/s/system# cat doh-relay.service
[Unit]
Description=Dns-over-HTTPS relay
After=syslog.target network.target
[Service]
User=doh-relay
Group=doh-relay
WorkingDirectory=/tmp
ExecStart=/usr/local/bin/doh-relay --cache=true --doh -doh-upstream=https://doh.opendns.com/dns-query
Type=simple
Restart=always
RestartSec=3
[Install]
WantedBy=default.target
root@truta /e/s/system# systemctl daemon-reload
root@truta /e/s/system# systemctl enable --now doh-relay.service
Created symlink /etc/systemd/system/default.target.wants/doh-relay.service → /etc/systemd/system/doh-relay.service.
root@truta /e/s/system# systemctl status doh-relay
● doh-relay.service - Dns-over-HTTPS relay
Loaded: loaded (/etc/systemd/system/doh-relay.service; enabled; preset: enabled)
Active: active (running) since Thu 2024-03-07 09:47:09 -03; 5s ago
Main PID: 819347 (doh-relay)
Tasks: 6 (limit: 3535)
Memory: 4.0M
CPU: 15ms
CGroup: /system.slice/doh-relay.service
└─819347 /usr/local/bin/doh-relay --cache=true --doh -doh-upstream=https://doh.opendns.com/dns-query
Mar 07 09:47:09 truta.org systemd[1]: Started doh-relay.service - Dns-over-HTTPS relay.
Mar 07 09:47:09 truta.org doh-relay[819347]: *** Starting ***
Mar 07 09:47:09 truta.org doh-relay[819347]: time="2024-03-07T09:47:09" level=info msg="open : no such file or directory" file="geoip.go:41"
Mar 07 09:47:09 truta.org doh-relay[819347]: time="2024-03-07T09:47:09" level=info msg="resolver: [https://doh.opendns.com/dns-query], fallback: []" file="main.go:339"
O último passo foi adicionar a configuração ao apache com proxy interno conectando com a porta 15353 onde roda o doh-relay.
root@truta /e/a/conf-enabled# cat /etc/apache2/conf-enabled/doh-enabled.conf
<IfModule mod_proxy.c>
ProxyVia On
ProxyRequests Off
ProxyPass /dns-query http://localhost:15353/dns-query retry=0 timeout=10
ProxyPassReverse /dns-query http://localhost:15353/dns-query
ProxyPreserveHost on
<Proxy *>
Options FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Proxy>
</IfModule>
root@truta /e/a/conf-enabled# a2enmod proxy
Module proxy already enabled
root@truta /e/a/conf-enabled# a2enmod proxy_html
Considering dependency proxy for proxy_html:
Module proxy already enabled
Considering dependency xml2enc for proxy_html:
Enabling module xml2enc.
Enabling module proxy_html.
To activate the new configuration, you need to run:
systemctl restart apache2
root@truta /e/a/conf-enabled# a2enmod proxy_http
Considering dependency proxy for proxy_http:
Module proxy already enabled
Enabling module proxy_http.
To activate the new configuration, you need to run:
systemctl restart apache2
root@truta /e/a/conf-enabled# a2enmod proxy_http2
Considering dependency proxy for proxy_http2:
Module proxy already enabled
Considering dependency http2 for proxy_http2:
Enabling module http2.
Enabling module proxy_http2.
To activate the new configuration, you need to run:
systemctl restart apache2
root@truta /e/a/conf-enabled# apachectl configtest
Syntax OK
root@truta /e/a/conf-enabled# apachectl restart
E pronto. Um relay de DoH pronto pra servir.
06-05-2025: deu algum ziriguidum no serviço e no momento não está funcionando. Se alguém, além de mim, usava pra alguma coisa, sinto muito. Atualizo aqui quando voltar.
Finalmente criei vergonha na cara e criei um certificado pra usar https no site. Não que eu não usasse criptografia antes, mas era um certificado auto-assinado com aquele "SnakeOil". Motivo? Simplesmente uso conexão segura pra postar no site, e mais nada.
E os usuários? Bom... eu não tenho um "grande" site com muito tráfego. Acho que ninguém vai se sentir ofendido pelo fato de não ser possível acessar o conteúdo via https. Aliás, até é mas vi que várias coisas no Joomla estão apontando pra http ao usar https. Um dia eu devo arrumar isso. Ou mudar o tema pra algum que tenha isso corrigido.
Mas o importante de ter um certificado ssl pro meu https é que consegui um assinado. E gratuitamente. A autoridade certificadora startssl fornece gratuitamente certificados de nível 1. São os mais simples, mas pra quem quer algo gratuito, vale a pena.
O melhor é que bastou seguir uma receita de bolo que o pessoal da DigitalOcean fez:
Rápido, fácil e funcional. Quem ainda não tiver um certificado assinado, vale a pena tanto por ser gratuito quanto pelo aprendizado.
Como descrito e previsto anteriormente em "o último dos apaches", o servidor web IIS da Microsoft tornou-se o líder de mercado, de acordo com medições da Netcraft.
Netcraft's July 2014 Web Server Survey
Com isso chegamos ao fim de uma era de dominação do software livre. Claro que se somarmos as quantidades de servidores Apache e Nginx, teremos uma quantidade maior de servidores de software livre. Mas então teríamos de somar o IIS com os outros servidores proprietários, como Sun e NCSA.
Em números, a virada se deve à queda do uso do Apache, além do crescimento do IIS.
Em termos de sites realmente ativos, o Apache ainda continua líder, o que mostra uma certa "inflada" nesse número de servidores IIS.
Ainda de acordo com a Netcraft, essa inflada do IIS nos últimos tempos se deve aos sites chineses, principalmente os de compras, que apesar de serem chineses, estão hospedados em servidores americanos. Imagino que seja por conta dos serviços de cloud disponíveis por lá.
Fui verificar se meu querido site DealExtreme está entre os chineses que adotaram Microsoft, mas pude ver pelo Netcraft que ele está firme e forte com Linux.
Então posso continuar com minhas compras e com consciência tranquila.
Já outro dado que vi na Internet, e que aliás me faz lembrar de olhar o Netcraft, mostra que o uso de cloud Microsoft aumentou muito no último ano. Então esse efeito "inflado" de aumento de servidores, mas não ativos, deve ser com certeza o Azure.
Seria isso um reflexo da melhor qualidade do IIS? Acho que não. Apache sempre liderou com folga esse espaço. Seria então por ser gratuito? Nesse quesito, o Amazon AWS também é por 1 ano. Então não acho que seja um espaço de "servidores de experimentação", de quem está aprendendo, mas de coisa profissional, de site de e-commerce mesmo, como é dito pela Netcraft. Mas qual o motivo de escolherem IIS? Eu acho que é falta de conhecimento aliada com forte propaganda da Microsoft - e cursos - de Azure e .Net. Muitas pessoas saem das universidades sabendo isso, e nem mesmo olham pra outra coisa. Azure e .Net de hoje é o VB e Delphi de 15 anos atrás. A diferença é que estão entrando numa área que era dominada pela qualidade do software livre, mas que agora será tomada pela quantidade de uso. Assim foi com o navegador Internet Explorer 6. Riscos? Teremos novamente padrões web ditados pela Microsoft.
2014 será marcado como o ano de grandes perdas. Falecimentos de grandes personagens da história, como o autores Ariano Suassuna e João Ubaldo, e morte da presença do software livre na web. E da web livre.
Estamos em risco.
