Como verificar se o cliente rsyslog remoto está em execução

Question

No momento, estou implementando a parte do sistema de monitoramento que é construída em torno do rsyslog e auditd. Eu gostaria de incluir no projeto uma verificação correta do fato de que o recurso remoto do cliente rsyslog está sendo executado . Essa verificação deve ser repetida no servidor rsyslog em intervalos de tempo curtos.

A maneira mais simples de fazer isso é rastrear os registros de data e hora das últimas modificações no arquivo de log. Se o arquivo de log (qual é usado pelo servidor rsyslog para redirecionar as mensagens recebidas) não tiver sido modificado recentemente, podemos concluir que o rsyslog remoto ficou inativo e não enviou mais mensagens. Mas duvido da exatidão desse método.

    

Answer 1

Não é uma má ideia. Para melhorar um pouco, talvez cada um dos clientes possa ser configurado para enviar uma mensagem em um intervalo regular (fornecendo um "heartbeat" ou "mark"). Com o Rsyslog, a diretiva é $ActionWriteAllMarkMessages [on|off] . Mas cuidado com a man page:

Note that this option auto-resets to "off", so if you intend to use it with multiple actions, it must be specified in front off all selector lines that should provide this functionality.

E se houver um problema de configuração não descoberto no servidor Syslog que faça com que as mensagens sejam direcionadas para um local inesperado, como o arquivo que você monitora para mostrar que o cliente está ativo? Talvez um teste mais rigoroso possa ser (grep / awk) para as mensagens "heartbeat" ou "mark" fornecidas por $ActionWriteAllMarkMessages , procurando a hora da mensagem de um host específico.

Para verificar se o servidor Syslog remoto está em execução, você pode usar o netcat ( nc ) com as opções -z e -u . Do manual:

-u Use UDP instead of the default option of TCP.

-z Specifies that nc should just scan for listening daemons, without sending any data to them. [...]

Por exemplo, com um tempo limite de cinco segundos ( -w5 ):

#!/usr/bin/env bash
hostname="<FQDN or IP Address>"
port="514"

if (nc -z -u -w5 "$hostname" "$port" > /dev/null 2>&1); then
    echo "Syslog is up."
else
    echo "Syslog could not be reached."
fi

unset hostname
unset port

Ou, se o servidor Syslog também usar o TCP, você poderá omitir a opção -u para aproveitar a confiabilidade do TCP, se apenas para essa finalidade. Isso verifica se o servidor Syslog está escutando e disponível no local do servidor que está executando a verificação de conectividade. Há outra faceta que tem igual importância: espaço em disco. (Se o servidor Syslog ficar sem espaço para escrever mensagens, o servidor Syslog também pode ser considerado inativo.)

Considerando que o UDP pode ser "não confiável" por design, a contagem na mensagem "mark" ou "heartbeat" nem sempre funciona em uma rede congestionada ou em um servidor Syslog. Outra abordagem pode ser instalar um script em cada cliente. O script (BASH, Python ou o que quer que funcione) pode retornar qualquer código de erro que você criar (por exemplo: processo Syslog não executando? Return 1 ou tentar iniciar o processo Syslog primeiro ou criar outros testes como testes de conectividade, et al). Use xinetd para iniciar o script a partir de /etc/xinetd.d/script_name (no RHEL / CentOS):

service check_syslog
{
    type        = UNLISTED
    port        = 6777
    socket_type = stream
    protocol    = tcp
    wait        = no
    user        = root
    server      = /usr/local/sbin/script_name
    only_from   = 127.0.0.1 10.0.0.110
    disable     = no
}

No RHEL, o comando de reinicialização é service xinetd restart . Edite /etc/services para dar um nome à porta 6777. Eu gosto de usar iptables para aumentar a sub-rotina only_from . By the way, o porto, 6777, foi usado apenas para ilustração.