Rsyslog - Gerenciamento centralizado de logs

Rsyslog - Gerenciamento centralizado de logs

Postado por Britodfbr em fevereiro 16, 2017

Rsyslog - Gerenciamento centralizado de logs
Autor: Bill Carlos Cabral <cabral.bill at gmail.com>
Data: 02/07/2012

Introdução

O principal objetivo deste artigo é a configuração do Rsyslog de forma que máquinas distintas com sistemas operacionais distintos enviem seus logs do sistema para um servidor centralizado através da rede.

Logs são arquivos de texto gerados pelo sistema e que podem ajudar a descobrir problemas na execução de softwares, problemas de hardware, tentativas de invasão, acessos indevidos, entre outras coisas.

É muito importante manter estes arquivos seguros e intactos. Em uma auditoria de sistemas, estes logs poderão e serão bastante importantes, portanto, a sua integridade e disponibilidade são importantíssimas para um administrador de rede.

Com a atual abrangência das redes e de suas complexidades, a administração tornou-se uma tarefa que exige o máximo de recursos que sejam disponibilizados para que torne mais fácil esta tarefa.

A utilização de ferramentas que unifiquem a administração viabiliza a administração de redes complexas.

Utilizando o Rsyslog, que tem suporte à maioria dos sistemas operacionais utilizados no mercado, a centralização dos logs torna-se possível e de fácil configuração, com grande capacidade de configuração e customização de acordo com a necessidade, sem causar impacto na rede.

O que é o Rsyslog
O Rsyslog é um syslog com foco na segurança e confiabilidade, oferecendo suporte para várias operações como bufferização sob demanda, syslog confiável para TCP, SSL e TLS, gravando em diversos banco de dados diferentes (MySQL, PostgreSQL, Oracle,...), e-mails de alerta, formatos de saída totalmente configuráveis, sendo possível filtrar qualquer parte da mensagem, compressão de mensagem, conversão de arquivos textos para o Rsyslog.

Existem versões avançadas que permitem a customização para o ambiente corporativo, como proteção por criptografia. Um ponto forte é a facilidade de configuração para usuários novatos e inexperientes.

O objetivo do projeto Rsyslog é fornecer um daemon syslog com características mais ricas e confiáveis, mantendo altas as suas capacidades de reposição de estoque syslogd.

Por ser "confiável", isto significa que possui suporte para modos de transmissão confiáveis como TCP ou RFC 3195 (syslog-confiável). O Rsyslog também trabalha muito bem com infraestrutura de logs centralizados, implementando criptografia no tráfego, verificação na perda de dados e gerenciamento de banco de dados.

Como funciona
É necessário que se instale o Rsyslog em todos os nós que deverão ser monitorados e no servidor central.
O Rsyslog funciona tanto em GNU/Linux quanto em Windows, bastando fazer a instalação dos módulos pertinentes a cada distribuição e configurar de acordo com a necessidade e da disposição da rede.

Uma vez configurado o servidor e o cliente, o agente do cliente irá comunicar-se com o agente do servidor central.

O banco de dados no qual o Rsyslog do servidor central irá inserir os logs poderá ser qualquer um, sendo que o utilizado neste cenário será o PostgreSQL 9.1.

Instalação e configuração

Instalação do Rsyslog
Esta instalação será dirigida à distribuição CentOS 6.0, via YUM.

Antes de instalar o Rsyslog, deverá ser verificado se há o serviço syslog. Caso haja, o syslog deverá ser desinstalado para que o Rsyslog seja instalado.

Para instalar o Rsyslog:

# yum install rsyslog

Com o serviço do Rsyslog instalado, agora será necessário configurar para iniciar a utilização.

Configuração do servidor
Rsyslog é configurado através do arquivo rsyslog.conf, normalmente encontrado em /etc.

Mas, antes de inciar a configuração do arquivo rsyslog.conf, que será direcionada a um banco de dados, será necessário que haja um banco de dados instalado e ativo, para que seja criado o banco e suas tabelas default.

