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
.
Curso Amazon Web Services (AWS) - EC2 - Fundamentos
Conhecer o cursoA 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:
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:
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!