Tuning zabbix: Qual é o número de processos considerados razoáveis em um servidor?

Question

Sim, estou começando a entender (e amando) o zabbix e iniciei o processo de ajuste fino do alerts .

Eu tenho este alerta que é acionado em um servidor linux por ter mais de 300 processos.

Agora, este é um tipo de servidor central que atua como um firewall e executa um monte de coisas .. ou seja, proxy / httpd-servidor / mysql / open-vpn / zabbix

Existe algo a procurar antes de eu abrir o gatilho de alerta para 350 processos?

A carga da CPU ainda é relativamente baixa, eu estava pensando que talvez alguém verificaria outras coisas antes de aumentar os alertas.

Eu precisaria verificar se a máquina está com o gargalo da garrafa?

Qualquer bom conselho para esta ou boa documentação (esperançosamente bem escrita e fácil de entender), como sempre, seria muito apreciado.

    

Answer 1

Como @sam disse, tudo depende do que o servidor está fazendo e de quão pesado é o hardware do servidor. A execução de apenas um punhado de processos intensivos de CPU, memória e / ou CPU extremamente pesados pode facilmente sobrecarregar até mesmo um servidor poderoso. Especialmente se algo fizer com que o seu servidor troque, tudo estará avançando mais devagar que um caracol ou uma tartaruga.

Por outro lado, algo como o servidor Postfix pode facilmente ter o processo contado em centenas ou milhares, já que tudo o que o Postfix faz é muito leve.

Na minha opinião, monitorar (ou pelo menos alertar por causa disso) a contagem global de processos não é útil. No entanto, se você tiver certeza de que não deve haver mais de X instâncias de algum processo, monitore isso e crie um alerta em caso de haver mais de X partes delas em torno.

Você também pode representar graficamente a quantidade de alguns processos para tendências: por exemplo, tenho a tendência de representar graficamente a contagem de processos do Cyrus IMAP / POP para que eu possa ver se eles estão próximos dos limites atuais.

Se você tem alguns comportamentos de processo previsíveis, você pode usar algo como psmon para reiniciar / matar automaticamente (com registro opcional / e-mail para informações sobre eventos que manipularam processos mal comportados. Claro, o Zabbix pode ser usado para isso também, mas o psmon é muito fácil de configurar para esse tipo de tarefa.

O que eu graficaria e monitoraria

Em geral, graph (e monitore) pelo menos o seguinte:

• média de carregamento
• uso de memória
• uso de disco
• uso da CPU
• quantidade de tráfego de rede
• quantidade de alguns processos individuais, se você precisar
• tempos de resposta para seus serviços
• uptime do servidor (pode ser um gráfico muito útil; se algum servidor começar a se comportar mal e precisar ser reinicializado com frequência, é fácil identificar os gráficos no momento em que os problemas começaram)

Em seguida, monitore pelo menos o seguinte:

• são os processos que devem estar respondendo corretamente; na minha opinião, apenas testando se a porta está ativa ou se o processo está presente, se não for suficiente. Em vez disso, se você quiser verificar se o servidor da Web está em execução, veja se ele retorna HTTP 200 OK e, de preferência, veja se a página de teste contém algumas strings esperadas.
• ping do servidor. Se o ping falhar, avise imediatamente.
• logs do kernel para coisas graves, como erros de E / S, caminhos com falha na configuração do multipath do ambiente SAN, panes do kernel, eventos do OOM e assim por diante

Espero que isso ajude você. :)

    

Answer 2

Acho muito difícil responder isso sem mais informações, mas vou tentar.

Depende;

Ter cinco threads FFMPEG processando vídeo HD em um servidor de núcleo único seria muito, mas provavelmente seria muito fácil rodar centenas, até mesmo milhares, de scripts Python de 5 linhas sem problemas. Em geral, monitore tudo o que você puder imaginar! Se ele gerar um número, monitorar e registrar, você nunca saberá quais estatísticas você pode precisar no final da linha. Número de processos é provavelmente, por si só, uma medida ruim de desempenho, é útil em conjunto com outras informações, digamos que, se o servidor tivesse acabado de descer, é útil examinar procs em execução, CPU / carga, memória, disco IO etc. mas eu provavelmente diria, a menos que você possa determinar exatamente quanto de CPU / memória / etc. cada processo usa isso não é tão útil.

Digamos que você tenha um aplicativo previsível, cada usuário inicie uma proc no servidor e cada proc use 10MB de memória, 1% do uso de CPU disponível e 1% do IO de disco disponível continuamente pela duração da proc. corrida. Suponha que o uso base do sistema seja constantemente 3% de CPU e 500MB de memória e nenhum outro processo será iniciado na caixa além do seu aplicativo. A partir disso, é muito fácil prever quantos segmentos você pode executar antes de receber problemas, mas acho que nunca vi um aplicativo com um uso tão preciso.

Uma estratégia muito melhor seria monitorar os recursos usados por um processo / processos em particular, digamos, se você estiver executando um servidor Apache com mod_php, monitorar a memória média, CPU e IO de disco dos processos httpd , lhe dará uma visão muito melhor sobre o que seu servidor está realmente fazendo. Alerta sobre o uso do processo não é tão útil, o monitoramento é. Há muitas coisas que podem forçar o processo a contar sem ter qualquer efeito no sistema, mas um único processo poderia derrubar um servidor.

TL; DR

• A contagem de processos não é útil para um alerta
• Você ainda deve estar fazendo login
• Descubra o que seu servidor está fazendo e monitore o que é relevante para ele