O script de criação do banco de dados original, que vem no pacote durante a instalação, está disponível no arquivo /usr/share/doc/rsyslog-versão/createDB.sql:

CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII';

\c Syslog;

CREATE TABLE SystemEvents

(

      ID serial not null primary key,

      CustomerID bigint,

      ReceivedAt timestamp without time zone NULL,

      DeviceReportedTime timestamp without time zone NULL,

      Facility smallint NULL,

      Priority smallint NULL,

      FromHost varchar(60) NULL,

      Message text,

      NTSeverity int NULL,

      Importance int NULL,

      EventSource varchar(60),

      EventUser varchar(60) NULL,

      EventCategory int NULL,

      EventID int NULL,

      EventBinaryData text NULL,

      MaxAvailable int NULL,

      CurrUsage int NULL,

      MinUsage int NULL,

      MaxUsage int NULL,

      InfoUnitID int NULL ,

      SysLogTag varchar(60),

      EventLogType varchar(60),

      GenericFileName VarChar(60),

      SystemID int NULL

);

CREATE TABLE SystemEventsProperties

(       ID serial not null primary key,

      SystemEventID int NULL ,

      ParamName varchar(255) NULL ,

      ParamValue text NULL

);

Este arquivo está na linguagem SQL padrão, logo, é compatível com qualquer banco que trabalhe com essa linguagem.

* Um ponto importante a ressaltar é quanto a codificação do banco utilizado pelo Rsyslog, que é por padrão SQL_ASCIII.

Por padrão, de instalação do PostgreSQL, caso não seja setado uma codificação padrão, a "LATIN1" é considerada default por conter todos os caracteres das línguas européias (o português está incluso nesse grupo), mas a maioria dos bancos utilizam "UTF-8", pela interoperabilidade dos símbolos (podendo conter caracteres de todas línguas).

Ao tentar criar um banco na codificação "SQL_ASCII" numa instalação que já possui um padrão de codificação diferente dessa, apresentará erros.

Para sanar este erro, basta que crie o banco "SYSLOG" (conforme arquivo de criação do banco createDB.sql) em outra template que não a principal (onde foi criado o banco postgres).

Na instalação, por default, são criados mais duas templates: a "template0" e a "template1". Crie o banco em uma delas.

A modificação sugerida para o PostgreSQL 9.1 segue abaixo:

CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII' TEMPLATE=template0;

\c Syslog;

CREATE TABLE SystemEvents

(

      ID serial not null primary key,

      CustomerID bigint,

      ReceivedAt timestamp without time zone NULL,

      DeviceReportedTime timestamp without time zone NULL,

      Facility smallint NULL,

      Priority smallint NULL,

      FromHost varchar(60) NULL,

      Message text,

      NTSeverity int NULL,

      Importance int NULL,

      EventSource varchar(60),

      EventUser varchar(60) NULL,

      EventCategory int NULL,

      EventID int NULL,

      EventBinaryData text NULL,

      MaxAvailable int NULL,

      CurrUsage int NULL,

      MinUsage int NULL,

      MaxUsage int NULL,

      InfoUnitID int NULL ,

      SysLogTag varchar(60),

      EventLogType varchar(60),

      GenericFileName VarChar(60),

      SystemID int NULL

);

CREATE TABLE SystemEventsProperties

(

      ID serial not null primary key,

      SystemEventID int NULL ,

      ParamName varchar(255) NULL ,

      ParamValue text NULL

);

Após criar o banco e as tabelas, algumas configurações deverão ser feitas no arquivo rsyslog.conf. Inicialmente iremos habilitar o suporte a banco de dados.

Suporte de banco de dados em Rsyslog é integrado por módulos (plugin) carregáveis. Para usar a funcionalidade de banco de dados, o plugin do banco de dados deve ser habilitado no arquivo de configuração antes que a primeira tabela do banco de dados seja usada.

