Computação em nuvem

Monitorar o Nginx com o Netdata

Veja como você pode monitorar as conexões ao servidor Nginx e aos seus logs de acesso com o Netdata.

há 3 anos 9 meses

Formação Administrador AWS
Conheça a formação em detalhes

No artigo Monitorar servidor em tempo real com o Netdata, vimos o que é o Netdata e como instalá-lo. Agora veremos como monitorar o Nginx com o Netdata.

Ativando a status page do Nginx

A maioria das instalações do Nginx já vem com o módulo http_stub_status_module instalado. Você pode verificar isso executando o comando:

nginx -V 2>&1 | grep -o with-http_stub_status_module

Se você visualizar um retorno assim:

with-http_stub_status_module

Significa que a instalação do seu Nginx tem esse módulo instalado. Esse é o primeiro passo para que possamos prosseguir aqui. Esse módulo fornece informações em tempo real sobre as conexões e requisições ao servidor.

Só que para ter acesso a essas informações, é preciso definir uma location (um endpoint) de acesso a elas e normalmente utiliza-se /nginx_status.

Amazon Web Services (AWS) - EC2 - Fundamentos
Curso Amazon Web Services (AWS) - EC2 - Fundamentos
Conhecer o curso

A location /nginx_status

Algumas pessoas definem essa location dentro do virtualhost do domínio da aplicação delas e acessam assim:

http://www.meusite.com/nginx_status

Ao acessar, as seguintes informações são impressas:

Active connections: 134 
server accepts handled requests
 979653 979653 4496872 
Reading: 0 Writing: 5 Waiting: 130 
  • Active connections: Número de conexões abertas. Isso não reflete o número de usuário online no seu site, uma vez que um único usuário pode ter mais de uma conexão aberta (de forma simultânea);
  • Server accepts handled requests: O primeiro valor é o total de conexões aceitas e o segundo valor é o total de conexões que o nginx definitivamente chegou a lidar, e na maioria das vezes esses dois valores são iguais. O terceiro valor refere-se ao número de solicitações recebidas. Dividindo o terceiro valor pelo segundo, chega-se ao número de requisições por conexão. No caso desse exemplo: 4496872 / 979653 = 4,5, ou seja, 4,5 requisições por conexão;
  • Reading: O número atual de conexões em que o nginx está lendo o cabeçalho da solicitação;
  • Writing: O número atual de conexões em que o nginx está escrevendo uma resposta de retorno ao cliente;
  • Waiting: O número atual de conexões inativas aguardando uma solicitação (algumas conexões são mantidas abertas).

Mas ter essas informações de forma pública e acessível por todos, pode não fazer tanto sentido. A recomendação aqui é:

  • 1) Se for pra liberar um acesso externo, fora da rede local do servidor, bloqueie esse acesso por IP ou defina uma autenticação nesse endpoint (e isso pode ser feito no próprio Nginx mesmo);
  • 2) Permita apenas acesso local a esse endpoint (que é a opção mostrada nesse artigo);

Definindo a location /stub_status

O bloco server a ser adicionado é:

server {
    listen 1701;
    server_name 127.0.0.1 localhost;

    location /stub_status {
        access_log off;
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

Ou seja, ficaremos na porta 1701 (você pode escolher outra porta se desejar) do localhost escutando pelas requisições ao endpoint stub_status e quando isso acontecer, a diretiva stub_status; é executada e retorna as informações atuais sobre o servidor. A diretiva allow 127.0.0.1; especifica que apenas quem tiver acesso à rede local poderá requisitar esse endpoint.

Reinicie o nginx:

sudo service nginx restart

E então você pode testar se o endpoint está acessível executando:

curl 127.0.0.1:1701/stub_status

A primeira etapa está feita. Agora é hora da gente configurar o Netdata pra ele buscar essas informações desse endpoint que acabamos de definir.

Configurando o Netdata para monitorar o Nginx

Para que o Netdata possa exibir gráficos dessas informações, temos que configurar o coletor do Nginx. Acesse o diretório de configuração:

cd /etc/netdata

E então execute:

sudo ./edit-config python.d/nginx.conf

É nesse arquivo que você vai configurar quais servidores Nginx você está monitorando. É possível monitorar servidores locais ou remotos.

Deverá existir nesse arquivo três diretivas padrões:

localhost:
  name : 'local'
  url  : 'http://localhost/stub_status'

localipv4:
  name : 'local'
  url  : 'http://127.0.0.1/stub_status'

localipv6:
  name : 'local'
  url  : 'http://[::1]/stub_status'

Podemos trocar as três por apenas uma:

localhost:
  name : 'local'
  url  : 'http://localhost:1701/stub_status'

Salve o arquivo e reinicie o Netdata:

sudo service netdata restart

E agora é só acessar a interface do seu Netdata e navegar pelo novo item “nginx local” que ele adicionou:

netdata nginx

Monitorar os logs de acesso do Nginx

Outro coletor disponível no Netdata é o “Web log” que é capaz de monitorar os logs de acesso do Nginx (ou apache) e assim fornecer uma visão bem ampla da quantidade de requisições que estão tendo sucesso/erro, o tipo delas etc:

netdata weblog

Para ativá-lo, acesse o diretório de configuração do Netdata:

cd /etc/netdata/

E então execute:

sudo ./edit-config python.d/web_log.conf

Um exemplo de configuração que pode ser adicionada nesse arquivo:

nginx:
  name: 'nginx'
  path: '/var/log/nginx/access.log'
  categories:
    blog: '^/blog'
    checkout: '^/checkout'

Em path temos o caminho onde o Nginx guarda os logs de acesso. Você pode confirmar isso no arquivo de configuração do Nginx:

sudo nano /etc/nginx/nginx.conf

É preciso que exista uma diretiva assim:

access_log /var/log/nginx/access.log

Esse que é o log de acesso geral de todo o Nginx.

Em categories é onde você pode agrupar essas informações pelo endpoint de acesso. Por exemplo, você notou que está tendo muitas requisições com erro 500, se você tem elas agrupadas no Netdata, você consegue distinguir que a maioria dos erros estão vindo do seu Blog (www.seusite.com/blog), por exemplo. Essa configuração categories é opcional. Você pode simplesmente removê-la.

Salve o arquivo e reinicie o Netdata:

sudo service netdata restart

Pronto. Você está apto a visualizar os logs do Nginx diretamente pelo Netdata.

Até a próxima!

Amazon Web Services (AWS) - Fundamentos
Curso Amazon Web Services (AWS) - Fundamentos
Conhecer o curso

Autor(a) do artigo

Kennedy Tedesco
Kennedy Tedesco

Head de desenvolvimento. Vasta experiência em desenvolvimento Web com foco em PHP. Graduado em Sistemas de Informação. Pós-graduando em Arquitetura de Software Distribuído pela PUC Minas. Zend Certified Engineer (ZCE) e Coffee Addicted Person (CAP). @KennedyTedesco

Todos os artigos

Artigos relacionados Ver todos