Monitoramento de Servidor: Verificações de CPU, RAM e Disco
O monitoramento de servidor do HostTracker acompanha a carga de CPU, RAM e HDD em tempo real. Ele monitora a carga de CPU, o uso de memória e a carga do HDD, ajudando a otimizar o desempenho do servidor e a experiência do usuário.
Identifique problemas de recursos antes que causem downtime
Acompanhamento de Carga de CPU
O HostTracker monitora o uso de CPU para manter os servidores eficientes e estáveis. Ele acompanha o uso de CPU do seu servidor, identificando problemas e alertando sobre picos incomuns. Monitorar a carga de CPU ajuda os administradores a manter seus servidores funcionando sem problemas e prevenir downtime.
Tendências de Uso de Memória
O HostTracker monitora o uso de memória para ajudar a manter o desempenho do servidor. Esse recurso acompanha o uso de memória e identifica tendências que podem causar lentidão ou travamentos. Relatórios e alertas ajudam os administradores a melhorar o uso de memória. Um bom monitoramento de RAM significa que os aplicativos funcionam bem e não há surpresas causadas por problemas de memória.
Alertas de Espaço em Disco
O monitoramento de HDD do HostTracker previne problemas de armazenamento que afetam o desempenho do servidor. Este serviço acompanha o uso do espaço em disco e alerta os administradores para prevenir problemas como armazenamento insuficiente ou falhas de disco. Monitoramento e relatórios ajudam você a ficar de olho nos problemas de espaço em disco, para que seu servidor sempre tenha espaço suficiente para funcionar sem problemas. Isso ajuda a manter os servidores confiáveis e evita perda de dados por problemas de armazenamento.
Como os números chegam até a HostTracker - sem agente no seu servidor
A maioria dos produtos de monitoramento de servidor pede que você instale um agente: um processo em segundo plano com acesso em nível de sistema que roda permanentemente na sua máquina e transmite dados para fora. A HostTracker deliberadamente não faz isso. É um serviço de monitoramento externo, e uma verificação de carga de servidor funciona ao contrário - o seu servidor expõe um pequeno endpoint somente leitura que reporta um único número, e a HostTracker o consulta no cronograma que você definir.
Essa inversão é todo o design. Não há daemon para manter vivo, nenhum software privilegiado que você não escreveu rodando em produção, nenhuma credencial entregue a terceiros e nenhuma porta de gerenciamento de entrada. O que você expõe é uma URL que não aceita comandos, não muda nada e retorna um único valor.
O coletor em PHP
Um script pronto para um host Linux ou Unix que já roda PHP. Coloque-o em um diretório servido pela web e aponte o monitor para essa URL base. Ele lê localmente os próprios números de CPU, memória e disco da máquina e responde com o número.
O coletor em ASP.NET
O equivalente para Windows, para um host rodando IIS. A mesma ideia, com acesso a qualquer contador de desempenho do Windows por categoria, nome e instância - então tudo que o Performance Monitor pode mostrar localmente pode ser monitorado remotamente.
Seu próprio endpoint
Aponte o monitor para qualquer URL que preferir e responda com um pequeno objeto JSON. Dez linhas em qualquer linguagem, nada no seu servidor que você não tenha escrito, e você decide exatamente quais números são expostos. Essa é a opção que a maioria das equipes de engenharia acaba preferindo.
Nada é enviado à sua máquina. O coletor é implantado por você, quando você escolher, e a HostTracker apenas faz requisições a ele. Se você o remover, o monitoramento para - não há outra forma de entrada.
O que um monitor de servidor pode medir
Cada monitor observa um valor, então um servidor típico acaba com três ou quatro deles - e cada um recebe seu próprio limite, seu próprio histórico e seu próprio alerta. Os tipos de valor são:
| Métrica | Reportado como | Para que serve |
|---|---|---|
| CPU | Percentual de utilização | Saturação sustentada, processos descontrolados, instâncias subdimensionadas, a carga que uma implantação adicionou |
| RAM | Percentual de utilização | Vazamentos de memória, consumo crescente entre reinicializações, a pressão que antecede um encerramento por falta de memória |
| Disco | Percentual de utilização de um caminho ou unidade que você especifica | Logs, uploads e backups enchendo um volume - a queda mais lenta e mais previsível que existe |
| Porta TCP | Tempo de conexão em milissegundos | Se um serviço na máquina ainda está aceitando conexões, e com que rapidez |
| SQL Server | Tempo de conexão em milissegundos | Acessibilidade e autenticação do banco de dados sob o ponto de vista do próprio servidor |
| MySQL | Tempo de conexão em milissegundos | O mesmo, para o MySQL |
| Contador de desempenho do Windows | O que quer que o contador reporte | Tudo que o Performance Monitor expõe, por categoria, nome do contador e instância - tamanhos de fila, handles, números por processo |
Se o que você precisa é o banco de dados por trás do servidor, e não o tempo de conexão dele, isso é uma verificação diferente e mais profunda: um monitor de consultas de banco de dados conecta, autentica, executa uma consulta que você escreve e compara o valor retornado com um limite.
Escrevendo seu próprio coletor
O contrato é deliberadamente trivial, porque a ideia é que você consiga lê-lo de uma vez e implementá-lo em qualquer linguagem que sua equipe já use. A HostTracker faz uma requisição à sua URL; seu endpoint responde com um objeto JSON contendo o valor:
{ "v": 42.7 }Essa é toda a superfície exigida. Dois membros opcionais tornam o resultado mais útil: e
carrega uma string de erro quando o valor não pôde ser lido dessa vez - um resultado muito melhor do que
relatar um zero enganoso - e vs carrega uma string de versão sua, que aparece no resultado
para que você saiba qual build do coletor respondeu.
{ "v": 91.4, "e": "", "vs": "collector-2.1" }Como você mesmo escreve o leitor, você não está limitado ao que um agente genérico sabe coletar. Profundidade da fila, taxa de acerto de cache, número de tarefas aguardando, idade do registro não processado mais antigo, inodes livres, o tamanho de um diretório que nunca pode crescer - qualquer coisa que você consiga expressar como um número se torna um valor monitorado, com limites, histórico e alertas associados.
Proteja o endpoint. Ele precisa ser acessível pelos verificadores que o chamam, então trate-o como qualquer outra URL pública: coloque-o em um caminho não adivinhável, mantenha-o somente leitura e exponha apenas os números que você se sente confortável em deixar ler. Ele não aceita parâmetros que mudem qualquer coisa, o que mantém a exposição a exatamente um valor.
Definindo um limite que realmente signifique algo
Um número bruto é apenas dado; um limite é o que o transforma em monitoramento. Cada monitor carrega uma condição e um ou dois limites, para que você possa expressar a forma de "errado", e não apenas um teto:
- maior que ou menor que um limite - a forma do dia a dia. CPU acima de 90. Disco livre abaixo de 10.
- igual a ou diferente de um limite - para um valor que na verdade é um estado: uma contagem de workers que deve permanecer em 4, uma flag que deve permanecer em 0.
- dentro de um intervalo ou fora de um intervalo, com dois limites - a forma certa para qualquer coisa que tenha uma faixa saudável em vez de um máximo saudável. Uma fila que normalmente fica entre 10 e 500 está dizendo algo quando marca 0, e outra coisa quando marca 5.000.
- nenhuma condição - colete e trace o gráfico do valor sem nunca reprovar a verificação. Útil para uma métrica em que você quer ter histórico antes de saber como é o "ruim".
O debounce é a configuração que interrompe o ruído
Ao lado do limite fica uma contagem de verificações consecutivas em sobrecarga antes de o monitor ser considerado fora do ar, ajustável de zero até vinte. É o controle mais valioso da página e o mais frequentemente deixado no padrão. Um servidor a 95% de CPU em uma única amostra durante um backup noturno não é um incidente. Um servidor a 95% em cinco verificações seguidas é. Ajuste a contagem para corresponder a quanto tempo sua carga de trabalho tem permissão legítima para estar ocupada, e toda uma categoria de alarmes falsos às 3 da manhã desaparece sem que seu limite fique menos rigoroso.
Isso importa mais aqui do que em uma verificação web, porque uma métrica de servidor é lida de uma única fonte autoritativa - o seu próprio coletor - em vez de ser confirmada por vários checkpoints independentes, como acontece em uma verificação de disponibilidade. Não há uma segunda opinião para suavizar um pico momentâneo, então a contagem de debounce é o que desempenha esse papel.
Sobre o que cada métrica avisa
As três métricas principais falham de formas genuinamente diferentes, e saber qual delas você está observando diz quanto tempo você tem.
| Métrica | Como a falha chega | Quanto aviso você recebe |
|---|---|---|
| CPU | Nada quebra. Tudo fica mais lento - cada requisição, cada consulta, cada tarefa em segundo plano - e o site se degrada bem antes de cair de vez. | Geralmente bastante, se você estiver observando. Uma subida sustentada fica visível por horas ou dias antes de se tornar visível para o usuário. |
| RAM | Súbita e violenta. As aplicações são encerradas pelo sistema operacional para recuperar memória, reiniciam e são encerradas de novo - produzindo exatamente a queda intermitente e difícil de reproduzir que é mais difícil de diagnosticar. | Pouco, no final. Mas a subida lenta de um vazamento de memória entre reinicializações é um dos sinais mais legíveis em monitoramento, se o histórico existir. |
| Disco | Tudo de uma vez. Os logs param de gravar, o banco de dados recusa gravações, as sessões falham, arquivos temporários não podem ser criados - e a causa é invisível nas próprias mensagens de erro da aplicação. | O maior aviso de todos, e o mais frequentemente ignorado. Um volume enchendo a uma taxa constante é previsível com dias de antecedência. |
| Tempo de conexão | Uma dependência da qual o servidor depende ficou lenta ou inacessível, antes que isso apareça como uma queda completa. | Muitas vezes o sinal mais antecipado de que algo mais adiante está errado. |
O disco merece sua reputação de ser a clássica queda evitável. É a única falha que um monitor com um limite e uma semana de histórico sempre vai detectar primeiro, e a mais constrangedora de explicar depois.
Leia a tendência, não apenas o alerta
Toda leitura é armazenada, então cada monitor de servidor tem um gráfico do seu próprio valor ao longo do tempo, com a média, o mínimo e o máximo da janela que você está observando. Percentuais são exibidos em gráfico como percentuais, e tempos de conexão em milissegundos, então tanto um monitor de CPU quanto um monitor de latência de banco de dados se leem da forma que você espera.
O alerta diz que algo ultrapassou uma linha; o gráfico mostra as duas coisas que você realmente precisa saber em seguida. Isso é novo? - um pico que parece alarmante isoladamente muitas vezes é o mesmo pico que acontece toda terça-feira às 02h há um ano. E para onde está indo? - um número de memória que sobe de forma constante entre reinicializações é um vazamento, seja qual for o valor atual, e um disco subindo dois por cento por semana tem uma data associada a ele.
Essa segunda pergunta é o uso de planejamento de capacidade do monitoramento de servidor, e é a razão para começar a coletar uma métrica antes mesmo de saber qual limite aplicar a ela. Você pode adicionar o limite daqui a um mês, assim que o histórico tiver mostrado como é o normal. O histórico que você não coletou é aquele que você não consegue recuperar.
Monitoramento de servidor e monitoramento de uptime respondem a perguntas diferentes
Eles são complementares, não alternativas, e a divisão é clara o suficiente para valer a pena declarar diretamente.
| Monitoramento de uptime | Monitoramento de servidor | |
|---|---|---|
| A pergunta que responde | Um visitante consegue acessar o site agora? | A máquina por trás dele está saudável o suficiente para continuar respondendo? |
| De onde observa | De fora - mais de 300 checkpoints em 158 cidades | De dentro - um valor lido na própria máquina |
| Momento típico | Avisa no momento da falha | Avisa antes da falha, se você definir o limite antes do precipício |
| Controle de alarme falso | Uma observação de falha é reverificada a partir de outros checkpoints e confirmada por um quórum | Uma única leitura autoritativa, com uma contagem de sobrecargas consecutivas como debounce |
| Detecta um vazamento de memória | Não - até que finalmente derrube algo | Sim - como uma tendência, semanas antes |
| Detecta uma falha de rota de rede entre seus usuários e você | Sim | Não - a máquina está perfeitamente bem |
Usar apenas um deles deixa uma lacuna real em cada direção. A combinação que a maioria das contas adota é uma verificação de disponibilidade de um minuto a partir de vários locais mais alguns monitores de servidor para CPU, memória e o volume com mais chance de encher.
SNMP, para hardware que nunca vai rodar um coletor
Roteadores, switches, firewalls, nobreaks e impressoras não conseguem hospedar um script, mas quase todos já falam SNMP. Uma verificação SNMP separada lê um valor numérico diretamente do dispositivo por OID - contadores de interface, temperatura, carga, uptime, carga da bateria - via SNMP v1, v2c ou v3, incluindo v3 com autenticação e privacidade, para que as credenciais não sejam enviadas em texto simples.
Para ser direto sobre onde isso está hoje: uma verificação SNMP lê e registra o valor que o dispositivo reporta. O alerta baseado em limite sobre um valor SNMP ainda não está disponível - quando você precisa que um número realmente abra um incidente, use um monitor de carga de servidor contra um coletor, que tem o modelo completo de condição e debounce descrito acima.
Configurando o monitoramento de servidor
- Decida o que expor. Se o seu servidor já roda PHP ou IIS, o coletor pronto correspondente é o caminho mais rápido; caso contrário, escreva o endpoint você mesmo - ele retorna um número.
- Implante-o no servidor que você quer observar e confirme que você mesmo consegue fazer a requisição. Coloque-o em um caminho não adivinhável. Se a máquina for nova, a verificação gratuita de porta TCP e o teste de ping gratuito são uma forma rápida de confirmar que ela é acessível de fora antes de você avançar - sem necessidade de login.
- Adicione um monitor do tipo Monitorar CPU, RAM, HDD, escolha qual valor ele lê e informe a URL do coletor. Para um monitor de disco, indique o caminho ou a unidade; para um monitor de tempo de conexão de banco de dados, informe os detalhes de conexão que o coletor deve discar.
- Defina a condição e os limites - e defina a contagem de sobrecargas antes de cair deliberadamente, em vez de deixá-la no padrão. Essa é a configuração que decide se o monitor é útil ou ignorado.
- Escolha um intervalo, de um minuto a 24 horas. Um minuto é adequado para uma máquina que roda algo crítico para o negócio; 5 ou 10 minutos são suficientes para uma tendência como o uso de disco.
- Repita para cada valor que importa naquele host - CPU, memória e o volume com mais chance de encher são um conjunto inicial sensato - depois adicione os contatos que devem ser avisados.
- Deixe passar uma semana antes de ajustar qualquer coisa. A primeira semana de histórico é o que mostra se o seu limite está certo, e é uma evidência muito melhor do que um palpite feito no primeiro dia.
Limites que vale a pena conhecer
- O coletor precisa ser acessível. Um host sem nenhum acesso de entrada não pode ser consultado. O que precisa ser exposto é uma URL somente leitura, não uma porta de gerenciamento - mas ela precisa mesmo ser exposta.
- Um monitor observa um valor. CPU, memória e disco são três monitores, cada um com seu próprio limite e seu próprio histórico. É isso que torna o alerta preciso, e isso significa que um servidor movimentado usa várias vagas de monitor.
- Contadores de desempenho do Windows precisam do coletor ASP.NET. O trio categoria / nome / instância é lido localmente por esse coletor; um host PHP reporta CPU, memória, disco e tempos de conexão em vez disso.
- Não há confirmação multi-localização. Diferente de uma verificação de disponibilidade, uma métrica de servidor vem de uma única fonte autoritativa, então uma única leitura anômala é uma leitura real. A contagem de sobrecargas consecutivas é a ferramenta para isso, e vale a pena configurá-la.
- Ele reporta o que o coletor reporta. Se o seu endpoint personalizado tiver um bug, o monitor alerta fielmente sobre o número errado - por isso o membro opcional de erro na resposta importa: relate um erro em vez de um zero.
- Sem contador de throughput de rede. Os valores disponíveis são CPU, memória, uso de disco, tempos de conexão e contadores de desempenho do Windows; a largura de banda não está entre eles. Para um dispositivo que reporta throughput via SNMP, uma verificação SNMP pode ler e traçar o gráfico desse contador.
Perguntas Frequentes
O monitoramento de servidor é o acompanhamento contínuo do uso dos principais recursos do seu servidor - carga de CPU, uso de RAM (memória) e carga do HDD (disco) - para que você veja como sua infraestrutura está realmente performando, e não apenas se o site em cima dela responde. O monitoramento de servidor da HostTracker verifica essas três métricas e reporta tendências e picos ao longo do tempo, o que importa porque o esgotamento de recursos é uma das causas raiz mais comuns por trás de desempenho lento, travamentos e downtime. Um servidor pode estar tecnicamente "no ar" e ainda assim estar a instantes de falhar se o uso de CPU está no limite, a memória está quase esgotada ou o espaço em disco está criticamente baixo - nada disso uma simples verificação de disponibilidade necessariamente revelaria até o problema realmente causar uma queda visível.
Um servidor pode continuar acessível e tecnicamente online enquanto opera perigosamente perto de seus limites de recursos, o que significa que o alto uso de CPU ou RAM costuma ser um sinal de alerta precoce em vez do próprio problema. A carga de CPU alta e sustentada deixa mais lenta cada requisição que o servidor processa, degradando a experiência de todos os visitantes mesmo que o site nunca caia completamente. A pressão de memória é ainda mais perigosa - conforme o uso de RAM se aproxima da capacidade, aplicações podem começar a travar, reiniciar ou ser encerradas pelo sistema operacional para liberar memória, o que frequentemente causa quedas intermitentes e difíceis de diagnosticar, que parecem falhas aleatórias em vez de uma falha clara. Detectar o aumento no uso de CPU ou RAM pelo monitoramento de servidor, antes que ele evolua para um travamento, dá tempo aos administradores para investigar e adicionar capacidade de forma proativa.
Quando o monitoramento de CPU, RAM ou carga de disco detecta atividade incomum - um pico sustentado, memória subindo em direção à capacidade máxima ou espaço em disco ficando baixo - o HostTracker envia uma notificação por qualquer um dos seus 9 canais de alerta configurados, incluindo e-mail, SMS, chamada de voz, webhook, Slack e os aplicativos de mensagens Telegram, Discord e Viber. Isso significa que o responsável pela infraestrutura do servidor fica sabendo diretamente sobre um problema de recursos em desenvolvimento, em vez de descobri-lo só depois que ele já causou uma lentidão ou travamento perceptível pelos clientes. Como relatórios e alertas são gerados automaticamente a partir dos dados monitorados, os administradores obtêm um histórico documentado das tendências de recursos junto com a notificação em tempo real, o que ajuda a distinguir um pico isolado de um problema de capacidade real que precisa de uma solução de longo prazo.
O monitoramento de uptime responde a uma pergunta mais restrita: o site ou serviço está acessível e respondendo agora. O monitoramento de servidor olha por baixo dessa superfície, para a infraestrutura que realmente executa o site - carga de CPU, uso de memória e espaço em disco - que frequentemente são a causa raiz por trás de uma falha de uptime, e não uma questão separada e não relacionada. Um servidor com pouca memória ou espaço em disco ainda pode passar em uma verificação de uptime por um tempo antes de finalmente travar ou ficar extremamente lento, então depender só do monitoramento de uptime significa descobrir o problema apenas depois que ele já virou uma queda. Combinar os dois dá um quadro mais completo: o monitoramento de uptime confirma que o site está acessível agora, enquanto o monitoramento de servidor acompanha as tendências de recursos subjacentes que preveem se ele vai continuar assim.
A frequência de verificação é configurável para acompanhar a rapidez com que você precisa saber sobre um problema de recursos em desenvolvimento. Os planos pagos do HostTracker suportam intervalos de monitoramento tão rápidos quanto uma vez por minuto, o que é útil para servidores que executam aplicações críticas para o negócio, onde um pico de recurso precisa ser detectado e resolvido rapidamente. Servidores menos críticos ou com tráfego menor podem usar um intervalo mais longo, e o plano gratuito permanente verifica dois monitores a cada 30 minutos, o que geralmente é suficiente para detectar uma tendência sustentada, como o espaço em disco enchendo gradualmente ao longo de dias, mesmo que não detecte um pico de CPU muito breve. Um teste gratuito de 30 dias com todos os recursos, sem necessidade de cartão de crédito, permite experimentar intervalos de verificação mais rápidos e ver quanto detalhe os dados resultantes oferecem antes de escolher um plano.
Não - não existe um agente da HostTracker para instalar, nenhum daemon para manter rodando e nenhuma credencial para entregar. Uma verificação de carga de servidor funciona ao contrário: o seu servidor expõe um pequeno endpoint somente leitura que reporta um único número, e a HostTracker o consulta no cronograma que você definir. Você tem três formas de fornecê-lo. Duas são scripts coletores prontos que você coloca em um servidor que já roda - um para PHP em Linux ou Unix, outro para ASP.NET no IIS - e a terceira é escrever o endpoint você mesmo, o que leva cerca de dez linhas em qualquer linguagem: leia o valor da forma que preferir e responda com um pequeno objeto JSON contendo-o. Essa terceira opção é a que muitas equipes preferem, porque significa que nada que elas não escreveram roda na própria máquina, e elas decidem exatamente quais números são expostos. Nada é enviado automaticamente ao seu servidor, e a HostTracker nunca abre uma sessão de gerenciamento nele.
O endpoint do coletor precisa ser acessível pelos verificadores da HostTracker, então um servidor atrás de um firewall sem nenhum acesso de entrada não pode ser consultado diretamente. Na prática, isso é um obstáculo menor do que parece, porque o que precisa ser exposto é uma única URL somente leitura que retorna um número - não SSH, não uma porta de gerenciamento, não um protocolo de monitoramento. As abordagens usuais são publicar o endpoint em um caminho não adivinhável, restringi-lo aos endereços que o chamam, ou hospedá-lo em uma máquina na mesma rede que já está exposta à internet e fazer com que ela reporte em nome do host privado. Seja qual for a escolha, a exposição é deliberadamente mínima: o endpoint não aceita comandos, não muda nada e retorna um único número. Essa é uma conversa de segurança muito diferente de instalar um agente de terceiros com acesso em nível de sistema, e é exatamente por isso que a verificação foi projetada dessa forma.
O monitoramento de carga de servidor - verificações de CPU, RAM e HDD - é um dos 13 tipos de verificação disponíveis no produto HostTracker, e o plano gratuito permanente permite monitorar dois servidores ou sites sem custo, com verificações a cada 30 minutos. O HostTracker como um todo não é um produto só gratuito - é um serviço de monitoramento pago com um nível gratuito junto - então o plano gratuito funciona bem para testar o monitoramento de servidor em algumas máquinas ou como opção leve para projetos menores, não como a oferta principal. Para monitorar mais servidores, intervalos de verificação mais curtos ou infraestrutura crítica para o negócio onde a detecção mais rápida importa, os planos pagos começam em cerca de US$ 5 por mês, e um teste gratuito de 30 dias com todos os recursos, sem necessidade de cartão de crédito, permite testar os intervalos mais rápidos antes de decidir.
Continue explorando o monitoramento da HostTracker
Monitore conexões de banco de dados e resultados de consultas
Execute verificações periódicas de conexão e valide os resultados de consultas em MySQL, PostgreSQL, SQL Server e mais, para que um problema silencioso no banco de dados nunca passe despercebido.
Conheça todos os recursos de monitoramento da HostTracker
Veja os 8 tipos de monitoramento lado a lado e combine as verificações que se encaixam no seu site.
Detecte a sobrecarga do servidor antes que ela te derrube
Comece um teste grátis e seja alertado quando a carga de CPU, RAM, disco ou rede ultrapassar seus limites.
Faz parte do serviço de monitoramento de sites da HostTracker.