Isto é feito através da configuração da diretiva abaixo, no inicio do arquivo de configuração:

$ModLoad ompgsql

Neste caso estaremos habilitando o suporte ao banco de dados PostgreSQL, escolhido como padrão. Vários bancos de dados são suportados. A lista e as especificações estão disponíveis no site:

www.rsyslog.com

Em seguida nós precisamos dizer ao Rsyslogd para gravar dados no banco de dados. Como usamos o esquema padrão, não precisamos definir um modelo para isso.

Podemos usar a hardcoded (rsyslogd lida com o modelo adequado de um link). Então, tudo o que precisamos fazer, por exemplo, para o PostgreSQL, é adicionar uma linha simples seletor para /etc/rsyslog.conf:

*.* :ompgsql:database-server,database-name,database-userid,database-password

Onde:

database-server : É o nome ou o endereço IP do servidor;
database-name : É o nome do banco onde as tabelas foram criadas;
database-userid : É o nome do usuário que tem acesso ao banco;
database-password : É é a senha do usuário.

Com estas configurações feitas, basta iniciar o serviço do Rsyslog e verificar a entrada de dados na tabela do banco de dados.

Toda esta entrada de dados pode ser configurada de acordo com a necessidade e do ambiente em questão. Neste caso, os logs serão originados de dois sistemas operacionais distintos, sendo um Windows Server 2003 e um GNU/Linux Red Hat 5.5 Enterprise Edition.

Os principais logs do GNU/Linux serão enviados ao servidor centralizado, como o /var/log/messages, e outros específicos como do DHCP, Squid e Apache.

No Windows serão enviados os logs do "System Events Reports".

Configurações de arquivo e cliente

Configuração do arquivo /etc/rsyslog.conf
A customização para a coleta dos dados específicos são inseridas através de regras no rsyslog.conf. Por exemplo, para coletar os dados TCP da máquina, basta ativar os módulos de entrada.

Os módulos de entrada são utilizados para reunir mensagens de várias fontes. Eles interagem com os geradores de mensagens. Já os módulos do analisador são utilizados para analisar o conteúdo da mensagem, uma vez que a mensagem foi recebida.

Eles podem ser usados para processar formatos de mensagens personalizadas e invalidamente formatadas. Existem ainda os módulos de modificação de mensagens que são usados para alterar o conteúdo das mensagens que estão sendo processadas.

Eles podem ser implementados utilizando um módulo de saída ou da interface do módulo analisador. Do ponto de vista do núcleo Rsyslog, eles realmente são módulos de saída, ou parser, e é a sua implementação que os tornam especiais.

Atualmente existe apenas um conjunto limitado de tais módulos, mas os novos podem ser escritos com os métodos que o motor melhor lhe proporcione. Eles podem ser utilizados, por exemplo, a:

Anonimizar conteúdo da mensagem;
Adicionar conteúdo dinamicamente computada a mensagem (campos).

Módulos de modificação de mensagens geralmente são escritos para uma tarefa específica e, portanto, normalmente não são genéricos o suficiente para ser reutilizados.

No entanto, o código do módulo existente é provavelmente uma excelente base de partida para escrever um novo módulo, que pode ser escrito por terceiros também.

Abaixo segue o código do rsyslog.conf que será utilizado no servidor onde os logs serão centralizados:

#/etc/rsyslog.conf

$ModLoad  imuxsock.so
$ModLoad  imklog.so
$ModLoad  imtcp.so
$InputTCPServerRun  514
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$ModLoad ompgsql.so

*.* :ompgsql:127.0.0.1,syslog,postgres,postgres

*.info;mail.none;authpriv.none;cron.none    /var/log/messages
authpriv.*                                                /var/log/secure
mail.*                                                      /var/log/maillog
cron.*                                                      /var/log/cron
*.emerg                                                   *
uucp,news.crit                                          /var/log/ spooler
local7.*                                                    /var/log/boot.log

Nesse arquivo, cada linha tem a seguinte função:

