Script do Service Monitor para servidores Linux: 4 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:39

Ter um sistema estável e sempre em execução, mesmo se você estiver usando Linux, pode ser uma tarefa difícil.

Devido à complexidade dos pacotes de software modernos e codificação incorreta, inevitavelmente alguns processos podem travar de vez em quando. Isso pode ser ruim se você estiver executando um servidor e algumas pessoas dependerem desses serviços.

Etapa 1: usando métodos fornecidos pelo Systemd

Como você já deve saber, a maioria dos sistemas operacionais Linux modernos usa o systemd.

Se você não está familiarizado com o systemd, isto é, de acordo com a wikipedia:

"… Um sistema init usado em distribuições Linux para inicializar o espaço do usuário e gerenciar todos os processos subsequentemente, em vez dos sistemas init UNIX System V ou Berkeley Software Distribution (BSD).…"

Muitas pessoas ainda estão discutindo por que foi necessário substituir o bom e velho sistema init por este sistema de gerenciamento de processos mais complicado, mas no link a seguir pode-se encontrar uma boa explicação:

www.tecmint.com/systemd-replaces-init-in-l…

A melhoria mais importante seria que ele é capaz de trazer o sistema mais rápido do que o init, devido ao processamento simultâneo e paralelo na inicialização em vez da abordagem sequencial do init

Sem entrar nas profundezas do systemd, para adicionar um processo ao systemd, você deve criar um arquivo de serviço. A sintaxe de tal arquivo pode variar de muito simples a totalmente complicada, e não entraremos em detalhes. Para ter um arquivo.service básico, é suficiente usar as seguintes entradas:

[Unit] Description = Descrição do applicationDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Service] Type = simpleExecStart = / usr / sbin / applicationExecReload = / usr / sbin / application reloadExecStop = / usr / sbin / application stopRestart = always [Install] WantedBy = multi-user.target

Coloque-os no arquivo application.service na pasta / lib / systemd / system.

O que cada uma dessas opções faz é explicado no seguinte link:

access.redhat.com/documentation/en-US/Red_…

Para iniciar seu aplicativo, emita o seguinte comando:

sudo systemctl start application.service

Observação: a extensão.service pode ser omitida.

Para parar o aplicativo:

sudo systemctl stop application.service

Se o arquivo de configuração foi alterado e você gostaria de recarregar as configurações:

sudo systemctl reload application.service

Para reiniciar o aplicativo:

sudo systemctl restart application.service

Para ativar o início automático na inicialização:

sudo systemctl enable application.service

Se estiver ativado, o gerenciador de processo do systemd tentará iniciar o aplicativo com base nas configurações fornecidas pelo arquivo do sistema.

Para desabilitá-lo, use o mesmo comando acima, mas com o parâmetro 'desabilitar'.

Se você colocar Restart = always no arquivo de serviço, o systemd monitorará o processo e, se não puder ser encontrado na lista de processos, tentará reiniciá-lo automaticamente.

Se você colocar

RestartSec = 30

após a diretiva de reinicialização, ele aguardará 30 segundos antes de tentar reiniciar o processo. Isso pode ser útil, pois uma tentativa de reinicialização contínua de um serviço / aplicativo com falha pode levar a uma alta demanda no sistema (gravação de logs de erro, etc)

Como você pode ver, o systemd já fornece alguns meios para monitorar os processos. No entanto, em alguns casos, isso pode não ser suficiente. E se um processo não sair (ainda estará na lista de processos), mas parar de responder. Nesse caso, para ter certeza de que um processo está realmente funcionando, pode ser necessário realizar verificações adicionais.

É aqui que os scripts deste instrutível serão úteis.

Etapa 2: configurar e usar os scripts do Service Checker

Se você precisar de mais controle de seus processos / serviços em execução, esses scripts serão úteis, com certeza.

Como o código é um pouco grande, ele foi enviado ao github e pode ser encontrado no seguinte repositório:

github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh

O 'coração' de todo o pacote é o

checkService.sh

Antes de usá-lo, você deve substituir o caminho completo para a pasta de serviço. Isso pode ser encontrado no início do script.

O script pode monitorar vários processos e realizar tarefas adicionais, conforme descrito a seguir:

Ele percorre cada arquivo da subpasta / services com extensões.serv ou.check e verifica se há um processo ativo chamado 'aplicativo'.

Se não houver um arquivo '.check' para um aplicativo, apenas o arquivo application.serv:

Se o processo estiver ativo, ele o considerará ativo

Se o processo estiver inativo, ele reiniciará o serviço emitindo o seguinte comando:

systemctl reiniciar aplicativo

se o arquivo.serv estiver vazio!

Se o arquivo.serv não estiver vazio e tiver direitos executáveis, ele tentará executá-lo como um script BASH simples.

Isso é útil se algo adicional tiver que ser feito além de apenas reiniciar o serviço.

Por exemplo, no arquivo spamd.serv, do repo acima, caso o serviço spamd esteja inoperante, o serviço spamassassin precisa ser reiniciado, o que também reiniciará o spamd. Reiniciar apenas o spamd não seria suficiente.

Pode-se editar o conteúdo de tal arquivo serv de acordo com as necessidades.

Outro exemplo é o arquivo pcscd.serv. Neste caso, vários outros processos também foram reiniciados / eliminados.

Se houver um arquivo de verificação, após verificar se o processo está em execução, ele também executará esse arquivo de script para realizar verificações adicionais.

Por exemplo, para o serviço oscam, criamos um arquivo de verificação que tenta se conectar à sua interface da web para ver se é bem-sucedido. Caso contrário, então, apesar de ter o processo ativo, o serviço não está respondendo e precisa ser reiniciado. O reinício do serviço deve ser executado / chamado pelo próprio arquivo.check.

Outro exemplo seria o serviço DLNA mediatomb.

Este é um pequeno servidor que fornece conteúdo de vídeo / áudio para clientes DLNA e se transmite na rede. Às vezes, o serviço trava e não é mais detectável, mas o processo ainda estará ativo. Para verificar se o serviço pode ser descoberto, o utilitário CLI chamado gssdp-discover foi usado. Todo o código que verifica o servidor DLNA foi colocado dentro de um script mediatomb.check.

Estes são apenas alguns exemplos de como você pode usar os arquivos.serv e.check.

Para monitorar um novo serviço, você deve criar um.serv e, se necessário, também um arquivo de verificação e escrever o script correspondente dentro deles.

Se apenas a verificação da presença do processo for suficiente, um arquivo.serv vazio será suficiente. Se verificações adicionais devem ser executadas, um arquivo.check deve ser criado e um pequeno script deve ser escrito para fazer o trabalho.

Claro, o script.sh deve ser executado periodicamente, portanto, um cron job também deve ser criado para ele:

#check a execução de serviços a cada 5 minutos * / 5 * * * * /var/bin/ServiceCheck/checkService.sh> / dev / null

Etapa 3: considerações finais

Espero que você ache este pacote útil, pois pode simplesmente monitorar os processos do Linux e, com sorte, minimizar o tempo de inatividade dos seus serviços.

Sinta-se à vontade para fazer upload de scripts adicionais para o github, se você criar novos. Avise-me e adicionarei você como colaborador.