Então, você é um administrador de sistemas ou é DevOps? Aposto que adora passar seus dias colado na tela, caçando métricas de desempenho nos seus servidores. Coisa emocionante, não é?
Às vezes, as máquinas simplesmente decidem tirar uma soneca, rodando mais devagar que uma lesma, e claro, elas não deixam pistas sobre o que está errado. Super útil!
E quem nunca foi bloqueado de executar comandos remotos como top ou htop em máquinas que não respondem? É o auge da produtividade. Basta sentar e curtir enquanto você não consegue nem olhar o que está errado. Ah, e não vamos esquecer aquelas lentidões surpresas. Estão sempre à espreita, mas identificá-los de uma maneira rápida e simples? Ha! Boa sorte!
Mas e se, nesse mundo de constantes surpresas, tivéssemos um painel completo que realmente ajudasse a rastrear o desempenho geral e os processos individuais?
O objetivo deste tutorial é criar um painel de monitoramento que talvez salve o administrador de sistemas de arrancar os cabelos.
Índice
- O que você vai aprender
- Noções Básicas de Monitoramento de Processos Unix
- Detalhamento da Nossa Arquitetura de Monitoramento
-
Instalando as Diferentes Ferramentas
- Instalando Pushgateway
- Instalando Prometheus
- Instalando Grafana
Construindo um Script Bash para Recuperar Métricas
-
Construindo um Painel Incrível com Grafana
- Construindo Medidores Arredondados
- Construindo Medidores Horizontais
- Construindo Medidores Verticais
- Construindo Gráficos de Linha
Uma Palavra Rápida para Concluir
O Que Você Vai Aprender
Antes de mergulharmos de cabeça neste mundo maravilhoso da tecnologia, vamos dar uma olhada no que este artigo vai iluminar para você:
- Compreender as formas de monitorar o desempenho de processos em sistemas Unix.
- Instalar as novas versões brilhantes do Prometheus v2.9.2, Pushgateway v0.8.0 e Grafana v11
- Construir um script bash simples que magicamente exporta métricas para o Pushgateway.
- Criar um painel completo no Grafana com todos os recursos como os painéis ‘Gauge’ e ‘Bar Gauge’.
.
Noções Básicas de Monitoramento de Processos Unix
Quando se trata de monitorar processos em sistemas Unix, você está com sorte. A opção mais popular é ‘top’.
O comando top te dá métricas de desempenho como uso de CPU e memória, junto com métricas de processos individuais. É a ferramenta preferida dos administradores de sistemas para detectar gargalos de desempenho.
Depois tem o htop, o primo colorido do top, que exibe as mesmas métricas mas com um pouco mais de brilho.
Mas por que construir outra ferramenta de monitoramento de processos? Ótima pergunta! A principal razão é a disponibilidade do sistema: durante uma sobrecarga do sistema, top e htop são tão úteis quanto uma chaleira de chocolate.
Ao externalizar o monitoramento de processos, você pode analisar a raiz do problema sem nunca acessar a máquina. Quem precisa de acesso direto quando você tem um painel de monitoramento que pode magicamente voltar no tempo para mostrar qual processo foi o culpado?
Agora você sabe o básico de monitoramento de processos.
Detalhamento da Arquitetura
Antes de nos perdermos nos detalhes, vamos olhar a arquitetura que vamos usar.
Ela é projetada para ser:
Eficiente em termos de recursos: Para não consumir todos os seus recursos preciosos.
Simples de implantar: Porque você não tem nada além de tempo, certo?
Escalável: Para quando monitorar um servidor não for desafio suficiente.
Nossa arquitetura inclui:
- Um script bash que envia métricas para o Pushgateway.
- Pushgateway: Um cache de métricas para os dados do nosso script bash.
- Prometheus: O banco de dados de séries temporais que coleta e armazena essas métricas.
- Grafana: A ferramenta de painel que visualiza essas métricas, tornando sua vida mais fácil.
Para aqueles que conhecem o Prometheus, vocês sabem que ele coleta dados via HTTP para reunir métricas. Nosso script bash, no entanto, não expõe nenhuma porta HTTP, então precisamos do Pushgateway para preencher essa lacuna.
Instalando as Ferramentas
Agora, vamos à parte divertida: instalar todas essas ferramentas.
Instalando Pushgateway
Execute, no terminal, o comando wget para baixar os binários mais recentes.
No linux, o download pode ser feito no diretório home
wget https://github.com/prometheus/pushgateway/releases/download/v0.8.0/pushgateway-0.8.0.linux-amd64.tar.gz
Extraia o arquivo, execute o script e voilà!
tar xvzf pushgateway-0.8.0.linux-amd64.tar.gz
cd pushgateway-0.8.0.linux-amd64/
./pushgateway
Seu Pushgateway deve iniciar como um processo em segundo plano, escutando na porta 9091.
Instalando Prometheus
Vá para a página de download do Prometheus(https://prometheus.io/download/), pegue o arquivo, extraia-o e acesse o diretório.
wget https://github.com/prometheus/prometheus/releases/download/v2.45.6/prometheus-2.45.6.linux-amd64.tar.gz
tar xvzf prometheus-2.45.6.linux-amd64.tar.gz
cd prometheus-2.45.6.linux-amd64/
Modifique o arquivo de configuração para incluir nossos alvos
vi prometheus.yaml
Ex:
# my global config
global:
scrape_interval: 1s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: "prometheus"
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ["localhost:9090", "localhost:9091"]
Execute o Prometheus.
./prometheus
Se você ver o console web em http://localhost:9090/graph, parabéns, você não quebrou nada.
Instalando o Grafana
Baixe o pacote do Grafana, instale-o e certifique-se de que está rodando como um serviço.
wget https://dl.grafana.com/enterprise/release/grafana-enterpise_11.0.0_amd64.deb
sudo dpkg -i grafana-enterprise_11.0.0_amd64.deb
Verificar se o grafana está executando:
sudo systemctl status grafana-server.service
Pode verificar acessando http://localhost:3000.
Agora que temos que configurar o Prometheus como uma fonte de dados, e pronto.
Construindo um Script Bash para Recuperar Métricas
Em seguida, construiremos um script bash para buscar métricas como uso de CPU e memória para processos individuais. Este script será executado a cada segundo e enviará os dados para o Pushgateway. Estamos usando o comando ps aux em vez de top.
> touch script_cpu_memory
> chmod u+x script_cpu_memory
> vi script_cpu_memory
script:
Execute o script
while sleep 1; do ./script_cpu_memory; done;
Agora que nossas métricas foram enviadas para o Pushgateway, vamos ver se podemos explorá-las no Prometheus.
Vá para http://localhost:9090. No campo ‘Expression’, simplesmente digite ‘cpu_usage’. Agora você deve ver todas as métricas no seu navegador.
Parabéns! Suas métricas de CPU agora estão armazenadas no Prometheus.
Construindo um Painel Incrível com Grafana
Com nossas métricas armazenadas com segurança no Prometheus, é hora de construir um painel no Grafana para visualizá-las. Usaremos os painéis mais recentes disponíveis no Grafana: medidores arredondados, medidores horizontais, medidores verticais e gráficos de linha clássicos.
Medidores Arredondados: Para uso geral de CPU no momento e uso médio de CPU.
Medidores Horizontais: Para exibir os 10 processos que mais consomem recursos.
Medidores Verticais: Semelhantes aos medidores horizontais, mas com uma reviravolta vertical, monitorando o uso de memória.
Gráficos de Linha: Para rastrear o desempenho histórico dos processos.
1 – Construindo Medidores Arredondados
Aqui está uma visão mais detalhada de como são os medidores arredondados em nosso painel.
Por enquanto, vamos nos concentrar no uso da CPU dos nossos processos, pois isso pode ser facilmente espelhado para o uso de memória.
Com esses painéis, vamos rastrear duas métricas: o uso atual da CPU de todos os nossos processos e o uso médio da CPU.
Para recuperar essas métricas, vamos realizar consultas PromQL em nossa instância do Prometheus.
Então... o que é PromQL?
PromQL é a linguagem de consulta projetada para o Prometheus.
Da mesma forma que você encontra nas instâncias do InfluxDB com o InfluxQL (ou IFQL), as consultas PromQL podem agregar dados usando funções como soma, média e desvio padrão.
A sintaxe é muito fácil de usar, como vamos demonstrar com nossos painéis.
A - o uso atual do Processdor(CPU)
Para recuperar o uso geral atual do processador, vamos usar a função sum do PromQL.
O nosso uso geral do processador é simplesmente a soma dos processos.
B - o use médio do processador
Não há muito trabalho para fazer em relação ao uso médio da CPU, você simplesmente vai usar a função avg do PromQL.
2 – Construindo Medidores Horizontais
Nosso objetivo com este painel é expor os 10 processos que mais consomem recursos do nosso sistema.
Para isso, vamos usar a função topk que recupera os k principais elementos de uma métrica.
Da mesma forma que fizemos antes, vamos definir limites para sermos informados quando um processo estiver consumindo muitos recursos.
3 – Construindo Gráficos de Linha
Gráficos de linha estão presentes no Grafana há muito tempo e este é o painel que vamos usar para ter uma visão histórica de como nossos processos evoluíram ao longo do tempo.
Este gráfico pode ser particularmente útil quando:
Você teve alguma interrupção no passado e gostaria de investigar quais processos estavam ativos na época.
Um determinado processo morreu, mas você quer ter uma visão de seu comportamento logo antes de isso acontecer.
Quando se trata de exploração e resolução de problemas, isso honestamente precisaria de um artigo inteiro.
A partir daqui, temos todos os painéis que precisamos para o nosso painel final.
Você pode organizá-los da maneira que quiser ou simplesmente se inspirar no que construímos.
Você acabou de construir um dashboard para monitoramento de processos com Grafana.
Uma Conclusão Rápida
Parabéns! Agora você tem um painel de monitoramento completo para uma única instância. Escalá-lo para monitorar um cluster inteiro de instâncias Unix? Apenas um pequeno passo. O monitoramento DevOps é fascinante—até que se torne um pesadelo. Mas ei, é por isso que construímos esses painéis: para ajudá-lo a alcançar a máxima eficiência com essas ferramentas. Porque quem não ama espremer cada gota de produtividade das ferramentas utilizadas?
Top comments (1)
Awesome post!