$MoadLoad imuxsock.so : Fornece a capacidade para aceitar mensagens de syslog via sockets locais Unix. Mais importante, este é o mecanismo pelo qual o syslog envia mensagens syslog rsyslogd. Então, você precisa ter este módulo carregado para ler o socket de log do sistema e ser capaz de processar as mensagens de log de aplicativos em execução no sistema local.
$MoadLoad imklog.so : Lê mensagens de log do kernel e as envia para o motor de syslog.
$MoadLoad imtcp.so : Habilita a conexão TCP. Necessário para possibilitar que hosts remotos se conectem para centralizar os logs.
$InputTCPServerRun 514 : Declara a porta pelo qual o servidor irá escutar os rsyslogs remotos.
$ActionFileDefaultTemplate RSYSLOG_FileFormat : Define um novo modelo padrão para ações de arquivo. É um formato de arquivo de log de estilo moderno semelhante ao TraditionalFileFormat, mas com alta precisão timestamps e informações de fuso horário.
$ModLoad ompgsql.so : Carrega o módulo responsável pela conexão com o banco de dados PostgreSQL.
*.* :ompgsql:127.0.0.1,syslog,postgres,postgres : String de conexão com o banco de dados.

Os demais dados do arquivo são as informações sobre o que selecionar no log e sua localização.

É possível que sejam customizadas essas entradas de acordo com a necessidade.

Instalação e configuração do cliente
Para que haja comunicação entre o servidor onde será centralizado os logs e os clientes que fornecerão estes logs, é necessário que seja instalado o cliente do Rsyslog nestas máquinas, além do servidor centralizado e configurá-lo para receber estas conexões.

Tanto para o GNU/Linux quanto para o Windows, faremos a configuração dos seus clientes. Iniciando pelo GNU/Linux.

Instalação dos clientes

Instalação do cliente no GNU/Linux
Para a instalação do cliente no GNU/Linux, serão os mesmos passos que foram utilizados na instalação do Rsyslog no servidor central, via YUM, conforme já descrito anteriormente.

A diferenciação se dará no arquivo de configuração rsyslog.conf, que terá algumas configurações diferenciadas, conforme mostrado abaixo:

# /etc/rsyslog.conf

*.* @@10.0.0.1:514
$ModLoad imuxsock.so   # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so       # provides kernel logging support (previously done by rklogd)
$ModLoad imtcp.so
$InputTCPServerRun 514
$ModLoad ompgsql.so
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

*.info;mail.none;authpriv.none;cron.none   /var/log/messages
*.*                                                         /var/log/yum.log
*.*                                                         /var/log/anaconda.log
*.*                                                         /var/log/boot.log
*.*                                                         /var/log/squid/access.log
*.*                                                         /usr/lib/rpm/rpm.log

A única diferença no arquivo de log do servidor para esse cliente, é a seguinte linha na configuração do arquivo rsyslog.conf:

*.* @@10.0.0.1:514

Onde as " @@ ", significam que o protocolo é TCP, depois é informado o IP e por último, a porta no qual o servidor estará escutando.

Basta (re)iniciar o serviço e verificar no servidor se os logs estão chegando.

Instalação do cliente no Windows
Para a configuração de um cliente Windows que irá conectar-se no servidor centralizado, o software cliente Rsyslog deverá ser baixado na seguinte URL:

http://www.rsyslog.com/windows-agent/windows-agent-download/

Depois de baixado na maquina Windows, iniciaremos executando o arquivo rsyslogwa.exe.

A instalação é normal de Windows (next, next, finish). Após terminado esta instalação, no menu iniciar terá o Rsyslog Windows Agent Configuration.

Clique nele para que a tela abaixo seja apresentada.
Nesta tela começaremos criando uma regra onde vamos definir um novo conjunto de regras. Clique com o botão direito do mouse em cima de Rules. Um menu pop-up irá aparecer.

