Como definir o monitoramento adequado dos meus serviços de maneira automatizada? De modo que se um bater automaticamente no reinício da mosca?

Question

Como posso configurar o monitoramento para os serviços do meu sistema? Usando scripts automatizados que escaneiam todos os momentos, se httpd, mysqld, and my custom daemon estiver em execução ou não, se não estiver sendo executado, reiniciará automaticamente?

Alguma ideia?

Por exemplo:

*Day 1:* System is running in Rail way where no support can be 24/7 available, Day 1 was fine. 
*Day 2:* System in the middle of the Rail way crashed cause httpd and mysqld for some reason not running the service

Como pode ser automatizado para que o service httpd permaneça em execução e o service mysqld permaneça em execução?

    

Answer 1

Existem várias ferramentas para fazer isso (das quais, além de daemontools e perp, eu não tenho muita experiência):

• daemontools é mais ou menos a implementação "clássica" que gerou a maioria das outras implementações modernas
• supervisord
• minit
• s6
• runit

O que temos vindo a gostar no meu local de trabalho é perp , que foi o melhor destaque para a nossa infra-estrutura. Algumas dessas ferramentas só fazem o que você quer como um subconjunto de sua funcionalidade total, então elas podem não ser adequadas para o seu caso de uso.

    

Answer 2

Além do que Chris Down escreveu, eu também recomendaria monit . Ele pode notavelmente verificar se uma porta está aberta (por exemplo, 80) e reiniciar o serviço apropriado (por exemplo, httpd) se essa porta estiver fechada. Veja este exemplo para sshd:

check process sshd with pidfile /var/run/sshd.pid
start program  "/etc/init.d/sshd start"
stop program  "/etc/init.d/sshd stop"
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout

O Monit usa uma abordagem diferente do perp ou daemontools: ele não apenas garante que um processo está em execução, mas verifica se uma porta está aberta ou se existe um arquivo (pode ser um soquete UNIX). Pode ser mais fácil de configurar e um pouco menos intrusivo (você não precisa se certificar de que o monit interage adequadamente com o seu sistema init) do que os daemontools ou perp. Também pode ser configurado para enviar e-mails se falhar constantemente em reiniciar um serviço.

    

Answer 3

Como mencionado em outras respostas, os daemontools de Dan Bernstein começaram uma família inteira de conjuntos de ferramentas que compartilham os mesmos mecanismos brutos:

• freedt de Adam Sampson
daemontools-encore de Bruce Guenter
• s6
de Laurent Bercot
• Meu nosh
• runit de Gerrit Pape
• perp de Wayne Marshall

Em praticamente qualquer um deles, um grava um programa run que executa / é o daemon, e um gerenciador de serviços ou processo de supervisor simplesmente o monitora como um processo filho bifurcado usando o mecanismo Unix e Linux normal. Para o Apache e o MySQL, você está pisando onde um lote de pessoas já trilhou antes, e há muitos exemplos de como executar esses servidores sob o gerenciamento de serviço da família daemontools. Aqui estão apenas alguns:

• Kevin J. DeGraaf. Monitoramento de serviço com daemontools .
• Apache httpd . exemplos de serviços daemontools . Lógica de Cola. 2004.
• MySQL sob daemontools Outubro de 2011.
• Apache sob daemontools . Setembro de 2011.
• Gerrit Pape. "apache" . Uma coleção de scripts de execução .
• Gerrit Pape. "mysql" . Uma coleção de scripts de execução .

Chris Down sugere que os conjuntos de ferramentas maiores podem ser inadequados. Este não é realmente o caso. Embora todos esses conjuntos de ferramentas sejam coerentes e autoconsistentes, nenhum deles exige que se use qualquer uma das ferramentas além daquelas necessárias em qualquer situação específica. Pode-se também misturar e combinar. Pode-se usar execlineb de Laurent Bercot e todos os seus utilitários sob perp, ou meu intérprete de script nosh e todos os seus utilitários em runit; assim como alguém pode igualmente usar chpst de Gerrit Pape no meu service-manager .

Igualmente, você pode executar o Apache e o MySQL a partir do systemd (se você for somente Linux) ou launchd (se você estiver usando o MacOS 10). Um arquivo de configuração launchd é bastante complexo e complicado, em comparação com os outros sistemas mencionados. Os arquivos da unidade systemd, no entanto, estão na mesma ordem de simplicidade que run scripts:

• Jonathan de Boyne Pollard (2014). Uma análise lado a lado dos scripts e serviços de execução unidades. . Respostas frequentemente dadas.

Existem algumas poucas unidades de serviçomysqld.service e httpd.service fabricadas em casa na World Wide Web, em várias coleções de unidades de serviço domésticas.

Todos eles fornecem o substrato básico de iniciar um daemon no bootstrap, parando e iniciando-o sob controle administrador / automatizado enquanto o sistema está rodando, e automaticamente reiniciando-o em vários casos de falha. Xion345 comete o erro de confundir isso com monit. Como você pode ver na resposta xyr, o substrato lá para monitoramento e controle é o sistema do daemon 5 rc . Poderia igualmente ter sido systemd ou nosh. (Na verdade, se o exemplo do Xion345 tivesse usado o comando service em vez de tentar executar scripts init.d diretamente, o que não é uma boa ideia para isso e várias outras razões, ele teria funcionado praticamente como está com o systemd , upstart ou nosh.)

Onde monit pertence é na camada acima . monit usa o substrato start / stop / supervision, e monitora o serviço real fornecido , o qual faz além para supervisionar o processo daemon com um supervisor do daemon. Nesta camada encontra-se ferramentas relacionadas, como nagios. (Pode-se facilmente facilmente nagios em um daemon monitorado pela família do daemontools, e fazer com que ele verifique o estado do processo e uptimes via daemontools API. Meu conjunto de ferramentas vem com um plug-in nagios básico para fazer isso.)

    

Answer 4

Puppet permite que você defina quais serviços devem ser executados em seu sistema.

Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to patch management and compliance. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud.

Por exemplo:

service { 'apache2':
    ensure => running,
    enable => true,
    require => Package['apache2'],
    subscribe => File['/etc/apache2/httpd.conf'],
}

Esta configuração (chamada de manifesto no contexto do Puppet) garante que o serviço apache2 esteja em execução, iniciado no momento da inicialização, que não tente gerenciar o serviço, a menos que o pacote apache2 esteja instalado e que seja reiniciado se /etc/apache2/httpd.conf for alterado.

Com o Puppet, você pode não apenas gerenciar os processos de serviço, mas também suas dependências e arquivos de configuração.

    

Answer 5

Há também Deus .

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

Escreva um servidor simples, simple.rb :

loop do
  puts 'Hello'
  sleep 1
end

Agora crie um script, simple.god , que assiste ao daemon:

God.watch do |w|
  w.name = "simple"
  w.start = "ruby /full/path/to/simple.rb"
  w.keepalive
end

Agora, inicie o script de monitoramento:

god -c path/to/simple.god -D

Deus pode assistir a mais do que apenas aplicativos Ruby, pode assistir ao seu httpd ou mysqld e chamar o script /etc/init./d/... correspondente conforme necessário.