A partir deste menu, selecione: Add rules
Digite um nome para as regras que estaremos criando na tag: Name of RuleSet
Selecione apenas: Forward Syslog

Além disso, deixe a opção marcada: create a Rule for each of the following action

Clique em "Next". Você verá uma página de confirmação. Clique em "Concluir" para criar o conjunto de regras.
A nova Rule Set com o nome digitado está aparecendo. Clique no simbolo para expandi-lo na árvore até que o nível de ação do "Foward Syslog" apareça.

Clique nela para aparecer as configurações, conforme figura abaixo:
Configure o "Forward Syslog" inserindo o IP do seu Servidor Central Rsyslog alterando a porta para a que foi configurada no servidor, sabendo que a porta padrão é a "514".

Você também pode alterar o tipo de protocolo TCP, de acordo com o configurado com no seu servidor.

ATENÇÃO: O Rsyslog agente do Windows e seu servidor Rsyslog devem usar a mesma porta e o mesmo protocolo. Altere o "Message Format", clicando no menu suspenso para escolher: Use CEE enhanced Syslog Format
Agora clique em "Save". Esta primeira parte está pronta. Agora configuraremos a parte do EventLog Monitor Service. Iniciaremos clicando com o botão direito do mouse em:

Services
Selecione: Add Services
Depois: Event Log Monitor V2

Novamente você precisará digitar um nome ou deixar o padrão. Deixe o campo "Use default settings" selecionada e clique em "Finish".
Verá que tem um serviço recém-criado sob os "services" como parte da exibição de árvore. Para verificar seus parâmetros, clique em cima dele:
Como você pode ver, o serviço verifica automaticamente todos os EventLogs presentes no Windows. Agora você pode selecionar ou desativar determinados registros ou alterar algumas de suas propriedades.

Note que o conjunto de regras "Syslog Forward" foi automaticamente atribuído como o conjunto de regras para ser usadas. Agora basta inciar o serviço e começar a monitorar através do servidor centralizado.
Com esta configuração, o cliente do Windows está pronto e, possivelmente, inserindo os logs no servidor centralizado.

Instalação do LogAnalyzer

Para visualizar estes logs de uma maneira mais didática, iremos utilizar o LogAnalyser.

O LogAnalyser é um front-end free para Syslog-Rsyslog de fácil compreensão e manuseio. É um aplicativo gratuito de fonte GLP aberto, que foi desenvolvido, em sua maioria, em PHP.

Sua integração com a fonte de dados tanto pode ser um banco quanto o próprio arquivo texto gerado pelo Rsyslog.

Para instalar o LogAnalyser você precisará ter instalado os seguintes módulos no servidor centralizado de logs, seja ele Windows ou GNU/Linux:

Apache ou IIS Webserver
PHP5

Para iniciar precisaremos baixar LogAnalyzer. Escolha a versão mais recente através do site:

http://loganalyzer.adiscon.com/downloads

Será baixado um arquivo do tipo ".tar.gz". Copie toda a pasta "src" e os arquivos configure.sh e secure.sh da pasta "contrib", que estavam dentro do diretório recém descompactado, para o diretório padrão do Apache ou do IIS.

Neste caso tomaremos como padrão o Apache no servidor GNU/Linux, logo o arquivo deverá ser descompactado no diretório /var/www/html.

Agora será necessário dar as permissões necessárias na pasta e nos arquivos contidos dentro dela. Defina o sinalizador de execução para eles:

# chmod + x configure.sh secure.sh

Execute:

# ./configure.sh

Que criará um config.php em branco, e também irá definir o acesso de escrita a todos a ele. Poderá fazer isso manualmente, se quiser, configurando a permissão 777 neste arquivo.

Para iniciar a instalação LogAnalyzer, abra o seguinte link no browser que estará apontado para o script de instalação:

http://localhost/install.php

O script de instalação irá solicitar configurações para a instalação do LogAnalyzer, basta seguir as instruções.

Iniciado a instalação do LogAnalyser, uma mensagem de boas-vindas será apresentada. Esta é a primeira página da instalação. Diz-lhe apenas, que antes de instalar, algumas diretivas de permissão de arquivos serão verificados.

Basta clicar em "Next" para iniciar o processo.
Verifique as permissões do arquivo. Aqui você vai ver, se o config.php pode ser escrito ou não. Se não pode ser escrito, você terá que aplicar as permissões necessárias manualmente (chmod 777 config.php) e clicar em "Next".
Algumas opções básicas deverão ser definidas aqui nesta tela:

Number of syslog messages per page = 50 (default)

Este é o número de mensagens syslog indicadas em cada página. Você pode aumentar o valor ou diminuir o valor de acordo com a necessidade, vale lembrar que quanto maior o número, mais lento poderá ficar.

Message character limit for the main view = 80 (default)

Defina o número de caracteres por mensagem, que será mostrado na última coluna da janela principal. Mensagens completas podem ser revistas ao passar o mouse sobre elas. Muitas pessoas preferem usar uma configuração de "0", para que toda a mensagem seja exibida.

Character display limit for all string type fields = 30 (default)

Limite de caracteres para exibição. O default é pequeno, porém agiliza no tempo de retorno do sistema.

Show message details popup (default yes) = yes (default)

Muitas pessoas acham que os pop-ups são intrusivos e preferem desativá-los. Use "no" neste caso.

Automatically resolved IP Adrress (inline) = yes (default)

Resolve os IPs em nomes durante a visualização dos logs. Não é recomendado, pois poderá abaixar o rendimento da aplicação.

Na próxima tela teremos o passo mais importante, onde será configurada a fonte de dados, onde estão armazenados todos os dados do Rsyslog.

Primeiramente terá que ser escolhido um "Name of the Source" (Nome da Fonte) e um "Source Type" (Tipo de Origem).

O nome será escolhido por você e este será exibido no menu drop-down com no qual você escolherá a sua fonte de dados Rsyslog ativa.

O "Source Type" (Tipo de Fonte) pode ser um arquivo, um banco de dados MySQL ou o PHP PDO que suporta tipos de dados diferentes como MS SQL, PostgreSQL, ODBC, Oracle ou IBM DB2 mesmo.

Neste caso utilizaremos a última opção, onde será configurado o banco PostgreSQL 9.1.

Database Storage Engine = MySQL Server (default)

Escolha o tipo do banco de dados você está usando. Estes bancos são suportados:

MySQL Server
Microsoft SQL Server
ODBC Conexão Banco de Dados
PostgreSQL
Oracle Call Interface
IBM DB2
Firebird / Interbase 6
IBM Informix Dynamic Server
SQLite 2

E a configuração do banco:

Table Type = monitorware (default)

Este é o layout da tabela. Atualmente, você pode usar "monitorware" ou "syslogng"

*Database Host = localhost (default)

Este é o nome da maquina ou IP de onde o banco de dados está localizado. Por padrão é localhost. Você pode especificar qualquer outro host, de acordo com o seu cenário.

Database Name = loganalyzer (default)

O nome do banco de dados que você configurou no banco.

Database Tablename = systemevents (default)

Este é o nome da tabela em que os dados são armazenados. O tablename padrão corresponde às tabelas criadas com a Linha "Table Type".

Database User = user (default)

O nome de usuário do banco de dados.

Database Password = não definido por padrão

A senha do usuário.

Enable Row Counting = No (default)

Se configurado para "Yes", a quantidade de linhas na tabela serão contados com cada consulta, mostrando os registros totais para a sua pesquisa. Poderá ter um grande impacto em seu sistema ao utilizar um banco de dados muito grande.

Se configurado para "No", as linhas não serão contadas, proporcionando um desempenho melhor.

Se tudo ocorreu bem, você deve ver mensagens do Rsyslog já após a sua instalação LogAnalyzer. Por segurança você pode remover o script install.php.
Conforme figura acima, os dados que já foram inseridos no banco de dados podem ser visualizados pelo browser através do endereço do IP, ou localmente através do localhost.

Detalhando uma das mensagem acima, teremos a seguinte tela:
Acima, temos os seguintes campos:

uiD - ID da mensagem conforme sua inserção no banco;
Date - data e hora do evento;
Host - nome da maquina onde o evento ocorreu;
Severity - tipo de prioridade da mensagem;
Syslogtag - tag que identifica qual o serviço que gerou o evento;
Checksum - tag utilizada quando o rsyslog é utilizado com SSL/TLS;
Message - conteúdo da mensagem com os dados do evento.
Messagetype
Facility

Neste evento, podemos perceber alguns dados interessantes: por ser um evento do tipo DHCPACK (onde o servidor confirma a alocação do endereço IP ao cliente), o endereço MAC da máquina que recebeu o IP e o endereço IP que foi atribuído. Isto pode permitir uma rastreabilidade na rede.

Conclusão

Com o Rsyslog, torna-se possível o gerenciamento centralizado de logs, independentemente do sistema operacional, permitindo a visualização dos eventos de todos os pontos monitorados de forma que um relatório pode ser emitido demostrando um cenário geral da rede para um certo tipo de evento, ou até mesmo de todos os eventos, procurando o de maior ocorrência para verificar o motivo de tanta repetição.

Um fator positivo é a possibilidade de utilização de um banco de dados para armazenamento centralizado destes eventos (logs). Independente de qual seja o banco, o fato de estar inserido em um SGBD (sistema de gerenciamento de banco de dados) permite uma integração com outras ferramentas e até mesmo, outros sistemas, além de possibilitar ações que garantirão a alta disponibilidade desses dados, como o backup e redundância, que já não é tão funcional como o backup de um arquivo e redundância do mesmo.

Outro ponto positivo é a interoperabilidade: a maioria dos bancos mais usados no mercado são suportados nessa ferramenta, que garante a cobertura de mais de 90%.

Por ter a licença do tipo GPLv3, há uma liberdade para se trabalhar com esta ferramenta adequando-a, dentro dos termos da licença, à necessidade.

Qualquer um pode desenvolver um plugin para o Rsyslog, ou mesmo adaptar (de acordo com o tipo de licença dele, pois o projeto Rsyslog é regido pela GLPv3, e nada implica que seus plugins sejam, já que a grande maioria não foram desenvolvidos pelos criados/desenvolvedores do Rsyslog) para a sua melhor aplicação num cenário específico.

Durante a configuração do "servidor" centralizado Rsyslog, houveram muitos erros. Na configuração da string de conexão com o banco de dados, por exemplo, um simples espaço entre os dados desta string gera o erro na conexão com o banco de dados, e nada na documentação do site www.rsyslog.com/doc fala sobre isso.

Aliás, tirando a documentação do site oficial, pouquíssimos são os documentos disponíveis que tem algum valor mensurável em questão de conteúdo, pois a maioria é uma replica de algum trabalho que é uma cópia/tradução do que está no site.

Este documento foi todo escrito com palavras do autor, tendo uma sinopse do conteúdo encontrado na documentação oficial que foi usada como referência.

Talvez se houvesse uma documentação mais detalhada, a maioria destes erros poderiam ser corrigidos mesmo antes da sua ocorrência.

O tráfego na rede causado pelo Rsyslog não é impactante para influenciar no desempenho, porém, ao se pensar em banco de dados e dependendo da quantidade de pontos monitorados, poderá gerar um I/O muito grande no banco, que pode onerar sua performance, cabendo ao responsável pela instalação/configuração, procurar por soluções que possam resolver e que atenda as necessidades.

Outro ponto forte do Rsyslog, é a possibilidade da implementação de segurança na transmissão dos eventos para o servidor centralizado, utilizando SSL/TLS.

No próximo artigo, implementaremos esta funcionalidade juntamente com o suporte de strings com mais de 32 bits.

Comentários