Manual do MTMON

O MTMON é um framework para monitoração de ativos, que pode ter agentes instalados em computadores ou integrado à outros softwares de monitoração, como por exemplo: Nagios ou Centreon, Zabbix e PRTG.

Foi concebido para que os eventos gerados sejam apresentados numa CONSOLE. Estes eventos, podem estar associados a execução de procedimentos, que são executados por operadores que atuam 24x7 no NOC da Multitask.

Iniciaremos com os procedimentos de instalação por ser o motivo principal de consulta deste documento.

Instalação do agente

Para configurar o cliente use o seguinte check-list:

Instalação do perl e dos módulos necessários
Download e instalação dos programas do agentes
Instalar o inst_mtadm e o inst_mtmon_client
Configurar o arquivo mtadm.conf e mtmon.conf

1. UNIX (AIX, HP-UX e linux em geral)

1.1. Instalação do perl

Para o perfeito funcionamento dos agentes do MTMON, é necessário que os módulos do perl estejam instalados e atualizados.

A versão minima recomendada do perl é 5.12.1 ou superior. Para identificar a versão do perl instalado no computador use o comando:

 # perl -v
 This is perl 5, version 32, subversion 0 (v5.32.0) built for darwin-thread-multi-2level

 Copyright 1987-2020, Larry Wall

 Perl may be copied only under the terms of either the Artistic License or the
 GNU General Public License, which may be found in the Perl 5 source kit.

 Complete documentation for Perl, including FAQ lists, should be found on
 this system using "man perl" or "perldoc perl".  If you have access to the
 Internet, point your browser at http://www.perl.org/, the Perl Home Page.

O MTMON usa alguns módulos do perl para realizar as verificações e a versão mínima necessária é apresentada abaixo:

 CGI - 3.43
 CPAN - 1.9304
 LWP - 5.825
 Mail::Sender - 0.8.13
 Net::Ping - 2.35
 Net::Telnet - 3.03

Para identificar a versão dos módulos, use o script abaixo:

1
2
3
4
 for modulo in CPAN CGI LWP Net::Ping Net::Telnet Mail::Sender
 do
   perl -M$modulo -e "print qq(\$$modulo::VERSION\t$modulo\n);"
 done

Red Hat

yum -y install perl-CGI perl-CGI.noarch perl-CPAN perl-Crypt-SSLeay.x86_64 perl-JSON perl-JSON.noarch perl-JSON-PP.noarch perl-LWP-Protocol-https.noarch

Ubuntu

apt-get update
apt-get -y install libcgi-application-plugin-json-perl libjson-xs-perl liblwp-protocol-https-perl perl-modules

SuSE

zypper update
zypper install perl-Test-LWP-UserAgent perl-LWP-Protocol-https perl-JSON-XS perl-JSON perl-CGI

1.2. Softwares recomendados

No linux podemos instalar os seguintes softwares que podem ser úteis e necessários para algumas configurações:

Red Hat, Centos, Fedora e Oracle Linux

yum -y install bison expect flex gawk gcc make m4 nmap rcs sharutils sysstat wget

Debian/Ubuntu

apt-get install bison expect flex gawk gcc make m4 nmap rcs sharutils sysstat wget

SuSE

zypper install bison expect flex gawk gcc make m4 nmap rcs sharutils sysstat wget

1.2.1. rsyslog

Alguns equipamentos estão preparados para gerar mensagens na syslog de servidores remotos. Para usar este recurso é necessário instalar o rsyslog.

Centos, Fedora e Red-Hat

Instalar o pacote rsyslog:

yum -y install rsyslog

Incluir as seguintes linhas no arquivo /etc/rsyslog.conf:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

kern.err     /usr/local/Multitask/mtmon/log/mtmon.log (1)

1	O arquivo pode ser monitorado pelo plugin mtmon_check_log.pl

Desative o syslog default do linux e ative o rsyslog:

chkconfig syslog off
chkconfig rsyslog on (1)

1	Válido no próximo reboot do servidor

Execute os comandos service para substituir o syslog:

# service syslog stop
Shutting down kernel logger:      [  OK  ]
Shutting down system logger:      [  OK  ]
# service rsyslog restart
Starting system logger:           [  OK  ]

2. Windows

2.1. Instalação do perl

O software usado para executar a monitoração é o Strawberry Perl.

Faça o download do instalador no link acima clicando na versão 64 bits.

  strawberry-perl-5.32.0.1-64bit.msi (1)

1	use a versão mais nova disponível no site. No exemplo acima é da versão 5.32.0.

No endereço https://mttmb.multitask.com.br//install/ estão disponíveis as cópias dos instaladores do perl e do agente do MTMON.

O link https://mttmb.multitask.com.br//install/strawberry-perl-5.32.0.1-64bit.msi aponta para o instalador atualizado.

Windows 2000

O windows 2000 não é mais suportado pelo Strawberry Perl. Use o instalador disponibilizado no link da Multitask, que já está com os módulos pré-instalados.

Execute o programa strawberry-perl-5.10.0.4.exe e na sequência descompacte o strawberry-perl-5.10.0.4_w2k.zip no diretório C:\Stramberry..

Em ambiente de WTS pode ser necessário executar o comando:

change user /install

3. Instalando módulos usando o CPAN

Os plugins do MTMON usam alguns módulos do perl e estes precisam ser instalados. A instalação/atualização destes módulos pode ser feita com o instalador de módulos do perl, chamado CPAN - Comprehensive Perl Archive Network ou usando os pacotes pré-definidos nos repositórios do Sistema Operacional.

Os comando para configuração do perl são:

# perl -MCPAN -e shell (1)
cpan> o conf build_requires_install_policy yes
cpan> o conf prerequisites_policy follow
cpan> o conf commit
cpan> install YAML (2)
cpan> install Bundle::CPAN CGI JSON LWP (3)
cpan> install DateTime MIME::Base64 Mail::Sender Net::Ping Net::Telnet Net::Telnet::Cisco Rcs Template Text::ParseWords Unicode::MapUTF8 (4)
cpan> install Win32 Win32::EventLog Win32::OLE Win32::PerfLib Win32::Process::Kill Win32::Registry Win32::Service (5)

   ...

cpan>

1	No Windows execute o comando C:\strawberry\perl\bin\perl.exe -MCPAN -e shell
2	Este módulo é pré-requisito para vários outros módulos e instalando ele antes dos demais, diminui o tempo de instalação, pois alguns módulos não são instalados sem o YAML.
3	Módulos necessários para o funcionamento do core do agente do MTMON
4	Estes módulos podem ser necessários para alguns plugins ou documentação do ambiente
5	Aplicável apenas para o Windows

Quando o CPAN já está configurado e desejar que o default das opções seja aceito para os módulos à serem instalados, pode ser chamado com a sintaxe:

# PERL_MM_USE_DEFAULT=1 perl -MCPAN -e shell (1)

1	O CPAN não solicitará um `ENTER` para cada definição que o instalador necessitar, assumindo o valor default.

Para instalar usando módulos do CPAN, é necessário garantir que NÃO estejam definidas variáveis que possam alterar o diretório de instalação. As variáveis em questão podem forçar a instalação dos módulos no $HOME do usuário root e quando chamados via crontab, não estarão acessíveis ao agente, pois o PATH é simplificado no cron.

# unset $(env | grep -e '^PERL' | sed -e 's/=.*//') (1)

1	Remove as variáveis do shell cujo nome iniciam com PERL

Problemas com NLS, podem usar a solução de contorno abaixo, que limpa as variáveis de shell LANG e LC*_:

# unset LANG $(env | grep -e 'LC_' | sed -e 's/=.*//')

A instalação dos módulos pode ser simplificada copiando o diretório C:\Strawberry de um servidor Windows que já tem os módulos instalados. A versão do perl deve ser a mesma para evitar conflitos.

Se ocorrer o erro abaixo:

# perl -MCPAN -e shell
Cant locate CPAN.pm in @INC (@INC contains: /root/perl5/lib/perl5 /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .).
BEGIN failed--compilation aborted.

instale o módulo básico do CPAN com o comando abaixo:

# yum -y install perl-CPAN

Em alguns ambientes, os programas yum ou up2date não estão disponíveis e nestes casos é necessário que seja compilado o módulo no perl.
Para compilar o módulo do CPAN é necessário obter os fontes dos módulos disponível no link abaixo:

http://cpan.perl.org/modules/01modules.index.html

Uma versão bem básica está disponível no link:

https://mttmb.multitask.com.br/install/

Faça o download dos módulos: CPAN-1.9402.tar.gz e Test-Harness-3.22.tar.gz

Instale na ordem abaixo:

App  ANDYA Test-Harness-3.22.tar.gz  286k  14 Aug 2010
CPAN ANDK  CPAN-1.9402.tar.gz        665k  27 Jun 2009

Após desempacotar os fontes, compile os mesmos usando a seqüência abaixo:

# perl Makefile.PL
# make
# make test
# make install

Se o ambiente está com o CygWin, Data Protector ou cliente do ORACLE com perl instalado, o PATH poderá usar uma versão incompatível do perl para instalar os módulos acima. A solução de contorno é alterar numa sessão cmd o PATH conforme abaixo:

C:\> echo set PATH=%PATH% > x.bat
C:\> edit x.bat
C:\> x.bat

Quando editar o arquivo x.bat remova as referencias ao caminho do CygWin ou cliente do ORACLE.

Se o acesso à internet é por meio de um proxy, configure as variáveis ftp_proxy e http_proxy no arquivo C:\strawberry\perl\lib\CPAN\Config.pm.

'ftp_proxy' => q[http://proxy:porta],
'http_proxy' => q[http://proxy:porta],

Se a autenticação é necessária use a sintaxe abaixo:

'ftp_proxy' => q[http://usuario:senha@proxy:porta],
'http_proxy' => q[http://usuario:senha@proxy:porta],

Alguns UNIX tem o comando cpan instalado, que pode ser usado com a sintaxe abaixo:

cpan install CPAN Bundle::CPAN
cpan install JSON CGI LWP Net::Ping Rcs Mail::Sender MIME::Base64 Net::Telnet Net::Telnet::Cisco Text::ParseWords Template

O Oracle Linux, na instalação padrão, não tem o perl instalado. Os comandos abaixo podem ser usados para agilizar a instalação do ambiente necessário para o funcionamento do agente do MTMON:

yum install perl-CPAN rcs sharutils sysstat wget
wget http://189.45.197.30/install/inst_mtadm.new
wget http://189.45.197.30/install/inst_mtmon_client.new

out of memory ou Segmentation fault (core dumped) no AIX

Setar a variável do shell abaixo e executar novamente:

export LDR_CNTRL=MAXDATA=0x80000000

Verifique o documento sobre AIX Core DUMP.

4. Instalar o agente do MTMON

O diretório /usr/local/Multitask/mtmon ou C:\Multitask\mtmon é a base que contém todos os arquivos do MTMON. Neste documento, é referenciado com o link MTMONbase.

Em qualquer servidor, para remover o agente do MTMON, desative os programas que estão sendo chamados na crontab ou via serviço MTMON do Windows e remova o diretório. No UNIX, alguns link’s simbólicos são criados no diretório /usr/local/bin.

4.1. UNIX

Faça o download dos instaladores para UNIX — inst_mtadm e inst_mtmon_client e execute:

# sh inst_mtadm
# sh inst_mtmon_client

Os instaladores criarão o diretório MTMONbase.

4.2. Windows

Crie o diretório C:\Multitask e descompacte os arquivos win_binMultitask.zip, win_inst_mtadm.zip e win_inst_mtmon_client_windows.zip neste diretório.

No windows explorer os arquivos .zip podem ser abertos clicando o arquivo e copiando o conteúdo para o diretório C:\Multitask.

No prompt do DOS, use os comandos abaixo:

C:\Multitask> unzip -o win_binMultitask.zip
  inflating: bin/awk.exe
  inflating: bin/basename.exe
  inflating: bin/bash.exe

   ...

  inflating: bin/uniq.exe
  inflating: bin/wc.exe
  inflating: bin/gvim.exe

C:\Multitask> unzip -o win_inst_mtadm_windows.zip
C:\Multitask> unzip -o win_inst_mtmon_client_windows.zip (1)
C:\Multitask> mtmon\bin\Install.bat  (2) (3)

1	Antes de executar o `Install.bat`, crie o arquivo `C:\Multitask\mtadm\etc\mtadm.conf` e configure de acordo com as definições do cliente
2	Depois de finalizar a execução, abra nova janela `CMD` e execute o comando `cpzip` para finalizar a instalação
3	Observe que depois de executar o `cpzip` é necessário executá=lo novamente na janela aberta com o comando `psexec -i -s -d cmd`. Este segundo `cpzip` definirá as permissões necessárias para o agente do MTMON executar com o usuário SYSTEM

Se precisar instalar o agente em vários servidores Windows, use o comando rem_install que agiliza o processo.
O script cria o diretório C:\Multitask no servidor remoto e copia os arquivos necessários para instalar o agente.
Depois é só executar o script Instala.bat no servidor remoto com permissões de Administrator.

C:\Multitask> C:\Multitask\mtmon\bin\rem_install CLIENTE (1)

1	`CLIENTE` é o nome ou `IP` do servidor Windows que será instalado

5. Configuração inicial

A configuração inicial é realizada no servidor onde o agente do MTMON é instalado.

As informações abaixo são fornecidas aos clientes pela Multitask quando é realizada a instalação do primeiro servidor.

Crie ou altere o arquivo MTADMbase/etc/mtadm.conf, ajustando as opções:

origem: Identifica a empresa em que o agente do MTMON está instalado. É única para cada empresa.

O nome da Origem e do Servidor só pode conter os caracteres [a-z0-9_].
Nomes com letras maiúsculas serão convertidas para minúsculas pelo agente.

Para criar uma nova origem:

Entre como Administrador no servidor MTMON
Selecione a opção Manutenção de Origem na janela esquerda
Selecione a opção Incluir nova origem

server: define o nome do servidor no MTMON.
Alguns ambientes em que o nome do servidor é repetido, podemos personalizar o nome do servidor apenas para o MTMON.
Default: hostname do servidor monitorado. Se o hostname tem o DNS incorporado, a parte de domínio é removida.
TransKEY: é uma chave simétrica usada para validar as transações e garantir que os eventos sejam do cliente associado.

Num cliente que já tem outros servidores monitorados, podemos copiar o arquivo MTADMbase/etc/mtadm.conf de outro servidor configurado.

proxy: A comunicação entre o agente e o servidor MTMON é realizada pelo protocolo HTTP[s].
Configure esta opção quando é necessário um proxy para acessar as páginas do MTMON.

Exemplo de configuração do SQUID

As entradas abaixo definem que apenas os IP’s do MTMON sejam acesados via SQUID.
Instale o SQUID e inclua as linhas abaixo no arquivo /etc/squid/squid.conf:

 #
 # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
 #
 acl mtmon_170 src 170.84.17.136/32
 acl mtmon_189 src 189.45.197.30/32

 http_access allow mtmon_170
 http_access allow mtmon_189

Na sequência sugerimos:

Executar o comando MTMONbase/bin/cpzip.pl, que atualizará o agente com a última versão do agente.
Executar o comando MTADMbase/bin/IncluirArquivos.pl --aplicar.
Ajustar a crontab conforme sugerido pelo instalador inst_mtmon_client.

5.1. Definindo a origem

No servidor MTMON, a definição da origem é definida no arquivo MTMONbase/etc/Origem/{origem}.conf.

MTMONbase/etc/Origem/cliente.conf:

[cliente]
  nome="Nome do cliente"
  transkey="6py$SZtJzi.Mr"  (1) (2)
  email="suporte@cliente.com.br"
  finaliza=2

1	Num primeiro momento, apenas a TransKEY é necessária, mas outros campos também podem ser configurados aqui.
2	A TransKEY deve ser a mesma usada em MTADMbase/etc/mtadm.conf

Para cada cliente deve ser criado um arquivo {origem}.conf.

Nos servidores que rodam o agente do MTMON, configurar o arquivo MTADMbase/etc/mtadm.conf:

$MTADMbase/etc/mtadm.conf:

[Global]
  Origem="cliente" (1)
  ServerMTMON="189.45.197.30"
  Proxy=
  TransKEY="6py$SZtJzi.Mr" (2)
  ...
  UsarHTTPS=1

1	cliente está relacionado com o nome do arquivo descrito acima.
2	A TransKEY deve ser a mesma

Cada servidor que tem o agente do MTMON instalado, deve ter uma cópia do arquivo mtadm.conf.

Quando já existem outros servidores que tem o agente do MTMON instalado no cliente, apenas copiar o arquivo mtadm.conf e revisar o campo server simplifica a configuração.

5.2. Entendendo o $TransKEY

O campo TransKEY é usado para validar a origem do evento sendo cadastrado e validar se os eventos estão sendo recebidos em ordem cronológica.

Todo evento à ser cadastrado, gera uma chave usando a TransKEY e a hora do evento. A data da transação é enviada junto com a mesma e usando criptografia simétrica, é realizada a validação da mesma.

A TransKEY NUNCA É TRANSMITIDA entre o cliente e o servidor.

O objetivo da TransKEY é garantir que a transação seja de um cliente autorizado. Os dados não são criptografados na transmissão. Para criptografar a informação, é usado o protocolo HTTPS,

Se a TransKEY do cliente não for igual à do que está definida no servidor MTMON ou a hora da transação é anterior à última registrada, a mensagem é rejeitada.

6. Ativando o serviço

Após a configuração inicial, execute o comando cpzip para que seja feita uma revisão da instalação. O próprio script fará o download da última versão disponível do agente,

A execução do inventário do servidor é feito com o comando: MTMONbase/plugin/mtmon_doc.pl.

É útil para mapear as configurações do servidor.

6.1. UNIX

No UNIX, é necessário incluir na crontab a linhas definidas na execução do comando cpzip.

# cpzip
/usr/local/bin/cpzip: $Id: cpzip.pl,v 5.32 2019/11/29 21:42:38 user Liberado $

09/10/2020 21:22:18 Conectado em terminal. OK
Lista de IP : 170.84.17.136,189.45.197.30,170.84.17.136,189.45.197.30,189.45.197.30,170.84.17.136
URL: https://170.84.17.136/mtmon-cgi/mtmon_cpzip_cksum.cgi
200 OK
<!-- $ Conectado no servidor mtfln $ -->
mtmon_cpzip_cksum.cgi:51 inst_mtadm [647.08 KB] download.
mtmon_cpzip_cksum.cgi:48 inst_mtcl [390.69 KB] OK.
mtmon_cpzip_cksum.cgi:51 inst_mtmon_client [935.04 KB] download.
mtmon_cpzip_cksum.cgi:48 inst_mtpdf [153.39 KB] OK.
mtmon_cpzip_cksum.cgi:48 inst_mtsend [117.54 KB] OK.
mtmon_cpzip_cksum.cgi:48 inst_mtsms [68.61 KB] OK.

get https://170.84.17.136/install/inst_mtadm.new
200 OK
mv /usr/local/Multitask/mtmon/tmp/inst_mtadm /usr/local/Multitask/inst_mtadm
get https://170.84.17.136/install/inst_mtmon_client.new
200 OK
mv /usr/local/Multitask/mtmon/tmp/inst_mtmon_client /usr/local/Multitask/inst_mtmon_client
Executando : /usr/local/Multitask/inst_mtadm

Servidor : mtmon
Versao instalada : 5.004.045
Instalando inst_mtadm.5.4.48


x - created lock directory _sh84272.
x - extracting ComandosMT.pl (text)
x - extracting mtadm.tgz (text)

...

Entradas usando crontab -e : (1)

# MTMON
59 * * * * /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
0,15,30,45 * * * * /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
@reboot /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
*/15 * * * * /usr/local/Multitask/mtadm/bin/ColetaMemoriaReal.sh #

1	Incluir as linhas abaixo com o comando crontab -e

Observe que na configuração via crontab -e, não é incluido o usuário root no sexto campo.
Veja nota abaixo.

Algumas distribuições do Linux usam o arquivo /etc/crontab. Neste caso, inclua as seguintes entradas no arquivo:

# vi /etc/crontab  (1) (2)
59 * * * * root /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * root /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
0,15,30,45 * * * * root /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #

1	O comando cpzip já faz esta verificação e apresenta a alternativa.
2	Observe que, neste formato, as linhas incluem o usuário root no sexto campo de cada linha. O cron ignora silenciosamente este erro e não executa as chamadas programadas.

Visão geral dos programas chamados na crontab

6.2. Windows

Após instalar o perl, é necessário abrir uma nova sessão do CMD para que o PATH com o caminho para o perl seja reconhecido.

O instalador do agente executa todos os comandos necessários para que a configuração seja funcional e já inicializa o serviço MTMON.

6.3. Windows usando o SCHTASKS

Esta forma não é a melhor para configurar o agente do MTMON, pois introduz algumas vulnerabilidades no ambiente do Windows.

A vulnerabilidade mais expressiva é a necessidade de definir um usuário com status de Administrador Local. A forma recomendada é criar um serviço para o agente do MTMON, explanada na sessão anterior deste manual.

Se configurado, desative o serviço do mtmon com o comando:

NET STOP mtmon

Para configurar o SCHTASKS crie o usuário sa_mtmon com status de Administrador Local.

Recomenda-se que seja criado um usuário exclusivo para a execução dos programas do MTMON com status de administrador, uma vez que a senha não deve ser alterada. Este usuário não pode expirar a senha e preferencialmente não deve ser autorizado para fazer login no Windows.

Executar o script C:\Multitask\mtadm\bin\preparaAmbiente.bat

O script incluirá no Agendador de Tarefas/Scheduled Task os programas de monitoração com os comandos abaixo:

schtasks /create /sc MINUTE /mo 30 /tn mtmon_cron1 /tr C:\Multitask\mtmon\bin\ChamaMTMON_CRON.bat /st 00:00 /du 0024:00 /RU sa_mtmon /RP {senha}
schtasks /create /sc MINUTE /mo 30 /tn mtmon_cron2 /tr C:\Multitask\mtmon\bin\ChamaMTMON_CRON.bat /st 00:15 /du 0024:00 /RU sa_mtmon /RP {senha}
schtasks /create /sc HOURLY /mo 2 /tn MonitoraAmbiente1 /tr C:\Multitask\mtadm\bin\MonitoraAmbiente.bat /st 00:59 /du 0024:00 /RU sa_mtmon /RP {senha}
schtasks /create /sc HOURLY /mo 2 /tn MonitoraAmbiente2 /tr C:\Multitask\mtadm\bin\MonitoraAmbiente.bat /st 01:59 /du 0024:00 /RU sa_mtmon /RP {senha}
schtasks /create /F /sc ONSTART /tn ResetaScheduleTask /tr C:\Multitask\mtadm\bin\ResetaScheduleTask.bat /RU sa_mtmon /RP {senha}

Após a execução destes comandos, alterar na guia Configurações do Agendador de tarefas:

mtmon_cron1 e mtmon_cron2: desmarcar o box Interromper a tarefa se ele for executada por.
MonitoraAmbiente1 e MonitoraAmbiente2: alterar no box Interromper a tarefa se ele for executada por: o valor para 1 hora e 10 minutos.

Em algumas instalações ocorre o seguinte erro:

The new task could not be created.
The specific error is:
0x800700005: Access is denied.
Try using the Task page Browse button to locate the application.

Execute o seguinte comando para autorizar a criação de tarefas no schtasks:

CD \Windows
CACLS TASKS /E /G builtin\administrators:F

6.4. Testar comunicação com o servidor MTMON

Execute o comando abaixo para validar a criação de evento no servidor MTMON:

$MTMONbase/bin/mtmon_evento.pl --aplicacao=teste --debug \
      --mensagem="Teste de conexao" --eventual --forceteste --severidade=0 (1)

...

C:\Multitask\mtmon\bin\mtmon_evento.pl --aplicacao=teste --debug --mensagem="Teste de conexao" --eventual --forceteste --severidade=0 (2)

1	Unix
2	Windows

Quando a transkey ou a origem estão diferentes no cliente e no servidor do MTMON, poderá ocorrer o erro:

# mtmon_evento.pl --severidade=0 --aplicacao=teste --mensagem='Teste de conexao'
<!DOCTYPE html
        PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>MTMON v.1.27 - Multitask Consultoria Ltda</title>
<link type="text/css" rel="stylesheet" href="/mtmon.css" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<!-- $Id: mtmon_novo_evento.cgi,v 1.19 2006/10/01 13:55:40 user Liberado $ -->
<!-- Conectado no servidor 'server.cdlflorianopolis.org.br' -->
<meta content="no-cache" http-equiv="Pragma" />

MTMON::ERRO : [Nao autorizado. Verifique no arquivo /usr/local/Multitask/mtmon/etc/mtmon.conf a variavel $TransKEY.]
MTMON::ERRO : [Origem=empresa]

Nao autorizado. Verifique no arquivo /usr/local/Multitask/mtmon/etc/mtmon.conf a variavel TransKEY.

No exemplo abaixo, o nome proxy não foi resolvido no DNS ou /etc/hosts.

# mtmon_evento.pl --severidade=0 --aplicacao=teste --mensagem='Teste de conexao'
500 Cant connect to proxy:3128 (Bad hostname 'proxy')

Em servidores do VMWARE, verifique se o firewall local permite que os pacotes TCP/IP de comunicação estão autorizados. O comando abaixo libera totalmente a saída dos pacotes:

esxcfg-firewall -AllowOutgoing
esxcfg-firewall -AllowOutgoing -o 3128,tcp,out,PROXY

O segundo comando pode ser usado para definir apenas as portas desejadas.

Uma vez que o evento foi gerado corretamente na console do MTMON, execute o comando abaixo para gerar um relatório com as informações gerais do servidor.
Isso facilitará na definição de quais plugins podem ser configurados no mesmo.

/usr/local/Multitask/mtmon/plugin/mtmon_doc.pl --deb

Sempre que um evento é criado, um arquivo de controle chamado Ctrl.Origem.Server.live é criado no servidor MTMON. Este arquivo salva a data do evento e se eventos com data menor que a registrada no arquivo são enviados ao MTMON, um erro é devolvido.

# date
Sex Out  6 11:48:25 BRT 2020
# mtmon_evento.pl --severidade=0 --aplicacao=teste --mensagem='Teste de conexao'
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html
        PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head><title>MTMON v.1.29 - Multitask Consultoria Ltda</title>
<link type="text/css" rel="stylesheet" href="/mtmon.css" />
</head><body>
<!-- $Id: mtmon_novo_evento.cgi,v 1.21 2020/10/03 19:25:18 user Liberado $ -->
<!-- Conectado no servidor 'Multitask' -->
<meta content="no-cache" http-equiv="Pragma" />
Ultimo registro : 1160944314

MTMON::ERRO : [Evento fora da tolerancia. Ultimo registro : 15/10/2020 18:31:54]

Evento fora da tolerancia. Ultimo registro : 15/10/2020 18:31:54

Note que a data no cliente é 06/out/2020 11:48:25 e o último evento está registrado com a data 15/10/2020 18:31:54. O objetivo é evitar um ataque do tipo Man In The Middle, onde alguém intercepta um evento e depois re-envia este evento inúmeras vezes, gerando um DOS (Deny Of Service) no servidor do MTMON.

O problema pode se manifestar, se houver uma alteração de data no cliente do MTMON e depois voltar para uma data anterior. Para resolver o problema remova o arquivo de controle Ctrl.Origem.Server.live no servidor do MTMON.

6.5. Executando o agente com debug

Para identificar problemas na execução do mtmon_cron.pl, execute no prompt o comando abaixo:

/usr/local/Multitask/mtmon/bin/mtmon_cron.pl --debug (1)

...

C:\Multitask\mtmon\bin\mtmon_cron.pl --debug (2)

1	Unix
2	Windows

6.6. Scheduler central

O programa que centraliza as chamadas dos plugins é o mtmon_cron.pl. Seu ojetivo é chamar os plugins que fazem a efetiva verificação dos serviços monitorados no computador cliente.

O mtmon_cron.pl é um serviço do sistema operacional, rodando em background.

O programa usa o arquivo de configuração $MTMONbase/etc/mtmon_cron.conf para definir as ações que serão tomadas para a verificação do serviço.

Opções disponíveis na linha de comando:

--debug: Um log detalhado das operações é apresentado na saída padrão.
--origem: Útil quando a monitoração é para uma origem diferente da definida em MTADMbase/etc/mtadm.conf.

6.6.1. Arquivo mtmon_cron.conf

É o arquivo de configuração do comando mtmon_cron.pl, responsável por controlar a execução dos PLUGINS que automatizam a monitoração.

O formato do arquivo é:

[Global]
  PATH = /usr/local/Multitask/mtmon/plugin
  Obs = "Observacao"  (1) (2)
  Obs0 = "Observacao de documentacao"

[sessao1]
  Ativo=0
  Nagios=1
  Intervalo="*/2 15"
  Comando="check_teste -w 10 -c 5" (3)
  Finaliza=1
  Info=info.pdf
  Limite=3 horas
  Notifica=oracle
  Origem=NovaOrigem
  Objeto=objtst
  Repete=1
  Aplicacao=teste
  Servidor=srvTeste
  env_senha=PWD_xxxxxx
  Obs0 = "Redefinicao da observacao de documentacao" (4)
  Obs1 = "com continuacao na linha abaixo"

1	Valor default que será propagado nas sessões que não definirem a opção Obs.
2	As aspas não são obrigatórias
3	O comando invocado pelo programa será: MTMONbase/plugin/check_teste. Veja definição de PATH.
4	A opção Obs0 para a sessão sessao será definida com o valor correspondente. Nas demais sessões vale o valor definido em Global.

A primeira sessão é denominada Global e contém parâmetros para o comando mtmon_cron.pl. Estas definições serão incluídas nas demais sessões como valor default se a opção for omitida.

PATH: Quando o comando de uma sessão não tem um PATHNAME completo, o diretório apontado no PATH é adicionado ao comando.

Abaixo uma lista dos parâmetros aceitos, sendo que os seguintes são obrigatórios: Aplicacao, Comando e Intervalo.

Aplicacao

Ao criar o evento, associa a aplicação relacionada ao mesmo.

Comando

Comando que será invocado para realizar a monitoração. Deve obedecer aos critérios de PLUGIN do Nagios.

O comando poderá devolver um arquivo de dump criando um arquivo cujo nome é fornecido na variável do Shell MTMON_CRON_dump.

Intervalo

Define a periodicidade que a monitoração deve ser realizada para esta sessão. Este parâmetro tem a sintaxe idêntica à crontab. O primeiro argumento é hora e o segundo o minuto:

intervalo=* *: minuto à minuto
intervalo=*/2 15,45: de duas em duas horas nos minutos 15 e 45
intervalo=* */5: de 5 em 5 minutos
intervalo=8-17 */5: de 5 em 5 minutos durante o horário comercial (das 8:00 às 17:55)

Se alguma sessão omitir algum parâmetro obrigatório, é gerado um evento informativo e a sessão é ignorada.

Os parâmetros abaixo são opcionais:

Ativo: Uma sessão de monitoração pode ser desativada informando '0' neste parâmetro.
Delay: Informa quando tempo deve ser aguardado até gerar efetivamente o evento.
Email: Define um endereço de email que será usado na criação do alerta.
Finaliza: Quando a --severidade do evento é 0 (Normal), o evento pode ser auto-finalizado. Este parâmetro é útil quando se deseja gerar eventos para estatística usados em futura análise.
Info: Ao criar o evento, inclui o parâmetro --informacao.
WeekDay: Define os dias da semana que a monitoração será realizada. Segue o mesmo padrão definido na crontab, i.é., pode assumir valores entre 0-7 (0 e 7 é domingo, 1 é segunda …).
Limite: Quando ocorre re-incidência do problema reportado, um novo evento só será gerado depois do tempo definido nesta opção. É uma forma de controle para não gerar eventos repetidos no MTMON.

Pode ser definido em minutos, horas ou dias.

Na sintaxde antiga, o parâmetro recebe 2 números n,m, onde n define o número de eventos gerados quando ocorre a identificação do problema monitorado. m define a periodicidade que um novo evento será gerado se o mesmo não for resolvido.

Consulte a opção Limite na descrição do comando mtmon_evento.pl.

Nagios: Informa o mtmon_cron.pl que o comando é um plugin do Nagios. A mensagem estará na primeira linha da saída padrão.
Notifica: Ao criar o evento, inclui o parâmetro --notifica.
Obs[N]: onde [N] pode ser 0-9. Define comentários para documentar o item monitorado.
Objeto: Ao criar o evento, inclui o parâmetro --objeto.
Origem: Ao criar o evento, inclui o parâmetro --objeto.
Repete: Ao criar o evento, inclui o parâmetro --repete.
env_xxxx: A variáveis cujo nome iniciam com env_, são exportadas para o plugin na forma de variáveis de ambiente, e podem ser acessadas no script substituindo o env por MTMON_CRON.

Se por exemplo, uma variável é definida no mtmon_cron.conf com o nome env_teste=conteudo, o script poderá usar a variável $MTMON_CRON_teste que devolverá o valor conteudo.

É possível ofuscar uma senha no arquivo de configuração. No exemplo abaixo, a senha é P@ssw0rd. Execute o comando GeraSenha.pl para criar a string com a senha:

$ /usr/local/Multitask/mtadm/bin/GeraSenha.pl --PWD default -- P@ssw0rd

Senha : PWD_2277140206673e20

No arquivo mtmon_cron.conf incluir a opção na sessão desejada:

[teste]
  ativo=1
  env_senha=PWD_2277140206673e20
  . . .

Na chamada do plugin, a variável de ambiente MTMON_CRON_senha conterá o valor P@ssw0rd e poderá ser usada normalmente.

Consulte a sessão de ofuscamento de senhas em script’s para um detalhamento deste recurso.

Servidor: Identifica o servidor que está sendo monitorado.

Por exemplo: Se o objeto da monitoração é um Switch ou um servidor Windows usando o NRPE, pode ser informado neste parâmetro um nome de identifique o hardware, e este nome será associado ao evento gerado com a opção --servidor.

7. Informações gerais

7.1. Opções padrão

Os plugins podem ser chamados com algumas opções que definirão os parâmetros que farão parte do evento gerado.

A imagem à seguir apresenta estas opções:

--origem: Origem ou cliente ao qual está associado o evento gerado. A valor de origem normalmente é o nome do cliente e se não informado, será recuperado de MTADMbase/etc/mtadm.conf.

No servidor MTMON, colocar o arquivo com a definição da origem no arquivo $MTMONbase/etc/Origem/{origem}.conf.

$MTMONbase/etc/Origem/cliente.conf:

[cliente]
  email_asefaz="exemplo@cliente.com.br, operadores@cliente.com.br"
  email_hpux="suporte@cliente.com.br, noc@multitask.com.br"
  finaliza=0
  nome="Nome do cliente"
  transkey="6py$SZtJzi.Mr" (1)

1	A TransKEY deve ser a mesma usada em MTADMbase/etc/mtadm.conf

Para cada cliente deve ser definido um arquivo

Nos servidores que rodam o agente do MTMON, configurar o arquivo MTADMbase/etc/mtadm.conf:

$MTADMbase/etc/mtadm.conf:

[Global]
  Origem="cliente" (1)
  ServerMTMON="189.45.197.30"
  Proxy=
  TransKEY="6py$SZtJzi.Mr" (2)
  ...
  UsarHTTPS=1

1	cliente está relacionado com o nome do arquivo descrito acima.
2	A TransKEY deve ser a mesma

Para cada servidor que tem o agente do MTMON instalado, o arquivo mtadm.conf deve ser copiado.

--servidor: É o nome do servidor/equipamento onde ocorreu o fato gerador do evento. O nome é livre e pode ser usado qualquer seqüência de letras e números. Não é realizada nenhuma verificação de IP e/ou DNS. O objetivo é que o MTMON seja flexível e usado em aplicações que podem ter uma nomenclatura não relacionada com TI.

Se definida a variável pServer no arquivo de parâmetros, então --servidor é opcional, pois o comando recuperará a informação do mesmo.

Por exemplo, o comando poderia ser chamado com a opção --servidor fresadora07, para definir que o evento ocorreu numa fresadora denominada fresadora07, sendo que este equipamento não necessariamente está conectado numa rede TCP/IP. O evento poderia ser identificado e gerado por um programa que monitora o equipamento usando uma porta serial RS232C ou RS422C.

--aplicacao: [shape = flowchart.terminator];

Também livre a ser definido pelo administrador do MTMON.

--objeto: [shape = flowchart.terminator]; Livre a ser definido pelo administrador do MTMON. Permite uma identificação mais precisa do equipamento/módulo/função onde ocorreu o fato gerador do evento.
--classe
--debug: Incrementa o número de informações apresentadas no cadastramento do evento.
--notifica: Este parâmetro se relaciona com os parâmetros pScriptServer e/ou pScriptClient definidos no arquivo de parâmetros. Quando o script é chamado, uma das variáveis definidas é MTMON_Notifica. O script pode assim identificar eventuais usuários/responsáveis pelo evento que está gerando a notificação.

Além desta função, na CONSOLE de monitoração é criado um link de define o procedimento que o operador deve executar. Este procedimento é realizado consultando o link que é gerado.

Por exemplo, chamando o comando com a opção --notifica ORACLE e definindo a variável ScriptServer=/usr/local/bin/TrataEvento.sh, o servidor MTMON acionará o script definido em pScriptServer e/ou pScriptClient. O script executado receberá variáveis pertinentes ao evento.

O script poderia ter o seguinte código:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
 for Grupo in -- $MTMON_Notifica
 do
   case "$Grupo" in
   ORACLE) echo "Manda SMS para responsavel do ORACLE"
           ...
   ;;
   UNIX) echo "Manda email para responsavel do UNIX"
           ...
   ;;
   esac
 done

Plugins

8. Recursos de Servidor

Os plugins apresentados nesta sessão podem ser usados em todos os Sistemas Operacionais.
Plugins para determinados Sistemas Operacionais, Storages, hardware ou integrações específicas serão apresentadas em sessões apropriadas.

8.1. Uso de área de dados

O plugin mtmon_disco.pl é responsável pela verificação da disponibilidade de área em disco ou de Volumes de dados.

O princípio para a monitoração de áreas de dados pode ser aplicado para qualquer software que conta com o conceito de volume:

área em disco (df/bdf)
tablespaces do ORACLE - para a configuração da monitoração do ORACLE, pode ser usado o script ConfiguraOracle.sh que prepara os scripts e arquivos de configuração
chunk’s do Informix
volumes do VMWare

Para isso, é necessário que seja criado o arquivo dffile definido na opção --dffile

Filesystems com status de Read Only são ignorados.

O instalador do agente do MTMON já configura automaticamente a sessão abaixo em MTMONbase/etc/mtmon_cron.conf:

[mon_filesystem]
  aplicacao=mon_filesystem
  comando=mtmon_disco.pl
  intervalo=* */15

Algumas opções específicas do plugin que merecem consideração:

--alerta: Substitui o default informado no arquivo de configuração mtmon_disco.conf.
--config: Define o nome do arquivo usado para definir os limites do volumes monitorados.
Default: MTMONbase/etc/mtmon_cron.conf
--critico: Substitui o default informado no arquivo de configuração mtmon_disco.conf.
--dfcheck: Flag que instrui o plugin à validar o tempo que o arquivo --dffile está sem alteção.
Precisa estar definido para que --tempodf seja avaliada.
Default: NULL
--dffile: Informa o arquivo que será usado com as informações dos volumes monitorados.
Se não for informado, o plugin usará o comando equivalente ao df do sistema operacional.
--fator: Usado para definir a unidade de medida em que o --dffile foi gerado.
Internamente o plugin trabalha com os tamanhos em bytes. Portanto, se o arquivo informado no --dffile está em Kb, é necessário informar o script para converter as informações para byte, definindo o fator como 1024.
Default: 1024
--html arquivo: Grava no arquivo informado o resultado da verificação das áreas de disco no formato HTML.
Quando o plugin é finalizado, o arquivo continurá disponível para consulta.
Exemplo: --html /tmp/exemplo.html
--ignore expressaoRegular: Define que o padrão informado em expressaoRegular será usado para ignorar a monitoração do Volume.

No exemplo abaixo, o plugin não irá gerar eventos para os Volumes temporários gerados pelo TSM e o outro pelo Veeam:

 comando=mtmon_disco.pl --ignorar 'C:.TSM'  (1) (2)

...

 comando=mtmon_disco.pl --ignorar /tmp/veeam/snapmnt (1)

1	Parte da sessão `[mon_filesystem]`
2	A string `C:.TSM` é a expressão regular usada para não processar o volume que atende ao critério definido. Lembre-se que o caracter `\` no pattern `C:\TSM` pode dar problema, em função da interpretação que as `ERs` fazem dos caracteres: `\`, `+` e `*`.

Consulte exemplo para ignorar tablespace UNDO

--inodes: Nos sistemas operacionais UNIX, um dos itens à ser monitorado é o uso de inodes.

Um exemplo comum é quando o diretório contém muitos arquivos.
Ex. Diretório de NFe ou o /usr/sap no SAP.
Neste caso, o comando df aponta que existe área disponível no filesystem, mas a disponibilidade de inodes foi exaurida, gerando a mensagem de disk full.
Para resolver, normalmente é necessário remover arquivos antigos ou compactar os mesmos usando o comando tar cvzf …

--nfs

Inclui na verificação diretórios montados via NFS ou CIFS.
Por default, a verificação é realizada com o df -l, que não inclui diretórios remotos.

--oracle

Flag que informa o plugin que o --dffile foi gerado pelo script do próprio MTMON e neste caso, os dados já estão em bytes.

Consulte a documentação para configuração do ORACLE.

--script

script chamado para tratar o Volume em caso de alerta.
Consulte a documentação Exemplos usando a opção --script.

--tempodf n

Tempo em horas que o arquivo --dffile pode ficar sem alteção.
Se o valor para n for 3, e o arquivo estiver à mais de 3 horas sem alteração, será gerado um evento com severidade 1.
É uma alternativa para o uso do mtmon_cda.pl.

8.1.1. Formato de dffile

O arquivo informado na opção --dffile contém as informações usadas pelo plugin mtmon_disco.pl para avaliar o status de volumes.

Abaixo um exemplo do arquivo:

 Total (Bytes) Used         Free        %Used     Autoextent Tablespace (1)
 ------------- ------------ ----------- --------- ---------- ----------
   10737418240    133955584   128188416   1,24755          1 PRD::ACESINDX
   10737418240   2253258752   473038848 20,985107          1 PRD::AUTOMA_INDEX
   10737418240   6794838016  3942580224 63,281860          1 PRD::ISDOC
   10737418240   7406092288  3331325952    68,974          1 PRD::ISOSYSTEM
   10737418240   7915241472   997654528 73,716430          1 PRD::RH_DADOS
   10737418240   5910036480  2478571520  55,04150          1 PRD::RH_INDEX
   10737418240   5467209728   824246272 50,917358          1 PRD::SYSAUX
   34359721984   2517368832  8220049408 7,3265110          1 PRD::SYSTEM
   10737418240     63700992   460587008    ,59326          1 PRD::TOOLS
   75161927680  66458746880    62914560 88,420758          7 PRD::UNDOTBS1 (2)
   10737418240   2777153536  1417150464   25,8642          1 PRD::USERS
   85899345920  74591633408 11307712512 86,836090          8 PRD::USER_DATA
   53687091200  43300749312 10386341888 80,653930          5 PRD::USER_INDEX

1	Internamente o plugin ajusta o cabeçalho no DUMP do evento para os seguintes softwares: TSM, Informix, ORACLE e vCenter.
2	Normalmente as tabelas UNDO são ignoradas na monitoração para Oracle. Veja nota à seguir.

Para ignorar as tablespace UNDO, inclua a opção --ignore undo na chamada do plugin:

 [ora_PRD_tablespace]
   aplicacao=mon_PRD
   classe=oracle
   comando=mtmon_disco.pl --oracle --servidor PRD \
      --config mtmon_tablespace.conf --ignore undo \
      --dffile /ORACLE_HOME_DIR/PRD.df
   intervalo=* */15

8.1.2. Arquivo mtmon_disco.conf

O arquivo MTMONbase/etc/mtmon_disco.conf é usado na definição dos limites usados pelo comando mtmon_disco.pl na verificação da área em disco.

Exemplo de arquivo de configuração:

 [default]
   alerta=80 % (1)
   critico=95%
   notifica=unix

 [/oracle/archive]
   alerta=0
   critico=50Mb
   notifica=oracle
   script=PATH/backupArchive.sh (2)

 [/stand]
   ignorar=1

1	O caracter `%` é apenas removido no processamento da sessão
2	Defina a opção `script` na sessão default para que o mesmo seja chamado para cada filesystem ou Volume processado.

Valores definidos entre 0 e 110 serão considerados em percentual.
RAZÃO: O limite de 110% é por conta de alguns tipos de filesystem reservarem 10% da área para o usuário root.

Valores entre 110 e 999 são usados para controle interno do plugin e não são tratados pelo programa, gerando erro de sintaxe.

Acima de 1000 será considerado valor absoluto.

Quando o limite é definido como percentual, o alerta deve ser um valor menor do que o parâmetro para crítico.
RAZÃO: Quando o filesystem está em 70% é menos crítico do que quando está em 99%.

Quando o limite é definido em termos absolutos, por exemplo, 150000, 150Kb, 10Mb ou 3Gb, o alerta deve ser um valor maior do que o parâmetro para crítico.
RAZÃO: Quando o filesystem tem 200Mb de área livre é menos crítico do que quando está com 10Mb de área livre.

As opções disponíveis para configurar o plugin são:

alerta: É a definição do limite de área usado no filesystem para gerar um evento de alerta.
critico: É a definição do limite de área usado no filesystem para gerar um evento crítico.

Se alerta=0, assume que apenas eventos críticos (vermelhos) serão reportados, ignorando eventos de alerta (amarelos).
O mesmo princípio se aplica para critico=0

notifica: Define notificações distintas para os filesystems monitorados.
ignorar: Quando um filesystem não deve ser monitorado, use esta opção e não será realizada nenhuma verificação para o mesmo.
É útil para filesystems de banco de dados que já usam toda a área de dados disponível.

Exemplo: diretório onde estão os datafiles do ORACLE ou chunks do Informix.
Neste caso, é necessário criar uma outra sessão que verifique o uso dos volumes para o Banco de Dados.

script: Esta variável define o script que será chamado quando um evento com severidade ocorrer no filesystem monitorado.
Consulte exemplo neste documento.

O nome da sessão que define o critério de verificação pode ser o nome do filesystem ou do mount point.

Para o filesystem abaixo, a sessão poderia se chamar /var ou /dev/hdb3.

 /dev/hdb3   116661  12878 97759  12% /var

Os limites para geração de eventos são definidos nas opções alerta e critico em termos de percentual ou tamanho absoluto da área livre no filesystem.
No exemplo acima temos definição nos dois formatos.

8.1.3. Exemplo usando a opção --script

Quando é definida a opção script, o mesmo é executado para cada filesystem ou Volume monitorado.
A execução será realizada para qualquer severidade.

Em diretórios de archive do ORACLE, podemos executar um backup quando o limite for alcançado,
A idéia é que a execução do backup seja realizada num limite configurado em amarelo. Assim, o script de backup pode realizar a tarefa e remover os arquivos de forma segura, dispensando o acionamento do analista responsável. Mas se o backup não conseguir liberar área suficiente e o consumo de área aumentar até o limite crítico, o acionamento será realizado.

As seguintes variáveis são repassadas para o script:

MTMON_disco_Free: área livre do filesystem
MTMON_disco_Percentual: percentual usado
MTMON_disco_Total: área total
MTMON_disco_Used: área usada
MTMON_mensagem: mensagem que será enviada no evento
MTMON_notifica: notifica do evento
MTMON_severidade: severidade do evento

Além das variáveis de shell acima, são passados 3 parâmetros de linha de comando: device, diretorio e severidade.

Considere o filesystem abaixo, em que ocorre disk full sempre que uma aplicação aborta de forma não planejada por conta da geração de um core.

 # df /home/fprint
 Filesystem    512-blocks      Free %Used    Iused %Iused Mounted on
 /dev/hd1          212992    202416    5%     1080     5% /home

Podemos criar um script, que tratará esta situação:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 #!/bin/bash (1)

 # Script chamado pelo plugin mtmon_disco.pl do MTMON.
 # No arquivo $MTMON/etc/mtmon_disco.conf e' definida a opcao script que
 # identificara este script.

 . /usr/local/bin/ComandosMT.sh

 export PS4='+ ${FUNCNAME:-main}:$LINENO '

 export MTADM_Debug=on
 export MTADM_logSize=1Gb
 export MTADM_logFile=$MTMONbase/log/trata_mtmon_disco.log
 . $MTADMbase/bin/shell_debug.sh (2)

 export device=$1
 export diretorio=$2
 export severidade=$3

 [ "$diretorio" = '/home' ] || exit 0 (3)

 $C_find /home -type f -name core -exec $C_rm -f {} \; (4)

 exit 0

1	Salve este script com o nome `MTMONbase/bin/trata_mtmon_disco.sh`
2	Consulte documentação de debug e log de shell script
3	Se o diretório NÃO É `/home,` finaliza com `rc=0`
4	Remove os arquivos com o nome `core` em `/home`

Por fim, configuramos no arquivo MTMONbase/etc/mtmon_disco.conf a opção script para que atue no filesystem quando atingir o limite definido:

 [default]
   alerta=85%
   critico=90%
   script=/usr/local/Multitask/mtmon/bin/trata_mtmon_disco.sh (1)

1	Observe que o script será chamado para todos os filesystems monitorados. Se o objetivo é atuar apenas no diretório `/home,` podemos definir a opção script na sessão correspondente

O script poderá alterar 3 dos atributos de geração do evento: mensagem, notifica ou severidade.
Para isso, é necessário executar o comando echo com as instruções desejadas para o plugin:

1
2
3
4
 echo MTMON_mensagem="Mensagem que sera substituida no evento" (1)
 echo MTMON_notifica=novo
 echo MTMON_severidade=1
 echo MTMON_nao_gerar_evento (2)

1	Exemplo de alteração de atributos do evento
2	Este comando evitará a criação do evento, pois forçará a severidade para '0' e adicionará na mensagem o texto: Ignorado pelo script script

O script abaixo foi usado por algum tempo para ajustar os filesystems do servidor MTMON:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 #!/bin/bash

 . /usr/local/bin/ComandosMT.sh

 export device=$1
 export diretorio=$2
 export severidade=$3

 case "$diretorio" in
   /usr/local/Multitask*) : ;;
   *) echo "${0##*/}:$LINENO So processa diretorios de /usr/local/Multitask"
      exit 0
   ;;
 esac
 if [ ! -d $diretorio ]
 then
   echo $FD nao eh diretorio
   exit
 fi

 $C_mount | \
   $C_grep $diretorio | \
   $C_awk '$5 = "btrfs" { exit 99 } ' (1)
 if [ $? != 99 ]
 then
   echo "$diretorio - filesystem deve ser BTRFS"
   echo
   exit
 fi

 set -- $($C_df $diretorio | $C_grep -e $diretorio)
 LV=$1
 [ -e $LV ] || exit 1
 newTotal=$(($3 * 11 / 10))
 size=$(($newTotal - $2))
 if [ $size -lt 0 ] (2)
 then
   SZ=$size'K'
   comando1="$C_btrfs filesystem resize $SZ $diretorio"
   comando2="lvreduce --yes --size $SZ $LV"
   if [ $size -gt -500 ]
   then
     echo "$diretorio : Menos de 500K de ganho. Ignorado"
   fi
   echo
   echo "   $comando1"
   echo "   $comando2"
   exit
 else
   if [ $size -lt 500 ]
   then
     echo "$diretorio : Menos de 500K de ganho. Ignorado"
     echo "   $comando1"
     echo "   $comando2"
   fi
   SZ='+'$size'K'
   comando1="$C_lvextend -L$SZ $LV" (3)
   comando2="$C_btrfs filesystem resize max $diretorio"
 fi

 echo (4)
 echo
 echo FS=$diretorio
 echo LV=$LV
 echo SZ=$SZ
 echo
 echo $comando1
 echo $comando2
 echo
 echo
 echo
 set -x (5)
 $comando1
 $comando2
 set +x
 $C_df $diretorio
 $C_btrfs filesystem show $diretorio
 exit 0

1	Neste caso os filesystems eram BTRFS
2	Redução de filesystem e Logical Volume
3	Ajusta o Logical Volume e o filesystem
4	Informações que eram incluídas no DUMP do evento gerado
5	`set -x` para ter um registro de debug dos comandos executados

8.2. Uso de CPU

O plugin mtmon_load_average.pl usa o comando uptime para identificar a carga da CPU e gerar os alertas.

[mon_load]
  Aplicacao=mon_load
  Comando=mtmon_load_average.pl -w 0,6,5 -c 0,9,8 (1)
  Intervalo=* */5

1	Neste exemplo o indicador de 1 minuto do comando `uptime` será ignorado

O comando uptime retorna a carga média de consumo de CPU, apresentando os indicadores por 1, 5 e 15 minutos.

O plugin usará esta informação para identificar se o status de alerta ou crítico será gerado.

No exemplo acima, será gerado evento crítico quando o indicador de 5 ou 15 minutos passarem de 9 e 8.
O evento será alerta se o indicador de 5 ou 15 minutos forem maiores do que 6 ou 5 respectivamente.

8.3. Controle de data de alteração de arquivos

Quando algum processo atualiza arquivos com uma periodicidade conhecida, podemos usar o mtmon_cda.pl, que monitora a data de alteração.

Por exemplo, se os arquivos de archive do ORACLE são copiados de 15 em 15 minutos, podemos incluir no script de backup um touch para criar um arquivo de controle.

No arquivo MTMONbase/etc/mtmon_cron.conf, verifique a sessão:

[mon_cda]
  aplicacao=mon_cda
  ativo=1
  comando=mtmon_cda.pl (1)
  intervalo=* */5

1	`cda` é um acrônimo de Controla Data de Alteração

Opções disponíveis para o comando mtmon_cda.pl:

--config: Define o nome do arquivo de configuração que define os padrões a serem usados na identificação dos arquivos monitorados.
Se não for informada esta opção, o programa usará o arquivo MTMONbase/etc/mtmon_cda.conf.
--notifica: Na criação de eventos identificando arquivos que atendem ao critério, é informado o parâmetro --notifica.
--debug: Um log detalhado das operações é apresentado na saída padrão.

8.3.1. Arquivo mtmon_cda.conf

O formato do arquivo é:

[Global]
  severidade=0
  aplicacao=cda

[sessao1]
  arquivo=/caminho/para/arquivo
  objeto=objeto
  severidade=2
  tempo=2 dias

[archive_PRD]
  ativo=1
  arquivo=/usr/local/Multitask/mtmon/log/backup/arch_tim.log
  severidade=2
  tempo=150 minutos

A sessão Global contém os valores padrão que serão assumidos nas sessões subseqüentes.
Cada sessão pode ter os seguintes parâmetros:

Arquivo: Define o nome do arquivo que será monitorado.
Tempo: Informa quanto tempo o arquivo pode ficar sem atualização antes de gerar um evento.
A unidade de tempo informada pode ser uma das seguintes: minuto, hora ou dia.
Omitindo a unidade de tempo, assume que o tempo informado é em segundos.
NotFoundOK: Quando o arquivo monitorado não existe, a ação padrão é gerar um evento com erro.
A opção notfoundok=1 considera que a monitoração está OK e retorna rc=0.
Severidade: Gera o evento com a --severidade informada.
Aplicacao: O evento é gerado com o nome da aplicação informado.
Objeto: O evento é gerado com o nome do --objeto informado. Se não for informada, o programa assume o nome da sessão como sendo o objeto.
Limite: O evento é gerado com o --limite informado.
Obs: Define uma observação que será usada para gerar um arquivo de DUMP para ajudar na solução do incidente.

8.4. Verificação de arquivos de log

Arquivos de log: O comando mtmon_checklog.pl analisa um arquivo de log e procura padrões de string para gerar os alertas.

Um exemplo pré-definido é a monitoração da syslog.

  [mon_syslog]
     aplicacao=mon_syslog
     ativo=1
     comando=mtmon_checklog.pl --arquivo /var/adm/syslog/syslog.log
     intervalo=* */2

Um plugin derivado é o mtmon_alert_log.pl, que é específico para monitorar o arquivo de log do ORACLE.

8.5. Validação de processos do boot

8.5.1. Linux

Em determinados momentos, o que se deseja é verificar se o ambiente não foi de alguma forma alterado.

O exemplo abaixo pode ser usado para controlar se configurações na chamada de scripts de boot foram alteradas no ambiente Fedora.

Criar um script chamado MTADMbase/bin/mtadm_cria_controles.sh com o conteúdo:

1
2
3
4
#!/bin/sh
. /usr/local/bin/ComandosMT.sh
$C_chkconfig --list > $MTADMbase/var/chkBoot.txt
exit 0

Execute o script e verifique se o arquivo MTADMbase/var/chkBoot.txt foi criado.

O arquivo criado poderá conter o seguinte à título de exemplo:

  dsm_om_connsvc  0:off   1:off   2:off   3:on    4:on    5:on    6:off
  mdmpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
  snmptrapd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
  lm_sensors      0:off   1:off   2:on    3:on    4:on    5:on    6:off
     .
     .
     .
  dkms_autoinstaller      0:off   1:off   2:on    3:on    4:on    5:on    6:off
  ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
  iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
  snmpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
  portmap         0:off   1:off   2:off   3:off   4:on    5:on    6:off
  xinetd based services:
          echo:   off
          tftp:   off
          cups-lpd:       off
          finger: off
          omni:   on
          time:   off
          krb5-telnet:    off
          time-udp:       off
          daytime:        off
          chargen:        off
          klogin: off
          daytime-udp:    off
          ktalk:  off
          rsync:  off
          echo-udp:       off
          gssftp: off
          kshell: off
          dbskkd-cdb:     off
          eklogin:        off
          chargen-udp:    off

Na seqüência, inclua o arquivo no repositório do mtwdog_files.pl com o comando abaixo:

# /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --ncd --incluir /usr/local/Multitask/mtadm/var/chkBoot.txt
Incluindo arquivo /usr/local/Multitask/mtadm/var/chkBoot.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
Controla alteracoes no boot.
.
#

O texto informado servirá de descrição para a monitoração da saída do comando.

Por fim, inclua a linha abaixo na crontab:

  10 6 * * * /usr/local/Multitask/mtadm/bin/mtadm_cria_controles.sh #

Confirme se na crontab está incluída a linha que executa o comando mtwdog_files.pl nos horários desejados.

Antes de fazer qualquer verificação dos arquivos monitorados, o comando mtwdog_files.pl irá executar o script definido na opção PreExec do arquivo de configuração. O script poderá criar outros arquivos, se desejar, e estes poderão também ser incluídos para monitoração.

8.5.2. HP-UX

A configuração para HP-UX é similar à descrita na sessão anterior.

A alteração mais expressiva ocorre no script que gera o arquivo chkBoot.txt, que pode ser conforme abaixo:

  #!/bin/sh
  . /usr/local/bin/ComandosMT.sh
  $C_find /sbin/init.d /sbin/rc* ! -type d -exec $C_ls -l {} \; -exec $C_cksum {} \; > $MTADMbase/var/chkBoot.txt
  exit 0

A criação do arquivo chkBoot.txt reflete a situação dos arquivos usados pelo HP-UX no boot do Sistema, e se houve alteração desde a última execução, isto será identificado e tratado.

Os demais itens de configuração são exatamente iguais ao Linux.

8.6. Fila de email

O plugin mtmon_postqueue.pl verifica se a fila de envio de email’s do postfix está muito elevada.

[mon_postqueue]
  aplicacao=mon_postqueue
  comando=mtmon_postqueue.pl --fila 1000 --severidade 2
 intervalo=* */15

O plugin assume que o software de email é o postfix. Para tratar email’s do sendmail, inclua a opção --sendmail.

8.7. Alterações em arquivos

O plugin mtmon_cda.pl controla a data de alteração de arquivos configurados.

É útil para identificar se replicações de archive do Oracle estão ocorrendo dentro do prazo definido.

[mon_cda]
  aplicacao=mon_cda
  comando=mtmon_cda.pl
  intervalo=* */20

8.8. Processos e daemons

O plugin mtmon_daemon.pl valida a execução de processos.

No UNIX é usado o comando ps -ef para listar os processos ativos e no Windows o comando é tasklist.

A monitoração consiste em contabilizar o número de processos que atendem aos critérios definidos no arquivo de configuração.

Os itens para monitoração são definidos no arquivo MTMONbase/etc/mtmon_daemon.conf:

[smbd]
  ppid=1
  padrao=smbd
  total=1 >=
  Severidade=2
  notifica=samba

[smbd_pid]
  ppid=1
  padrao=smbd
  total=5 <=
  Severidade=2
  notifica=samba_pid1

[cron]
  ppid=1
  padrao=cron
  total=1 >=
  Severidade=2
  notifica=unix

[lpsched]
  padrao=lpsched
  ppid=1
  severidade=2
  total=1 >=
  Notifica=lpsched

O padrão de busca será usado pelo plugin para identificar os processos monitorados.

Nas sessões smbd e smbd_pid no exemplo acima, devem existir de 1 à 5 processos com o comando smbd, com PPID=1 em execução. Este caso particular identifica quando o samba é finalizado ou termina de forma anormal, deixando os processos filho do daemon sem 'pai'.

A opção PPID=1 é usado para identificar daemons, uma vez que os processos filhos do daemon possuem PPID=pid do daamon.

As sessões cron e lpsched esperam encontrar mais de 1 processo com o comando correspondente.

A chamada do plugin pode ser feita no arquivo MTMONbase/etc/mtmon_cron.conf:

[mon_daemon]
   Aplicacao=mon_daemon
   Comando=mtmon_daemon.pl
   Intervalo=* */5

8.9. Tamanho de arquivos

Para monitorar o tamanho de arquivos use o plugin mtmon_filesize.pl. Incluir a sessão abaixo no arquivo de configuração MTMONbase/etc/mtmon_cron.conf:

[mon_filesize]
  aplicacao=mon_filesize
  comando=mtmon_filesize.pl
  intervalo=* */30

O plugin usa o arquivo mtmon_filesize.conf para definir quais arquivos serão controlados:

[PRDalert_log]
  arquivo=/oracle/PRD/admin/bdump/alert.log
  tamanho=100Mb
  NotFoundOK=1
  objeto=PRDalert_log
  severidade=1

A opção tamanho tem a seguinte sintaxe:

nnn [kmgtb] flag

onde:

nnn: define o tamanho do arquivo
[kmgtb]: opcional, informa a unidade de medida do tamanho do arquivo, que pode ser em Kb, Mb, Gb, Tb ou bytes.
flag: Pode ser: <, >, =, >= ou <=
Por exemplo, se o tamanho informado for 100Mb, o alerta será gerado se o arquivo for maior que 100Mb.
Default: >

9. Sistemas Operacionais

9.1. AIX

9.1.1. Configurar Error Logging Facility

Para integrar o MTMON com o AIX Error Logging Facility é necessário criar os objetos usados pelo ODM (Object Data Manager) do AIX.

Crie um arquivo chamado /tmp/mtmon.add com o conteúdo abaixo:

errnotify:
  en_name = "mtmon"
  en_method = "/usr/local/Multitask/mtmon/plugin/MonitoraErrpt.sh $1 $2 $3 $4 $5 $6 $7 $8 $9"

Em seguida execute o comando:

# odmadd /tmp/mtmon.add

Para consultar a configuração do ODM:

# odmget -q 'en_name=mtmon' errnotify

Para remover uma entrada do ODM:

# odmdelete -q 'en_name=mtmon' -o errnotify

Dicas para erros específicos no AIX:

errpt: DMPCHK_TOOSMALL

Para este erro, execute o comando /usr/sbin/extendlv lg_dumplv 32 hdisk0, que aumentará a área de DUMP do AIX. Abaixo um exemplo de execução:

  root@ServerAIX:/home/mtask$ lsvg -l rootvg
  rootvg:
  LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
  hd5                 boot       1       1       1    closed/syncd  N/A
  hd6                 paging     16      16      1    open/syncd    N/A
  hd8                 jfs2log    1       1       1    open/syncd    N/A
  hd4                 jfs2       32      32      1    open/syncd    /
  hd2                 jfs2       160     160     1    open/syncd    /usr
  hd9var              jfs2       17      17      1    open/syncd    /var
  hd3                 jfs2       320     320     1    open/syncd    /tmp
  hd1                 jfs2       1       1       1    open/syncd    /home
  hd10opt             jfs2       16      16      1    open/syncd    /opt
  hd11admin           jfs2       4       4       1    open/syncd    /admin
  lg_dumplv           sysdump    64      64      1    open/syncd    N/A
  livedump            jfs2       8       8       1    open/syncd    /var/adm/ras/livedump
  root@ServerAIX:/home/mtask$ lspv
  hdisk0          00f84b54ffe03923                    rootvg          active
  root@ServerAIX:/home/mtask$ /usr/sbin/extendlv lg_dumplv 32 hdisk0
  root@ServerAIX:/home/mtask$ lsvg -l rootvg
  rootvg:
  LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
  hd5                 boot       1       1       1    closed/syncd  N/A
  hd6                 paging     16      16      1    open/syncd    N/A
  hd8                 jfs2log    1       1       1    open/syncd    N/A
  hd4                 jfs2       32      32      1    open/syncd    /
  hd2                 jfs2       160     160     1    open/syncd    /usr
  hd9var              jfs2       17      17      1    open/syncd    /var
  hd3                 jfs2       320     320     1    open/syncd    /tmp
  hd1                 jfs2       1       1       1    open/syncd    /home
  hd10opt             jfs2       16      16      1    open/syncd    /opt
  hd11admin           jfs2       4       4       1    open/syncd    /admin
  lg_dumplv           sysdump    96      96      1    open/syncd    N/A
  livedump            jfs2       8       8       1    open/syncd    /var/adm/ras/livedump
  root@ServerAIX:/home/mtask$

No exemplo acima, para identificar os parâmetros do comando extendlv, observe na saída do comando lsvg -l rootvg a coluna TYPE que tenha o valor sysdump e no comando lspv, procure o hdiskN que corresponde ao Volume Group rootvg.

9.2. HP-UX

Nesta parte do documento, estão reunidas informações que são exclusivas ao sistema operacional da HP (HP-UX).

9.2.1. Recuperação do SPOOLER do HP-UX

Diariamente na execução do mtmon_doc.pl, é exportada a configuração do SPOOLER. No caso de uma ação indevida que torne o SPOOLER inoperante, o mesmo pode ser restaurado usando o comando abaixo:

 # /usr/sam/lbin/lpmgr -R -xsavedir=/usr/local/Multitask/mtmon/var/local/lp/

Verifique se a data dos arquivos é compatível com a configuração desejada.

Além desta versão, são preservadas as últimas 6 cópias no diretório MTADMbase/var/local, que podem ser recuperadas da seguinte maneira:

 # cd /usr/local/Multitask/mtmon/var/local
 # ls -l spool.cpio.*
 -rwxrwxrwx   1 root       sys          12617 Sep  6 23:51 spool.cpio.3.gz
 -rwxrwxrwx   1 root       sys          12624 Sep  7 23:51 spool.cpio.4.gz
 -rwxrwxrwx   1 root       sys          12619 Sep  8 23:51 spool.cpio.5.gz
 # rm -rf lp.old
 # mv lp lp.old
 # gunzip -c spool.cpio.4.gz | cpio -icxvdum
 # /usr/sam/lbin/lpmgr -R -xsavedir=/usr/local/Multitask/mtmon/var/local/lp/

Se os arquivos no diretório acima forem removidos, uma cópia da última configuração está disponível no site do MTMON, seguindo a seqüência:

 Origem -> Servidor -> Relatórios -> Upload -> spool.cpio.gz

Neste mesmo diretório existem vários arquivos relevantes para recuperação do ambiente dos Sistemas Operacionais.

9.2.2. EMS

O EMS Event Monitoring Service é o software nativo do HP-UX que monitora e gera alertas de problemas de hardware.

Inicie verificando se o EMS está ativo.

 # date
 Sat Apr 21 14:34:23 Brasil 2007
 # /etc/opt/resmon/lbin/monconfig

 ===========================================================================
 ====================         Event Monitoring Service
 ====================        Monitoring Request Manager
 ===========================================================================

    EVENT MONITORING IS CURRENTLY ENABLED. (1)
    EMS Version : A.04.20.23
    STM Version : C.58.00

 ===========================================================================
 ===============        Monitoring Request Manager Main Menu
 ===========================================================================

 Note: Monitoring requests let you specify the events for monitors
       to report and the notification methods to use.

 Select:
     (S)how monitoring requests configured via monconfig
     (C)heck detailed monitoring status
     (L)ist descriptions of available monitors
     (A)dd a monitoring request
     (D)elete a monitoring request
     (M)odify an existing monitoring request
     (E)nable Monitoring
     (K)ill (disable) monitoring
     (H)elp
     (Q)uit
     Enter selection: [s]

1	Mensagem referenciada na nota abaixo.

Se a mensagem EVENT MONITORING IS CURRENTLY ENABLED não aparecer, escolha a opção (E)nable Monitoring.
Escolha a opção (C)heck detailed monitoring status que fará uma checagem das monitorações disponíveis.

Verifique junto à HP se não existe um versão mais atualizada dos softwares de monitoração no endereço http://software.hp.com.

Informe em Search:: Event Monitoring Service e selecione o produto desejado.

Os eventos gerados pelo EMS podem ser tratados de 3 formas:

Integrado na monitoração da syslog com o comando mtmon_checklog.pl (forma PREFERENCIAL)
Interceptando o email gerado para o superusuário (root)
Consultando o arquivo /var/opt/resmon/log/event.log

9.2.2.1. Integração com o checklog.pl

A HP define que eventos críticos do HP-UX sejam registrados na syslog. A integração com o mtmon_checklog.pl ocorre quando é incluída a linha abaixo no arquivo de configuração MTMONbase/etc/mtmon_checklog.conf:

 #include templates/EMS.conf

Consulte a documentação do comando mtmon_checklog.pl.

9.2.3. set_fixed

O plugin MonitoraEMS.sh faz uma verificação na integridade dos itens monitorados por ele.

[mon_set_fixed]
  Aplicacao=mon_set_fixed
  Ativo=1
  Comando=MonitoraEMS.sh
  Intervalo=9 0

Este plugin é preventivo e como tal, a sugestão é que seja executado 1 vez por dia. No exemplo acima será executado às 9:00 da manhã.

9.2.4. syslog.log

O comando mtmon_checklog.pl analisa um arquivo de log e procura padrões de string para gerar os alertas.

Um exemplo pré-definido é a monitoração da syslog.

[mon_syslog]
  aplicacao=mon_syslog
  ativo=1
  comando=mtmon_checklog.pl --arquivo /var/adm/syslog/syslog.log
  intervalo=* */2

9.2.5. Processando email’s gerados pelo EMS (OBSOLETO)

Evite usar esta configuração.

Configure o arquivo /etc/mail/aliases com a definição abaixo:

root: | /usr/local/Multitask/mtmon/bin/mtmon_EMS_email.pl[, endereco@dominio.com]

A definição de endereco@dominio.com é opcional e é apresentada apenas como informativo.

Efetive a alteração com o comando:

# newaliases

Quando o EMS gerar um evento que exige a intervenção do administrador do HP-UX, será enviado um email para o root. Este email será processado pelo programa mtmon_EMS_email.pl que se encarregará de abrir um evento no MTMON.

9.2.6. Inicialização no HP-UX

Criar um arquivo de inicialização (/sbin/init.d/MTMON) com o conteúdo abaixo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#!/sbin/sh
PATH=/usr/sbin:/usr/bin:/sbin
export PATH
rval=0
case $1 in
'start_msg')
        echo "MTMON: Inicializa monitoracao da syslog"
;;
'stop_msg')
        echo "MTMON: Finaliza monitoracao da syslog"
;;
'start')
       # Inicializa controles de monitoracao da SYSLOG
        /usr/local/Multitask/mtmon/bin/mtmon_checklog.pl --preview --reset \
                 --arquivo /var/adm/syslog/syslog.log
;;
'stop')
        # Resgata a ultimas mensagens de erro da SYSLOG
        /usr/local/Multitask/mtmon/bin/mtmon_checklog.pl \
                 --arquivo /var/adm/syslog/syslog.log
;;
*)
        echo "usage: $0 {start|stop|start_msg|stop_msg}"
        rval=1
;;
esac
exit $rval

Criar os links para serem executados no boot e shutdown do HP-UX:

chmod 555 /sbin/init.d/MTMON
ln -s /sbin/init.d/MTMON /sbin/rc2.d/S730MTMON
ln -s /sbin/init.d/MTMON /sbin/rc1.d/K100MTMON

O comando na inicialização é chamado S730MTMON para ser executado imediatamente antes do cron.

9.2.7. Configuração do plugin de RAID SAS (HP-UX)

Os servidores HP podem ser configurados com uma controladora RAID que substitui o Mirror/UX. Para monitorar este recurso, existe um plugin específico, que pode ser configurado incluindo as linhas abaixo no arquivo de configuração MTMON/etc/mtmon_cron.conf:

[mon_SAS]
  aplicacao=mon_sasmgr
  comando=MonitoraSAS.sh
  intervalo=* */15

9.2.8. EVA com Secure Path

Para monitorar o Storage EVA é necessário que o Secure Path seja instalado no HP-UX. O Secure Path é um produto da HP que pode ser comprado, cuja função é otimizar e balancear o uso das fibras conectadas ao Storage. Se o produto não está disponível, procure instalar o produto Bundle evainfo, que pode ser encontrado no Google com as palavras: evainfo download hp-ux

Com o produto Secure Path instalado, configure o arquivo MTMON/etc/mtmon_cron.conf:

[mon_EVA]
  aplicacao=mon_eva
  ativo=1
  comando=MonitoraEVA.sh
  intervalo=* */15

9.2.9. EVA com sssu - Monitoração de Controladoras, disk_groups e disk

O plugin para monitorar estes itens usa o sssu, que pode ser obtido no site da HP. Procure no Google pela string: sssu download. Existem versões para HP-UX e Windows.

Depois de copiar o executável para o diretório desejado, (ex. /usr/local/bin), execute o comando inst_mtadm, para que o comando seja reconhecido pelo MTMON.

Valide com o comando abaixo:

  # grep sssu /usr/local/bin/ComandosMT.*
  /usr/local/bin/ComandosMT.pl:$Comando{'sssu'}=q(/usr/local/bin/sssu);
  /usr/local/bin/ComandosMT.sh:C_sssu="/usr/local/bin/sssu"
  /usr/local/bin/ComandosMT.sh:export C_sssu

9.2.9.1. Senha de Acesso

Para que a senha de acesso ao Command View não fique visível, use o comando abaixo:

GeraSenha.pl --PWD 'MT-3v@' SENHA

Senha : PWD_60330e0515

No caso acima, a senha 'SENHA' criará uma máscara [PWD_60330e0515], que poderá ser decodificada internamente pelo MTMON. Esta máscara é reversivel, ou seja, alguém com acesso ao ambiente, poderá decifrar a senha se tiver o conhecimento necessário. O objetivo, é apenas dificultar o acesso à senha.

9.2.9.2. Configuração do mtmon_cron.conf

Inclua as seguintes sessões no arquivo MTMONbase/etc/mtmon_cron.conf:

  [monEVA_controllers]
    aplicacao=health
    objeto=controllers
    ativo=0
    comando=mtmon_check_EVA.sh -H cv_server -U hpcv -P PWD_60330e0515 -C controllers -E EVA6400
    delay=7 minutos
    intervalo=* */5
    nagios=1
    servidor=eva6400
    notifica=storage

  [monEVA_disk_groups]
    aplicacao=health
    objeto=disk_groups
    ativo=0
    comando=mtmon_check_EVA.sh -H cv_server -U hpcv -P PWD_60330e0515 -C disk_groups -E EVA6400
    delay=7 minutos
    intervalo=* */5
    nagios=1
    servidor=eva6400
    notifica=storage

 [monEVA_disk]
    aplicacao=health
    objeto=disk
    ativo=0
    comando=mtmon_check_EVA.sh -H cv_server -U hpcv -P PWD_60330e0515 -C disks -E EVA6400
    delay=7 minutos
    intervalo=* */5
    nagios=1
    notifica=storage
    servidor=eva6400

No exemplo acima temos:

cv_server - Servidor onde está instalado o __Command View__.
hpcv      - Usuário do servidor configurado com permissão de acesso ao Storage.
EVA6400   - Nome do Storage monitorado.

A opção delay=7 minutos, é para evitar os falso/positivos abaixo:

  OK: 2 of 2 Fans are in good status
  OK: 2 of 2 Power System are in good status

  ATTENTION: controller available on this Cell: modelnumber not found

ou

  Erro na execucao do comando /usr/local/bin/sssu|
  SSSU for HP StorageWorks Command View EVA
  Version: 6.0.2
  Build: 5
  Error opening https connection

9.2.10. Recuperação do SPOOLER

Diariamente na execução do mtmon_doc.pl, nos sistemas HP-UX, é exportada a configuração do SPOOLER. No caso de uma ação indevida que torne o SPOOLER inoperante, o mesmo pode ser restaurado usando o comando abaixo:

# /usr/sam/lbin/lpmgr -R -xsavedir=/usr/local/Multitask/mtmon/var/local/lp/

Verifique se a data dos arquivos é compatível com a configuração desejada.

Além desta versão, são preservadas as últimas 6 cópias no diretório /usr/local/Multitask/mtmon/var/local, que podem ser recuperadas da seguinte maneira:

# cd /usr/local/Multitask/mtmon/var/local
# ls -l spool.cpio.*
-rwxrwxrwx   1 root       sys          12617 Sep  6 23:51 spool.cpio.3.gz
-rwxrwxrwx   1 root       sys          12624 Sep  7 23:51 spool.cpio.4.gz
-rwxrwxrwx   1 root       sys          12619 Sep  8 23:51 spool.cpio.5.gz
# rm -rf lp.old
# mv lp lp.old
# gunzip -c spool.cpio.4.gz | cpio -icxvdum
# /usr/sam/lbin/lpmgr -R -xsavedir=/usr/local/Multitask/mtmon/var/local/lp/

Se os arquivos no diretório acima forem removidos, uma cópia da última configuração está disponível no site do MTMON, seguindo a seqüência:

Origem → Servidor → Relatórios → Upload → spool.cpio.gz *

Neste mesmo diretório existem vários arquivos relevantes para recuperação do ambiente dos Sistemas Operacionais.

9.3. VMWare

O PowerCLI é o software fornecido pela VMWARE para administrar e recuperar informações do VMWare.

Os plugins de monitoração do VMWare usam os cmdlets e tem os seguintes pré-requisitos:

.NET 2.0 SP1
Windows PowerShell 3.0
VMware vSphere PowerCLI 5.5 or mais recente

O software pode ser obtido no site da VMWare ou da Multitask.

Para auxiliar na configuração dos plugins, podemos usar o script configura_vCenter.pl:

 C:\Multitask\mtmon\bin\configura_vCenter.pl (1)

1	Serão solicitados o usuário e senha com acesso Read Only ao vCenter e o MTMON identificará disponíveis para configurar.

Valide se o Windows está configurado para permitir a execução de script’s no Powershell.
Se necessário ajustar a permissão, use o comando abaixo:

  Set-ExecutionPolicy Unrestricted

Para configurar os plugins, é necessário primeiro definir o usuário e senha para acessar as informações usadas para monitorar o ambiente do VMWare.

Crie um usuário/senha com permissões de acesso ao VMWare somente Read Only.

Crie em C:\Multitask\mtadm\etc\mtadm_salt.conf uma entrada com a sessão chamada vcenter:

 [vcenter]
   salt=ubVsY9uIufk72

Consulte documentacão sobre senha ofuscada.

 C:/Multitask/mtadm/bin/GeraSenha.pl --PWD vcenter -- <# SenhaUsuario_vCenter #>
 Senha : PWD_6aa04b1d11440f (1)

1	A senha criada nesta etapa, será usada em todos os plugins que usam os cmdlets da VMWare.

Para validar se a senha está OK, execute o comando abaixo:

 C:\Multitask\mtadm\bin\getPWD.pl --PWD vcenter -- PWD_6aa04b1d11440f
 SenhaUsuario_vCenter

Num ambiente que contém mais de um vCenter, a sessão definida acima pode ser copiada, e com isso, a mesma senha poderá ser usada nos diversos servidores.

Crie a sessão abaixo no arquivo C:\Multitask\mtmon\etc\mtmon_cron.conf:

 [mon_vcenter_df]
   aplicacao=mon_vcenter_df
   classe=vmware
   comando=mtmon_disco.pl --dffile C:/Multitask/tmp/vCenter.df --config mtmon_vcenter.conf --fator 1
   env_pwd=PWD_6aa04b1d11440f (1)
   env_user=ro_user (2)
   intervalo=* */15
   preexec=C:\Multitask\mtadm\bin\powershell.cmd C:\Multitask\mtmon\bin\GeraArquivos_vCenter.ps1 (3)
   salt=vcenter

1	Criado pelo programa `GeraSenha.pl`
2	Se o usuário pertence ao domínio do cliente: `env_user=ro_user@cliente.ad`
3	O script é executado antes do comando e criará o arquivo vCenter.df, que conterá as informação necessárias para monitorar os datastores do vCenter.

No diretório C:\Multitask\tmp será criado o arquivo vCenter.df que poderá ser consultado:

 C:\Multitask>dir C:\Multitask\tmp\vCenter.df
  Volume in drive C has no label.
  Volume Serial Number is XXXX-XXXX

  Directory of C:\Multitask\tmp

 25/08/2015  22:31             5.351 vCenter.df
                1 File(s)          5.351 bytes
                0 Dir(s)  32.334.045.184 bytes free

 C:\Multitask> type C:\Multitask\tmp\vCenter.df (1)
 Total (Bytes) Used (Bytes)  Free (alocado) %Used Id           Datastore
 ------------- ------------- -------------- ----- ------------ ----------
  291252469760   22752002048   268500467712     8 Datastore-1  DC_JVE::Local_ESX_A
  291252469760    4499439616   286753030144     2 Datastore-2  DC_JVE::Local_ESX_B
  590826438656  178368020480   412458418176    30 Datastore-3  DC_JVE::Local_ESX_C
  536602476544  465311891456    71290585088    87 Datastore-4  DC_JVE::VM001
  536602476544  209621876736   326980599808    39 Datastore-5  DC_JVE::VM002
  536602476544  418119680000   118482796544    78 Datastore-6  DC_JVE::VM003
  536602476544  392489336832   144113139712    73 Datastore-7  DC_JVE::VM004

1	Estas informações serão usadas pelo plugin mtmon_disco.pl para gerar eventos quando os limites definidos forem atingidos.

Para garantir que o arquivo vCenter.df está sendo atualizado, podemos incluir a sessão abaixo no arquivo C:\Multitask\mtmon\etc\mtmon_cda.conf:

 [vCenter.df]
   notFoundOK=1 (1)
   classe=vmware
   arquivo=C:\Multitask\tmp\vCenter.df
   objeto=vcenter
   severidade=1
   Tempo=2 horas

1	Avalie se o arquivo não existir é aceitável

Depois, ativar o plugin correspondente no mtmon_cron.conf:

 [mon_cda]
   aplicacao=mon_cda
   comando=mtmon_cda.pl
   intervalo=* */20

10. SAN e Storages

10.1. Monitoração de Switch de SAN

A monitoração de Switch usa o plugin mtmon_check_switch.sh. É necessário instalar o Net-SNMP para disponibilizar o comando snmpwalk, que faz a consulta nos DEVICES via SNMP.

Valide a instalação com o comando:

 # type snmpwalk
 snmpwalk is hashed (/usr/bin/snmpwalk)
 # type snmpget
 snmpget is /usr/bin/snmpget
 # grep snmp /usr/local/bin/ComandosMT.sh (1)
 C_snmpget="/usr/bin/snmpget"
 export C_snmpget
 C_snmpwalk="/usr/bin/snmpwalk"
 export C_snmpwalk

1	`ComandosMT.sh` é um script com o PATH dos comandos do Sistema Operacional usados pelo MTMON.

Se o Net-SNMP está instalado e a validação acima não encontrou os arquivos, execute novamente o atualizador de agente do MTMON: cpzip.
No processo o arquivo ComandosMT.sh será atualizado.

Para cada Switch de SAN monitorado, é necessário criar uma sessão no arquivo mtmon_cron.conf:

 [172.21.250.50]
   aplicacao=health
   notifica=storage
   comando=mtmon_check_switch.sh -H 172.21.250.50 -T status -C public -D 'Switch Fabric1' (1)
   intervalo=* */5
   nagios=1
   servidor=swsan1

1	O plugin `mtmon_check_switch.sh` está na base do Exchange Nagios e foi convertido para integrar no MTMON Para monitorar as portas individuais do Switch, consulte a documentação portas de switch.

 # cd /usr/local/Multitask/mtmon/plugin
 # ./mtmon_check_switch.sh -H 172.21.250.50 -C public -T status -D 'Descricao'
 chgMTMON_JSON_classe=rede
 chgMTMON_scriptgerador=mtmon_check_switch.sh
 chgMTMON_JSON_args=-H 172.21.250.50 -C public -T status -D Descricao
 Descricao - Status do device: OK|

 IP: "172.21.250.50"
 Produto: "Access Gateway."
 Numero serial: "BRBEZJ1935M03X"

 TEMP #1 = type 3 is OK, value is 27
 TEMP #2 = type 3 is OK, value is 27
 TEMP #3 = type 3 is OK, value is 29
 FAN #1 = type 4 is OK, value is 6308
 FAN #2 = type 4 is OK, value is 6308
 FAN #3 = type 4 is OK, value is 6308
 Power Supply #1 = type 5 is OK, value is 1

 Gerado pelo script ./mtmon_check_switch.sh em 01/01/2021 12:54:54 - Servidor lnx64

10.2. Monitoração portas de Switch

Para monitorar as portas de switch, o programa mtmon_portas.pl poderá ser usada.

O plugin suporta as seguintes opções:

--endereco: IP do Switch
--nome: Nome atribuído na criação do evento no MTMON.
Default: switch_X.X.X.X onde X.X.X.X é o IP do DEVICE.
--comunidade: Nome da comunidade SNMP do Switch monitorado.
Default: public
--versao: Versão do SNMP usada para obter as informações. Pode ser 1 ou 2c.
Default: 2c

Execute o comando abaixo, tendo como base o nome swsan1 e o IP 172.21.250.50:

 # cd /usr/local/Multitask/mtmon/plugin
 # ./mtmon_portas.pl --endereco 172.21.250.50 --nome swsan1 --finaliza --debug
 # ./mtmon_portas.pl --endereco 172.21.250.50 --nome swsan1 --finaliza --debug (1)

1	É necessário executar o plugin `2x.` Veja nota abaixo.

Na primeira execução, não será criado nenhum evento na console do MTMON, apenas os arquivos de controle interno do plugin, são criados.
Na segunda execução, serão criados os eventos na console do MTMON. A opção --finaliza é usada para não poluir a console do NOC em caso de erros identificados.

Abaixo, exemplo de arquivo de configuração criado:

 # cat /usr/local/Multitask/mtmon/etc/switch_swsan1.conf (1)
 [default]
   severidade_error=1 (2)
   severidade_operstatus_error=1
   severidade_speed_error=1

 [p_1073741824]
   descricao=FC port 0/0 - fibreChannel
   operstatus=down
   speed=8000 (3)

 [p_1073741825]
   descricao=FC port 0/1 - fibreChannel
   operstatus=up
   speed=8000

 [p_1073741826]
   descricao=FC port 0/2 - fibreChannel
   operstatus=up
   speed=8000

1	Arquivo de configuração criado na primeira execução. Sempre que houver mudança na configuração do switch, será gerado evento no MTMON com a severidade definina na sessão default
2	A severidade pode ser alterada para 2 (crítico)
3	Valide se as velocidades estão corretas e ajuste de acordo com a necessidade de cada porta

severidade_operstatus_error: alteração do status da porta, ex.: de up para down.
severidade_speed_error: alteração na velocidade da porta monitorada.
severidade_error: outros erros na porta.

Para cada porta identificada, as informações de monitoração são guardadas na sessões correspondente:

 [p_1073741825]
   descricao=FC port 0/1 - fibreChannel
   operstatus=up
   speed=8000

onde:

descricao: identifica a porta do Switch
operstatus: Estado esperado da porta monitorada. Pode ser up ou down
speed: Velocidade esperada da porta

Se o valor obtido para operstatus ou speed for diferente do esperado, gera alerta na severidade definida em severidade_operstatus_error ou severidade_speed_error.
Os demais eventos serão gerados com a severidade definida em severidade_error.

Será gerado evento de erro para os itens inDiscards, inErrors, inUnknownProtos, outDiscards e outErrors.

10.3. Storages da EMC

10.3.1. powerpatch

Com o produto powerpatch instalado, inclua a sessão abaixo no arquivo MTMONbase/etc/mtmon_cron.conf:

 [mon_EMC]
   aplicacao=mon_emc
   comando=MonitoraEMC.sh
   intervalo=* */15

10.3.2. Monitoração de Recovery Point

O plugin Monitora_EMC_RecoveryPoint.sh pode ser usado para monitorar o status do Recovery Point de storages EMC.

Inclua a seguinte sessão no arquivo MTMONbase/etc/mtmon_cron.conf:

 [monEMC_RecoveryPoint]
   aplicacao=storage
   objeto=rp
   comando=Monitora_EMC_RecoveryPoint.sh -w 10% -c 25% -h admin@172.16.200.200
   intervalo=* */15
   nagios=1
   notifica=storage
   servidor=emc_rp

Configure o ssh no Storage de modo à permitir o acesso sem senhas, usando uma chave pública, que será usada pelo script.
Se o usuário root, do servidor que está executando o plugin, tem acesso direto via ssh ao Storage, definindo a opção -h na sessão acima é suficiente para a execução do plugin.

Se o usuário root não tem acesso direto com a sua chave privada, é necessário configurar o arquivo Monitora_EMC_RecoveryPoint.local no mesmo diretório onde está localizado o plugin, para associar uma chave SSH específica do Recovery Point:

  # cat Monitora_EMC_RecoveryPoint.local
  export cmdConexaoStorage="$C_ssh -i /root/.ssh/id_rsa_recovery_point admin@172.16.200.200"

Se existir mais de 1 consistency group no Recovery Point com alerta, será gerado apenas 1 evento, com a maior gravidade encontrada.
Isso significa, que o responsável pelo ambiente, deve avaliar o contexto inteiro do Storage, ao corrigir a situação.
A razão disso, é para evitar massivas de eventos.

10.4. Storages da HP

10.4.1. 3Par

O plugin mt_check_3par usa uma conexão ssh para verificar o status de storage 3PAR.
Para permitir o acesso ao storage, é necessário configurar o cliente do storage para aceitar conexões SSH sem senha.

Se ainda não tem a chave SSH configurada, execute o comando abaixo, que gera a chave RSA:

 # ssh-keygen -t rsa -b 2048
 # cat ~/.ssh/id_rsa.pub
 ssh-dss ABAAB3NzaC1kc3MAAACBAN1DPr6fE7oBiXkMWXY ... 0SxmBtdHhPmRiwc= root@mtmon

De posse da chave pública que será usada no storage, conecte com o usuário que será usado para monitorar e execute o comando setsshkey:

  # ssh 3parcli@192.168.0.250
  Password: [SENHA]
  3par01 cli% setsshkey (1)
  Please enter the SSH public key below.  When finished, press enter twice.
  The key is usually long.  It's better to copy it from inside an editor
  and paste it here.  (Please make sure there are no extra blanks.)
  The maximum number of characters used to represent the SSH key
  (including the "from" option, key type, and additional comments) is 4095.

  ssh-dss ABAAB3NzaC1kc3MAAACBAN1DPr6fE7oBiXkMWXY ... 0SxmBtdHhPmRiwc= root@mtmon (2)

  SSH public key successfully set.
  3par01 cli% Connection to 192.168.0.250 closed.

1	setsshkey é o comando executado no prompt do Storage
2	Copie e cole a chave completa

Na próxima execução do SSH, o acesso deve ocorrer sem pedir a senha.

Execute o comando MTMONbase/bin/Configura3PAR.sh 3parcli@192.168.0.250 para criar as sessões no arquivo MTMONbase/etc/mtmon_cron.conf que executação os comandos de monitoramento do storage 3PAR.

10.4.2. EVA com Secure Path

Para monitorar o Storage EVA é necessário que o Secure Path seja instalado no HP-UX.
O Secure Path é um produto da HP que pode ser comprado, cuja função é otimizar e balancear o uso das fibras conectadas ao Storage.
Se o produto não está disponível, procure instalar o produto Bundle evainfo, que pode ser encontrado no Google com as palavras: evainfo download hp-ux

Com o produto Secure Path instalado, configure o arquivo MTMONbase/etc/mtmon_cron.conf:

 [mon_EVA]
   aplicacao=mon_eva
   ativo=1
   comando=MonitoraEVA.sh
   intervalo=* */15

10.4.3. EVA com sssu

O plugin mtmon_check_EVA.sh permite a monitoração de controladoras, disk_groups e disk.

O plugin usa o sssu para recuperar as informações do Storage.

Procure no Google pela string sssu download.
Existem versões para HP-UX e Windows.

Depois de copiar o executável para o diretório desejado, (ex. /usr/local/bin), execute o comando inst_mtadm, para que o comando seja reconhecido pelo MTMON.

10.4.3.1. Configuração do mtmon_cron.conf

Inclua as seguintes sessões no arquivo MTMONbase/etc/mtmon_cron.conf:

 [monEVA_controllers]
   aplicacao=health
   objeto=controllers
   comando=mtmon_check_EVA.sh -H cv_server -U hpcv -P PWD_60330e0515 -C controllers -E EVA6400 (1)
   delay=7 minutos
   intervalo=* */5
   nagios=1
   servidor=eva6400
   notifica=storage

 [monEVA_disk_groups]
   aplicacao=health
   objeto=disk_groups
   comando=mtmon_check_EVA.sh -H cv_server -U hpcv -P PWD_60330e0515 -C disk_groups -E EVA6400
   delay=7 minutos
   intervalo=* */5
   nagios=1
   servidor=eva6400
   notifica=storage

[monEVA_disk]
   aplicacao=health
   objeto=disk
   comando=mtmon_check_EVA.sh -H cv_server -U hpcv -P PWD_60330e0515 -C disks -E EVA6400
   delay=7 minutos
   intervalo=* */5
   nagios=1
   notifica=storage
   servidor=eva6400

1	Consulte a sessão de ofuscamento de senhas em script’s para gerar a senha no formato PWD_xxxx

No exemplo acima temos:

cv_server: Servidor onde está instalado o Command View.
hpcv: Usuário do servidor configurado com permissão de acesso ao Storage.
EVA6400: Nome do Storage monitorado.

A opção delay=7 minutos, é para evitar os falso/positivos abaixo:

 OK: 2 of 2 Fans are in good status
 OK: 2 of 2 Power System are in good status

 ATTENTION: controller available on this Cell: modelnumber not found

 Erro na execucao do comando /usr/local/bin/sssu|
 SSSU for HP StorageWorks Command View EVA
 Version: 6.0.2
 Build: 5
 Error opening https connection

11. Hardware

11.1. Dell

A monitoração do hardware da Dell usa o software Dell OpenManage Server Administrator Managed Node.

O link acima aponta para o software na versão Windows.

Para o Sistema Operacional Linux, a instalação pode ser feita com o usuário root, executando os comandos abaixo:

 # wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
 # yum -y install srvadmin-all
 # /opt/dell/srvadmin/sbin/srvadmin-services.sh restart
 # yum -y install dell_ft_install
 # yum -y install $(bootstrap_firmware)

Para os servidores com up2date, os comandos são:

 # up2date -i srvadmin-all
 # /opt/dell/srvadmin/sbin/srvadmin-services.sh restart
 # up2date -i dell_ft_install
 # up2date --solvedeps=$(bootstrap_firmware -u)

Depois de instalado o software OMSA - OpenManage Server Administrator Managed, execute os comandos abaixo para configurar o agente do MTMON:

 # sh /usr/local/Multitask/inst_mtadm
 # sh /usr/local/Multitask/inst_mtmon_client
 # /usr/local/Multitask/mtmon/bin/config.pl

No Windows:

 C:\Multitask\mtmon\bin\Install.bat
 C:\Multitask\mtmon\bin\config.pl

Em algumas instalações o software de monitação da Dell ou o firmware do equipamento está desatualizado e com isso gera eventos de alerta com a mensagem:

 Problema no array Ctrl=0. Status: Non-Critical

Para estes casos o procedimento correto é atualizar o firmware do hardware e a versão do software de monitoração da Dell (OMSA).
Se a atualização não é possível, inclua a opção --ignora_warnings, que informa ao plugin para ignorar especificamente este alerta.

Para evitar eventos desnecessários, execute o comando abaixo, para uma visualização prévia do status do servidor:

 # omreport chassis (1)
 Health

 Main System Chassis

 SEVERITY : COMPONENT
 Ok       : Fans
 Ok       : Intrusion
 Ok       : Memory
 Ok       : Power Supplies
 Ok       : Processors
 Ok       : Temperatures
 Ok       : Voltages
 Critical : Hardware Log
 Ok       : Batteries

1	O comando no Windows é o mesmo.

Se o Hardware Log está com severidade Critical, execute os seguintes comandos para limpar os logs:

 # omconfig system alertlog action=clear
 # omconfig system cmdlog action=clear
 # omconfig system esmlog action=clear

11.2. IPMI

O Intelligent Platform Management Interface (IPMI) é um padrão para controlar dispositivos para monitorar o hardware do Sistema.

Uma documentação interessante é fornecida pela Oracle em Using IPMItool to View System Information

O plugin usa o programa ipmitool que pode ser instalado no Linux com o comando:

 # yum -y install ipmitool

Para não dar um reboot no Linux, execute os comandos para ativar no kernel o IPMI:

 # modprobe ipmi_msghandler
 # modprobe ipmi_devintf
 # modprobe ipmi_si

Para incluir o plugin na monitoração, configure no arquivo MTMONbase/etc/mtmon_cron.conf a sessão abaixo:

 [mon_ipmitool]
   aplicacao=mon_ipmitool
   ativo=1
   comando=Monitora_ipmitool.sh
   finaliza=1
   intervalo=* */20
   nagios=1

12. Integrações

O agente do MTMON pode ser integrado com outros softwares, gerando eventos para acionamento e ações no NOC da Multitask.
É uma dupla checagem da monitoração do sistema.

A definição abaixo é apenas uma recomendação.
Não é pré-requisito para integrar com o software base usado.

Para isso, sugerimos que sejam configurados os seguintes plugins:

Área em disco - mtmon_disco.pl
Muitos problemas de monitoração envolvem disk full.
daemon para validar se o programa usado pelo software base está em execução - mtmon_daemon.pl
Exemplo: O daemon do Zabbix, Nagios ou qualquer outro programa que aciona agente do MTMON pode abortar a execução e neste caso a monitoração é interrompida silenciosamente.
Validação da comunicação entre o agende e os servidores do MTMON no NOC daMultitask - mtmon_sinaliza_live.pl
Valide na origem deste servidor, a configuração do arquivo mtmon_audit_live.conf se o tempo definido é aceitável para este ambiente.
Para controlar a alteração de arquivos do ambiente, configure o sub-sistema mtwdog_files.pl.
Ao incluir o script usado para integrar com o MTMON, um histórico é preservado no próprio servidor.

12.1.1. Integração com syslog

O Fortigate pode ser monitorado, redirecionando as mensagens de alerta para a syslog de algum servidor linux.

A instalação do servidor de rsyslog, pode ser encontrada em Integração do rsyslog com o MTMON.

No servidor de syslog, incluir a seguinte linha no arquivo /etc/rsyslog.conf:

local5.*    /usr/local/Multitask/mtmon/log/mtmon.log (1)

1	Atente para o local5 que será usado na configuração do Fortigate

Execute os comandos service para substituir o syslog:

# service rsyslog restart
Starting system logger:           [  OK  ]

Valide se as mensagens estão sendo recebidas pelo novo syslog:

logger -p local5.info 'Teste de MTMON' (1)

1	Consulte o arquivo /usr/local/Multitask/mtmon/log/mtmon.log

No fortigate, acesse o menu Log&Report na janela à esquerda, seguido por Log Config e Log Setting.

Marque a opção syslog
Informe o endereço do servidor Linux que receberá as mensagens na syslog
Na opção mininal log level, selecione Error
Na opção Facilility, selecione local5

Confira na imagem abaixo:

Conectar no Fortigate via ssh:

# ssh admin@[IP]
     ...
config log syslogd setting
set status enable
set server 192.168.0.73
set port 514
set facility local5 (1)
set loglevel error
end
config log syslogd filter
set severity error
end
exit

1	A configuração de local5 pode ser consultada no link.

Substituir o endereço 192.168.0.73 definido no exemplo acima, pelo endereço do servidor de syslog da empresa.

12.1.2. Fortigate usando SCP

A configuração do Fortigate pode ser salva em formato texto, usando o comando SCP.

Acesse o Fortigate

 ssh admin@[IP]

Identifique qual é a interface interna, para permitir que o acesso via ssh seja realizado somente à partir da Intranet da empresa

config system interface
edit interface1
set allowaccess ping https ssh
end

Libere o uso do comando scp

config system global
set admin-scp enable
end

Inclua uma chave pública de SSH para o acesso direto ao Fortigate

config system admin
edit admin
set ssh-public-key1 "ssh-rsa AAAA ... xyz== mtadm - Chave para backup de Fortigate"
set ssh-public-key2 "ssh-rsa AAAA ... xyz== Outra chave da empresa" (1)
next
end

1	Outras chaves podem ser incluidas incrementando o comando set ssh-public-keyN

Para configurar o acesso via ssh, conecte via browser e acesse a console do Fortigate clicando na sessão CLI Console:

Quando o Fortigate está configurado para permitir o acesso via ssh, recomendamos que seja usado um cliente de SSH, por exemplo o PuTTY, pois assim podemos copiar e colar os comandos abaixo.

Link com as instruções para criar as chaves no PuTTY: http://www.dc.ufscar.br/suporte/nossa-rede/acesso-remoto/ssh-usando-putty

Execute um vez o comando:

/usr/local/Multitask/mtadm/bin/SalvaConfiguracaoFortigate.sh 10.0.14.254 fg60c (1)

1	Na primeira execução a host_key do Fortigate será incluída no know_hosts do servidor local.

Inclua na crontab uma entrada para salvar a configuração do FortiGate

20 * * * * /usr/local/Multitask/mtadm/bin/SalvaConfiguracaoFortigate.sh 10.0.14.254 fg60c (1)

1	Neste exemplo, será criado um backup do FortiGate cujo IP é 10.0.14.254. Será criado o arquivo MTMONbase/var/fortigate/fg60c.config. O script também incluirá o arquivo no mtwdog.

O mtwdog pode ser configurado para gerar eventos no MTMON quando houver alterações no Fortigate.

Para gerar eventos em vermelho, execute:

mtwdog_files.pl --severidade 2 --arquivo /usr/local/Multitask/mtmon/var/fortigate/fg60c.config

12.2. INFORMIX

Estão disponíveis 2 plugins para monitoração do INFORMIX:

mtmon_alert_log.pl: busca padrões de mensagens de erro no arquivo de log do INFORMIX (alert.log).
mtmon_disco.pl: avalia os chunk’s (áreas dados do Informix) de forma semelhante ao df no UNIX.

12.2.1. alert.log

O plugin mtmon_alert_log.pl consulta o arquivo alert.log (log do INFORMIX) definido na chamada do programa ou no arquivo de configuração mtmon_alert_log.conf.

Incluir no arquivo MTMONbase/etc/mtmon_cron.conf a entrada abaixo:

 [informixTST]
   ativo=0
   Intervalo=* */15
   Comando=mtmon_alert_log.pl --config mtmon_informix_log.conf --arquivo /opt/informix/logs/online_tst.log
   Objeto=tst
   Aplicacao=mon_informixTST
   Notifica=informix

Observe a opção ativo=0.
O objetivo é lembrar que antes de liberar esta monitoração é necessário inicializar os controles internos do plugin, evitando assim uma massiva de eventos associados às mensagens anteriores no arquivo de log.

Para inicializar os controles, execute o comando abaixo:

 # /usr/local/Multitask/mtmon/plugin/mtmon_alert_log.pl --arquivo /opt/informix/logs/online_tst.log --objeto=tst --config mtmon_informix_log.conf --preview --reset --debug   (1) (2) (3)

1	O arquivo `/opt/informix/logs/online_tst.log` é fornecido pelo DBA do Informix
2	A opção `--preview` não enviará nenhum evento para o servidor do MTMON
3	As opções `--reset` e `--debug` nos ajudam na identificação de padrões que queremos ignorar ou gerar eventos

12.2.2. Área livre nos arquivos do INFORMIX

O plugin mtmon_disco.pl foi adaptado para suportar a verificação de áreas de dados do INFORMIX.
A configuração é composta de 2 fases:

Criação de um arquivo que apresenta as áreas de dados no formato do comando df/bdf do UNIX.
Chamada do mtmon_disco.pl com as opções que suportam esta configuração.

12.2.2.1. Script para criar o arquivo dffile

O primeiro passo para monitorar uma áreas de dados do INFORMIX é configurar o script que gera um arquivo no formato abaixo:

Total       Used        Free (alocado) %Used       Autoextent      Chunck
----------- ----------- -------------- ----------- ----------- ----------
 2048108544      108544        1000000     99.9947           0 TST::tempdbs1
 2048108544      108544        1000000     99.9947           0 TST::tempdbs2
 2048108544      108544        1000000     99.9947           0 TST::tempdbs3
 2048108544      466944         999825     99.9772           0 TST::sdstempdbs1

O script /usr/local/Multitask/mtmon/bin/Gera_dffile_informix.sh depende de um arquivo de configuração com as variáveis do Informix, chamado /usr/local/bin/DefineVariaveisInformix.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
 export INSTANCIA=PRD

 export DBDATE=dmy4/
 export DSMI_INF_DIR=/opt/informix/lib
 export DSMI_LOG=/opt/informix
 export DSM_LOG=/opt/informix
 export HOME=/home/informix
 export HOSTNAME=stoldb01.marfrig.com.br
 export INFORMIXDIR=/opt/informix
 export INFORMIXSERVER=prd_soc_01
 export INFORMIXTERM=termcap
 export LANG=en_US.UTF-8
 export LD_LIBRARY_PATH=:/opt/informix/lib:/opt/informix/lib/esql
 export ONCONFIG=onconfig.prd
 export PATH=/usr/local/bin:/bin:/usr/bin:/opt/informix/bin:/home/informix/bin
 export SHLVL=2
 export TERM=vt100
 export USER=informix

As definições export no script acima podem ser obtidas com o comando env com o usuário do informix:

# su - informix
$ env > env.txt

Ajuste as variáveis de modo que possam ser executadas na crontab do servidor monitorado.

Execute o script e valide se o arquivo $INSTANCIA.informix.df é criado corretamente.

Depois de validar o arquivo gerado, incluir na crontab do usuário informix o script criado acima:

14,29,44,59 * * * * /usr/local/Multitask/mtmon/bin/Gera_dffile_informix.sh #

Observe que os minutos correspondem ao minuto anterior configurado na sessão definida no arquivo MTMONbase/etc/mtmon_cron.conf, para que o arquivo DB.df possa ser atualizado antes da execução do plugin mtmon_disco.pl.

12.2.2.2. Configuração do mtmon_cron.conf

Uma vez que o arquivo dffile foi gerado no formato esperado, incluir no arquivo MTMONbase/etc/mtmon_cron.conf a entrada abaixo iniciará a monitoração da áreas de dados desejada.

[mon_DB]
  aplicacao=mon_DB
  comando=mtmon_disco.pl --config mtmon_tablespace.conf --dffile /informix/DB.informix.df
  intervalo=* */15
  notifica=informix

Para cada Banco de Dados do INFORMIX que se deseja monitorar, é necessário criar uma entrada correspondente.

Observe que o nome da sessão e a aplicacao deve iniciar por mon e sugere-se que o fim seja o nome do banco de dados do INFORMIX que é monitorada.

12.3. Monitoração de logs

Os arquivos de log podem ser monitorados procurando padrões de string.

O exemplo abaixo é para monitorar o Fortigate, configurado para gerar mensagens na syslog:

Mensagem do Fortigate registrada em syslog

Jun  3 15:26:51 date=2013-06-03 time=14: 27:04 devname=IDUFGFW01 device_id=FGT60C3G12015686 log_id=0104032002 type=event subtype=admin pri=alert vd=root user="soporte" ui=ssh(200.68.44.244) action=login status=failed reason="name_invalid" msg="Administrator soporte login failed from ssh(200.68.44.244) because of invalid user name"

Para que o plugin do MTMON (mtmon_checklog.pl) possa processar a mensagem, é necessário que o mesmo esteja configurado no mtmon_cron.pl:

[mon_syslog]
  aplicacao=mon_syslog
  comando=mtmon_checklog.pl --arquivo /usr/local/Multitask/mtmon/log/mtmon.log --zeralog
  intervalo=* */2

No arquivo de configuração do plugin, inclua a seguinte sessão:

[FGT60C3G12015686]
  servidor=idufgfw01
  severidade=1
  padrao=^... [\s\d]\d \d\d:\d\d:\d\d .+dev(ice_)?id=FGT60C3G12015686.+(pri|level)=(\w+).+msg=\"([^\"]+)\"?
  mensagem={p3}: {p4}
  ignorar=Administrator a login failed from .+ because of invalid user name
  ignorar=Administrator admin login failed from
  ignorar=Configuration is changed in the admin session
  ignorar=Disk logs exceed full final warning threshold. Deleted rolled log file
  ignorar=Log disk is 100% full
  ignorar=Login disabled from IP .+seconds because of \d+ bad attempts
  ignorar=progress IPsec phase
  ignorar=iprope_in_check.. check failed, drop

onde:

FGT60C3G12015686: é o nome do device que está gerando o evento.
idufgfw01: nome do dispositivo no MTMON.

Se o Fortigate é configurado com log rotate automático, inclua a linha abaixo, pois a mensagem informa que parte do log será perdido:

ignorar=Log disk failure is imminent, logs should be backed up

12.4. ORACLE

Estão disponíveis os seguintes plugins para monitoração do ORACLE:

mtmon_alert_log.pl: permite filtrar o arquivo de log do ORACLE (alert.log) para identificar erros.
ValidaDiretoriosArchive.sh: busca por arquivos com mais de 12 horas nos diretórios de archive do ORACLE, o que sinaliza erro nos backup’s de archive.
mtmon_disco.pl: customizado para tratar as tablespaces de forma semelhante ao comando df no UNIX.
MonitoraOracleUNDO.sh: customizado para identificar a tabela de UNDO/ROLLBACK que estão no limite de área livre.

Para configurar os plugins num servidor ORACLE, o comando ConfiguraOracle.sh pode ser usado para identificar o usuário e instâncias que existem no servidor.

Quando servidor não tem ORACLE instalado, a mensagem de retorno será a seguinte:

# /usr/local/Multitask/mtmon/bin/ConfiguraOracle.sh
Nao foi possivel reunir informacoes sobre o ORACLE para configurar

As informações são avaliadas e os arquivos de configuração são configurados. No exemplo abaixo, o script identificou 2 instâncias de ORACLE:

# /usr/local/Multitask/mtmon/bin/ConfiguraOracle.sh

28/07/2017 12:03:16 Potenciais instancias de ORACLE [2]:
	Instancia=fabrica          Usuario=oracle
	Instancia=producao         Usuario=oracle

28/07/2017 12:03:16 Processando: ORACLE_SID=fabrica, dbuser=oracle

Servidor=srv_oracle.cliente.local
Usuario ORACLE=oracle
ORACLE_SID=fabrica
ORACLE_HOME=/ORACLE/PATH

28/07/2017 12:03:16 TNS_ADMIN=/ORACLE/PATH/network/admin
28/07/2017 12:03:16 sqlplus=/ORACLE/PATH/bin/sqlplus
Gerando controles para o arquivo de log:
/ora01/app/oracle/diag/rdbms/fabrica/trace/alert_fabrica.log : 14.93 Mb

Servidor : srv_oracle.cliente.local
Versao instalada : 5.002.046
Instalando inst_mtadm.5.2.46


x - created lock directory _sh67520.
x - extracting ComandosMT.pl (texto)
x - extracting mtadm.tgz (texto)
x - removed lock directory _sh67520.

ComandosMT.pl : $Revision: 5.12 $
/usr/local/bin/ComandosMT.pl.tmp syntax OK

... (1)

Inclua na crontab a linha abaixo para coletar informacoes do servidor :

59 * * * * /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
*/15 * * * * /usr/local/Multitask/mtadm/bin/ColetaMemoriaReal.sh #

Execute com o usuario oracle : /ORACLE/PATH/bin/Gera_dffile.sh fabrica


28/07/2017 12:03:56 Processando: ORACLE_SID=producao, dbuser=oracle

Servidor=srv_oracle.cliente.local
Usuario ORACLE=oracle
ORACLE_SID=producao
ORACLE_HOME=/ORACLE/PATH

28/07/2017 12:03:57 TNS_ADMIN=/ORACLE/PATH/network/admin
28/07/2017 12:03:57 sqlplus=/ORACLE/PATH/bin/sqlplus
Gerando controles para o arquivo de log :
/ora01/app/oracle/diag/rdbms/producao/trace/alert_producao.log : 192.78 Mb

Servidor : srv_oracle.cliente.local
Versao instalada : 5.002.046
Instalando inst_mtadm.5.2.46


x - created lock directory _sh67520.
x - extracting ComandosMT.pl (texto)
x - extracting mtadm.tgz (texto)
x - removed lock directory _sh67520.

ComandosMT.pl : $Revision: 5.12 $
/usr/local/bin/ComandosMT.pl.tmp syntax OK

... (1)

Inclua na crontab a linha abaixo para coletar informacoes do servidor :

59 * * * * /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
*/15 * * * * /usr/local/Multitask/mtadm/bin/ColetaMemoriaReal.sh #

Execute com o usuario oracle : /ORACLE/PATH/bin/Gera_dffile.sh producao


/usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /usr/local/Multitask/mtmon/bin/setenvOracle.fabrica.sh
/usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /usr/local/Multitask/mtmon/bin/setenvOracle.producao.sh
/usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /usr/local/Multitask/mtmon/bin/setenvOracle.sh

1	Mensagens do instalador inst_mtadm omitidas.

12.5. MYSQL

O programa getMysqlStatistics.sh coleta as seguintes informações de performance do MySQL:

Connections: Número de conexões abertas no periodo de amostragem, que normalmente é de 1 minuto.
Opened_files: Quantidade de arquivos abertos no periodo.
Queries: Quantidade de queries solicitadas ao MySQL.
Threads_created: Quantidade de Threads criadas no periodo.

12.5.1. Configuração do programa

Para incrementar a segurança de acesso ao programa, a senha usada para conectar ao MySQL poderá ser criptografa. Para isso usaremos o recurso de Proteção de senhas.

Crie uma entrada no arquivo MTADMbase/etc/mtadm_salt.conf:

[my] (1)
   salt=w%tXnj.HSWFwE

1	O script getMysqlStatistics.sh usa a sessão `my` para decodificar a senha

Na sequencia, crie um HASH usando o comando abaixo:

# $MTADMbase/bin/GeraSenha.pl --PWD my -- 'SENHA' (1)
Senha : PWD_60330e0515606719393b2e5b510335242f6067

1	A string `SENHA` deve ser substituida pela senha do usuário root de acesso ao mysql.

Incluir na crontab do usuário root a entrada:

MTADMbase=/usr/local/Multitask/mtadm
MTMONbase=/usr/local/Multitask/mtmon
0,15,30,45 * * * * $MTMONbase/bin/getMysqlStatistics.sh PWD_60330e0515606719393b2e5b510335242f6067 (1)

1	`PWD_nnnn` é o HASH criado acima para ofuscar a senha de acesso ao MySQL

12.6. Procmail

Muitos ativos monitorados não dispõe das formas mais modernas de gerar a informação necessária para criar um evento.
Nestes casos, pode ser muito útil configurar um servidor SNMP para receber os email’s e tratar as informações de acordo com a necessidade.

Inicie criando o usuário no linux que será o destino da mensagem, por exemplo evento_mtmon

Na sequência, crie o arquivo $HOME/.procmailrc com o conteúdo abaixo:

:0
| /opt/zimbra/postfix/libexec/eventoDeEmail.sh (1)

1	Consulte documentação para configurar o Procmail. O endereço de email será evento_mtmon@IP_SNMP.

mailbox_command = /usr/bin/procmail -a "$EXTENSION" (1)

1	Ajuste no arquivo `/etc/postfix/main.cf` a opção `mailbox_command` para que o Postfix chame o Procmail

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
#!/bin/bash

source /usr/local/bin/ComandosMT.sh

umask 000

YYYYMM=$($C_date +%Y%m)
logFile=$MTMONbase/log/evento_mtmon.$YYYYMM.log
tmpFile=$MTMONbase/tmp/evento_mtmon.$$.eml
dmpFile=$MTMONbase/tmp/evento_mtmon.$$.html
dump=''
strDate="%d/%m/%Y %H:%M:%S: Mensagem para evento_mtmon@multitask.com.br"

trap "$C_rm -f $tmpFile" 0

$MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 100Mb $logFile
$C_tty -s < /dev/tty || exec >> $logFile
$C_tty -s < /dev/tty || exec 2>&1

cat - > $tmpFile

$C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
#
#
#
function cliente_frontoffice {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

HHMM=$(date +%k%M)
[ $HHMM -ge 2200 ] && exit 0
[ $HHMM -le 0600 ] && exit 0

$C_awk 'BEGIN{IGNORECASE=1} /<!doctype html|<html>/, /<\/html>/' $tmpFile | \
  $C_sed -e 's/=$//' | \
  $C_tr -d '\n' > $dmpFile

if [ -s $dmpFile ]
then
  echo -e "\n\n<h1>ATEN&Ccedil;&Atilde;O</h1>\n\n" >> $dmpFile
  $C_date +"<pre>$strDate</pre>" >> $dmpFile
  dump="--dump $dmpFile"
fi

$MTMONbase/bin/mtmon_evento.pl --origem cliente --servidor appdynamics \
   --aplicacao frontoffice $dump --severidade 2 --debug --eventual \
   --mensagem "AppDynamics: Event Notification for the Prod-Hybris Application"

exit 0
}
#
#
#
function cliente_temperatura {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

set -- $($C_grep -e '^Subject:' $tmpFile)
shift 1

echo "*$**" > $dmpFile
$C_awk '/^Content-Type:/,/^End of File/' $tmpFile |
  $C_grep -v -e '^Content-Type:' |
  $C_iconv -f 'ISO8859-15' -t 'ascii//TRANSLIT' |
  $C_sed -e 's/^/  /' -e 's/\?//g' >> $dmpFile
echo >> $dmpFile
$C_date +"$strDate" >> $dmpFile

set -- $($MTADMbase/bin/mtadm_get_conf.pl --config evento_mtmon.conf \
              --sessao cliente_temperatura --param whatsapp)
if [ -n "$*" ]
then
  cat $dmpFile |
    /usr/local/bin/mtwhatsapp.pl --telefone "$*" --mensagem - --debug
  cat $dmpFile
fi
exit 0
}
#
#
#
function cliente7 {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente7.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

$MTMONbase/bin/mime_explode.pl $tmpFile /tmp/file.$$ $$
if [ -s $MTMONbase/tmp/$$/file.html ]
then
  $C_cp $MTMONbase/tmp/$$/file.html $dmpFile
  echo -e "\n\n<h1>ATEN&Ccedil;&Atilde;O</h1>\n\n" >> $dmpFile
  $C_date +"<pre>$strDate</pre>" >> $dmpFile
  dump="--dump $dmpFile"
fi

set -- $($C_grep -e 'Subject:' /tmp/file.$$)
shift 1

origem=$(echo $1 | $C_tr '[:upper:]' '[:lower:]')

$MTMONbase/bin/mtmon_evento.pl --origem $origem --servidor veeam \
   --aplicacao backup $dump --severidade 2 --debug --eventual \
   --mensagem "$*"

$C_rm -rf /tmp/file.$$ $MTMONbase/tmp/$$

exit 0
}
#
#
#
function cliente6 {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente6.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

# Ignora erros : 43SA Workstations
$C_grep -e '43SA Workstations' \
        -e '43SA-Workstatios' \
        -e 'SP Wserver' \
        -e 'SP-Workstation' \
        -e 'SP Workstations' $tmpFile && exit 0

$MTMONbase/bin/mime_explode.pl $tmpFile /tmp/file.$$ $$
if [ -s $MTMONbase/tmp/$$/file.html ]
then
  $C_cp $MTMONbase/tmp/$$/file.html $dmpFile
  echo -e "\n\n<h1>ATEN&Ccedil;&Atilde;O</h1>\n\n" >> $dmpFile
  $C_date +"<pre>$strDate</pre>" >> $dmpFile
  dump="--dump $dmpFile"
fi

set -- $($C_grep -e 'Subject:' /tmp/file.$$)
shift 1

$MTMONbase/bin/mtmon_evento.pl --origem cliente6 --servidor veeam \
   --aplicacao backup $dump --severidade 2 --debug --eventual \
   --notifica bkpveeam --mensagem "$*"

$C_rm -rf /tmp/file.$$ $MTMONbase/tmp/$$

exit 0
}
#
#
#
function cliente2 {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente2.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

set -- $($C_date +'%w %k')
wday=$1
hour=$2
case "$wday" in
0|6) : Fim de semana OK ;;
*)
  if [ $hour -ge 8 ]
  then
    if [ $hour -lt 18 ]
    then
      if /usr/local/Multitask/mtmon/bin/ehHoraComercial.pl
      then
        : So gera evento fora do horario comercial
        exit
      fi
    fi
  fi
;;
esac

$C_date +"<pre>$strDate</pre>" >> $tmpFile
dump="--dump $tmpFile"

set -- $($C_grep -e 'Subject: ' $tmpFile)
shift 1

$MTMONbase/bin/mtmon_evento.pl --origem cliente2 --servidor cliente1 \
   --aplicacao sap $dump --severidade 2 --debug --eventual \
   --notifica cliente1 --mensagem "$*"

$C_rm -rf $MTMONbase/tmp/$$

exit 0
}
#
#
#
function cliente5 {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente5.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

$MTMONbase/bin/mime_explode.pl $tmpFile /tmp/file.$$ $$
if [ -s $MTMONbase/tmp/$$/file.html ]
then
  $C_cp $MTMONbase/tmp/$$/file.html $dmpFile
  echo -e "\n\n<h1>ATEN&Ccedil;&Atilde;O</h1>\n\n" >> $dmpFile
  $C_date +"<pre>$strDate</pre>" >> $dmpFile
  dump="--dump $dmpFile"
else
  $C_date +"<pre>$strDate</pre>" >> $dmpFile
  dump="--dump $tmpFile"
fi

set -- $($C_grep -e 'Subject: ' $tmpFile)
shift 1

$MTMONbase/bin/mtmon_evento.pl --origem cliente5 --servidor veeamserver \
   --aplicacao backup $dump --severidade 2 --debug --eventual \
   --notifica veeam --mensagem "$*" --finaliza 1

$C_rm -rf /tmp/file.$$ $MTMONbase/tmp/$$

exit 0
}
#
#
#
function cliente4 {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente4.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

set -- $($C_grep -e 'Subject: ' $tmpFile)
shift 1

# SAP Relatório Eficiência Transporte
echo "$*" | $C_grep -e '5BNORMAL-'
sev=$?

aplicacao=cliente4
notifica=cliente4

case "$*" in
*VPN_e_acesso_WTS*)
  aplicacao=vpn
;;
*Servidor_de_Arquivos*)
  aplicacao=fileserver
;;
*SAP*rio_Efici*)
  aplicacao=sap
;;
esac

set -- $(perl -MEncode -e "print decode('MIME-Header', '$*')" | \
           $C_iconv -f ISO8859-15 -t ascii//TRANSLIT)

$MTMONbase/bin/mtmon_evento.pl --origem cliente --servidor cliente4 \
   --aplicacao $aplicacao --objeto eficiencia $dump --severidade $sev --debug \
   --notifica $notifica --mensagem "$*"

$C_rm -rf $MTMONbase/tmp/$$

exit 0
}
#
#
#
function cliente8 {
set -x
if $C_tty -s < /dev/tty
then
  : $LINENO: Em terminal nao gera log
else
  logFile=$MTMONbase/log/evento_mtmon.cliente8.$YYYYMM.log
  $MTADMbase/bin/ctrlFileSize.pl --gerador $0 --size 10Mb $logFile
  exec >> $logFile
  exec 2>&1
  $C_date +'%d/%m/%Y %H:%M:%S ---------------------------------------------------'
  cat $tmpFile
  echo
fi

set -- $($C_grep -e 'Subject: ' $tmpFile)
shift 1

: $LINENO: Severidade sempre sera 2 para cair na console do NOC
sev=1
servidor=proview
aplicacao=email
objeto=''
msg="$*"

if [ "$2" = '-' ]
then
  set -- $(echo "$1" | $C_sed -r -e 's/^([0-9]+)/pa\1 /')
  aplicacao=$1
  objeto=$2
  shift 2
fi

echo '<p>Dados do email:</p><p>' > $dmpFile
$C_awk '/^From/,/^End of File/' $tmpFile |
  $C_sed -e 's/>/\&gt;/g' -e 's/</\&lt;/g' -e 's/$/<br>/' >> $dmpFile
echo '</p><br><br>' >> $dmpFile
$C_date +"<pre>$strDate</pre>" >> $dmpFile
dump="--dump $dmpFile"

# Remove controle de massivas
$C_rm -f $MTMONbase/var/local/verMassivas/cliente8.proview.*

: $MTMONbase/bin/mtmon_evento.pl --origem cliente8 --servidor "$servidor" \
   --aplicacao $aplicacao --objeto $objeto $dump --severidade $sev \
   --eventual --debug --notifica proview --finaliza --mensagem "$msg"

$C_rm -rf $MTMONbase/tmp/$$

exit 0
}
#
#
#
$C_grep -E '^(Date|From|Subject):' $tmpFile
set -x
: $LINENO: Ignora mensagens com Subject contendo : Success ou Warning
$C_grep -i -E '^Subject:.*\[Success|Warning\]' $tmpFile && exit 0

: $LINENO: Primeiro valida email da Hering de alert.email
$C_grep -e '^From: alert.email@cliente3.com.br' $tmpFile && cliente_frontoffice

: $LINENO: Primeiro valida email da Hering de alert.email
$C_grep -e '^From: <Temp.*@cliente3.com.br>' $tmpFile && cliente_temperatura

$C_grep -e '^From: suporte.ti@cliente7.com.br' $tmpFile && cliente7
$C_grep -e '^From: <alertas.veeam@cliente6.com.br>' $tmpFile && cliente6
$C_grep -e '^From: veeamserver@cliente5.com.br' $tmpFile && cliente5
$C_grep -e '^From: .noreply@cliente4.cloud.' $tmpFile && cliente4
$C_grep -e '^From: .proview@cliente8.coop.br.' $tmpFile && cliente8
$C_grep -e '^To: .*sapmon-alert@cliente2.com.br' $tmpFile && cliente2

cat $tmpFile
echo
exit 0

12.7. PRTG

O PRTG pode ser monitorado por três vias:

HTML Action: Os eventos serão gerados diretamente pelo PRTG usando o opção HTML Action de Notification Templates.
XML: As informações dos sensores são obtidas via wget no formato XML.
Event Viewer do Windows: O PRTG gera eventos no Windows que são processados pelo plugin do MTMON.

12.7.1. HTML Action

O recurso HTML Action permite que uma chamada HTML seja feita pelo PRTG diretamente ao MTMON Server.

No PRGT, a opção de Setup que permite configurar o recurso é chamado Notification Templates.

Na console do PRTG, selecione as opções na sequencia:

Setup → Account Settings → Notification Templates

Crie um novo template e preencha conforme a necessidade.
Apresentaremos aqui as opções relevantes para Execute HTTP Action:

URL: https://mtmon.multitask.com.br/api/makeEvento
SNI Handling: Do not send SNI (default)
HTTP Method: POST
Payload: transkey=0oQwqo&ativo=%device&aplicacao=%group&objeto=%sensor&mensagem=%message&severidade=%laststatus&procedimento=proc

A informação de transkey no JSON do quadro acima, pode ser obtida com o NOC da Multitask ou no arquivo mtadm.conf na configuração do agente antigo..

Os seguintes campos de notificação pode ser usados para gerar o evento:

%device %group %host %laststatus %location %message %objecttags %prio %probe %sensor %status %tags

A lista completa dos campos de notificação podem ser obtidas no link:
https://www.paessler.com/manuals/prtg/list_of_placeholders_for_notifications

Procure no Google por: PRTG Manual: List of Placeholders for Notifications

HTTP Version: HTTP 1.1 (default)

Depois de definido o template, teste a comunicação e valide as informações recebidas pelo script no diretório /usr/local/Multitask/mtmon_v3/logs_eventos.

12.7.2. via XML

O PRTG permite a recuperação do status dos sensores no formato XML por meio de uma URL.

URL para gerar uma senha de acesso ao PRTG

https://{PRTG_SERVER}/api/getpasshash.htm?username={USUARIO}&password={SENHA} (1) (2)

1	Para melhorar a segurança, podemos criar um usuário que terá acesso somente de leitura aos sensores.
2	O retorno da URL é um número chamado `passhash`

Podemos usar o wget para recuperar o passhash de acesso:

# wget -q -o - "https://{PRTG_SERVER}/api/getpasshash.htm?username={USUARIO}&password={SENHA}" --no-check-certificate

Para recuperar o XML, usamos o comando wget com a opção passhash. Incluir na crontab o comando para recuperar as informações dos sensores de acordo com a periodicidade desejada:

Comando da crontab para obtenção do XML com informações dos sensores

# Recupera o XML com status dos sensores do PRTG
*/3 * * * * /usr/bin/wget "https://{PRTG_SERVER}/api/table.xml?username=mtmon&passhash=1234567890&content=sensortree" --no-check-certificate -q -O /usr/local/Multitask/mtmon/tmp/prtg.xml (1) (2) (3)

1	Para otimizar a monitoração, defina o tempo da crontab na mesma razão que a chamada do plugin `mtmon_prtg_XML.pl,` definida no arquivo MTMONbase/etc/mtmon_cron.conf
2	O usuário é mtmon e o `passhash` é o número recebido na chamada da URL `getpasshash.htm`
3	O arquivo MTMONbase/tmp/prtg.xml será usado para definir o status dos sensores e gerar eventos apropriados.

Validar se o arquivo XML foi recebido corretamente e depois validar se os módulos do perl usados pelo plugin estão instalados:

# PERL_MM_USE_DEFAULT=1 perl -MCPAN -e shell (1)
cpan> install XML::Simple DateTime::Format::Excel

1	A variável `PERL_MM_USE_DEFAULT=1` define que o default das opções seja aceito para os módulos à serem instalados

Para instalar o módulo XML::Simple do perl, é necessário instalar a biblioteca libexpat-dev no linux.
Consulte o link abaixo para uma explanação da biblioteca:

https://www.systranbox.com/how-to-install-expat-devel-in-linux/

Incluir a sessão prtg no arquivo MTMONbase/etc/mtmon_cron.conf:

 [prtg]
   aplicacao=mon_prtg
   ativo=1
   comando=mtmon_prtg_XML.pl --prtg_server={PRTG_SERVER} --tag=24x7  (1) (2)
   intervalo=* */3 (3)
   sleep=20
   delay=1 min

1	A opção `--prtg_server={PRTG_SERVER}` é usada para criar os links para as URL’s associadas com informações dos sensores no DUMP do evento no MTMON.
2	A opção `--tag=24x7` é usada como filtro para definir os sensores que serão usados para gerar eventos no MTMON. O PRTG tem a opção de tags e quando a string 24x7 for incluída, o plugin tratará o sensor. Se a opção `--tag` não for definida, todos os sensores serão tratados e isso pode representar um volume bastante expressivo de eventos na console do MTMON.
3	Observe que o tempo está associado à periodicidade de execução da crontab. O `sleep=20` define um tempo de espera antes de iniciar o plugin, permitindo que a informação seja atualizada pelo comando `wget`.

Para monitorar a execução do wget, podemos configurar o plugin mtmon_cda.pl, que gera evento quando o tempo de alteração do arquivo monitorado ultrapassar o limite definido.

 [prtg_xml]
   notFoundOK=0
   arquivo=/usr/local/Multitask/mtmon/tmp/prtg.xml (1)
   objeto=prtg_xml
   severidade=1
   tempo=30 minutos

1	Arquivo XML obtido com a execução do comando `wget` chamado via crontab

12.7.3. via Event Viewer do Windows

O PRTG é um software usado para monitorar dispositivos de rede. Para até 100 sensores, a licença é livre e é uma boa opção para monitorar dispositivos que tenha MIB’s SNMP, como por exemplo: switch, roteadores e no-break’s.

Criar uma notificação no PRTG que permita a integração com o MTMON:

Faça Login no PRTG e clique no menu superior: Setup ⇒ Account Settings ⇒ Notifications ⇒ + Add new notification

Preencher os seguintes campos:

Variável Valor

Basic Notification Settings :

Notification Name

mtmon

Notification Summarization :

Method

Always notify ASAP, never summarize

Add Entry to Event Log :

Logfile

PRTG Network Monitor

Event Type

Information

Event Log Message

{datetime: %datetime}, {device: %device}, {deviceid: %deviceid}, {host: %host}, {location: %location}, {message: %message}, {probe: %probe}, {sensor: %sensor}, {settings: %settings}, {shortname: %shortname}, {since: %since}, {sitename: %sitename}, {status: %status}, {comments: %comments}, {commentsdevice: %commentsdevice}

Clique no botão Save para efetivar a criação na notificação.

Associar o sensor com a notificação mtmon:

Clique no menu superior: Device ⇒ _Sensor desejado ⇒ Notifications_
Em Object Triggers defina o Threshold Trigger para acionar a notificação mtmon.

O PRTG enviará para o Event Viewer do Windows, no arquivo de log PRTG Network Monitor, informações de eventos de acordo com as definições dos gatilhos.

Para que o evento seja gerado na console do MTMON, o programa mtmon_prtg.pl deve ser chamado.

Incluir no arquivo MTMONbase/etc/mtmon_cron.conf:

[mon_prtg]
  aplicacao=mon_prtg
  comando=mtmon_prtg.pl
  intervalo=* */3

Sempre que no Event Viewer do Windows for identificada uma mensagem do PRTG, um evento será gerado no MTMON.

A severidade será definida pelo status do sensor: Up=0 e Down=1. Para alterar a severidade, ajuste o arquivo mtmon_prtg.conf, na sessão do sensor ou no default.

12.7.3.1. Outras notificações

Existem situações em que o sensor pode assumir valores intermediários, que reflete a gravidade do item monitorado.

Podemos configurar que um sensor de temperatura alerte quando chegar em 25 graus (amarelo) e 30 graus (vermelho). Para isso, precisamos criar outras notificações que informem o PRTG sobre isso.

O processo de criação da notificação é semelhante ao descrito na sessão anterior. Na opção Event Log Message inclua a opção associada ao MTMON para a notificação.

Exemplo que inclui a opção severidade e notifica na geração do evento:

{severidade:2}, {notifica:nobreak}, {datetime:%datetime}, {device:%device}, ...

A opção msg_operador pode ser usada para enviar uma mensagem para o operador que monitora a console do MTMON.

{severidade:2},{msg_operador:%commentsdevice}, ...

Aparecerá em destaque para o operador, a mensagem incluída no PRTG para o device monitorado.

12.7.3.2. Caso específico para link’s

Uma vez criada uma notificação, você poderá clicar em clone para duplicar a mesma, e alterar os campos desejados.

No caso de link’s, temos 2 estados possíveis e para isso criaremos duas notificações com as seguintes opções no JSON enviado ao Event Log:

Nome: mtmon_link_OK

{severidade:0}, {mensagem:Link OK}, {datetime:%datetime}, {device:%device}, ...

Nome: mtmon_link_DOWN

{severidade:2}, {parado:1}, {mensagem:Link Parado}, {datetime:%datetime}, {device:%device}, ...

12.8. SNMP

Para monitoração de Storages, Tape libraries e outros dispositivos, podemos usar o snmptrap.

Consulte a recomendação de configuração do agente do MTMON em ambiente misto.

Centos, Fedora e Red-Hat

Instalar os pacotes net-snmp e net-snmp-utils:

yum install net-snmp net-snmp-utils

SuSE Linux

Instalar o pacote net-snmp:

zypper install net-snmp

O arquivo /etc/snmp/snmptrapd.conf é usado pelo SNMP para as configurações necessárias.

Incluir as linhas:

authCommunity log public
disableAuthorization yes
traphandle default /bin/bash /usr/local/Multitask/mtmon/bin/trapHandle.sh -debug (1)

1	Se o arquivo não existir, poderá ser criado

Depois, reinicie o daemon do snmptrap.

Centos, Fedora e Red-Hat

service snmptrapd restart
chkconfig --level 345 snmptrapd on (1)

1	Comando para iniciar o SNMP no boot

Red-Hat 7 (ou superior)

systemctl enable snmptrapd
systemctl start snmptrapd

Para identificar os diretórios default de MIBs, consulte a descrição da opção -M do comando snmpwalk -h:

# snmpwalk -h
USAGE: snmpwalk [OPTIONS] AGENT [OID]

  Version:  5.7.2
  Web:      http://www.net-snmp.org/
  Email:    net-snmp-coders@lists.sourceforge.net

OPTIONS:
  -h, --help		display this help message

   ...

General options
  -m MIB[:...]		load given list of MIBs (ALL loads everything)
  -M DIR[:...]		look in given list of directories for MIBs
    (default: $HOME/.snmp/mibs:/usr/share/snmp/mibs) (1)
...

1	Nestes diretórios podem ser encontradas as MIB’s usadas no servidor.

Link’s úteis:

Para verificar o SNMP está operacional, execute o comando abaixo:

snmptrap -v 1 -c public 127.0.0.1 '1.2.3.4.5.6' '192.193.194.195' 6 99 '55' 1.11.12.13.14.15 s "Teste de MTMON"

Consulte o arquivo /usr/local/Multitask/mtmon/log/trapHandle.AAAAMM.log e veja se foi incluida uma entrada semelhante:

13/10/2020 16:49:36 MTMON - snmptrap
localhost
UDP: [127.0.0.1]:55648->[127.0.0.1]
DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:00:00.55
SNMPv2-MIB::snmpTrapOID.0 iso.2.3.4.5.6.0.99
iso.11.12.13.14.15 "Teste MTMON"
SNMP-COMMUNITY-MIB::snmpTrapAddress.0 192.193.194.195
SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 "public"
SNMPv2-MIB::snmpTrapEnterprise.0 iso.2.3.4.5.6

Se o teste acima não resultar no log esperado, verifique se o SELINUX ou IPTABLES não estão bloqueando o acesso às portas configuradas.

Configure o SELINUX para permitir o recebimento de traps do SNMP com o comando:

setenforce 0

Valide o resultado com o comando:

# sestatus

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

Ajuste o arquivo /etc/selinux/config:

SELINUX=permissive

Assim, após o reboot, o servidor já estará com o SELINUX desativado.

12.8.1. Processar trap de SNMP

Ao receber um trap de SNMP, o script /usr/local/Multitask/mtmon/bin/trapHandle.local trata o mesmo e disponibiliza as seguintes variáveis:

Nome: nome do servidor que gerou a mensagem SNMP. Pode ser o IP, quando o DNS não resolver corretamente o nome.
IP: endereço IP do servidor que gerou a mensagem SNMP.
errFile: arquivo com a saída do trace (set -x) do script trapHandle.sh. É necessário remover o comentário no script para habilitar esta forma de debug.
ignFile: pode ser usado para registrar a mensagem num log de descarte.

Consulte o exemplo de trapHandle.local.

Útil para debug. Quando a configuração do SNMP está OK, não precisa manter este log, pois só consumirá recursos.

logFile: arquivo de log com as mensagens recebidas.
tmpFile: contém o nome do arquivo que contém a mensagem SNMP recebida pelo script trapHandle.sh.

Também podemos usar o plugin mtmon_snmplog.pl, que permite configuração no arquivo mtmon_snmp.conf.

Normalmente, com um simples grep é possível ignorar a mensagem, pois sabemos o que podemos descartar.

Exemplo de conteúdo no arquivo tmpFile:

30/09/2018 21:20:30 MTMON
<UNKNOWN>
UDP: [10.10.10.81]:7774->[10.1.1.100]
DISMAN-EVENT-MIB::sysUpTimeInstance 7:20:23:58.32
SNMPv2-MIB::snmpTrapOID.0 SNMPv2-SMI::enterprises.12740.66.0.1
SNMPv2-SMI::enterprises.12740.66.1.1.0 46716901
SNMPv2-SMI::enterprises.12740.66.1.2.0 "5.4"
SNMPv2-SMI::enterprises.12740.66.1.3.0 "Port at Reduced Speed Alert"
SNMPv2-SMI::enterprises.12740.66.1.4.0 "SWRJ"
SNMPv2-SMI::enterprises.12740.66.1.5.0 1
SNMPv2-SMI::enterprises.12740.66.1.6.0 "0A AD 65 6E "
SNMPv2-SMI::enterprises.12740.66.1.7.0 "Ethernet Port (PS6101 eth1) is not connected to a 10 Gigabit link."
SNMPv2-SMI::enterprises.12740.66.1.8.0 1538288430
SNMPv2-SMI::enterprises.12740.66.1.9.0 "SWRJ.dominio.com"

Trap SNMP recebido pelo script /usr/local/Multitask/mtmon/bin/trapHandle.sh no servidor snmp.multitask.com.br

No exemplo abaixo, identificamos nas últimas linhas que é definida a variável LOCAL_options, que permite ajustar os parâmetros --notifica e --finaliza para o plugin mtmon_snmplog.pl.

Exemplo de script:

trapHandle.local

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#
# Id: trapHandle.local
#

# Esta mensagem vem à cada minuto e pode ser ignorada
$C_grep -e 'SNMPv2-SMI::experimental.9999.1.7.1.1.4.1.[0-9]* "iqn.*.riverbed:' \
        -q $tmpFile (1)
if [ $? = 0 ]
then
  # Nao registra esta mensagem no log
  if [ ! -z "$ignFile" ]
  then
    $C_date +'%d/%m/%Y %H:%M:%S trap ignorado por trapHandle.local :' >> $ignFile
    cat $tmpFile >> $ignFile
    echo >> $ignFile
  fi
  $C_rm -f $tmpFile
  trap 0
  exit 0
fi

# Identifica nome do servidor pelo OID do trap
set -- $($C_grep -e SNMPv2-SMI::enterprises.12740.66.1.9.0 \
                 -e SNMPv2-SMI::enterprises.674.10892.2.1.1.10.0 \ (2)
                 -e SNMPv2-SMI::enterprises.674.10892.5.3.1.10.0 \
                 -e SNMPv2-SMI::enterprises.674.10892.5.3.1.11.0 \
                 -e SNMPv2-SMI::enterprises.6876.4.3.307.0 \
                 $tmpFile |
            while read chave valor
            do
              echo "$valor" | $C_grep -q -e ' ' && continue
              echo $valor | $C_sed -e 's/"//g' -e 's/\..*$//'
            done)
[ -z "$1" ] || Nome=$1

# Define o procedimento que aparecerá na console do MTMON
case "$Nome" in
ibm*) LOCAL_options='--notifica aix' (3)
jve2k*) LOCAL_options='--notifica windows' (3)
esac

# No horario comercial - finaliza evento
$MTMONbase/bin/ehHoraComercial.pl && LOCAL_options="$LOCAL_options --finaliza" (3)

1	Use o comando grep para descartar os trap’s que não serão usados na monitoração
2	Consulte o no Google a documentação da MIB usando o string SNMPv2-SMI::enterprises.674
3	O valor da variável LOCAL_options é incluída na chamada do comando mtmon_snmp.pl

O script trapHandle.local poderá gerar os seus próprios eventos e finalizar o processamento ou devolver o controle para o script trapHandle.sh que chamará o plugin mtmon_snmp.pl que processará a mensagem.

12.9. SoftDesk

Um evento do MTMON pode abrir um chamado no SoftDesk.

Usaremos como exemplo a origem cliente.

O arquivo MTADMbase/sd/cliente.conf contém as definições para a abertura de chamados no SoftDesk.

Abaixo exemplo que será usado na explanação dos recursos do script:

[sd]
  cd_area=TI (1)
  cd_prioridade=Padrao (2)
  cd_servico=MONITORAMENTO
  cd_tipo_chamado=Incidente
  cd_usuario=MTMON - Incidentes
  url_sd=https://multitask.soft4.com.br/modulos/incidente/chamado_incluir.php

[infra]
  cd_area=2
  cd_categoria=1663
  cd_grupo_solucao=118
  cd_nivel_indisponibilidade=4
  cd_prioridade=115
  cd_servico=163
  cd_tipo_chamado=5
  cd_usuario=4481
  url_sd=https://softdesk.cliente.com.br/modulos/incidente/chamado_incluir.php (3)

[oracle]
  cd_area=73
  cd_prioridade=4
  cd_servico=26
  cd_tipo_chamado=10
  cd_usuario=545
  url_sd=https://multitask.soft4.com.br/modulos/incidente/chamado_incluir.php

[link]
  cd_area=11
  cd_prioridade=4
  cd_servico=7
  cd_tipo_chamado=10
  cd_usuario=30
  url_sd=https://multitask.soft4.com.br/modulos/incidente/chamado_incluir.php

1	Quais parâmetros devem ser inseridos no arquivo de configuração, está fora do escopo deste documento. O administrador do SoftDesk poderá fornecer estas informações.
2	Você pode informar o código do parâmetro. Observe que nas demais sessões as informações são fornecidas em formato numérico.
3	O script pode criar incidentes em instâncias diferentes do SoftDesk. No exemplo acima, a sessão infra define que o incidente será criado na instância do cliente cliente. As demais serão criadas na URL da Multitask.

Valide a URL em um browser e verifique se a chamada está funcionando.
Por exemplo, a URL chamado_incluir.php deverá retornar:

Não esta sendo fornecido a hash pelo método GET.

O script que prepara as variáveis para abrir o incidente no SoftDesk será criado no diretório MTMONbase/script/sd_cliente.sh.

Abaixo um exemplo de script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#!/bin/bash

set -x
: $LINENO Cliente: Teste (1)

[ "$MTMON_severidade" = 2 ] || exit 0 (2)

set -- $($C_date +'%Y%m%d %H')

export Tipo='sd' (3)
export sdServidor="$MTMON_origem/$MTMON_servidor"
export Titulo="$sdServidor: [$MTMON_aplicacao] $MTMON_mensagem"

case "$MTMON_aplicacao" in
oi|gvt|tpa|level3)
  : $LINENO Nao cria evento no SoftDesk se a mensagem contem as strings abaixo
  echo "$MTMON_mensagem" |
    $C_grep -e 'Request timed out' \
            -e 'TTL expired in transit' \
            -e 'No response'
  [ $? = 0 ] && exit 0 (4)
  Tipo='link'
;;
oracle)
  Tipo='oracle'
;;
storage|tapelib|san)
  Tipo='infra'
;;
esac

1	Consulte o log em MTMONbase/log/mtmon_sd.log
2	Só abre incidentes para severidade critica
3	A variável Tipo será usada internamente para associar o evento do MTMON com o incidente que será criado no SoftDesk. A sessão correspondente no arquivo MTMONbase/script/sd_cliente.sh é definida nesta variável
4	`exit 0` finaliza o script e o incidente não será criado no SoftDesk

Internamente o script chama um outro programa cujo log é MTMONbase/log/CriaIncidenteSD.log.

O script poderá retornar as seguintes mensagens:

Chamado no Soft Desk: 107369: Chamado aberto com sucesso.
A busca por usuários resultou em ZERO registros ou mais de um registro contendo o filtro 'MTMON - Incidentes': Revise as definições no arquivo MTADMbase/sd/cliente.conf com a ajuda do administrador do SoftDesk.
Não esta sendo fornecido a hash pelo método GET.: Verifique se a variável Tipo está definindo um valor que corresponde à uma sessão no arquivo de configuração do SoftDesk.
Ex.: MTADMbase/sd/cliente.conf

12.10. TSM

Para configurar os plugins do TSM, o script ConfiguraTSM.sh solicita o usuário e senha de acesso, cria os arquivos necessários para as futuras conexões e identifica os pools disponíveis para monitoração.

O script pode ser executado à qualquer momento, pois não é alterado nada no Sistema Operacional. Só o arquivo $MTMONbase/etc/mtmon_cron.conf é que será alterado se identificar novos itens para monitorar.

# /usr/local/Multitask/mtmon/bin/ConfiguraTSM.sh
Usando definicoes de /usr/local/Multitask/mtmon/bin/setenvTSM.sh
Informe o usuario do TSM: admin
Informe a senha do TSM:
Sessao [tsm_db] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_drive] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_log] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_scratch] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_unav] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_volerr] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_path] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_volreclaim] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_tapeslib] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_DIRVMPOOL] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_FILEPOOL] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_FILEPOOLDB] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_FILEPOOLMIG] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Configurando sessao [tsm_stgpool_FILEPOOL_EMC]
Configurando sessao [tsm_stgpool_FILEPOOL_SEMANAL]
Sessao [tsm_stgpool_LTOPOOL01] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_LTOPOOL02] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_LTOPOOL03] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_LTOPOOL6ASA] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_LTOPOOL6B] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_LTOPOOL6BSA] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Configurando sessao [tsm_stgpool_LTOPOOL_CP]
Sessao [tsm_stgpool_STGLTO6EMC] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Sessao [tsm_stgpool_STOSAP] ja configurada em $MTMONbase/etc/mtmon_cron.conf
Incluir as sessoes no arquivo /usr/local/Multitask/mtmon/etc/mtmon_cron.conf

O plugin mtmon_tsmmonitor.sh é configurado com as opções e pools identificados no ambiente.

mtmon_tsmmonitor.sh foi alterado com base no plugin disponível em TSMmonitor - Thobias Salazar Trevisan

12.11. Zabbix

Esta sessão contou com a ajuda de Leandro Schattschneider, que cedeu as instruções e imagens para a configuração do Zabbix integrado com o MTMON.

Consulte a recomendação de configuração do agente do MTMON em ambiente misto.

A configuração do MTMON no Zabbix é feita em Administração → Tipos de mídia

Os parâmetros que serão encaminhados para o script gerar o evento, são definidos na opção Message templates.

Opções à serem definidas na janela:

servidor="{HOST.NAME}"
aplicacao="{ITEM.NAME}"
objeto="{EVENT.ID}"
mensagem="{EVENT.SEVERITY}: {EVENT.NAME}"
severidade=1 (1)
notifica=teste (2)
event.ack.status="{EVENT.ACK.STATUS}"
event.date="{EVENT.DATE}"
event.id="{EVENT.ID}"
event.name="{EVENT.NAME}"
event.severity="{EVENT.SEVERITY}"
event.status="{EVENT.STATUS}"
event.time="{EVENT.TIME}"
host.name="{HOST.NAME}"
item.lastvalue="{ITEM.LASTVALUE}"
trigger.id="{TRIGGER.ID}" (3)

1	No Zabbix defina em action a severidade desejada
2	Defina aqui o procedimento associado ao evento
3	Variáveis que serão expandidas no `eval` do script chamaMTMON.sh

Script chamaMTMON.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#!/bin/bash

source /usr/local/bin/ComandosMT.sh

export notifica='zabbix'
export tmpFile="$MTMONbase/tmp/mtmon_zabbix.$$.txt" (1)
export MTADM_Debug=on
export MTADM_logSize=10Mb (2)
export MTADM_logFile="$MTMONbase/log/mtmon_zabbix.log" (3)
export MTADM_stdout=''
export MTADM_stderr=''
source $MTADMbase/bin/shell_debug.sh (4)

trap "$C_rm -f $tmpFile" 0

$C_date +"%d/%m/%Y %H:%M:%S *** Iniciado script $0 em $HOSTNAME"
if [ $# -gt 0 ]
then
  printf "ARGS:"
  for arg in "$@ii"
  do
    printf " '$arg'"
  done
  echo
#  echo "env:"
#  env | $C_grep -v -e ^C_ (5)
#  echo
fi > $tmpFile

eval -- $(echo "$1" | $C_dos2unix | $C_sed -e 's/\./_/g') (6)

$MTMONbase/bin/mtmon_evento.pl --servidor "$servidor" --aplicacao "$aplicacao" \
    --objeto "$objeto" --notifica "$notifica" --severidade $severidade
    --mensagem "$mensagem" --debug --dump $tmpFile --finaliza=1 (7)
exit 0

1	Arquivo usado para enviar informações no dump do evento
2	Controle de tamanho do arquivo de log. Quando chegar em 10 Mb, arquivo é movido para .OLD e um novo é criado
3	Arquivo de log com o trace da chamada do script pelo Zabbix
4	Quando executado com a opção `-d` não gera log. Consulte documentação de debug e log de shell script
5	Descomente estas linhas para incrementar o nível de debug, incluindo as variáveis de shell no DUMP do evento
6	As variáveis definidas na nota acima são convertidas em variáveis de shell script e podem ser usadas para definições do evento
7	Remova a opção `--finaliza=1` para que o evento seja tratado pelo `NOC` da Multitask

Criar uma notificação para Usuário dentro do Zabbix associando com o tipo de mídia MTMON:

Finalmente, criar uma Trigger de Ação em que caso exista a TAG Telegram/Monitorar no evento gerado, ele chama o script chamaMTMON.sh passando os parâmetros do Host ou serviço afetado:

Outras ferramentas MT

13. MT-Adm - Ferramentas de apoio

13.1. Auditoria de arquivos

O comando mtwdog_files.pl é usado para monitorar alterações em arquivos do ambiente.
Uma vez que o arquivo é incluído no sistema, sempre que ele for alterado, é registrada a alteração numa base interna. Assim é possível rastrear as alterações ocorridas no Sistema Operacional.

Para controlar as alterações dos arquivos monitorados, é usado o software GNU RCS.

13.1.1. Opções disponíveis

Opcões aceitas pelo comando mtwdog_files.pl:

--arquivo arquivo: É o nome do arquivo sobre o qual será realizado o controle e/ou ações.
--base diretório: É o diretório usado como repositório de documentos RCS. É recomendado que se instale o GNU RCS, pois ele oferece melhores recursos para verificação de alterações nos arquivos.
Consulte o manual do GNU RCS para mais informações.

O parâmetro base poderá ser configurado no arquivo de configuração ou na variável de ambiente MTWDOGbase.
Default: MTADMbase/base definido em mtwdog_files.conf

Podem ser definidos vários diretórios como base, que conterão os repositórios de arquivos monitorados. Um repositório é o arquivo ,v usado pelo RCS para manter o histórico de atualizações de um arquivo.

Por exemplo, podemos manter bases com fontes de programas em COBOL, C, Shell Scripts, arquivos do ORACLE e do Sistema Operacional.
O WDOG pode ser usado como um Gerenciador de Fontes rudimentar mas perfeitamente funcional.

--changes [ "dd/mm/YYYY HH:MM,dd/mm/YYYY HH:MM" ]: O WDOG identificará os arquivos que foram alterados no período informado.
Consulte o exemplo apresentado neste capítulo.

O relatório apresentado conterá informações que podem gerar muitas linhas. Por isso, a opção --lista é sugerida na primeira abordagem para identificar os arquivos alterados no período.

As aspas somente serão necessárias se informar a hora da alteração dos arquivos.

Se não for informado o período, será considerado o dia 1 do mês corrente até o momento da execução.

--debug: Incrementa nível de log com informações para debug.
Apresenta informações complementares em relação à --verbose.
--descricao texto: Quando um arquivo é cadastrado para ser monitorado ou uma alteração manual é realizada, pode ser informada uma descrição da alteração.
Isso permite um acompanhamento mais detalhado das alterações.
--diff versao1[,versao2]: Esta opção permite a verificação das alterações entre duas versões do arquivo controlado pelo WDOG.
O exemplo apresentado neste capítulo, demonstra como mapear os arquivos alterados num período de tempo e na sequência apresentar as alterações registradas no WDOG.

Se não forem informadas duas versões, serão apresentadas as alterações ocorridas no arquivo monitorado desde a última execução de --sincroniza

--excluir: Junto o parâmetro --arquivo ou --indice define o arquivo que será removido dos controles do WDOG.
Alias: --remover
--force: O WDOG verifica se a área disponível nos filesystems envolvidos estão dentro de um limite seguro ou se a verificação feita pelo mtmon_disco.pl está à mais de 2 horas sem ser executada. Quando um destes critérios é observado, a solicitação não é processada e é apresentada uma mensagem informativa.
Quando a opção --force é informada, WDOG ignora estes controles de segurança e o analista é o responsável pela análise dos riscos envolvidos.

Quando invocado com a opção --excluir não é solicitada a confirmação com S.

--incluir: O objetivo da opção --incluir é permitir que vários arquivos sejam informados numa chamada do comando, facilitando a inclusão de arquivos para monitoração.
Neste caso, a lista de arquivos será repassada como opção de linha de comando. Consulte exemplo clicando aqui.
--indice número: O número do índice está associado ao arquivo monitorado pelo WDOG.
Pode ser usado no lugar de --arquivo para identificar o alvo do comando.
Identifique o índice com a opção --listar.
--listar: Apresenta os arquivos monitorados.
Quando usado junto com a opção --change retorna apenas o nome dos arquivos que atenderam o critério do período informado.
--log: Apresenta um relatório de alterações dos arquivos monitorados.
Se nenhum dos parâmetros --arquivo ou --indice for informado, apresenta o log de todos os arquivos monitorados.
--script "script shell": Substitui a definição encontrada no arquivo de configuração do WDOG.
Consulte a explanação para integrar o WDOG com o MTMON.
--severidade: Consulte a explanação para integrar o WDOG com o MTMON.
--sincronizar: Invoca o programa para sincronizar os arquivos cadastrados com a base do WDOG.
Sincronizar é o processo de verificar cada arquivo cadastrado e registrar se houve alterações nos mesmos.

O arquivo monitorado não é alterado no processo. Uma cópia do mesmo é feita para uma área de trabalho no diretório MTADMbase/base/tmp e nesta cópia são feitas a verificações.
Por este motivo é que aparece o diretório tmp/arquivo,v na identificação do arquivo nos relatórios:

 RCS file: tmp/arquivo,v

--verbose: Incrementa nível de log com informações para debug.
Apresenta informações complementares em relação à --debug.
--versao versao: Recupera a versão escolhida do arquivo monitorado no diretório corrente.
--help: Apresenta uma tela com as opções disponíveis.

13.1.2. mtwdog_files.conf

O arquivo de configuração MTADMbase/etc/mtwdog.conf contém as variáveis padrão usadas pelo WDOG.

 [Global]
   base=/usr/local/Multitask/mtadm/base
   compactar=1
   eventoSeveridade=2
   minimoLivre=10 Mb
   script=/usr/local/Multitask/mtmon/bin/mtwdog_files.sh
   semLicenca=0
   validarDiskFree=1

Suporta as seguintes opções de configuração :

base: Consulte --base
compactar: Quando definido, compacta os arquivos no repositório com o comando gzip.
eventoSeveridade: Valor repassado para o script de integração com o MTMON para definir se será criado evento no MTMON.
O número define a maior severidade aceita para gerar eventos no MTMON. Portanto, se definir que o valor desta opção é 1 então serão gerados eventos para severidades 1 e 2.
Default: 2
minimoLivre: Limite mínimo para que o programa altere a base.
Isso é para garantir que não ocorra um disk full e comprometa a integridade do Sistema Operacional.
Chamando o programa com a opção --force anula este controle.
script: shell script invocado sempre que houver alteração no arquivo controlado pelo WDOG.
Consulte exemplo de integração com o MTMON.
semLicenca: Controla a apresentação da mensagem Licenca valida até dd/mm/AAAA.
validarDiskFree: Controle que atua junto com minimoLivre para evitar que um disk full comprometa a integridade do Sistema Operacional.
Chamando o programa com a opção --force anula este controle.

13.1.3. Incluir arquivos no WDOG

Para incluir um arquivo no ambiente do WDOG, use o comando abaixo:

 # cd /diretorio (1)
 # mtwdog_files.pl --arquivo arquivo --incluir   (2) (3) (4)

1	Usaremos o arquivo arquivo para demonstração
2	O programa mtwdog_files.pl está no diretório /usr/local/bin, que deve estar no $PATH
3	Pode ser informado o PATHNAME absoluto para incluir o arquivo
4	Forma simplificada: `mtwdog_files.pl --incluir arquivo`

Esta opção permite incluir vários arquivos de uma vez:

 # mtwdog_files.pl --incluir *.c *.h (1)

1	Neste exemplo, todos os arquivos com sufixo `.c` ou `.h` no diretório corrente serão incluídos.

Quando desejar incluir vários arquivos, não informe a opção --arquivo, pois ela terá precedencia sobre a opção --incluir e será incluído apenas o primeiro arquivo da lista informada.

13.1.4. Incluir arquivos sensíveis à segurança do Sistema Operacional

Num ambiente de produção, saber o que foi alterado em arquivos sensíveis ou críticos incrementa a segurança do servidor.

Cada administrador de sistemas pode ter uma percepção particular do que é sensível, mas alguns arquivos merecem uma atenção especial.

3 exemplos de arquivos sensíveis:

 ~/root/.ssh/authorized_keys
 /etc/profile
 /etc/ssh/sshd_config

O comando MTADMbase/bin/IncluiArquivos.pl conta com uma base de conhecimento que ajuda na identificação de arquivos que podem prejudicar o Sistema Operacional se alterados indevidamente.
Um relatório é gerado com os comandos necessários para incluir os arquivos. Estes comando podem ser executados individualmente.

 # /usr/local/Multitask/mtadm/bin/IncluiArquivos.pl
 Para efetivar a execucao execucao o comando com a opcao --aplicar

 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /boot/grub/grub.conf --incluir
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/bashrc --incluir --severidade=1 (1)
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/crontab --incluir
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/fstab --incluir
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/group --incluir
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/httpd/conf/httpd.conf --incluir
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/inittab --incluir --severidade=1
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/issue --incluir
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/krb5.conf --incluir --severidade=1
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/profile --incluir --severidade=1
 /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --arquivo /etc/resolv.conf --incluir --severidade=1

1	Se o procedimento de integração com o MTMON for implementado, a severidade aqui definida é que será usada na criação do evento.

Quando o RCS não está instalado, as mensagens abaixo serão apresentadas:

# /usr/local/Multitask/mtadm/bin/IncluiArquivos.pl (1)
Comando ci nao encontrado.
Comando co nao encontrado.
Comando rcs nao encontrado.
Comando rlog nao encontrado.

1	Depois de instalar o RCS é necessário executar o inst_mtadm para incluir os comandos no script `/usr/local/bin/ComandosMT.sh`

 # /usr/local/Multitask/mtadm/bin/IncluiArquivos.pl --aplicar (1)
 Incluindo arquivo /etc/whatsapp.conf
 Incluindo arquivo /etc/whatsapp_mtmon.conf
 ...

1	A opção `--aplicar` inclui os arquivos encontrados.

13.1.5. Listar arquivos no WDOG

Para listar os arquivos que estão no WDOG use o comando:

 # mtwdog_files.pl --lista (1)
 Índice Versão Severidade/Arquivo
 ------ ------ ----------------------------
      1 1.1    0 /diretorio/arquivo   (2) (3) (4)

1	Observe que o arquivo é salvo com o PATHNAME absoluto
2	O Índice permite interagir com o arquivo salvo usando um número associado à ele
3	A versão apresentada na lista corresponde à mais recente
4	O número apresentado antes do nome do arquivo, é a Severidade que será usada para gerar eventos no MTMON se for configurado o recurso

13.1.6. Atualizando a base

Se alterar o arquivo e executar o comando com a opção --sincronizar, teremos:

 # mtwdog_files.pl --sincronizar
 Arquivo /diretorio/arquivo alterado. Data : 05/11/2020 17:37.
 # mtwdog_files.pl
 Índice Versão Severidade/Arquivo
 ------ ------ ----------------------------
      1 1.2    0 /diretorio/arquivo (1)

1	Observe que a versão do arquivo monitorado foi incrementada.

Se novas alterações forem feitas no arquivo, o registro é processado nos horários associados à execução do comando com a opção --sincronizar.

A opção --sincronizar fará uma verificação dos arquivos incluídos no WDOG e se houveram alterações, as mesmas serão registradas.

Incluir na crontab do UNIX automatiza esta tarefa:

MTADMbase=/usr/local/Multitask/mtadm (1)
30 6,12,18 * * * $MTADMbase/bin/mtwdog_files.pl --sincronizar #

1	Algumas versões de crond não suportam a definição de variáveis. Neste caso, é necessário definir o caminho completo na linha do `mtwdog_files.pl`

13.1.7. Listar as atualizações nos arquivos

Um log das alterações pode ser verificado com o comando:

 # mtwdog_files.pl --indice 1 --log
 RCS file: tmp/arquivo,v
 Working file: arquivo
 head: 1.3
 branch:
 locks: strict
 access list:
 symbolic names:
 keyword substitution: kv
 total revisions: 3;	selected revisions: 3
 description:
 /diretorio/arquivo
 ----------------------------
 revision 1.3
 date: 2020/11/05 20:40:16;  author: root;  state: Exp;  lines: +1 -1 (1)
 Arquivo /diretorio/arquivo alterado. Data : 05/11/2020 17:40. (2)
 ----------------------------
 revision 1.2
 date: 2020/11/05 20:37:17;  author: root;  state: Exp;  lines: +2 -1
 Arquivo /diretorio/arquivo alterado. Data : 05/11/2020 17:37.
 ----------------------------
 revision 1.1
 date: 2020/11/05 19:20:12;  author: root;  state: Exp;
 /diretorio/arquivo
 =============================================================================

1	A hora registrada é UTC, por ser um controle interno do GNU RCS
2	Na mensagem é registrada a hora (localtime) da alteração do arquivo

13.1.8. Identificar alterações e recuperar versão específica de arquivo

Podemos comparar duas versões do arquivo monitorado com o comando:

 # mtwdog_files.pl --indice 1 --diff 1.1,1.3
 ===================================================================
 RCS file: tmp/arquivo,v (1)
 retrieving revision 1.1
 retrieving revision 1.3
 diff -r1.1 -r1.3
 1c1,2
 < arquivo
 ---
 > Incluidas linha - primeira alteracao
 > Alteracao 2 : removida a linha origimal

1	É usado o rcsdiff para fazer as comparações

Para recuperar uma versão específica do arquivo monitorado, use a opção --versao:

 # mtwdog_files.pl --indice 1 --versao 1.1
 Já existe um arquivo chamado 'arquivo' no diretório corrente.
 Arquivo '/diretorio/arquivo.1.1' recuperado
 # mtwdog_files.pl --indice 1 --versao 1.2
 Já existe um arquivo chamado 'arquivo' no diretório corrente.
 Arquivo '/diretorio/arquivo.1.2' recuperado
 # mtwdog_files.pl --indice 1 --versao 1.3
 Já existe um arquivo chamado 'arquivo' no diretório corrente.
 Arquivo '/diretorio/arquivo.1.3' recuperado
 # ls -l arquivo*
 -rw-r--r--. 1 root root 100 Nov  5 17:46 arquivo
 -r--r--r--. 1 root root   6 Nov  6 11:47 arquivo.1.1 (1)
 -r--r--r--. 1 root root  44 Nov  6 11:47 arquivo.1.2
 -r--r--r--. 1 root root  77 Nov  6 11:47 arquivo.1.3
 # cat arquivo
 Incluidas linha - primeira alteracao
 Alteracao 2 : removida a linha origimal
 Alteracao com mensagem
 # cat arquivo.1.1
 arquivo
 # cat arquivo.1.2
 arquivo
 Incluidas linha - primeira alteracao
 # cat arquivo.1.3
 Incluidas linha - primeira alteracao
 Alteracao 2 : removida a linha origimal

1	Quando o arquivo existe no diretório corrente, ele não é substituído. Uma cópia com o sufixo da versão é criada.

13.1.9. Identificar os arquivos alterados num período

Um recurso muito importante para resolver problemas no ambiente, é identificar os arquivos que foram alterados num período.

Não é possível identificar quem alterou o arquivo, pois esta informação não está disponível.
É relevante, neste contexto, o horário sugerido para a execução da rotina de sincronização: 06:30, 12:30 e 18:30.
Executando a sincronização nestes horários, é possível identificar o período em que houve a alteração e com isso mapear os acessos ao servidor nos log do sistema.

 # mtwdog_files.pl --changes 1/12,20/12 (1)
 Alteracoes ocorridas entre as datas : 01/12/2020 12:00:00 e 10/12/2020 10:03:00
 Indice Arquivo
 ------ ----------------------
     15 /etc/group

 RCS file:        tmp/group,v;   Working file:    group
 head:            1.149
 locks:           ;  strict
 access list:
 symbolic names:
 comment leader:  "# "
 total revisions: 150;    selected revisions: 1
 description:
 ----------------------------
 revision 1.148
 date: 2020/12/08 06:30:31;  author: root;  state: Exp;  lines added/del: 1/1
 Arquivo /etc/group alterado. Data : 08/12/2020 05:32.
 =============================================================================



    138 /etc/opt/samba/smb.conf

 RCS file:        tmp/smb.conf,v;   Working file:    smb.conf
 head:            1.395
 locks:           ;  strict
 access list:
 symbolic names:
 comment leader:  ""
 total revisions: 395;    selected revisions: 5
 description:
 ----------------------------
 revision 1.395
 date: 2020/12/18 18:30:31;  author: root;  state: Exp;  lines added/del: 1/1
 Arquivo /etc/opt/samba/smb.conf alterado. Data : 18/12/2020 13:00.
 ----------------------------
 revision 1.394
 date: 2020/12/08 18:30:30;  author: root;  state: Exp;  lines added/del: 2/2
 Arquivo /etc/opt/samba/smb.conf alterado. Data : 08/12/2020 13:15.
 ----------------------------
 revision 1.393
 date: 2020/12/08 12:30:30;  author: root;  state: Exp;  lines added/del: 1/1
 Arquivo /etc/opt/samba/smb.conf alterado. Data : 08/12/2020 07:56.
 ----------------------------
 revision 1.392
 date: 2020/12/07 18:30:31;  author: root;  state: Exp;  lines added/del: 1/1
 Arquivo /etc/opt/samba/smb.conf alterado. Data : 07/12/2020 16:09.
 ----------------------------
 revision 1.391
 date: 2020/12/07 12:21:11;  author: root;  state: Exp;  lines added/del: 6/6
 Arquivo /etc/opt/samba/smb.conf alterado. Data : 07/12/2020 08:28.
 =============================================================================

1	Se a opção `--lista` for incluída, somente o nome dos arquivos é apresentado.

Para apresentar o que foi alterado no arquivo, use a opção --diff:

 # mtwdog_files.pl --arquivo /etc/group --diff 1.148,1.149
 RCS file: tmp/group,v
 retrieving revision 1.148
 retrieving revision 1.149
 rdiff  -r1.148 -r1.149
 76c76
 < teste::88:root,adm,
 ---
 > teste::88:root,adm,fischer

13.1.10. Integrando com o MTMON

Para integrar o WDOG com MTMON valide se a opção script está configurada no arquivo MTADMbase/etc/mtwdog.conf:

 script=/usr/local/Multitask/mtmon/bin/mtwdog_files.sh

A versão mais recente do script mtwdog_files.sh está disponível no diretório MTMONbase/bin com o nome mtwdog_files.sh.new.

Sempre que o processo de sincronizar os arquivos monitorados encontrar alterações nos mesmos, para cada arquivo é chamado o script definido nesta opção.

Exemplo de script padrão fornecido no inst_mtmon_client:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 #!/bin/sh
 #
 # $Id: mtwdog_files.sh,v 5.1 2017/01/30 11:45:32 user Liberado $
 #
 # Incluir no arquivo /usr/local/Multitask/mtadm/etc/mtwdog.conf :
 #
 # Script=/usr/local/Multitask/mtmon/bin/mtwdog_files.sh
 #
 #
 # Variaveis entregues pelo mtwdog_files.pl :
 #
 # MTWDOG_Indice - Id do arquivo controlado dentro da base do mtwdog_files.pl
 # MTWDOG_Arquivo - Nome do arquivo - caminho completo
 # MTWDOG_Descricao - Descricao da alteracao
 # MTWDOG_Origem - Origem no MTMON
 # MTWDOG_Servidor - Servidor no MTMON
 # MTWDOG_Notifica - Notifica no MTMON
 # MTWDOG_Severidade - Severidade no MTMON
 # MTWDOG_Log - Arquivo com o diff da mudanca
 #
 . /usr/local/bin/ComandosMT.sh
 export origem=''
 export servidor=''

 script=$MTMONbase/bin/mtwdog_files.local.sh (1)
 if [ -x $script ]
 then
   : $script pode gerar o evento e finalizar
   . $script
 fi
 [ "$MTWDOG_GerarEvento" = 1 ] || exit 0
 [ "$MTWDOG_Severidade" -lt "$EventoSeveridade" ] && exit 0

 [ -n "$MTWDOG_Origem" ] && origem="--origem $MTWDOG_Origem"
 [ -n "$MTWDOG_Servidor" ] && servidor="--servidor $MTWDOG_Servidor"

 $MTMONbase/bin/mtmon_evento.pl --aplicacao "mtwdog" \
    --objeto $(echo $MTWDOG_Arquivo | $C_sed -e 's,.*/,,' -e 's/\./_/g') \
    --severidade $MTWDOG_Severidade \
    --mensagem "$MTWDOG_Descricao" \
    --dump $MTWDOG_Log --eventual $MTWDOG_Opcao $origem $servidor
 exit 0

1	script local usado para customizar os atributos na criação do evento. Exemplo: notifica, severidade, etc.

Na sequência inclua os arquivos desejados no WDOG.

Valide se a lista não contém algum arquivo indesejado, como por exemplo, com sufixo .old, .bak ou com uma data.

Para definir a severidade associada ao arquivo monitorado, use o comando abaixo:

 # mtwdog_files.pl --arquivo /root/.ssh/authorized_keys --severidade 2 (1)

1	O evento será gerado no MTMON com severidade crítica (vermelho) sempre que o arquivo `/root/.ssh/authorized_keys` for alterado.

Para o WDOG gerar eventos de alerta (amarelos), altere o parâmetro eventoSeveridade para 1.
Assim, quando o script MTMONbase/bin/mtwdog_files.sh é chamado e a severidade for maior ou igual à definida no arquivo mtwdog.conf, será gerado um evento no MTMON.

13.2. Avalia período entre datas

Eventualmente temos de avaliar se uma data está dentro de um intervalo pré-definido, como por exemplo, férias de algum contato para acionamento.

O script MTADMbase/bin/avaliaPeriodo.pl endereça esta situação.

Suporta as sequintes opções:

--data dd/mm/AAAA HH:MM:SS: Permite que seja informada a data que se deseja avaliar.
Default: hora da execução do comando.
--epoch epoch: Mesma função de --data, mas em formato epoch.
Default: hora da execução do comando.

Na chamada a opção --data tem precedência sobre --epoch.
Internamente, a data fornecida é convertida para epoch.

--periodo string: Define o intervalo de data que será considerado para avaliar se a data está inserida.
--verbose: Flag que informa se mais informação é para ser apresentada.

Considere --data ou --epoch como o momento e --periodo intervalo de avaliação.
Se o momento está dentro do intervalo definido em --periodo, o resultado é rc=0, caso contrário rc=1.

13.2.1. Formato de string em `--periodo`

A string informada pode ter o seguinte formado:

token[,token1[,tokenN]]

onde cada token pode ser configurado:

dd/mm/AAAA HH:MM:SS-dd/mm/AAAA HH:MM:SS

# avaliaPeriodo.pl --periodo '10/01/2001-20/01/2021' --verbose; echo $? (1)
OK. Momento: 19/01/2021 17:55:00. Periodo: 10/01/2001 00:00:00 e 20/01/2021 23:59:59
0

# avaliaPeriodo.pl --periodo '19/01/2001 16:00:00-19/01/2021 17:00:00' --verbose; echo $?
Momento: 19/01/2021 17:55:00. Periodos avaliados:
   19/01/2001 16:00:00 e 19/01/2021 17:00:00
1

# avaliaPeriodo.pl --periodo '1-5,11-15,21-25' --verbose; echo $? (2)
Momento: 19/01/2021 17:55:00. Periodos avaliados:
   01/01/2021 00:00:00 e 05/01/2021 23:59:59
   11/01/2021 00:00:00 e 15/01/2021 23:59:59
   21/01/2021 00:00:00 e 25/01/2021 23:59:59
1

# avaliaPeriodo.pl --periodo '. 13-. 19' --verbose; echo $? (3)
OK. Momento: 19/01/2021 17:55:00. Periodo: 19/01/2021 13:00:00 e 19/01/2021 19:00:00
0

# avaliaPeriodo.pl --data '15/1' --periodo '1-5,11-15,21-25'; echo $? (4)
0

1	Os exemplos contemplam a data de `19/01/2021 17:55:00`
2	Observe que o dia `19` não está nos intervalos definidos e neste caso o `rc=1`
3	Quando é informado o caracter `.` no lugar de `dd/mm/AAAA` será considerado o dia atual
4	Exemplo definindo a data do momento à ser avaliado

13.3. Extração de arquivos de parâmetros

O comando mtadm_get_conf.pl permite extrair sessões de arquivos de configuração em script shells.

As seguintes opções estão disponíveis:

--config: Define o arquivo de configuração que será processado. É o único argumento obrigatório.

Se não for informado o caminho completo do arquivo de configuração, é incluído como PATHNAME o diretório /usr/local/Multitask/mtmon/etc.

O formato do arquivo de configuração é:

[sessão] (1)
  a=a (2)
  b=b

1	Quando `--sessao` é informada, somente ela é processada e apresentada na saída.
2	O parâmetro é definido no formato `chave=valor`.

--default: Sessão cujos parâmetros serão propagados para as demais sessões
Default: Não é definido nenhum default justamente para que o script tenha a opção de receber os parâmetros efetivamente configurados na sessão informada.
--sessao: Sessão do arquivo de configuração que será processado

Se não for informado --sessao, um DUMP formatado do arquivo de configuração é apresentado.
Junto com o parâmetro --json, o DUMP completo do arquivo de configuração será neste formato.

--param: Parâmetro da sessão escolhida que será apresentado

Só é processado junto com o argumento --sessao.

--env: Prepara a saída para ser usada no com o comando eval do shell script.
--prefix: Junto com o argumento --env inclui um prefixo antes da variáveis.
--json: Saída será gerada no formato JSON

Útil para converter os arquivos de configuração para uso com PHP e Javascript

--debug: Apresenta informações de debug

13.3.1. Exemplos

Para gerar um DUMP do arquivo de configuração mtmon_cron.conf, que está no diretório /usr/local/Multitask/mtmon/etc, pode ser usado o comando abaixo:

 # mtadm_get_conf.pl --config mtmon_cron.conf
 [Global]
   limite='3 horas'
   path='/usr/local/Multitask/mtmon/plugin'
   repete='1'

 [MonitoraNetstat]
   aplicacao='network'
   ativo='0'
   comando='MonitoraNetstat.sh 1 3'
   intervalo='* 9,19,29,39,49,59'
   nagios='1'

 [audit]
   aplicacao='audit'
   ativo='1'
   comando='/Users/user/projetos/mtmon/src/mtmon_audit.pl'
   finaliza='1'
   intervalo='06 10'
   weekday='0'

Observe que o programa coloca os valores de parâmetros entre aspas. Assim podemos extrair estes valores para usar em shell script como variáveis cujo nome é o próprio parâmetro.

Informando o argumento --default Global teremos a saída:

 # mtadm_get_conf.pl --config mtmon_cron.conf --sessao audit --default Global
 [audit]
   aplicacao='audit'
   ativo='1'
   comando='/Users/user/projetos/mtmon/src/mtmon_audit.pl'
   finaliza='1'
   intervalo='06 10'
   limite='3 horas' (1)
   path='/usr/local/Multitask/mtmon/plugin' (1)
   repete='1' (1)
   weekday='0'

1	A opção `--default` instrui o programa à propagar os parâmetros da sessão informada, no caso Global.

Para extrair as definições da sessão MonitoraNetstat podemos usar o comando:

 # eval $(mtadm_get_conf.pl --config mtmon_cron.conf --sessao MonitoraNetstat --env --prefix 'export MTMON_')
 # env (1)
 MTMON_aplicacao=network (2)
 MTMON_ativo=0
 MTMON_comando=MonitoraNetstat.sh 1 3
 MTMON_intervalo=* 9,19,29,39,49,59
 MTMON_nagios=1

1	No exemplo apenas apresentamos as variáveis extraídas no comando acima
2	Para cada par de `chave=valor` da sessão definida é adicionado o prefixo `export MTMON_.` O export é necessário quando outros comandos que usarão as variáveis são invocados.

Quando é necessário extrair apenas o valor de um parâmetro específico, podemos usar o comando:

 # echo "Intervalo definido: <<<$(mtadm_get_conf.pl --config mtmon_cron.conf --sessao MonitoraNetstat --param intervalo)>>>"
 Intervalo definido: <<<* 9,19,29,39,49,59>>>

Nos programas em PHP e Javascript, é útil o formato JSON. Para que a informação seja apresentada em JSON, adicione na chamada do comando o argumento --json.

 # mtadm_get_conf.pl --config /usr/local/Multitask/mtmon/etc/mtmon_cron.conf --sessao MonitoraNetstat --json
 {"MonitoraNetstat" : { "aplicacao" : "network", "ativo" : 0, "comando" : "MonitoraNetstat.sh 1 3", "intervalo" : "* 9,19,29,39,49,59", "nagios" : 1 } }

13.4. Lock em shell script

O comando mtadm_lock.sh é usado para garantir que apenas um script seja executado num dado momento. As chamadas subsequentes aguardarão o término do primeiro script, liberando os demais quando o recurso está disponível.

É usado o comando mkdir para definir o lock, pois é uma operação atomica controlada pelo próprio sistema operacional.
Apenas um processo consegue criar um diretório num dado momento e com isso é assegurada a exclusividade do recurso.
Para liberar o recurso, o script que detém o lock executa o rmdir correspondente.

O script suporta as seguintes variáveis:

MTADM_lock_lockDir: Nome do diretório que será criado para garantir o lock.
Default: $MTADMbase/tmp/mtadm.LOCK

É necessário que o nome indicado seja de um diretório pai que existe. Se o diretório pai não existir, o processo fará 500 tentativas e abortará o processo, retornando o status via variável de ambiente MTADM_lock='nOK'.

Exemplo: Se a variável MTADM_lock_lockDir=/var/tmp/dirNotFound/lock.dir for informada, e o diretório /var/tmp/dirNotFound não existir

MTADM_lock_time: Define o tempo em segundos que o script aguardará entre as tentativas de obter o lock.
Default: 3
MTADM_lock_count: Define quantas vezes o script tentará obter o lock antes de retornar com MTADM_lock='nOK'.
Default: 10
MTADM_lock_naoAborta: Se esta variável conter algum valor, o script retornará com MTADM_lock='nOK' caso o lock não for obtido logo na primeira tentativa.
Esta opção é útil quando se deseja que o próprio programa que quer obter o recurso trate a situação.
Default: (não definido)

Após a chamada do script, a variável MTADM_lock será definida com os valores OK ou nOK, de acordo com o sucesso da solicitação.

O script faz uso do trap 0, para que no fim da execução o diretório seja removido.
Se o seu script precisa do trap 0, garanta que o diretório seja removido no fim da execução, para que o lock não seja permanente.

O lock só funciona para processos que executam no mesmo servidor.
Quando o diretório de lock está em GPFS ou NFS o resultado é imprevisível, pois o PID registrado no arquivo de controle, será um PID válido no servidor que obteve o lock. Nos demais servidores, o número do PID poderá estar livre, e o lock será delegado à esta chamada.

Exemplo de script que define lock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#!/bin/bash

. /usr/local/bin/ComandosMT.sh

end_script() {
$C_rm -f $arquivoTemporarioDoScript (1)

# Libera lock de mtadm_lock.sh
: eval "$MTADM_TRAP0" (2)
}

export MTADM_lock_time=3
export MTADM_lock_count=50
export MTADM_lock_naoAborta=1 (3)
export MTADM_lock_lockDir=/var/tmp/script.lock
. $MTADMbase/bin/mtadm_lock.sh --  (4) (5)

if [ "$MTADM_lock" = 'OK' ] (6)
then
  echo 'Executando o restart do crond'
  /sbin/init.d/crond restart
  trap "$MTADM_TRAP0; end_script" 0 (7)
else
  echo 'Não poderá executar o restart' (8)
  exit 1
fi

exit 0

1	`trap 0` é útil para executar comandos na finalização do programa, como por exemplo, remover arquivos temporários.
2	A variável `MTADM_TRAP0` contém os comandos à serem executados para liberar o lock para outro programa. No exemplo são apresentados os 2 formatos possíveis para liberar o lock: na função chamada ou na própria definição do `trap xxx 0`
3	Se a variável `MTADM_lock_naoAborta` estiver vazia, o script fará várias tentativas de obter o lock. As variáveis `MTADM_lock_count` e `MTADM_lock_time` serão usadas no processo para definir o tempo de aguardo para obter o lock. No script acima, serão 50 tentativas aguardando 3 segundos entre cada avaliação.
4	O `--` garante que não seja repassado indevidamente os argumentos que serão tratados pelos script chamador.
5	Será criado um diretório com o nome `/var/tmp/script.lock` e dentro do diretório um arquivo com informações do processo com direito ao lock. Se depois de `$MTADM_lock_count` tentativas o lock não for obtido, retornará `nOK` na variável `MTADM_lock`.
6	Mesmo que a opção `MTADM_lock_naoAborta` não esteja definida, é interessante validar se o lock está `OK`. Isso depende da criticidade do processo que está em execução.
7	Na finalização do programa o shell executará a função `end_script`.
8	Observe que aqui a variável `MTADM_TRAP0` estará vazia e não será executado nenhum comando no `trap 0` quando o script finalizar.

13.5. Proteção de senhas

O objetivo desta sessão é criar um mecanismo que dificulte o acesso de senhas de usuários ou serviços em script shell.

Chamamos este esquema de ofuscamento de senhas

Se alguém executar o script com a opção set -x, poderá ver a senha e o roteiro aqui definido será inócuo.

Para definir uma senha ofuscada, siga os passos abaixo:

Crie uma entrada no arquivo MTADMbase/etc/mtadm_salt.conf:

 [tsm] (1)
   salt=w%tXnj.HSWFwE (2)

1	Usaremos como teste a senha de acesso ao TSM - Tivoli Storage Manager’s, software de backup da IBM.
2	O salt é uma seqüência será usada internamente pelos script de recuperação da senha. Para cada sessão, com uma string diferente no salt, será gerado um PWD_XXXX diferente, dificultando a recuperação da senha para usuários não autorizados.

Se o salt for perdido, não poderá ser recuperada a senha, pois a mesma é usada na criptografia simétrica do processo.

Execute o comando GeraSenha.pl para ofuscar a senha, informando a sessão definida no passo anterior e a senha do TSM:

 # /usr/local/Multitask/mtadm/bin/GeraSenha.pl --PWD tsm -- T5M@cc355
 Senha : PWD_0c5b276e2b3064

Valide se a senha gerada está OK com o comando abaixo:

 /usr/local/Multitask/mtadm/bin/getPWD.pl --PWD tsm -- PWD_0c5b276e2b3064
 T5M@cc355

A senha gerada será incluída nos script’s que de fato usarão a senha do TSM e chamarão o script getPWD que recuperará a mesma.

O script em shell poderá conter o seguinte código:

1
2
3
4
 param='PWD_0c5b276e2b3064'
 [ -x "$C_getPWD" ] || . /usr/local/bin/ComandosMT.sh
 pwd=$($C_getPWD --PWD tsm -- $param)
 echo $pwd

Em perl use a rotina abaixo:

1
2
3
4
5
6
7
 use lib '/usr/local/Multitask/mtadm/bin';
 use MTAdm;
 ...
 my $param='PWD_0c5b276e2b3064';
 $ENV{'MTAdm_salt'}='tsm';
 my $pwd=getPassword($param, '');
 print "$pwd\n";

Nos 2 exemplos acima, a variável $pwd conterá a senha original que será usada na chamada do comando DSMC do TSM.

13.6. Cofre de senhas

Os conceitos apresentados na sessão Proteção de senhas serão usados nesta sessão para permitir a consulta de senhas de forma segura.
O objetivo desta sessão, neste momento, é apresentar um road map para instalar o produto.

Crie a estrutura de diretório

Inicie criando um diretório que será usado na URL de acesso:

1
2
3
4
# cd /var/www/html
# mkdir mtdoc (1)
# cp -p /usr/local/Multitask/mtadm/bin/mtpwd.php mtdoc/mtpwd.php (2)
# cp -p DIR_IMAGEM mtdoc/logoMultitask_32.gif (3)

1	Usaremos a URL https://mttmb.multitask.com.br/mtdoc/mtpwd.php neste tutorial
2	O script é fornecido junto com o inst_mtadm
3	Internamente o script usa o nome `logoMultitask_32.gif` para apresentar o favicon

Defina o nível de segurança desejado

No arquivo /etc/httpd/conf/httpd.conf para acesso às senhas:

<Directory "/var/www/html/mtdoc">
    AuthType Basic
    AuthName "MTDOC"
    AuthBasicProvider file
    AuthUserFile "/usr/local/etc/mtdoc.htpasswd" (1)
    Require valid-user
</Directory>

1	Crie o usuário de acesso com o comando: `htpasswd -c /usr/local/etc/mtdoc.htpasswd mtdoc SENHA`

Para atualizar a senha do usuário use o comando:
htpasswd -b /usr/local/etc/mtdoc.htpasswd mtdoc SENHA
Sem a opção -b a senha será solicitada no terminal

Para usar o sistema, acesse a URL do Cofre de Senhas, será solicitada a senha de acesso.

Salve as senhas com o comando set que aceita 2 parametros:

índice que pode ser número ou caracteres
senha que será definida

Para incluir ou atualizar a senha no cofre, use a URL abaixo:

https://mttmb.multitask.com.br/mtdoc/mtpwd.php/set/1/5enh@PARANa0Poder3screver

Recupere a senha desejada com o comando get informando o índice desejado.

Quando acessar a URL do Cofre de Senhas, será solicitada a senha de acesso.

13.7. Valida sessão em página da WEB

O objetivo desta sessão é criar um mecanismo que permita validar se uma transação chamada via HTTP é válida, usando uma chave criada dinamicamente.

O processo ocorre em 2 etapas:

cliente: faz uma chamada ao script, que irá gerar um HASH para iniciar a sessão
servidor: recebe o HASH do cliente e valida se está autorizado

Este processo não tem a intenção de criptografar a informação transmitida, apenas garantir que o cliente é autorizado para executar a chamado HTTP.

O script $MTADMbase/bin/validaSessao.sh suporta as seguintes opções:

-d: deve ser o primeiro parametro informado. Quando informado, um set -x é apresentado na saída padrão.
-s sistema: permite definir sistemas distintos para geração da transação.
sistema é um campo opcional.
-t n: define o tempo máximo que a transação deve ser apresentada ao servidor. Quando passar o tempo definido, a transação não será autorizada.
n é informado em segundos.
-v: apresenta um mensagem no servidor do resultado da validação da transação.

Observe que o script foi pensado em termos de minutos, não horas ou dias.

13.7.1. Cliente

Para iniciar um ciclo de transação execute o comando abaixo:

# /usr/local/Multitask/mtadm/bin/validaSessao.sh -s mtopera (1)
2350659996:141113

1	O comando pode ser chamado no PHP usando o comando `shell_exec(…);`

Na sequencia podemos chamar a página no servidor usando o HASH gerado:

# /usr/bin/wget https://servidor.com.br/cgi-bin/teste.cgi?token=2350659996:141113 (1)

1	Observe que a string é o HASH gerado acima: `2350659996:141113`

A variável token será tratada internamente pelo script chamado pelo Apache.

13.7.2. Servidor

O programa no servidor chamará o script com o token fornecido pelo cliente:

# /usr/local/Multitask/mtadm/bin/validaSessao.sh -s mtopera -v -t 120 2350659996:141113 (1)

1	A transação será aceita se o servidor receber o token em até 120 segundos depois de gerado o mesmo no cliente.

O parametro -v apresentará uma mensagem, de acordo com o resultado da validação:

# /usr/local/Multitask/mtadm/bin/validaSessao.sh -s mtopera -v 2350659996:141113 (1)
Nao autorizado.
# echo $? (2)
1
# /usr/local/Multitask/mtadm/bin/validaSessao.sh -s mtopera -t 999 -v 2350659996:141113
OK. Autorizado.
# echo $?
0

1	O timeout default é de 60 segundos.
2	Observe que com o rc=$?, podemos tratar se a transação é válida ou não.

13.8. Rotina de debug e log de shell scripts

O programa MTADMbase/bin/shell_debug.sh é um template que é distribuído junto com o inst_mtadm, que pode ser incluído nos shell script’s (sh, ksh e bash) para gerar informações de debug.

Podem ser definidas as variáveis abaixo, que serão usadas pelo script:

MTADM_logFile: Nome do log que será gerado.
Default: /usr/local/Multitask/mtadm/log/shell_debug.log
MTADM_logSize: O próprio template faz um rotate do log para evitar que o tamanho do arquivo venha a encher a área em disco.
Default: 1Mb
MTADM_scriptPrimario: Usado para agrupar o registro dos logs no mesmo arquivo.
Default: ''
MTADM_Debug: Ativa o debug. Quando a variável for definida com n* ou 0, o set -x não é executado, permitindo assim que o script chamador faça o controle do debug.
Default: Não
MTADM_stdout: Quando esta variável for definida com n* ou 0, a saída padrão não é incluída no arquivo de log.
Default: Sim
MTADM_stderr: Quando esta variável for definida com n* ou 0, a saída de erro não é incluída no arquivo de log.
Default: Sim

Exemplo de script com o nome /usr/local/bin/teste.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash

source /usr/local/bin/ComandosMT.sh

# Prepara para mandar mensagem para tty
exec 7>&1 (1)

export PS4='+ ${FUNCNAME:-main}:$LINENO ' (2)

export MTADM_Debug=on
export MTADM_stderr='' (3)
export MTADM_stdout=no (4)
export MTADM_logSize=100Kb (5)
export MTADM_myScript=${0##*/}
export MTADM_scriptPrimario={string} (6)
export MTADM_logFile=$MTADMbase/log/${MTADM_myScript%sh}log (7)
source $MTADMbase/bin/shell_debug.sh

echo "Comandos do script..."
echo "Saida deste comando sera no tty e nao no arquivo de log." >&7 (8)

1	`7>&1` abre um stdout com identificador `&7`
2	$FUNCNAME não é funcional no KornShell Alternativa mais portável: `PS4='+ $0:$LINENO '` Coloque o nome do script no lugar de `main` para melhor documentação
3	Quando as variáveis `MTADM_stdout` ou `MTADM_stderr` estão zeradas (valor = ''), a saída de stdout/stderr é registrada no arquivo de log. O padrão é registrar no arquivo de log as informações de saída dos comandos. Portanto, a idéia das variáveis é definir quando não se deseja fazer o registro. No exemplo acima, a saída de erro (stderr) irá para o arquivo de log e a saída padrão (stdout) continuará à ser o terminal.
4	Definindo a variável com valor nullo (''), garante que o script registrará no log as informações, pois o script chamador pode ter definido as mesmas variáveis com valores diferentes.
5	O tamanho pode ser definido em bytes, Kbytes ou Mbytes Internamente o programa valida apenas a primeira letra após o número informado. Assim, os seguintes valores serão tratados como iguais: 1048576, 1024K ou 1Megabyte.
6	Informa ao script que os logs devem ser agrupados no arquivo de log deste script. A string é apenas um label sem função ativa. Mas atente para o caso de algum script chamador ter definido a variável: neste caso o log será registrado no arquivo do primeiro script que definiu a variável.
7	Ao iniciar o script, o tamanho do arquivo de log é avaliado e se for maior do que 100Kb (definido na variável MTADM_logSize), o arquivo existente é movido para $MTADM_logFile.OLD. Na sequência um novo arquivo de log é criado.
8	Útil para interação com usuário ou mensagens de erro. O redirecionamento `>&7` apresenta a mensagem no terminal ou na saída da crontab.

Observe que no script acima, o set -x será ativado por conta da variável MTADM_Debug cuja função independe das variáveis MTADM_std(out|err).
A saída padrão será apresentada normalmente no terminal.

Se o PATHNAME do arquivo de log não iniciar com o caracter /, o arquivo é criado em relação ao diretório em que o script está sendo executado.
No exemplo abaixo, o arquivo teste.log será criado no diretório corrente $PWD.

export MTADM_logFile=teste.log

Em cada função definida no script que usar este recurso, é necessário incluir os comandos abaixo, pois nem todos os shell scripts herdam esta definição em chamadas de subrotinas:

funcao_do_shell() {
[ -n "$MTADM_Debug" ] && set -x (1)
: $($C_date +'%d/%m/%Y %T') funcao $FUNCNAME $* (2)

echo 'Comandos da função'
}

1	Quando shell_debug.sh é chamado e o debug está definido como não (default), a variável `MTADM_Debug` é zerada para simplificar as chamadas subsequentes em funções. O teste para verificar o tamanho da string associada à variável é muito mais barato do que validar conteúdo.
2	A variável $FUNCNAME só está disponível no bash. No KornShell é necessário informar em cada função no seu nome para registrar corretamente no log.

Uma vantagem no bash é que o set -x é herdado da parte chamadora do script.
Mas em scripts cuja duração é maior, é útil a inclusão deste código, pois a data da chamada da função é registrada no log e esta informação ajudará na identificação daquelas que precisam de atenção para otimização.
Além disso, facilita no caso de ativar/desativar o debug, pois alterando a variável MTADM_Debug podemos desativar o trace nas funções.

Uma opção disponível é chamar o script com a opção -d, que não grava o arquivo de log e gera o trace do shell script no terminal, permitindo acompanhar a execução dos comandos.
Por exemplo, se o script acima tem o nome de exemplo.sh, para chamar o mesmo com a opção -d execute na linha de comando:

exemplo.sh -d -d -o opcao1 -f opcao2  (1) (2)

1	Para ativar o debug no terminal, a opção `-d` deve ser a primeira definida.
2	exemplo.sh é executado com a opção duas vezes: `-d -d.` O primeiro `-d` é usado pela rotina do shell_debug.sh que à consome e na sequência remove a mesma com o comando shift, permitindo que o script cliente possa usar a segunda opção no seu processamento.

O programa shell_debug.sh faz um shift quando a primeira opção é -d ou --.
O programa exemplo.sh receberá as opções: -d -o opcao1 -f opcao2

Para executar sem debug um script cliente que também suporta a opção -d, temos duas alternativas:

exemplo.sh -- -d -o opcao1 -f opcao2 (1)
exemplo.sh -o opcao1 -f opcao2 -d (2)

1	A forma preferida de chamar o script cliente, pois não haverá conflito.
2	Alternativa funcional, quando a opção `-d` não é a primeira informada.

13.8.1. Configuração de script’s na crontab

Normalmente, nas configurações da crontab, são incluídos argumentos na chamada dos comandos para ignorar as mensagens do script e de erro, direcionando as mesmas para /dev/null.

As mensagens do script e de erro serão direcionadas para o arquivo de log definido, permitindo o debug futuro.

Exemplo sem o template:

0 3 * * * /usr/local/bin/script_teste.sh > /dev/null 2>&1 (1)

1	A proposta do script é eliminar esta forma de configuração

Exemplo com o template:

0 3 * * * /usr/local/bin/script_teste.sh (1)

1	O log só crescerá até o limite definido na variável MTADM_logSize

14. MT-Cluster

O MT-Cluster é um software de controle de recursos que podem ser compartilhados entre computadores.
O planejamento antecipado de problemas minimiza o impacto gerado na parada do servidor configurado com o cluster, pois as tarefas de ativação do serviço estão definidas num pacote, que é a unidade básica de controle do MT-Cluster.

O diretório base usado pelo programa é /usr/local/Multitask/mtcl e será referenciado nesta sessão como MTCL.

O objetivo é permitir que os recursos configurados no pacote possam ser ativados em qualquer servidor definido no pacote.

Para ativar um pacote MT-Cluster, é necessário que seja garantida a integridade dos recursos e que o mesmo pacote não esteja ativo em outro servidor do cluster.

As verificações realizadas antes de ativar o pacote incluem:

Procura em todos os servidores que podem ativar o pacote, o arquivo MTCL/var/pacote.lock.

A verificação é realizada por meio do comando ssh.
Se encontrar o arquivo MTCL/var/pacote.lock num dos servidores do cluster, assume que este servidor está com o pacote ativado e aborta a ativação solicitada.

Executa o comando ping no endereço IP associado ao pacote.
Se o endereço responder, o pacote não será ativado, pois no mínimo haverá conflito de endereços de rede.
Para cada VG definido no pacote, é verificado se o mesmo não está no estado active, pois ativar o pacote nestas circunstâncias poderia corromper a estrutura do LVM.

Se a verificação inicial concluir que o pacote pode ser ativado, a seguinte seqüência é executada:
- Executa o script do pacote com os argumentos: ativa inicio
- Configura as placas de rede com os endereços definidos na sessão IP
- Ativa os Volume Groups definidos na opção VG, na sessão Pacote
- Verifica com o comando fsck e monta os filesystems definidos na sessão MountPoint
- Exporta os diretórios para o NFS definidos na sessão ExportFS
- Configura as rotas definidas na sessão Route
- Executa o script do pacote com os argumentos: ativa fim
O processo de desativação ocorre em ordem inversa:
- Executa o script do pacote com os argumentos: desativa inicio
- Desativa as rotas definidas na sessão Route
- Desfaz a exportação dos diretórios do NFS definidos na sessão ExportFS
- Elimina os processos que tem arquivos abertos nos filesystems e desmonta os mesmos definidos na sessão MountPoint
- Desativa os Volume Groups configurados na opção VG, na sessão Pacote
- Desativa os endereços de rede TCP/IP definidos na sessão IP
- Executa o script do pacote com os argumentos: desativa fim

Observe que o script do pacote será chamado 2x: no início e no fim da ativação do pacote.
Esta segunda chamada é útil para iniciar aplicativos depois de montado o ambiente.

Na desativação do pacote, ocorre o mesmo processo.

14.1. Opções de chamada do programa

O comando mtcl.pl é usado para realizar as ações do MT-Cluster. Pode ser acionado com os seguintes parâmetros:

--ativar pacote: Ativa o pacote informado após verificar se o mesmo está liberado.
Consulte a sessão de configuração de pacotes para detalhes.

Se o nome do pacote informado é todos, serão ativados todos os pacotes definidos por default no servidor em que é executado o comando e que não estão ativados.

--desativar pacote: Desativa o pacote informado.
Se o pacote não está ativo, os procedimentos de desativação são executados, permitindo assim, que se garanta que os recursos sejam todos liberados.

Se o nome do pacote informado é todos, todos os pacotes ativos no servidor local serão desativados.

--lista: Apresenta lista dos pacotes configurados do cluster no servidor.
--status [ pacote ]: Apresenta a situação dos pacotes no servidor.
Se for informado o nome do pacote, apenas a situação deste pacote é verificada.
--force: Quando é feita a verificação do status do pacote e não é possível definir se o mesmo já está ativo em outro servidor do cluster, esta opção libera a seqüência de execução de comandos para ativar o pacote.
--sincronizar [ pacote ]: Se o pacote está configurado para sincronizar os arquivos de configuração, a chamada com esta opção permitirá que o script MTCL/bin/rsync.cluster.[pacote.]sh seja invocado para executar o procedimento.
Se for informado o nome do pacote, apenas a situação deste pacote é verificada.

O padrão é permitir a sincronização dos pacotes. Para desabilitar esta opção configure Sincronizar=0 no arquivo de configuração do pacote.

A sincronização sempre busca os arquivos que compõe o pacote no servidor em que o mesmo está ativado.
Se não está montado, a ação não é executada.

Defina a variável do shell export MTCL_debug=1 para que o script de sincronização execute o set -x e retorne o trace da execução.

Num cluster em que existem mais do que 2 servidores, esta opção é executada nos servidores em que o pacote NÃO ESTÁ MONTADO, pois a idéia é atualizar eventuais alterações que foram feitas nestes arquivos no servidor em que o pacote está ativo.

Um pacote pode estar configurado num único servidor.
Esta situação é útil para prover uma documentação integrada no MTMON, que disponibiliza as configurações e scripts em Informações do Sistema Operacional, na sessão Cluster.

--log arquivo

Grava as informações de --debug e --verbose no arquivo de log informado.

--verbose n

Quando informada esta opção, o nível de debug é incrementado.
O número informado é uma soma que define o nível de log que se deseja:

1 - Descrição básica da tarefa que será executada
2 - Comando que será executado
4 - Saída do comando executado

8 - Parâmetros definidos no arquivo de configuração do pacote

--verbose 7 apresentará as informações dos itens 1+2+3
--verbose 15 apresentará todas as informações de debug disponíveis

export MTCL_verbose=N definirá o nivel de debug em cada chamada do mtcl.pl
N é o nível de debug

--debug

Equivale à opção --verbose 7

--help

Apresenta uma tela de ajuda com as opções disponíveis na chamada do comando.

--versao

Versão do programa

14.2. Arquivo de configuração

Todos os pacotes do MT-Cluster estão definidos no diretório MTCL/etc.
Cada pacote tem um arquivo de configuração, cujo nome é pacote.pkg.

Se o nome do pacote é ora_prod, o arquivo de configuração será MTCL/etc/ora_prod.pkg.
Use o template MTCL/pacote.pkg.exemplo como base para criar o arquivo com o novo pacote.

A ativação e desativação do pacote é realizada com o comando mtcl.pl:

# mtcl.pl --ativa ora_prod
# mtcl.pl --desativa ora_prod

O arquivo de configuração do pacote pode ter as seguintes sessões:

Pacote
IP
MountPoint
ExportFS
Route

Algumas sessões podem ser repetidas.
Por exemplo, se existirem 5 diretórios que serão montados na ativação de um pacote, podemos configurar no arquivo de configuração pacote.pkg 5 sessões MountPoint.
Em alguns casos, quando é necessário maior controle para ativar os recursos do cluster, podemos executar manualmente os comandos no script chamado durante a ativação do pacote: MTCL/etc/{pacote}.sh.

As sessões Pacote e IP são obrigatórias, pois o mtcl.pl usa o endereço de rede como identificador único de pacote ativado.
Para validar se o pacote já está ativo em algum servidor do cluster, o comando ping é usado.

14.2.1. Sessão Pacote (obrigatória)

Define atributos gerais do pacote.

As seguintes opções podem ser configuradas:

Nome: Define o nome do pacote e é usado apenas para confirmar o seu nome.

É uma redundância que proteje o cluster quando uma cópia do arquivo de configuração é feita e as sessões não foram reconfiguradas adequadamente.
Este bloqueio protege contra a execução de comandos indevidos.

Default: Nome do servidor onde o pacote será carregado por padrão.

Quando o que se deseja é que no boot do servidor já seja ativado algum pacote, defina o servidor que será usado.

Servidores: Nome dos servidores, separados por virgula, que compõem o cluster para o pacote.
Sincronizar: Quando o comando mtcl.pl é chamado com a opção --sincronizar e o pacote está montado num servidor remoto, chama um script que pode ser configurado para sincronizar os arquivos de controle e outros diretórios, usando o comando rsync do sistema operacional.

O mtcl.pl tentará executar o primeiro script que encontrar: MTCL/bin/rsync.cluster.{pacote}.sh ou MTCL/bin/rsync.cluster.sh

Se não achar nenhum dos dois scripts, apresenta mensagem informando que não há script para processar a solicitação.

VG: Nome dos Volume Groups configurados no pacote.
O Volume Group será iniciado na ativação do pacote, permitindo montar os Logical Volumes configurados nele.
Esta opção pode ser definida também na sessão MountPoint.

14.2.2. Sessão IP (obrigatória)

Define atributos para configuração dos endereços de rede associados ao pacote.

Definir um IP para cada pacote que será configurado no cluster, pois o IP será o seu identificador único.
Não esqueça de configurar no DNS ou /etc/hosts estes endereços.

Podemos configurar nesta sessão as seguintes opções:

Endereco: Endereço TCP/IP que será usado quando o pacote é ativado.
Netmask: Máscara de rede associado ao endereço de rede.
Interface: Device usado para configurar a placa de rede.
Consulte a sessão Personalizando opções por servidor.
SemPing: O padrão é verificar se o endereço responde ao ping.
Com esta opção, o endereço não será validado.
É útil para endereços secundários que não respondem ao ping.

14.2.3. Sessão MountPoint

Quando existem diretórios que são pré-requisitos para ativar um pacote, estes devem ser montados pelo cluster.

A montagem dos file systems pode ser feita usando esta sessão ou ser incluida no script MTCL/etc/{pacote}.sh.

Opções suportadas:

Device: Nome do device que acessa os dados do file system no disco.

Se é usada uma estrutura de LVM, lembre-se de ativar o Volume Group correspondente na opção VG na sessão Pacote.

Diretorio: É o ponto de montagem usado pelo comando mount do UNIX.
Tipo: Define o tipo de file system que será montado.
Opcoes: Quando o device é um CDROM ou CIFS, a montagem pode exigir opções que devem ser repassadas para o comando mount.
VG: Tem a mesma função da opção VG configurado na sessão Pacote.
Foi criada a opção nesta sessão para facilitar a configuração do pacote.

Quando configurar um pacote que precisa montar um diretório de um servidor remoto via NFS, inclua no arquivo .pkg a diretiva:

[MountPoint]
  Device=remoto:/dir_remoto (1)
  Diretorio=/dir_local
  Tipo=nfs
  Opcoes= -o nolock (2)

1	`remoto` é o nome do servidor cadastrado no `DNS` ou no `/etc/hosts`
2	Como alternativa, podemos fazer o `mount` no script do pacote

14.2.4. Sessão ExportFS

Exporta diretório para ser montado via NFS num servidor remoto.

Diretorio: Nome do diretório local para ser exportado.

O linux exige que o diretório tenha a seguinte sintaxe:

Diretorio=*:/dir_exemplo
Diretorio=server_remoto:/dir_exemplo

Opcao: Opções repassadas para o comando exportfs.

14.2.5. Sessão Route

Cria rota alternativa no endereçamento TCP/IP.

Destino: endereço alvo da rota à ser definida.
Netmask: máscara de rede que será usada na definição da rota.

14.3. Comandos e scripts

14.3.1. Script do pacote

O script do pacote chamado pelo mtcl.pl durante a ativação/desativação do pacote chama-se MTCL/etc/{pacote}.sh.
Em ambientes mais complexos, pode existir também o script MTCL/etc/{pacote}.{servidor}.sh.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#!/bin/sh
#
# $Id: pacote.sh,v 2.4 2016/10/26 12:14:49 user Liberado $
#
# A variavel de ambiente $MTCL_pacote tem o nome do pacote sendo processado
#

. /usr/local/Multitask/mtcl/bin/funcoesMTCL.sh

export Acao=$1
export Fase=$2
if [ "$Acao" = 'ativa' ]
then
  case "$Fase" in
  inicio)
    : Colocar aqui os comandos executados antes de inicializar o pacote
    : validacao personalizada se o pacote pode ser ativado.
    : rc != 0 cancela ativacao (1)
  ;;
  fim)
    : Colocar aqui os comandos executados depois de inicializar o pacote
    : ex. Carga de banco de dados

    : RemontaMTMON $MTCL_pacote (2)
    : RemontaCrontab $MTCL_pacote
    : RemontaInittab $MTCL_pacote ### OBSOLETO ###  (3)

    : Comandos locais para ativar aplicativos executados no servidor (4)
  ;;
  esac
elif [ "$Acao" = 'desativa' ]
then
  case "$Fase" in
  inicio)
    : Colocar aqui os comandos executados antes de finalizar o pacote
    : ex. Derrubar o servidor de banco de dados (5)

    : RemontaCrontab '' (6)
    : RemontaMTMON ''
  ;;
  fim)
    : Colocar aqui os comandos executados depois de finalizar o pacote (7)
  ;;
  esac
fi
exit 0

1	Incluir aqui validações preliminares para ativar o pacote. Se finalizar com `rc` diferente de 0, a ativação do pacote é cancelada. Exemplo: `exit 1`
2	Estas funções estão definidas no script `funcoesMTCL.sh`
3	OBSOLETO: Era usado nos servidores HP-UX e AIX. Não é recomendado usar a `/etc/inittab` para iniciar processos, salvo recomendação do fornecedor do Sistema Operacional
4	Incluir os comandos para ativar o banco de dados, ex. Oracle ou Informix
5	Executar quaisquer comandos que desativem os daemons associados ao pacote
6	Observe que na ativação, o nome do pacote é fornecido. Na desativação, é repassado a string vazia
7	Incluir os comandos que precisam ser executados quando o pacote for desativado. Pode por exemplo, chamar o próprio mtcl.pl para ativar/desativar outro pacote

14.3.2. ComandoRemoto.sh

Para executar os comandos de validação e sincronização nos servidores configurados, o MT-Cluster usa o comando MTCL/bin/ComandoRemoto.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#
# $Id: ComandoRemoto.sh,v 2.1 2014/03/12 16:34:46 user Liberado $
#

#
# ComandoRemoto.sh e' chamado internamente pelo mtcl.pl para simplificar o
# processo de chamada de scripts em servidores remotos
#
#
# Voce pode definir qualquer forma de execucao remota que atenda a funcao que
# o mtcl.pl necessita. Por exemplo:
#
# export COMANDO_REMOTO=/usr/bin/remsh
# export COMANDO_REMOTO='/usr/bin/ssh -i /home/root/.ssh/id_dsa' (1)
#

. /usr/local/bin/ComandosMT.sh

exec 2>&1
export Servidor=$1
export COMANDO_REMOTO=$C_ssh (2)

shift

if [ -x "${COMANDO_REMOTO%% *}" ]
then
  $COMANDO_REMOTO $Servidor $*
else
  echo "Comando '$COMANDO_REMOTO' nao executavel"
  exit 1
fi

1	O comando pode incluir opções de chaves especificas
2	Valide as conexões entre os servidores para evitar que chaves não autorizadas bloqueiem o acesso ao servidor remoto

14.4. Personalizando opções por servidor

O arquivo de configuração contém informações de devices que são usados pelo cluster. A nomenclatura dos devices pode diferir entre os servidores e para endereçar esta necessidade, podemos configurar qual device será usado por incluir o nome do servidor na opção.

A sintaxe básica das opções seguem o modelo abaixo:

opcao:servidor1=valor1 (1)
opcao:servidor2=valor2
opcao=valor (2)

1	Quando é acrescentado o sufixo `:servidor` na opção, o valor será atribuído apenas no servidor informado
2	Sem o sufixo, o valor é atribuído para a opção em todos os servidores configurados no cluster

O sufixo servidor é um nome que pode ser traduzido para um endereço IP via /etc/hosts ou DNS.
Esta situação é usada principalmente para o nome do device de rede, mas é aplicável para qualquer opção de qualquer sessão na configuração do pacote.

Exemplo de arquivo de configuração definindo devices por servidor:

MTCL/etc/pacote.pkg

[Pacote]
  Nome=pacote
  Default=mtmon
  Servidores=mtmon, mtbkp
  VG:mtmon=vg10, vg11, vg12 (1)
  VG:mtbkp=vg10, vg05, vg12

[IP]
  Endereco=172.16.214.215
  Netmask=255.255.0.0
  Interface:mtmon=ens160:mtlan (2)
  Interface:mtbkp=lan0:mtlan (3)

[MountPoint]
 Device:mtmon=/dev/vg11/lvol1 (4)
 Device:mtbkp=/dev/vg05/lvol1
 Diretorio=/fs_legado
 Tipo=vxfs
 Opcoes=

1	O Volume Group possui nomes diferentes nos dois servidores e quando ativar o pacote parâmetros diferentes serão fornecidos ao comando de ativação do VG
2	No servidor `mtmon` a interface `ens160` será configurada com o IP do pacote, e terá o nome virtual de `ens160:mtlan`
3	O servidor `mtbkp` usará a interface física `lan0` com o nome virtual `lan0:mtlan`
4	Além da diferença no nome do VG05 e VG11, o mount point deverá ser ajustado de acordo com a nomenclatura de cada servidor

Quando a aplicação já existe e ela é migrada para usar o MT-Cluster, ocorrem situações onde não é possível reconfigurar o nome dos VG’s e mount point’s.
A recomendação é que se faça este remanejamento, pois simplifica bastante a administração e minimiza situações de erro na configuração do cluster.
Mas, em situações controladas, o software está preparado para suportar este modelo de implementação.

14.4.1. Configuração do SSH nos servidores

O aspecto mais importante na configuração do SSH é que as chaves de servidor (hosts keys) sejam as mesmas em todos os servidores que participam do cluster.
A razão é que quando o pacote migrar de um servidor para outro, não ocorra conflito nas conexões que validam e executam funções de manutenção do cluster.

As host keys normalmente estão no diretório /etc/ssh

[root@mtmon ~]# ls -l /etc/ssh/ssh_host_* (1)
-rw-------. 1 root root      668 Ago 14  2017 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 root root      617 Ago 14  2017 /etc/ssh/ssh_host_dsa_key.pub
-rw-------. 1 root ssh_keys  227 Set 29  2017 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root      162 Set 29  2017 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root ssh_keys  432 Set 29  2017 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root      112 Set 29  2017 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root      992 Ago 14  2017 /etc/ssh/ssh_host_key
-rw-r--r--. 1 root root      657 Ago 14  2017 /etc/ssh/ssh_host_key.pub
-rw-------. 1 root ssh_keys 1675 Ago  8  2016 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root      382 Ago  8  2016 /etc/ssh/ssh_host_rsa_key.pub

1	Ao copiar estes arquivos, os servidores passarão à ter a mesma assinatura `SSH` na conexão.

Na medida do possível, crie uma chave específica para o MT-Cluster e use esta chave para a comunicação entre os servidores.
Este procedimento não é mandatório, mas a esta definição evita que o MT-Cluster use as chaves do super-usuário e introduz mais um obstáculo para alguém violar o ambiente.

# ssh-keygen -f /usr/local/Multitask/mtcl/etc/id_dsa.mtcluster -t dsa -b 1024 -N '' (1)

1	A opção `-N ''` é necessária, pois não pode pedir a senha do usuário quando executar os comandos do cluster

Escolha um servidor base para incluir as chaves públicas usadas na comunicação no arquivo $HOME/.ssh/authorized_keys do usuário que executa os comandos de ativação dos pacotes (normalmente o root).
Replique o arquivo $HOME/.ssh/authorized_keys criado no passo anterior para os demais servidores do cluster.

14.4.2. Configuração da crontab para multiplos usuários

A crontab é um aspecto vital na configuração de qualquer pacote, pois existem muitas atividades que precisam ser executadas durante o tempo em que o mesmo está ativo no servidor.

Na primeira execução do instalador do MT-Cluster, é salva a versão corrente da crontab dos usuários no diretório MTCL/etc/crontabs/usuario/crontab.base.

# cd /usr/local/Multitask/mtcl/etc/crontabs
# ls -l */*
-rw-r--r-- 1 root root 1478 Apr 16 12:41 root/crontab.base (1)

1	Se a crontab para o usuário oracle existir, será criado um arquivo chamado `oracle/crontab.base`

O arquivo crontab.base de cada usuário será sempre incluído na reconstrução das crontabs na ativação e desativação dos pacotes, pois contém os comandos que são locais ao servidor.

Para os pacotes que possuem entradas na crontab é necessário criar um arquivo chamado MTCL/etc/crontabs/{usuario}/{pacote}.crontab

Descomentar no script do pacote a chamada para a função RemontaCrontab que de fato processa a alteração da crontab.

Se nenhum pacote está no ar, apenas o arquivo crontab.base será usado na montagem da crontab.
A variável $MTCL_PacotesAtivos contém a lista de pacotes que estão ativos no servidor no momento e pode ser usada pelo script do pacote para decidir se um pacote será ativado ou desativado.

14.5. Exemplo de pacote `ora_prod`

Nesta sessão, apresentaremos um estudo de caso em que as opções de configuração são aplicadas.

Consulte a sessão de configuração de pacotes e o documento MTCL/doc/MT-Cluster.ppt para detalhes.

Para identificar quais pacotes estão configurados no servidor execute o comando:

# mtcl.pl --lista
$Revision: 2.12 $
$Date: 2021/04/19 20:51:16 $

Pacotes disponiveis :

	ora_prod (1)

1	Usaremos para demonstração dos recursos do MT-Cluster, o pacote `ora_prod`

O arquivo de configuração:

MTCL/etc/ora_prod.pkg

[Pacote]
  Nome=ora_prod
  Default=mtmon
  Servidores=mtmon

[IP]
  Endereco=10.9.8.254
  Netmask=255.255.240.0
  SemPing=0
  Interface:mtmon=ens160:mtlan

[MountPoint]
  Device=ramfs
  Diretorio=/home/mtmon.multitask/ramdisk
  Tipo=ramfs
  Opcoes= -t ramfs -o size=10k

[Route]
  Destino=-net 192.168.199.0
  Netmask=255.255.255.0
  Gateway=gw 10.9.8.58
  Count=metric 1

O script do pacote:

MTCL/etc/ora_prod.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#!/bin/bash
#
# A variavel de ambiente $MTCL_pacote tem o nome do pacote sendo processado
#

source /usr/local/Multitask/mtcl/bin/funcoesMTCL.sh

export Acao=$1
export Fase=$2
if [ "$Acao" = 'ativa' ]
then
  case "$Fase" in
  inicio)
    if [ -e /oracle/diretorio/emBackup.flag ]
    then
      echo "$0:$LINENO Abortado: Backup do ORACLE offline em andamento"
      exit 1
    fi
  ;;
  fim)
    RemontaCrontab $MTCL_pacote
    echo "$0:$LINENO Comandos para colocar a aplicacao no ar" (1)
  ;;
  esac
elif [ "$Acao" = 'desativa' ]
then
  case "$Fase" in
  inicio)
    echo "$0:$LINENO Comandos para desativar a aplicacao"
    RemontaCrontab ''
  ;;
  fim)
    echo "$0:$LINENO Comandos que devem ser executados por ultimo"
  ;;
  esac
fi
exit 0

1	No log da ativação do pacote é apresentado o nome do script e a linha correspondente

Arquivos de configuração das crontabs dos usuários root e oracle usados no pacote:

crontabs/oracle/crontab.base

##########                                    ##########
##########   Crontab base para usuario oracle ##########
##########                                    ##########

crontabs/oracle/ora_prod.crontab

##########                                                  ##########
##########   Crontab para usuario oracle do pacote ora_prod ##########
##########                                                  ##########

crontabs/root/crontab.base

# MTMON
59 * * * * /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
0,15,30,45 * * * * /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
@reboot /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
*/15 * * * * /usr/local/Multitask/mtadm/bin/ColetaMemoriaReal.sh #

crontabs/root/ora_prod.crontab

###########                                                        ###########
########### Crontab exemplo para o usuario root do pacote ora_prod ###########
###########                                                        ###########

Para ativar o pacote, é usado o comando mtcl.pl e a sintaxe mais simples pode ser:

# mtcl.pl --ativa ora_prod --debug
21/04/2021 16:21 : Ativa ora_prod
21/04/2021 16:21 : Definicao do ambiente do pacote ora_prod
21/04/2021 16:21 : /usr/local/Multitask/mtcl/etc/ora_prod.mtmon.sh nao existe. (1)
21/04/2021 16:21 : Definido script /usr/local/Multitask/mtcl/etc/ora_prod.sh
21/04/2021 16:21 : Nao foram definidos 2 servidores. [/usr/local/Multitask/mtcl/etc/ora_prod.pkg]
[Pacote]
Servidores=mtmon (2)
21/04/2021 16:21 : Verifica se pacote 'ora_prod' esta liberado para ativacao (3)
21/04/2021 16:21 : Verifica se arquivo de lock existe. [/usr/local/Multitask/mtcl/var/ora_prod.lock]
21/04/2021 16:21 : Verificacao nos servidores 'mtmon'
21/04/2021 16:21 : Verificando servidor 'mtmon'
21/04/2021 16:21 : Servidor 'mtmon' nao tem lock
21/04/2021 16:21 : . Verificando endereco 10.9.8.254
21/04/2021 16:21 : Ativa enderecos de rede
21/04/2021 16:21 : . Ativando endereco 10.9.8.254 na interface ens160:mtlan
ens160:mtlan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.9.8.254  netmask 255.255.240.0  broadcast 10.9.15.255
        ether 00:50:56:9c:0a:b1  txqueuelen 1000  (Ethernet)

21/04/2021 16:21 : Ativa Volume Groups
21/04/2021 16:21 : . Nenhum Volume Group definido
21/04/2021 16:21 : Verifica e monta filesystems
21/04/2021 16:21 : . Processando /home/mtmon.multitask/ramdisk
fsck from util-linux 2.31.1
21/04/2021 16:21 : Ativa exportfs
21/04/2021 16:21 : . Nenhum diretorio para exportar
21/04/2021 16:21 : Ativa rotas
21/04/2021 16:21 : . Ativando rota -net 192.168.199.0
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.9.0.11       0.0.0.0         UG        0 0          0 ens160
10.9.0.0        0.0.0.0         255.255.240.0   U         0 0          0 ens160
192.168.199.0   10.9.8.58       255.255.255.0   UG        0 0          0 ens160
/usr/local/Multitask/mtcl/etc/ora_prod.sh:22 Comandos para colocar a aplicacao no ar (4)

1	Se o arquivo for encontrado, o mesmo será usado como script do pacote e o arquivo MTCL/etc/ora_prod.sh será ignorado
2	Mensagem meramente informativa que avisa potencial erro de configuração
3	Consulte a documentação sobre verificação de pacote
4	Observe a linha correspondente no script do pacote do exemplo

Se tentar ativar o pacote novamente ou executar com a opção --status o programa informa que o pacote já está ativado:

# mtcl.pl --ativa ora_prod
mtmon: Existe arquivo /usr/local/Multitask/mtcl/var/ora_prod.lock
Pacote ativado no servidor mtmon desde 21/04/2021 16:21
# mtcl.pl --status ora_prod

21/04/2021 16:24 : Verificando pacote 'ora_prod'.
mtmon: Existe arquivo /usr/local/Multitask/mtcl/var/ora_prod.lock
Pacote ativado no servidor mtmon desde 21/04/2021 16:21

Se o servidor for desligado sem executar o comando de desativação a mesma mensagem será apresentada.
Neste caso, execute o comando de desativação no servidor indicado, que garantirá a liberação dos DEVICES usados

Quando o pacote foi ativado corretamente, a crontab ficará assim:

# crontab -l

# ------------------------------------------------------------------------------
#
# 21/04/2021 16:41:36 - Incluido de /usr/local/Multitask/mtcl/etc/crontabs/root/crontab.base (1)
#
# INI /usr/local/Multitask/mtcl/etc/crontabs/root/crontab.base
# MTMON
59 * * * * /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
0,15,30,45 * * * * /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
@reboot /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
*/15 * * * * /usr/local/Multitask/mtadm/bin/ColetaMemoriaReal.sh #
# FIM /usr/local/Multitask/mtcl/etc/crontabs/root/crontab.base
# ------------------------------------------------------------------------------
#
# 21/04/2021 16:41:36 - Incluido de /usr/local/Multitask/mtcl/etc/crontabs/root/ora_prod.crontab (2)
#
# INI /usr/local/Multitask/mtcl/etc/crontabs/root/ora_prod.crontab
###########                                                        ###########
########### Crontab exemplo para o usuario root do pacote ora_prod ###########
###########                                                        ###########
# FIM /usr/local/Multitask/mtcl/etc/crontabs/root/ora_prod.crontab
# ------------------------------------------------------------------------------

1	crontab do usuário `root` que sempre será incluída na configuração
2	Esta parte da crontab só será incluída quando o pacote estiver ativo

# crontab -l -u oracle

# ------------------------------------------------------------------------------
#
# 21/04/2021 16:41:36 - Incluido de /usr/local/Multitask/mtcl/etc/crontabs/oracle/crontab.base
#
# INI /usr/local/Multitask/mtcl/etc/crontabs/oracle/crontab.base (1)
##########                                    ##########
##########   Crontab base para usuario oracle ##########
##########                                    ##########
# FIM /usr/local/Multitask/mtcl/etc/crontabs/oracle/crontab.base
# ------------------------------------------------------------------------------
#
# 21/04/2021 16:41:36 - Incluido de /usr/local/Multitask/mtcl/etc/crontabs/oracle/ora_prod.crontab (1)
#
# INI /usr/local/Multitask/mtcl/etc/crontabs/oracle/ora_prod.crontab
##########                                                  ##########
##########   Crontab para usuario oracle do pacote ora_prod ##########
##########                                                  ##########
# FIM /usr/local/Multitask/mtcl/etc/crontabs/oracle/ora_prod.crontab
# ------------------------------------------------------------------------------

1	Definições para outros usuários seguem o mesmo princípio

Comando de desativação do pacote:

# mtcl.pl --desativa ora_prod --verbose 3 (1)
21/04/2021 16:37 : Desativa ora_prod
21/04/2021 16:37 : Definicao do ambiente do pacote ora_prod
21/04/2021 16:37 : /usr/local/Multitask/mtcl/etc/ora_prod.mtmon.sh nao existe.
21/04/2021 16:37 : Definido script /usr/local/Multitask/mtcl/etc/ora_prod.sh
21/04/2021 16:37 : Nao foram definidos 2 servidores. [/usr/local/Multitask/mtcl/etc/ora_prod.pkg]
/usr/local/Multitask/mtcl/etc/ora_prod.sh:30 Comandos para desativar a aplicacao
21/04/2021 16:37 : Desativa rotas
21/04/2021 16:37 : . Desativanto rota -net 192.168.199.0
21/04/2021 16:37 : Desativa exportfs
21/04/2021 16:37 : . Nenhum diretorio exportado
21/04/2021 16:37 : Desmonta filesystems
21/04/2021 16:37 : . Processando /home/mtmon.multitask/ramdisk
21/04/2021 16:37 : . Eliminando processos que acessam /home/mtmon.multitask/ramdisk
21/04/2021 16:37 : . Desmontando diretorio /home/mtmon.multitask/ramdisk
21/04/2021 16:37 : Desativa Volume Groups
21/04/2021 16:37 : . Nenhum Volume Group definido
21/04/2021 16:37 : Desativa enderecos de rede
21/04/2021 16:37 : . Desativando endereco 10.9.8.254 na interface ens160:mtlan
/usr/local/Multitask/mtcl/etc/ora_prod.sh:35 Comandos que devem ser executados por ultimo

1	Observe o nível se verbose apresentando menos informações

Resultado da crontab depois de desativado o pacote:

# crontab -l

# ------------------------------------------------------------------------------
#
# 21/04/2021 16:47:16 - Incluido de /usr/local/Multitask/mtcl/etc/crontabs/root/crontab.base
#
# INI /usr/local/Multitask/mtcl/etc/crontabs/root/crontab.base
# MTMON
59 * * * * /usr/local/Multitask/mtadm/bin/MonitoraAmbiente.sh #
30 6,12,18 * * * /usr/local/Multitask/mtadm/bin/mtwdog_files.pl --sincronizar #
0,15,30,45 * * * * /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
@reboot /usr/local/Multitask/mtmon/bin/mtmon_cron.pl #
*/15 * * * * /usr/local/Multitask/mtadm/bin/ColetaMemoriaReal.sh #
# FIM /usr/local/Multitask/mtcl/etc/crontabs/root/crontab.base
# ------------------------------------------------------------------------------

# crontab -l -u oracle

# ------------------------------------------------------------------------------
#
# 21/04/2021 16:47:16 - Incluido de /usr/local/Multitask/mtcl/etc/crontabs/oracle/crontab.base
#
# INI /usr/local/Multitask/mtcl/etc/crontabs/oracle/crontab.base
##########                                    ##########
##########   Crontab base para usuario oracle ##########
##########                                    ##########
# FIM /usr/local/Multitask/mtcl/etc/crontabs/oracle/crontab.base
# ------------------------------------------------------------------------------

Abaixo um exemplo do script do pacote abortando a ativação do pacote:

# touch /oracle/diretorio/emBackup.flag (1)
# mtcl.pl --ativa ora_prod --debug
21/04/2021 16:51 : Ativa ora_prod
21/04/2021 16:51 : Definicao do ambiente do pacote ora_prod
21/04/2021 16:51 : /usr/local/Multitask/mtcl/etc/ora_prod.mtmon.sh nao existe.
21/04/2021 16:51 : Definido script /usr/local/Multitask/mtcl/etc/ora_prod.sh
21/04/2021 16:51 : Nao foram definidos 2 servidores. [/usr/local/Multitask/mtcl/etc/ora_prod.pkg]
[Pacote]
Servidores=mtmon
21/04/2021 16:51 : Verifica se pacote 'ora_prod' esta liberado para ativacao
21/04/2021 16:51 : Verifica se arquivo de lock existe. [/usr/local/Multitask/mtcl/var/ora_prod.lock]
21/04/2021 16:51 : Verificacao nos servidores 'mtmon'
21/04/2021 16:51 : Verificando servidor 'mtmon'
21/04/2021 16:51 : Servidor 'mtmon' nao tem lock
21/04/2021 16:51 : . Verificando endereco 10.9.8.254
/usr/local/Multitask/mtcl/etc/ora_prod.sh:16 Abortado: Backup do ORACLE offline em andamento (2)
21/04/2021 16:51 : Erro na execucao do script /usr/local/Multitask/mtcl/etc/ora_prod.sh. rc=1

1	Criado arquivo para demonstrar funcionalidade do script em abortar a ativação
2	Consulte a linha correspondente no script do exemplo e observe que a ativação é cancelada com `exit 1`

14.5.1. Integração do MTMON com pacotes

Quando uma monitoração é dependente do pacote, podemos ajustar a configuração do MTMON dinamicamente.
Os arquivos de configuração do MTMON serão alterados quando o pacote é ativado ou desativado.

Uma forma otimizada de integrar o MTMON com o MT-Cluster é usar a opção ctrlExecucao que chamará o plugin apenas se existir o arquivo de controle.
Por exemplo, na documentação do plugin do SAP Control, o diretório /usr/sap só é montado com o pacote do sap ativo. Por isso, podemos condicionar a execução do plugin à existência do arquivo /usr/sap/.InformacoesDoFileSystem.Ctrl

O exemplo abaixo é para ajustar os arquivos mtmon_cron.conf e mtmon_cda.conf do diretório MTMONbase/etc.

O primeiro passo é copiar o arquivo de configuração com o prefixo base.:

# cd /usr/local/Multitask/mtmon/etc (1)
# cp mtmon_cron.conf base.mtmon_cron.conf
# cp mtmon_cda.conf base.mtmon_cda.conf

1	Atente que o diretório destes arquivos é no MTMONbase/etc

Atente que o diretório destes arquivos é no MTMONbase/etc

Criar os arquivos pacote1.mtmon_cron.conf e pacote1.mtmon_cda.conf com as sessões que correspondem à monitoração desejada.
Em nosso exemplo, o nome dos arquivos seriam: ora_prod.mtmon_cron.conf e ora_prod.mtmon_cda.conf

Ajustar os script do pacote para chamar a função de reconstrução dos arquivos de configuração do MTMON:

RemontaMTMON $MTCL_pacote (1)

1	Não esqueça de definir o desmonte dos arquivos de configuração com o comando `RemontaMTMON ''` na rotina `desativa inicio` do script do pacote

14.6. Dicas para Linux

Lista de VG’s que serão ativados no boot

Alterar no arquivo /etc/lvm/lvm.conf com a lista de Volume Groups desejados:

volume_list = [ "vg00"  ]

Se existir algum VG que não está associado à nenhum pacote, inclua o mesmo na lista:

volume_list = [ "vg00", "vg01" ]

No RHEL 7, a opção é auto_activation_volume_list:

auto_activation_volume_list = [ "rhel" ]

Otimizar a busca de LVM’s no ambiente

Ajuste no arquivo /etc/lvm/lvm.conf a linha abaixo:

filter = [ "a|/dev/ccis*|", "a|/dev/mapper/*|", "r|/dev/sd.*|", "r|/dev/dm-.*|", "a|/dev/mapper/mpath.*|", "r|/dev/.*|" ]

Depois, remova o arquivo de cache do vgscan:

# rm /etc/lvm/cache/.cache

Liberação de LUN’s de storage no Linux

Criar as LUN’s e ajustar o zonning para o servidor Linux ter acesso às mesmas.

Executar comando para o Linux reconhecer os devices:

# /usr/local/Multitask/mtadm/bin/rescan-scsi-bus.sh
WARN: /usr/bin/sg_inq not present -- please install sg3_utils (1)
 or rescan-scsi-bus.sh might not fully work.
Scanning SCSI subsystem for new devices
Scanning host 0 for  SCSI target IDs 0
1
2
3
4
5
6
7, all LUNs
Scanning host 1 for  SCSI target IDs 0
1
2
3
4
5
6
7, all LUNs
 Scanning for device 1 0 0 0 ...
OLD: Host: scsi1 Channel: 00 Id: 00 Lun: 00
      Vendor: NECVMWar Model: VMware IDE CDR10 Rev: 1.00
      Type:   CD-ROM                           ANSI SCSI revision: 05
Scanning host 2 for  SCSI target IDs 0
1
2
3
4
5
6
7, all LUNs
 Scanning for device 2 0 0 0 ...
OLD: Host: scsi2 Channel: 00 Id: 00 Lun: 00
      Vendor: VMware   Model: Virtual disk     Rev: 1.0
      Type:   Direct-Access                    ANSI SCSI revision: 02
0 new or changed device(s) found.
0 remapped or resized device(s) found.
0 device(s) removed.

1	`sg3_utils` - Utilities for devices that use SCSI command sets

Identificar os WWN’s dos devices (os exemplos abaixo foram criados num storage IBM DS7200):

# multipath -l | grep mpath (1)
mpath16 (360050768028080ff18000000000001a4) dm-24 IBM,2145
mpath17 (360050768028080ff18000000000001a5) dm-25 IBM,2145
mpath18 (360050768028080ff18000000000001a6) dm-26 IBM,2145
mpath19 (360050768028080ff18000000000001a7) dm-27 IBM,2145

1	`apt install multipath-tools` ou `yum install device-mapper-multipath`

Editar o arquivo /etc/multipath.conf para definir os aliases:

multipath {
            wwid           360050768028080ff18000000000001a4
            alias          vghome1
            path_selector  "round-robin 0"
            rr_weight      priorities
            no_path_retry  5
}

multipath {
            wwid           360050768028080ff18000000000001a5
            alias          vghome2
            path_selector  "round-robin 0"
            rr_weight      priorities
            no_path_retry  5
}

multipath {
            wwid           360050768028080ff18000000000001a6
            alias          vghome3
            path_selector  "round-robin 0"
            rr_weight      priorities
            no_path_retry  5
}

multipath {
            wwid           360050768028080ff18000000000001a7
            alias          vghome4
            path_selector  "round-robin 0"
            rr_weight      priorities
            no_path_retry  5
}

Resetar o multipath:

# multipath -F
# multipath -r

Conferir no diretório /dev/mpath se os caminhos foram criados:

# ls -l /dev/mpath/*
lrwxrwxrwx 1 root root 8 Jan 16 20:07 /dev/mpath/maillog1-7000 -> ../dm-22
lrwxrwxrwx 1 root root 8 Jan 16 20:07 /dev/mpath/maillog2-7000 -> ../dm-21
lrwxrwxrwx 1 root root 8 Jan 16 20:07 /dev/mpath/maillog3-7000 -> ../dm-20
lrwxrwxrwx 1 root root 8 Jan 16 20:07 /dev/mpath/maillog4-7000 -> ../dm-19
lrwxrwxrwx 1 root root 8 Jan  3 19:54 /dev/mpath/vgamv-7000 -> ../dm-10
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vgftp-7000 -> ../dm-3
lrwxrwxrwx 1 root root 8 Jan 25 11:26 /dev/mpath/vghome1 -> ../dm-24
lrwxrwxrwx 1 root root 8 Jan 25 11:26 /dev/mpath/vghome2 -> ../dm-25
lrwxrwxrwx 1 root root 8 Jan 25 11:26 /dev/mpath/vghome3 -> ../dm-26
lrwxrwxrwx 1 root root 8 Jan 25 11:26 /dev/mpath/vghome4 -> ../dm-27
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vghome-7000 -> ../dm-4
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vgmys-7000 -> ../dm-5
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vgpos-7000 -> ../dm-6
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vgrel-7000 -> ../dm-7
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vgspam-7000 -> ../dm-8
lrwxrwxrwx 1 root root 7 Jan  3 19:54 /dev/mpath/vgwww-7000 -> ../dm-9

Até aqui estão disponíveis os devices para criação do VG.

Criar o VG:

# pvcreate /dev/mpath/vghome1
# pvcreate /dev/mpath/vghome2
# pvcreate /dev/mpath/vghome3
# pvcreate /dev/mpath/vghome4
# vgcreate -v vghome /dev/mpath/vghome1 /dev/mpath/vghome2 /dev/mpath/vghome3 /dev/mpath/vghome4

Criar os LV’s:

# lvcreate vghome -i4 -L 20Gb (1)
# lvcreate vghome -i4 -l 102396 (2)

1	`-i4` define o stripping
2	`-l` e `-L` são mutuamente exclusivas

Verificar se criou corretamente o VG e os LV’s:

# vgdisplay -v vghome
    Using volume group(s) on command line
    Finding volume group "vghome"

  --- Volume group ---
  VG Name               vghome
  System ID
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               399.98 GB
  PE Size               4.00 MB
  Total PE              102396
  Alloc PE / Size       102396 / 399.98 GB
  Free  PE / Size       0 / 0
  VG UUID               J0fxim-ojWk-GOXb-xRym-iPqr-cWd3-M19Fkw

  --- Logical volume ---
  LV Name                /dev/vghome/lvol0
  VG Name                vghome
  LV UUID                JGucgD-2Xh6-bVSk-5eZV-akXQ-RgZq-DE5osz
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                20.00 GB
  Current LE             5120
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1024
  Block device           253:28

  --- Logical volume ---
  LV Name                /dev/vghome/lvol1
  VG Name                vghome
  LV UUID                E9Mmzi-zPJX-PH1r-dbMk-QY4O-ap1Y-kXgZNG
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                379.98 GB
  Current LE             97276
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1024
  Block device           253:29

  --- Physical volumes ---
  PV Name               /dev/mpath/vghome1
  PV UUID               vQHk2x-JQVD-QDcR-R2rW-Pe68-sIG9-XRQvrL
  PV Status             allocatable
  Total PE / Free PE    25599 / 0

  PV Name               /dev/mpath/vghome2
  PV UUID               MoBV2P-SNb3-jlOc-7yfQ-Rv0w-ddID-zmpeeU
  PV Status             allocatable
  Total PE / Free PE    25599 / 0

  PV Name               /dev/mpath/vghome3
  PV UUID               x0DgqG-jdNA-PEVS-3C93-iStk-THk7-q17bkS
  PV Status             allocatable
  Total PE / Free PE    25599 / 0

  PV Name               /dev/mpath/vghome4
  PV UUID               tAi0IO-7yGH-cHG8-PgvJ-8u2y-oNRJ-F5NW2k
  PV Status             allocatable
  Total PE / Free PE    25599 / 0

Finalizar a criação dos filesystems:

# mkfs.ext3  /dev/vghome/lvol0
# tune2fs -c -1  /dev/vghome/lvol0
# tune2fs -i -1  /dev/vghome/lvol0

# mkfs.ext3  /dev/vghome/lvol1
# tune2fs -c -1  /dev/vghome/lvol1
# tune2fs -i -1  /dev/vghome/lvol1

# mkdir /var/maillog
# mount /dev/vghome/lvol0  /var/maillog

O comando tune2fs acima desativa as verificações de número de montagens do filesystem e última execução do comando fsck pelo sistema operacional.
O objetivo de desativar esta verificação, se deve ao fato de que num reboot durante um horário comercial, o fsck pode demorar, prejudicando o uptime do servidor em produção.

O MTMON já identifica e configura o plugin Verifica_tune2fs.sh para validar esta situação.
É muito melhor planejar um fsck no filesystem do que num fim de mês aguardar até 4 horas para finalizar a verificação de algum diretório gigante.

Sistema Operacional trava no boot do Red Hat

Da versão RedHat 6 em diante pode haver um delay no boot, até que áreas de DEVICES externos (Storage, NFS, etc..) sejam reconhecidos.

A solução de contorno proposta pela RedHat envolve incluir um parâmetro adicional no /etc/fstab ou alterar o limite de um parâmetro de kernel, aumentando o tempo de espera.

Configuração na fstab:

/dev/vgsap/lvol1 /sap ext4 defaults,_netdev 0 0

Validar a situação após a montagem do filesystem:

# mount | grep sap
/dev/mapper/vgsap-lvol1 on /sap type ext4 (rw,relatime,stripe=128,data=ordered,_netdev)

Verificações gerais

Verificar se os filesystems estão com o tune2fs corretamente configurados:

# tune2fs /dev/vg/lvol_xxx (1)

1	Para não executar o `fsck` em reboot’s incluir as opções `-i 0 -c 0`

Verificar se o IPTABLES ou o SELINUX não estão bloqueando o ICMP (Ping) para o servidor remoto.
O ping é usado para verificar se o pacote está no ar.
Verificar se o comando lsof está instalado.

14.7. Dicas para HP-UX

Desativar VG’s controlados pelo MT-Cluster no boot

Alterar no /etc/lvmrc os parâmetros:
- auto_vg_activate=0
- incluir na função custom_vg_activation() o comando:

/usr/sbin/vgchange -a y vg04 (1)

1	ativar manualmente os `VG’s` que não pertencem a nenhum pacote. o `vg00` já é ativado automaticamente pelo hp-ux

Comentar no arquivo /etc/fstab os filesystems controlados pelo MT-Cluster.

Migrar Volume Groups de um servidor para outro

No servidor origem:

# vgexport -p -s -v -m vgxx.mapa vgxx (1)

1	observe que no comando vgexport é usada a opção -p, pois não é necessário exportar de fato o vg. este comando criará um arquivo chamado vgxx.mapa com informações que permitirão importar o vg no servidor remoto.

copiar o arquivo vgxx.mapa para o servidor destino
no servidor destino:

# mkdir /dev/vgxx
# mknod /dev/vgxx/group c 64 0x__0000
# vgimport -s -v -m vgxx.mapa vgxx

14.8. Instalação e atualização do mt-cluster

Para instalar ou atualizar o MT-Cluster é necessário executar dois programas com o usuário root:

o script inst_mtcl produzirá uma saída semelhante ao exemplo abaixo:

# sh inst_mtcl

versao instalada : 2.8

instalando inst_mtcl 2.8


x - created lock directory _sh48359.
x - extracting dicasimplantacao.txt (text)
x - extracting comandoremoto.sh (text)
x - extracting verificalock.sh (text)
x - extracting mtcl.pl (text)
x - extracting net-ping.tgz (texto)
x - extracting pacote.pkg (text)
x - extracting pacote.sh (text)
x - extracting comandosmt.pl (texto)
x - extracting mtcl.html (texto)
x - extracting mtcl.txt (texto)
x - extracting rsync.cluster.sh (text)
x - extracting mt-cluster.ppt (texto)
x - extracting contingencia.sh (text)
x - extracting funcoesmtcl.sh (text)
x - extracting mtcl_versao.pl (text)
x - extracting processacrontab.sh (text)
x - extracting remontacrontab.sh (text)
x - removed lock directory _sh48359.
comandosmt.pl : $revision: 5.51 $
/usr/local/bin/comandosmt.pl.tmp syntax ok
modulo net::ping v.2.35 ja esta instalado.


atencao: as chaves dos servidores do cluster devem ter as mesmas 'hosts keys'.
         consulte a sessao 'configuracao do ssh nos servidores' no arquivo (1)
         /usr/local/multitask/mtcl/doc/mtcl.html

incluir na crontab a linha abaixo para sincronizar
os pacotes entre os sercvidores :

15 * * * * /usr/local/multitask/mtcl/bin/mtcl.pl --sincroniza #

1	Consulte como configurar o SSH

A configuração do script de boot/shutdown no linux (red hat) pode ser feita criando o arquivo /etc/rc.d/init.d/mtcl:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#!/bin/bash
#
#       /etc/rc.d/init.d/mtcl
#
# inicializa e reseta os controles do mt-cluster
#
# chkconfig: 345 99 01
# description: finaliza os pacotes do mt-cluster
# processname: mtcl

# source function library.
source /etc/init.d/functions

# pull in sysconfig settings
[ -f /etc/sysconfig/atd ] && source /etc/sysconfig/atd

export MTCLbase='/usr/local/Multitask/mtcl'
exec >> $MTCLbase/log/mtcl.log
exec 2>&1

echo $0 $1

case "$1" in
start)
        # esta desativacao e' para acertar os arquivos de controle quando
        #   o servidor e' desligado de forma impropria, p.e., queda de luz
        $MTCLbase/bin/mtcl.pl --desativa todos
        $MTCLbase/bin/mtcl.pl --ativa todos
        touch /var/lock/subsys/mtcl
        ;;
stop)
        $MTCLbase/bin/mtcl.pl --desativa todos
        rm -f /var/lock/subsys/mtcl
        ;;
*)
        echo $"usage: $0 {start|stop}"
        exit 1
esac

exit $?

Executar os comandos abaixo para configurar o script no ambiente do linux:

# chmod 555 /etc/rc.d/init.d/mtcl
# chkconfig --add mtcl
# chkconfig --list|grep mtcl
mtcl           	0:off	1:off	2:off	3:on	4:on	5:on	6:off

15. MT-Send para envio de email

O programa mtsend.pl é usado para envio de email em processo batch.
Na forma mais simples de envio, informe apenas as opções --email e --subject.

O diretório base usado pelo programa é /usr/local/Multitask/mtsend e será referenciado nesta sessão como MTSEND.

O mtsend.pl pode ser chamado com as seguintes opções:

--email: endereço de email do destinatário. É a única opção obrigatória, pois as demais possuem default’s que são assumidos pelo programa.
Exemplo: mtsend.pl --email contato@dominio.org …

A opção especial --mtemail inclui automaticamente o dominio @multitask.com.br nos endereços de email.
Abaixo os endereços noc,contato serão expandidos para noc@multitask.com.br e contato@multitask.com.br.
Exemplo: mtsend.pl --mtemail noc,contato …

--bcc: Define que o endereço de email informado nesta opção será enviado com a opção BCC, que é uma cópia oculta da mensagem.
Alias: --cco
--cc: Define outros endereços de email que serão copiados.
Exemplo:

mtsend.pl --email contato@dominio.org --email outro@dominio.org ... (1)
mtsend.pl --email principal@dominio.org --cc outro@dominio.org,mais@dominio.org ... (2)

1	Serão criados dois email’s, personalizando a mensagem para cada destinatário informado.
2	É criado um email com o destinatário principal sendo `principal@dominio.org` e os demais endereços serão incluídos em cópia.

Observe no exemplo acima a diferença de abordagem no envio de email.

--from: Endereço do autor do email.
Alias: --de
--replyto: Endereço de email que será usado ao responder a mensagem.
Exemplo: mtsend.pl --email contato@dominio.org --replyto suporte@dominio.org …
--subject: Assunto do email.
Alias: --assunto
Default: Sem assunto
Exemplo: mtsend.pl … --assunto 'Mensagem de teste'
--body: Mensagem à ser enviada.
Alias: --mensagem
Default: Corpo da Mensagem

Se a opção for o caracter -, o programa usará as informações recebidas na entrada padrão (stdin) para montar o corpo da mensagem.
Se for o nome de um arquivo, o conteúdo do arquivo será usado como corpo da mensagem.

Exemplo: mtsend.pl … --mensagem C:\Multitask\mtsend\etc\resposta.html

--attach: Arquivo que será enviado como anexo. Observe que o arquivo será tratado como arquivo texto.
Alias: --anexo
Exemplo: mtsend.pl … --anexo /usr/tmp/relatorio.txt
--binary: Arquivo que será enviado como anexo, mas será tratado como binário. É o caso de arquivos .zip, .png e outros arquivos executáveis.
Alias: --binario
--image: É um caso especial de anexo binário, que permite incluir no corpo do email imagens para uma melhor apresentação da mensagem.
Alias: --imagem
--assinatura: Um texto que será incluído no fim do corpo da mensagem.
Se a opção for o nome de um arquivo, o mesmo será usado.
Exemplo: mtsend.pl … --assinatura "\n\nMuito obrigado\nMeu nome\n"

Os caracteres \r e \n serão tratados para incluir linhas em branco no corpo da mensagem.

--log: Registra as atividades do programa no arquivo informado.
Default: MTSEND/log/mtsend.log
--confirma: Solicita uma confirmação de leitura do email enviado.

Esta opção pode ser desativada pelo receptor da mensagem. Portanto, não há garantia de que a confirmação seja realizada.

--background: Esta opção executa um fork e executa o programa em background, permitindo liberar o script chamador para outras atividades.

Opção usada em aplicações na WEB, que podem ter problemas por timeout se o script não finalizar em determinado tempo.

--html: Quando o conteúdo da mensagem é um documento HTML, é necessário informar o leitor de email. O programa define o MimeType='text/html' para isso.
--alias: No UNIX, existe um arquivo que permite que se faça associação de login ou nomes com endereços de email, permitindo que os destinatários sejam expandidos à partir do nome cadastro no arquivo.
Default: Usa o primeiro arquivo que encontrar: /etc/mail/aliases ou /etc/aliases
--auth, --authid e --authpwd: Usado para definir credenciais no servidor de SMTP, quando o mesmo exige autenticação.
--saltsession: Usado para ofuscar a senha.
--charset: Informa que o conteúdo do email está usando o conjunto de caractes informado.
Default: ISO8859-1
--smtp e --porta: Define o endereço e porta do servidor que servirá o programa para encaminhar a mensagem de email.
Default: Só é possível definir o default da porta : 587
--timeout: Define o tempo máximo que o programa aguardará para encaminhar o email antes de finalizar a sua execução.
Default: 180 segundos
--tls: Informa que a mensagem deverá ser encaminha de forma criptografada.
O programa usa STARTTLS.
--debug: apresenta informações de debug.
--versao: apresenta a versão do mtsend.pl

15.1. Variáveis de ambiente

Algumas informações podem ser passadas ao programa por meio de variáveis de ambiente.

MTSEND_email, MTSEND_cc ou MTSEND_bcc: Inclui os endereços de email na opção correspondente, conforme explanação acima.
MTSEND_anexo: Nome do arquivo que será anexado ao email.
MTSEND_assunto: Se a opção --subject não for informada, o conteúdo da variável será usada.
LOGNAME: Quando gravar o log de execução no arquivo definido em --log será usado para definir o usuário que enviou o email.

15.2. Arquivo de configuração

Para definir de forma permanente as opções do mtsend.pl podemos configurar o arquivo MTSEND/etc/mtsend.conf.

[mtsend]
   aliasfile=/etc/mail/aliases
   assinatura=\n\nSergio Fischer\nMultitask Consultoria Ltda (1)
   auth=LOGIN (2)
   authid=mtemail@multitask.com.br
   authpwd=S3nh@_mt (3)
   background=0
   bodyfile=Corpo da Mensagem
   confirma=0
   debug=
   from=Sergio Fischer - %HOSTNAME%<fischer@multitask.com.br> (4)
   log=/usr/local/Multitask/mtmon/log/mtsend.log
   port=587
   smtp=zimbra8.cdlfln.org.br
   subject=Sem assunto

1	`\n` é substituído por linhas em branco
2	Os protocolos de autenticação SMTP, a ser usado para fazer login no servidor, podem ser: LOGIN, PLAIN, CRAM-MD5 e NTLM
3	A senha pode ser criptograda com a rotina de ofuscamento de senhas
4	`%HOSTNAME%` é substituído pelo nome do servidor que está enviando o email

Para usar o protocolo CRAM-MD5 ou NTLM, é necessário instalar outros módulos do Perl:
CRAM-MD5 - Digest::HMAC_MD5
NTLM - Authen::NTLM

15.3. Exemplo do email em HTML

O primeiro passo é criar um documento no formato HTML que será depois definido como o body do email:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<html>
<head>
<title>Exemplo de envio de email no formato HTML</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#E3E9E2" text="#A0BEB8" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" scroll="auto">
<p>A tabela abaixo tem imagens para teste:</p>
<table height="100%" border="1" align="center" cellpadding="0" cellspacing="0">
<tr>
  <td width="180"><img src="cid:imagem1.jpg" width="180" height="101"></td> (1)
  <td><img src="cid:imagem2.jpg" width="318" height="104"></td>
  <td width="180" align="center">
    <img src="cid:imagem3.jpg" width="180" height="104">
  </td>
</tr>
<tr>
  <td width="180">Coluna 1</td>
  <td width="180">Coluna 2</td>
  <td width="180">Coluna 3</td>
</tr>
<tr>
  <td colspan="3">
    <img src="cid:img_abertura4.gif" width="245" height="39" border="0">
  </td>
</tr>
</table>
</body>
</html>

1	Observe que a imagem é associada no documento HTML com a tag `<img src="cid:imagem.xxx" … >` que é incluída com a opção `--imagem` do comando `mtsend.pl`

Para enviar a mensagem, o comando poderia ser o seguinte:

mtsend.pl --mtemail noc --html \  (1) (2)
  --subject 'Teste de email' \
  --body /home/usuario/documento.html \ (3)
  --image /imagens/imagem1.jpg \
  --image imagem2.jpg \
  --image /dir/imagem3.jpg \
  --image /usr/local/dados/imagem4.gif \
  --debug (4)

1	Destinatário será expandido para `noc@multitask.com.br`
2	A opção `--html` não é obrigatoria, pois a maioria dos clientes consegue identificar o formato automaticamente
3	Se não for informado o `PATHNAME` completo, procura o documento no diretório corrente
4	A opção `--debug` apresenta as informações completas que serão encaminhadas para o servidor SMTP. Os comandos SMTP são úteis para identificar que o servidor aceitou a solicitação de envio do email

15.4. Ofuscando a senha do usuário

Para dificultar a identificação da senha do usuário usado para envio do email, siga os seguintes passos:

Consulte a documentação em ofuscamento de senhas

Crie uma entrada no arquivo MTADMbase/etc/mtadm_salt.conf:

[mtsend]
  salt=M@t9ral<VcIorV.dv

Depois, é necessário gerar a senha no formato suportado pelo programa:

/usr/local/Multitask/mtadm/bin/GeraSenha.pl --PWD mtsend -- 'S3nh@_mt'

Senha : PWD_6a41 ... 21f03b

Na sequencia, ajuste as opções saltsession e authpwd no arquivo MTSEND/etc/mtsend.conf:

[mtsend]
   auth=LOGIN
   authid=mtemail@multitask.com.br
   authpwd=PWD_6a41 ... 21f03b
   saltsession=mtsend (1)

...

1	A definição `mtsend` é arbitrária, podendo ser usada qualquer sequencia de caracteres para definir o `saltsession`. Se não for informada, o programa assume o valor `saltsession=default`

16. Configuração de email

16.1. postfix

Instale os módulos de autenticação conectáveis dentro do pacote cyrus-sasl-plain para sistemas RHEL. O pacote permite autenticação ao usar Postfix.
Crie uma chave privada RSA e um certificado de teste X.509 autoassinado.

Execute os comandos abaixo:

yum install cyrus-sasl-plain
openssl req -new -x509 -days 1 -nodes -newkey rsa:2048 -keyout private.key -out public.cert -subj "/C=BR/ST=SC/L=Joinville/CN=${HOSTNAME%.*}.soft4.com.br"
\cp -f -p public.cert /etc/ssl/certs/
\mv -f    public.cert /etc/pki/tls/certs/
\mv -f    private.key /etc/pki/tls/private/

Crie o arquivo que será usado para autenticar o usuário no SMTP.

O arquivo /etc/postfix/sasl_passwd contém o nome de usuário e senha do servidor SMTP do Google, que precisa de uma senha de aplicativo para permitir a autenticação.

Incluir no arquivo /etc/postfix/sasl_passwd:

[smtp.gmail.com]:587 beta@soft4.com.br:SENHA (1)

1	Copie a senha de um servidor configurado

Para criar uma senha de aplicativo, você precisa da verificação em duas etapas na sua Conta do Google.
Consulte a documentação do Google no link Sign in with app passwords

Crie e use senhas de aplicativos

Se você usar a verificação em duas etapas e receber um erro de "senha incorreta" ao fazer login, tente usar uma senha de aplicativo.

Vá para sua conta do Google.
Selecione Segurança.
Em "Fazer login no Google", selecione Verificação em duas etapas.
Na parte inferior da página, selecione Senhas de aplicativos.
Digite um nome que ajude você a lembrar onde usará a senha do aplicativo.
Selecione Gerar.
Para inserir a senha do aplicativo, siga as instruções na tela. A senha do aplicativo é o código de 16 caracteres gerado no seu dispositivo.
Selecione Concluído.

Incluir no arquivo /etc/postfix/tls_policy:

[smtp.gmail.com]:587 encrypt

Incluir no arquivo /etc/postfix/main.cf:

relayhost = [smtp.gmail.com]:587

smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_CAfile = /etc/ssl/certs/public.cert

# SMTPD TLS configuration for incoming connections
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/public.cert
smtpd_tls_key_file = /etc/pki/tls/private/private.key
smtpd_tls_security_level = may

# SMTP TLS configuration for outgoing connections
smtp_use_tls = yes
smtp_tls_cert_file = /etc/pki/tls/certs/public.cert
smtp_tls_key_file = /etc/pki/tls/private/private.key
smtp_tls_security_level = may

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps =  regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_check

Reescrever o endereço do envelope do email originado do próprio servidor.

Incluir no arquivo /etc/postfix/sender_canonical_maps:

/.+/    beta@soft4.com.br

Reescrever do endereço no e-mail retransmitido SMTP.

Incluir no arquivo /etc/postfix/header_check:

/From:beta@soft4.com.br(.*)?/ REPLACE From:$1<beta@soft4.com.br>

Execute os comandos abaixo:

postmap /etc/postfix/tls_policy
postmap /etc/postfix/sasl_passwd
chown 0:0  /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db /etc/postfix/tls_policy /etc/postfix/tls_policy.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db /etc/postfix/tls_policy /etc/postfix/tls_policy.db
systemctl restart postfix
date | mail -s teste rafael@soft4.com.br

Valide o envio com o comando tail /var/log/maillog:

Nov 10 09:10:51 unilnxpro01 postfix/postfix-script[107324]: stopping the Postfix mail system
Nov 10 09:10:51 unilnxpro01 postfix/master[99790]: terminating on signal 15
Nov 10 09:10:51 unilnxpro01 postfix/postfix-script[107416]: starting the Postfix mail system
Nov 10 09:10:51 unilnxpro01 postfix/master[107418]: daemon started -- version 2.10.1, configuration /etc/postfix
Nov 10 09:10:51 unilnxpro01 postfix/pickup[107419]: E31AD600E6D2: uid=0 from=<root>
Nov 10 09:10:51 unilnxpro01 postfix/cleanup[107425]: E31AD600E6D2: message-id=<20231110121051.E31AD600E6D2@mercurio.soft4.com.br>
Nov 10 09:10:51 unilnxpro01 postfix/qmgr[107420]: E31AD600E6D2: from=<beta@soft4.com.br>, size=481, nrcpt=1 (queue active)
Nov 10 09:10:54 unilnxpro01 postfix/smtp[107427]: E31AD600E6D2: to=<rafael@soft4.com.br>, relay=smtp.gmail.com[172.217.192.109]:587, delay=2.5, delays=0.02/0.02/1.8/0.74, dsn=2.0.0, status=sent (250 2.0.0 OK  1699618254 e8-20020a170902744800b001cc50f67fbasm5161070plt.281 - gsmtp)
Nov 10 09:10:54 unilnxpro01 postfix/qmgr[107420]: E31AD600E6D2: removed

Internals

17. Configuração do MTMON Server

A configuração do MTMON Server pode ser feita em qualquer distribuição Linux que suporte os softwares apresentados abaixo.

17.1. Instalação do Linux

Nesta sessão usaremos o Sistema Operacional - CentOS 7.3

Sempre manter o S.O. atualizado para minimizar problemas de segurança

Alguns pacotes estão disponíveis no repositório epel-release
Instalar o repositório com o comando:

yum install epel-release

Os pacotes usados pelo MTMON Server são:

# yum install autoconf automake basesystem bash bc bzip2 chkconfig coreutils \
      coreutils-libs cpan cpio cpp cpuspeed crda diffutils dmidecode \
      dosfstools ethtool expat file file-libs findutils gawk gcc gettext \
      gettext-devel gettext-lins gnokii gnupg2 gnuplot gnuplot-common gnutls \
      graphviz graphviz-devel graphviz-doc graphviz-gd graphviz-graphs \
      graphviz-guile graphviz-java graphviz-lua graphviz-perl graphviz-php \
      graphviz-python graphviz-ruby graphviz-tcl grep gzip hdparm htop httpd \
      hwdata iftop iotop iptables iptables-ipv6 iptstate jwhois ksh \
      libjpeg-turbo libpng libtiff lm_sensors-libs lsof m4 make net-snmp \
      net-snmp-libs net-snmp-perl net-snmp-python net-snmp-utils net-tools ntp \
      ntpdate ntsysv pcre php-cli php-common php-gd php-mbstring php-mysql \
      php-odbc php-pdo php-pear php-pecl php-soap php-xml php-xmlrpc pinfo \
      ploticus popt rcs rrdtool rkhunter rsync sed sharutils smartmontools \
      sqlite squid strace sudo sysstat tar tcpdump txt2tags unix2dos unzip \
      usbutils wget which perl-LWP-Protocol-https perl-Unicode-MapUTF8 (1)

1	Nem todos os pacotes estarão disponíveis em todas as versões do Linux. Neste momento, o importante é instalar os principais, pois os detalhes de pacotes são detalhados à frente

Os seguintes módulos do perl são importantes para a saúde do MTMON Server:

# PERL_MM_USE_DEFAULT=1 perl -MCPAN -e shell (1)
cpan> install Bundle::CPAN CGI LWP Net::Ping Rcs Mail::Sender MIME::Base64 Net::Telnet Net::Telnet::Cisco Text::ParseWords Template Crypt::PasswdMD5 Mail::IMAPClient  (2) (3)

1	A variável `PERL_MM_USE_DEFAULT=1` define que o default das opções seja aceito para os módulos à serem instalados
2	A lista de módulos pode ser obtida na sessão pré-requisitos do perl na documentação do MTMON.
3	Os módulos `Crypt::PasswdMD5` e `Mail::IMAPClient` são usados para autenticação de login

17.2. Filesystems

A maioria dos arquivos usados pelo MTMON Server estão no diretório /usr/local/Multitask.
Para melhor administração do servidor, crie a estrutura abaixo:

# df
Sist. Arq.              1K-blocos     Usado Disponível Uso% Montado em
/dev/mapper/vg01-lvol0   26201600   1123921   25077679   5% /usr/local/Multitask (1)
/dev/mapper/vg01-lvol1   31441920   7808949   23632971  25% /usr/local/Multitask/mtmon
/dev/mapper/vg01-lvol3  439915520 285319053  154596467  65% /usr/local/Multitask/mtmon/var/upload
/dev/mapper/vg01-lvol4   16766976  10754681    6012295  65% /usr/local/Multitask/mtmon/eventos

1	O MTMON tem a caracteristica de usar muitos arquivos pequenos. Em função disso, sugerimos criar os filesystems com XFS

A opção noatime no arquivo /etc/fstab melhora o desempenho do filesystem:

/dev/vg01/lvol0	/usr/local/Multitask                  xfs defaults,noatime 0 0
/dev/vg01/lvol1	/usr/local/Multitask/mtmon            xfs defaults,noatime 0 0
/dev/vg01/lvol3	/usr/local/Multitask/mtmon/var/upload xfs defaults,noatime 0 0
/dev/vg01/lvol4	/usr/local/Multitask/mtmon/eventos    xfs defaults,noatime 0 0

17.3. ploticus

Para a geração de alguns gráficos, o ploticus é usado.
Para uniformizar o comportamento do software, o script abaixo pode ser usado:

#!/bin/bash (1)

export PLOTICUS_PREFABS=/usr/local/lib/ploticus/prefabs (2)

parametros='-linewidth 0.1'
while [ $# -gt 0 ]
do
  echo "$1" | grep -q ' '
  if [ $? = 0 ]
  then
    parametros="$parametros '$1'"
  else
    parametros="$parametros $1"
  fi
  shift
done
/usr/local/bin/pl $parametros (3)

exit 0

1	O nome do script deve ser `/usr/local/bin/ploticus.sh` pois é chamado internamente pelos script’s do MTMON Server
2	Valide se o caminho usado na distribuição está correto Um Link Simbólico para o executável pode ser necessário: `ln -s /usr/bin/ploticus /usr/local/bin/pl`
3	O comando pl é o executável do ploticus

Você pode copiar o prefabs de um servidor antigo usando o comando:

scp -pr MTMON_ANTIGO:/usr/local/lib/ploticus /usr/local/lib/

Valide se o caminho do executável para o ploticus está correto:

$Comando{'pl'}=q(/usr/local/bin/ploticus.sh); (1)


C_pl="/usr/local/bin/ploticus.sh" (2)
export C_pl

1	`/usr/local/bin/ComandosMT.pl`
2	`/usr/local/bin/ComandosMT.sh`

17.4. sudo

Incluir no visudo as linhas abaixo:

Defaults !requiretty
apache ALL = (ALL) NOPASSWD: /usr/local/Multitask/mtged/cgi-bin/Login.cgi
apache ALL = (ALL) NOPASSWD: /usr/local/Multitask/mtmon/bin/RemoveServidor.sh
apache ALL = (ALL) NOPASSWD: /usr/local/Multitask/mtmon/bin/rem.sh
apache ALL = (ALL) NOPASSWD: /usr/local/Multitask/mtmon/cgi-bin/Login.cgi

17.5. Chaves de acesso

Num cluster de MTMON Server, copiar as chaves de acesso para equivalencia de SSH.
A partir do servidor do MTMON já instalado, executar os comandos:

scp -p /etc/ssh/ssh_host_* root@NOVO_IP:/etc/ssh/
rsync -avu /root/.ssh/ root@NOVO_IP:/root/.ssh/

17.6. postfix

Execute os comandos abaixo:

yum install cyrus-sasl-plain
openssl req -new -x509 -days 1 -nodes -newkey rsa:2048 -keyout private.key -out public.cert -subj "/C=BR/ST=SC/L=Joinville/CN=${HOSTNAME%.*}.multitask.com.br"
\cp -f -p public.cert /etc/ssl/certs/
\mv -f    public.cert /etc/pki/tls/certs/
\mv -f    private.key /etc/pki/tls/private/

Crie o arquivo que será usado para autenticar o usuário no SMTP.

O arquivo /etc/postfix/sasl_passwd contém o nome de usuário e senha do servidor SMTP externo.

Incluir no arquivo /etc/postfix/sasl_passwd:

[smtp.office365.com]:587 mtlua@multitask.com.br:SENHA

Na sequencia, execute o comando para criar o banco de dados HASH usado pelo postfix.

Incluir no arquivo /etc/postfix/tls_policy:

[smtp.office365.com]:587 encrypt

Para usar o Google como relay, substitua as entradas acima a string [smtp.office365.com] por [smtp.gmail.com] e o endereço de autenticação mtlua@multitask.com.br por um user@google.com.

Incluir no arquivo /etc/postfix/main.cf:

relayhost = [smtp.office365.com]:587

smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_CAfile = /etc/ssl/certs/public.cert

# SMTPD TLS configuration for incoming connections
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/public.cert
smtpd_tls_key_file = /etc/pki/tls/private/private.key
smtpd_tls_security_level = may

# SMTP TLS configuration for outgoing connections
smtp_use_tls = yes
smtp_tls_cert_file = /etc/pki/tls/certs/public.cert
smtp_tls_key_file = /etc/pki/tls/private/private.key
smtp_tls_security_level = may

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps =  regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_check

Para criar uma senha de aplicativo, você precisa da verificação em duas etapas na sua Conta do Google.
Consulte a documentação do Google no link Sign in with app passwords

Crie e use senhas de aplicativos

Se você usar a verificação em duas etapas e receber um erro de "senha incorreta" ao fazer login, tente usar uma senha de aplicativo.

Vá para sua conta do Google.
Selecione Segurança.
Em "Fazer login no Google", selecione Verificação em duas etapas.
Na parte inferior da página, selecione Senhas de aplicativos.
Digite um nome que ajude você a lembrar onde usará a senha do aplicativo.
Selecione Gerar.
Para inserir a senha do aplicativo, siga as instruções na tela. A senha do aplicativo é o código de 16 caracteres gerado no seu dispositivo.
Selecione Concluído.

Reescrever o endereço do envelope do email originado do próprio servidor.

Incluir no arquivo /etc/postfix/sender_canonical_maps:

/.+/    mtlua@multitask.com.br

Reescrever do endereço no e-mail retransmitido SMTP.

Incluir no arquivo /etc/postfix/header_check:

/From:mtlua@multitask.com.br(.*)?/ REPLACE From:$1<mtlua@multitask.com.br>

Execute os comandos abaixo:

postmap /etc/postfix/tls_policy
postmap /etc/postfix/sasl_passwd
chown 0:0  /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db /etc/postfix/tls_policy /etc/postfix/tls_policy.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db /etc/postfix/tls_policy /etc/postfix/tls_policy.db
systemctl restart postfix
date | mail -s teste usuario@multitask.com.br

Valide o envio com o comando tail /var/log/maillog:

Nov 10 09:10:51 server postfix/postfix-script[107324]: stopping the Postfix mail system
Nov 10 09:10:51 server postfix/master[99790]: terminating on signal 15
Nov 10 09:10:51 server postfix/postfix-script[107416]: starting the Postfix mail system
Nov 10 09:10:51 server postfix/master[107418]: daemon started -- version 2.10.1, configuration /etc/postfix
Nov 10 09:10:51 server postfix/pickup[107419]: E31AD600E6D2: uid=0 from=<root>
Nov 10 09:10:51 server postfix/cleanup[107425]: E31AD600E6D2: message-id=<20231110121051.E31AD600E6D2@multitask.com.br>
Nov 10 09:10:51 server postfix/qmgr[107420]: E31AD600E6D2: from=<mtlua@multitask.com.br>, size=481, nrcpt=1 (queue active)
Nov 10 09:10:54 server postfix/smtp[107427]: E31AD600E6D2: to=<usuario@multitask.com.br>, relay=smtp.gmail.com[172.217.192.109]:587, delay=2.5, delays=0.02/0.02/1.8/0.74, dsn=2.0.0, status=sent (250 2.0.0 OK  1699618254 e8-20020a170902744800b001cc50f67fbasm5161070plt.281 - gsmtp)
Nov 10 09:10:54 server postfix/qmgr[107420]: E31AD600E6D2: removed

17.7. Apache

Verificar se o arquivo /etc/httpd/conf/httpd.conf tem as entradas abaixo:

<IfModule mod_deflate.c>
  SetOutputFilter DEFLATE
</IfModule>

#AddDefaultCharset UTF-8 (1)
AddDefaultCharset ISO-8859-1

ScriptAlias /mtmon-cgi/ "/usr/local/Multitask/mtmon/cgi-bin/"
Alias /mtmon-php/ "/usr/local/Multitask/mtmon/php/"
Alias /mtmon "/usr/local/Multitask/mtmon/htdocs"
Alias /mtmon_web "/usr/local/Multitask/mtmon/php/mtmon_web"

1	Revisar o arquivo para incluir as linhas nas posições mais significativas do arquivo `$APACHEconf/httpd.conf`

Se o serviço principal do servidor Apache é o MTMON Server, criar um link de index.html com o comando:

ln -s /usr/local/Multitask/mtmon/htdocs/index.html /var/www/html/

Definir que o número máximo de arquivos abertos por usuário (http):

[Service] (1)
    LimitNOFILE=65535

1	Incluir no arquivo `/etc/systemd/system/httpd.service.d/limits.conf` as linhas acima Se o arquivo não existir, criar o diretório e o arquivo

Depois reiniciar os serviços:

systemctl daemon-reload
systemctl restart httpd

Poderá validar os parametros com o comando:

su - apache -c 'ulimit -aHS' -s '/bin/bash'
grep 'Max open files ' /proc/*/limits

ps -fu apache
grep 'Max open files ' /proc/*/limits|grep 15903

Ativar o httpd no boot:

systemctl start httpd
systemctl enable httpd
systemctl status httpd

17.8. ntpd

A hora é um atributo muito importante na monitoração.
Por isso a configuração do ntpd é muito importante.

Atualizar a hora do servidor:

ntpdate ntp.org

Alterar a configuração para que o ntpd seja carregado no reboot (ntsysv):

systemctl start ntpd
systemctl enable ntpd
systemctl status ntpd

17.9. selinux

O SELINUX poderá ser desativado.

systemctl disable firewalld (1)

1	Se preferir, poderá configurar o SELINUX para oferecer maior proteção ao servidor

Alterar variável em /etc/selinux/config com o valor disable:

SELINUX=disable

17.10. Sincronização final

Uma vez que o servidor está configurado, sincronizar os arquivos à partir de um servidor já configurado para a migração dos dados:

cd /usr/local/Multitask (1)
rsync -av --delete mt* NOVO_IP:/usr/local/Multitask/

1	Executar estes comandos no servidor antigo

Executar o rsync do diretório de HTTP para o servidor novo:

cd /var/www/novo_mtmon (1)
rsync -auv --delete . NOVO_IP:/var/www/novo_mtmon/

1	Validar se outros diretórios devem ser copiados

18. Arquivos do MTMON

18.1. status_de_ativos.txt

No arquivo MTMONbase/var/local/status/status_de_ativos.txt podemos encontrar o status de todos os ativos monitorados no servidor.

No servidor MTMON, o mesmo arquivo está disponível em MTMONbase/var/status/ORIGEM/SERVIDOR/status_de_ativos.txt.

Uma versão consolidada com todos os servidores da origem, está disponível em MTMONbase/var/status/ORIGEM/status_de_ativos.txt.

O arquivo está no formato CSV, separado por “;” e é formato pelas seguintes informações:

#Hora;Origem;Servidor;Base;Aplicacao;Objeto;Severidade;Parado;Tipo;Notifica;Classe (1) (2)

1	O formato com campo Hora é YYYYmmddHHMMSS.
2	O campo Base é usado quando um ativo monitorado não é local ao servidor que faz os testes, útil para rastrear de qual servidor o plugin é executado.

As demais informações correspondem aos argumentos do evento associados ao ativo monitorado.

18.2. mtmon.ATIVO.Ctrl

No diretório MTMONbase/var/local/ctrl encontramos os arquivos de controle usados pelo agente do MTMON para controlar os status dos ativos monitorados.

mtmon.origem.servidor.aplicacao.objeto.Ctrl

contém dois campos no formato epoch:

Data inicial do status atual do ativo,
Data do último envio de evento para o servidor MTMON.

Se o status do ativo é OK, o arquivo conterá o valor 0,0.

Exemplo de conteúdo do arquivo em caso de status com severidade maior do que zero:

 1598102788,1607015191 (1)

1	O as datas estão no formado epoch.

mtmon.origem.servidor.aplicacao.objeto.err

contém dois campos:

Contador de quantas vezes o plugin chamou a rotina para envio do evento.
É a severidade da última chamada à rotina de controle.

Este arquivo só existe quando o status do ativo é nOK

Exemplo de conteúdo do arquivo:

 59,2 (1)

1	A rotina de controle foi acionada 59 vezes desde que o status mudou para severidade 2.

mtmon.origem.servidor.aplicacao.objeto.delay: quando é informada a opção delay na chamada do evento, este arquivo é criado.
Nas próximas chamadas à rotina de controle, a data de criação deste arquivo é usada para definir se o tempo definido na opção delay já foi alcançado.
Se já passou o tempo de delay, o evento é encaminhado para o servidor MTMON e o arquivo de controle será ignorado nas demais chamadas.

O conteúdo do arquivo não é usado para controle e possuirá a seguinte mensagem:
Nao gerou evento por enquanto. Periodo de delay=nn

onde: nn é o tempo informado na opção delay

Glossário

aplicacao

Identificador que associa o item monitorado à uma aplicação. Escolha nomes que ajudem na definição do item monitorado: tsm, filesystem, oracle ou data store de um storage.

ativo

Identifica um item monitorado, composto de uma combinação de origem/servidor/aplicação/objeto.
Define se uma sessão está ativa ou não em arquivo .conf.

MTADMbase e MTMONbase

A maioria dos arquivos dos sistemas desenvolvidos pela Multitask estão abaixo de /usr/local/Multitask. Os diretórios de cada software seguem este padrão.

No windows, o PATH correspondente é C:\Multitask.

Usando o mtadm como exemplo, o diretório no windows é C:\Multitask\mtadm\ e nos UNIX /usr/local/Multitask/mtadm.

origem: É um identificador do cliente (empresa) monitorado.
objeto: pode ser um item especifico de algum item monitorado.
Por exemplo, a porta de um switch ou o volume/disco monitorado de um servidor M:.
rm3.sh: É um script para remover arquivos nos servidores do cluster de MTMON.
Para executar, o diretório corrente deve ser obrigatóriamente um sub-diretório de MTADMbase ou MTMONbase.

Por exemplo, no diretório MTMONbase/var/upload, você pode executar:

rm3.sh -d teste (1)

1	Removerá o arquivo ou diretório MTMONbase/var/upload/teste nos 2 servidores do MTMON. A opção -d gera informações adicionais.

servermtmon (mtadm.conf)

É o endereço do servidor do MTMON. Podem ser definidos vários endereços de conexão para o servidor MTMON. Quando o servidor não consegue conexão com um endereço, ele automaticamente tenta o próximo endereço definido nesta variável.

Para configurar os endereços dos servidores do MTMON server, configure o parâmetro no arquivo mtadm.conf:

servermtmon=170.84.17.136, 189.45.197.30

servidor

Identifica o item monitorado.

Servidor MTMON

é um servidor linux que está configurado com Apache e recebe os eventos gerados na monitoração.

severidade

Estabelece o nível de criticidade associado ao evento,

Severidades possíveis associadas à um evento:

Normal '0': verde: alerta é informativo ou representa uma situação de normalidade
Atenção '1': amarelo: o ativo monitorado não está parado, mas houve um desvio da normalidade
Crítico '2': vermelho ou preto: ativo monitorado está na eminência de parar e exige uma ação imediata.
Com a flag parado, o ativo monitorado está parado e os serviços associados ao mesmo não respondem mais às solicitações

transkey: É uma sequência de caracteres usada como chave para autenticar a origem de toda comunicação entre o cliente e os servidores do MTMON.
O objetivo não é criptografar a comunicação, mas garantir a identificação do emitente da mensagem.
Veja uma explanação detalhada na sessão Entendendo o TransKEY.

Criptografia é fornecida pelo HTTPS.

Mensagem neste contexto pode ser um evento, upload de arquivos ou solicitação de envio de WhatsApp ou Telegram.

Documentação antiga

19. Evento

O evento é o resultado do um teste de monitoração que está associado a um ativo ou algum acontecimento que se deseja monitorar (trap SNMP). Este evento é gerado no servidor da Multitask, que atualmente está configurado em cluster com 2 nós: mttmb (Unifique em Timbó) e mtfln (Infotécnica em Florianópolis).

Os eventos podem ser associados à 3 severidades: normal, atenção ou crítico, sendo que no último caso, o evento pode sinalizar que o ativo está parado, definindo um prioridade emergencial.

Como sugestão, convencionamos que os status normal e crítico são elegíveis para serem tratados no NOC da multitask. Os eventos atenção são tratados pelos analistas e constituem evidencia de tarefas pró-ativas, evitando que o item monitorado fique parado.

A definição da severidade ocorre no momento da geração do evento.

Fluxo para criação de evento

A imagem à seguir, apresenta de forma mais detalhada a função EnviaEventoParaServidor(), com foco nas opções que podem alterar o processo de criação do evento:

Critérios para criação de evento

20. Ciclo de vida de um evento

20.1. Descrição de um evento

Quando um recurso é monitorado pelo MTMON, existe um plugin que avalia a necessidade de gerar um alerta. O alerta gera um evento, que é encaminhado para o servidor do MTMON, usando o protocolo http (porta 80).

O programa que recebe a solicitação e cria o evento no MTMON chama-se mtmon_novo_evento.cgi, e grava um arquivo no diretório MTMONbase/eventos/AAAAMM/DD, onde:

AAAAMM: data em que o evento ocorreu na origem, não da criação do mesmo no servidor MTMON.
DD: dia do evento.

O nome do arquivo criado, é uma composição com informações do evento descrito em Estrutura do arquivo de um evento.

Se o evento é gerado sem o opção de finalizar=1, um link simbólico é gerado no diretório de eventos, com o sufixo .new.

Execute o comando abaixo no diretorio MTMONbase/eventos:

 # ls -l |grep 1505245513.2.cliente.jve_internet_level3.level3.mtmon.133879
 lrwxrwxrwx  1 apache apache  68 Set 12 16:46 1505245513.2.cliente.jve_internet_level3.level3.mtmon.new -> 201709/12/1505245513.2.cliente.jve_internet_level3.level3.mtmon.133879

Quando alguém clica na opção Ciente na console, o sistema renomeia o arquivo do sufixo .new para .ack e gera uma transação para ser replicada nos demais servidores que compõe o cluster do MTMON. Além disso, é realizado o registro no próprio arquivo, incluindo uma sessão chamada Ciente. Se além do ciente é registrada uma nota, outra sessão, chamada Nota é incluida:

[Ciente]
  User=operador
  Time=1505245668

[Nota]
  User=operador
  Time=1505246076
  Arquivo=201709/12/nota/mttmb.nota.0166.txt

Quando o evento é finalizado, outro registro é incluido e o arquivo .ack é removido, finalizando o ciclo do evento.

20.2. Estrutura do arquivo de um evento

O nome do arquivo criado, é uma composição das seguintes informações:

epoch.severidade.origem.servidor.aplicacao.objeto.numero

epoch: é a data do evento convertido para o formato epoch (número de segundos desde 01/jan/1970).
severidade: pode assumir os valores 0, 1 ou 2, de acordo com a severidade do evento.
origem.servidor.aplicacao.objeto: compõe a assinatura do evento, que representa o ativo monitorado.
número: número serial do evento gerado pelo agente.

Exemplo do conteúdo de um arquivo de evento:

[Inicio]
  Time=1505245513
  Origem=cliente
  Server=jve_internet_level3
  Application=level3
  Object=mtmon
  Severity=2
  Hostname=mttmb
  Dump=201709/12/dump/mttmb.cliente.jve_internet_level3.0005.html
  Message=[3] O PING do servidor mttmb para jve_internet_level3 [200.186.230.126] perdeu 100% dos pacotes [alarmando desde 12/09/2017 16:46:25]
  HoraMTMON=1505245591
  Classe=outros
  Notifica=level3/E2RcnuUfsIgPk
  Versao=5.3.21
  ClientID=133879
  ServerID=25585

No exemplo acima, um dump é definido, e o arquivo pode ser acessado usando o caminho relativo ao diretório /usr/local/Multitask/evento. As seguinte informações compõe um evento:

Time: Hora do evento em formato epoch. Se um servidor está num timezone diferente do servidor MTMON ou representa um evento que ocorreu no passado, a hora registrada é convertida no momento de gerar o arquivo do evento. A informação entre agente e servidor MTMON referente à datas é sempre realizada no formado dd/mm/aaaa HH:MM:SS. Assim, quando o evento é consultado, a data e hora refletem o timezone da região de onde o evento foi gerado.
Origem: Origem (empresa) do recurso monitorado
Server: Servidor que representa o evento gerado.
Application: Aplicação
Object: Objeto
Severity: Severidade
Hostname: Quando o servidor que gerou o evento é diferente do servidor do evento, é feito o registro.
Dump: Arquivo que contém informações complementares do evento
Message: Mensagem do evento
HoraMTMON: Quando existe uma diferença de mais de 20 segundos em a hora do evento e a hora do registro do evento, é incluida esta informação, pois o SLA da operação do MTMON é baseada no tempo em que o evento está à disposição dos mesmos para tomar uma ação.
Classe: Classe do evento
Notifica: Procedimento associado ao evento.
Versao: Versão do agente no servidor monitorado
ClientID: número sequencial que é mantido no servidor monitorado.
ServerID: número sequencial que é mantido no servidor do MTMON.

21. Upload de arquivos de configuração

Depois de validar a comunicação com o servidor do MTMON, execute o comando mtmon_doc.pl para sincronizar os arquivos de configuração.

Assim é possível fazer as customizações no ambiente gráfico.

/usr/local/Multitask/mtmon/plugin/mtmon_doc.pl

  C:\Multitask\mtmon\plugin\mtmon_doc.pl

Consulte na janela de administração o Relatório de configuração de agentes, que auxiliará na identificação de plugins úteis para a monitoração do ambiente.

21.1. Inicialização no Linux (Red Hat / Fedora)

Criar o script /etc/rc.d/init.d/mtmon:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#!/bin/bash
#
#       /etc/rc.d/init.d/mtmon
#
# Inicializa e reseta os controles de verificacao de syslog (/usr/local/Multitask/mtmon/log/mtmon.log)
#
# chkconfig: 345 95 98
# description: Ajusta os controles de posicao para verificacao das mensagens na syslog \
#    Incluir no arquivo /etc/syslog.conf a linha: \
#         kern.err················································/usr/local/Multitask/mtmon/log/mtmon.log
# processname: mtmon

# Source function library.
. /etc/init.d/functions

# pull in sysconfig settings
[ -f /etc/sysconfig/atd ] && . /etc/sysconfig/atd

test -x /usr/local/Multitask/mtmon/plugin/mtmon_checklog.pl || exit 0

touch /usr/local/Multitask/mtmon/log/mtmon.log

case "$1" in
start)
        /usr/local/Multitask/mtmon/bin/mtmon_checklog.pl --preview --reset \
                --arquivo /usr/local/Multitask/mtmon/log/mtmon.log
        ;;
stop)
        # Resgata a ultimas mensagens de erro da SYSLOG
        /usr/local/Multitask/mtmon/bin/mtmon_checklog.pl --arquivo /usr/local/Multitask/mtmon/log/mtmon.log
        ;;
*)
        echo $"Usage: $0 {start|stop}"
        exit 1
esac

exit $?

Incluir no processo de boot com o comando:

chmod 555 /etc/rc.d/init.d/mtmon
chkconfig --add mtmon

21.1.1. Inicialização em outras distribuições de UNIX/Linux

Incluir na rotina de boot o comando abaixo:

/usr/local/Multitask/mtmon/bin/mtmon_checklog.pl --preview --reset \
                 --arquivo /usr/local/Multitask/mtmon/log/mtmon.log

Na rotina de shutdown, incluir o comando abaixo:

# Resgata a ultimas mensagens de erro da SYSLOG
/usr/local/Multitask/mtmon/bin/mtmon_checklog.pl --arquivo /usr/local/Multitask/mtmon/log/mtmon.log

21.2. Monitoração de links e serviços

O plugin mtmon_servico_remoto.pl verifica se o link e serviços estão respondendo.

[mon_servico_remoto]
  aplicacao=mon_servico_remoto
  comando=mtmon_servico_remoto.pl
  intervalo=* */5

21.3. Monitoração do tempo de boot

O plugin MonitoraBootTime.pl monitora o tempo de boot de 2 formas:

Tempo de boot menor do que um período em minutos
Tempo de boot maior do que um período em dias

O exemplo abaixo irá gerar evento que houver um reboot, pois o tempo será menor do que 90 minutos. Em função do critério de que novo evento será gerado apenas depois de 3 horas, apenas 1 evento será gerado.

Também será gerado evento se o tempo de boot for maior do que 120 dias. Assim podemos controlar eventuais reboot’s não planejados e mapear os servidores que estão à muito tempo sem executar o reboot.

A severidade padrão é amarela. Com o parâmetro --severidade é possivel ajustar para permitir o acionamento pelo NOC,

[mon_BootTime]
  aplicacao=mon_boottime
  comando=MonitoraBootTime.pl --dias 120 --minutos 90 --severidade 2
  finaliza=1
  intervalo=* */10
  nagios=1

21.4. Monitoração de data de alteração de arquivos

O plugin mtmon_cda.pl controla a data de alteração de arquivos configurados.

É útil para identificar se replicações de archive do Oracle estão ocorrendo dentro do prazo definido.

[mon_cda]
  aplicacao=mon_cda
  comando=mtmon_cda.pl
  intervalo=* */20

21.5. Monitoração de processos e daemons

O plugin mtmon_daemon.pl valida a execução de processos.

No UNIX é usado o comando ps -ef para listar os processos ativos e no Windows o comando é tasklist.

A monitoração consiste em contabilizar o número de processos que atendem aos critérios definidos no arquivo de configuração.

Os itens para monitoração são definidos no arquivo MTMONbase/etc/mtmon_daemon.conf:

[smbd]
  ppid=1
  padrao=smbd
  total=1 >=
  Severidade=2
  notifica=samba

[smbd_pid]
  ppid=1
  padrao=smbd
  total=5 <=
  Severidade=2
  notifica=samba_pid1

[cron]
  ppid=1
  padrao=cron
  total=1 >=
  Severidade=2
  notifica=unix

[lpsched]
  padrao=lpsched
  ppid=1
  severidade=2
  total=1 >=
  Notifica=lpsched

O padrão de busca será usado pelo plugin para identificar os processos monitorados.

A opção PPID=1 é usado para identificar daemons, uma vez que os processos filhos do daemon possuem PPID=pid do daamon.

As sessões cron e lpsched esperam encontrar mais de 1 processo com o comando correspondente.

A chamada do plugin pode ser feita no arquivo MTMONbase/etc/mtmon_cron.conf:

[mon_daemon]
   Aplicacao=mon_daemon
   Comando=mtmon_daemon.pl
   Intervalo=* */5

21.6. Monitoração do Join - Samba com Windows AD

Para validar se a conexão do SAMBA com o Windows AD está OK, incluir a sessão abaixo no arquivo de configuração MTMONbase/etc/mtmon_cron.conf:

[mon_join]
  aplicacao=mon_join
  comando=MonitoraJoin.sh
  intervalo=* */10

21.7. Monitoração tamanho de arquivos

Para monitorar o tamanho de arquivos use o plugin mtmon_filesize.pl. Incluir a sessão abaixo no arquivo de configuração MTMONbase/etc/mtmon_cron.conf:

[mon_filesize]
  aplicacao=mon_filesize
  comando=mtmon_filesize.pl
  intervalo=* */30

O plugin usa o arquivo mtmon_filesize.conf para definir quais arquivos serão controlados:

[PRDalert_log]
  arquivo=/oracle/PRD/admin/bdump/alert.log
  tamanho=100Mb
  NotFoundOK=1
  objeto=PRDalert_log
  severidade=1

A opção tamanho tem a seguinte sintaxe:

nnn [kmgtb] flag

onde:

nnn: define o tamanho do arquivo
[kmgtb]: opcional, informa a unidade de medida do tamanho do arquivo, que pode ser em Kb, Mb, Gb, Tb ou bytes.
flag: Pode ser: <, >, =, >= ou <=
Por exemplo, se o tamanho informado for 100Mb, o alerta será gerado se o arquivo for maior que 100Mb.
Default: >

21.8. Monitoração páginas da WEB

Para monitorar páginas da WEB use o plugin MonitoraPaginaWEB.pl. Incluir a sessão abaixo no arquivo de configuração MTMONbase/etc/mtmon_cron.conf:

[mon_web]
  aplicacao=web
  comando=MonitoraPaginaWEB.pl --severidade=1 'http://www.multitasknet.com.br/index.html' 'Multitask'
  intervalo=* */5

O plugin espera 2 argumentos:

URL completa para acessar a página desejada
string retornada pela página que identifica que o link está OK.

A severidade padrão é 1.

Você pode incluir na URL a tag {epoch}, que será substituído pelo epoch (data no formato em segundos desde 1970, interno do perl), do servidor que está executando o plugin. Com isso, podemos evitar que um proxy devolva informação não atualizada. Para monitorar um servidor WWW desta maneira crie um script e coloque na área de CGI.

Exemplo:

#!/bin/bash

echo 'Content-Type: text/html; charset=ISO-8859-1'
echo
echo $QUERY_STRING
exit 0

No caso do Apache, salve o script acima com o nome /var/www/cgi-bin/mtmon.cgi, e teste com o comando abaixo:

/usr/local/Multitask/mtmon/plugin/MonitoraPaginaWEB.pl 'http://192.168.210.245:8080/cgi-bin/mtmon.cgi?{epoch}' '{epoch}' ;echo $?

Saida do comando acima:

chgMTMON_JSON_target=http://192.168.210.245:8080/cgi-bin/mtmon.cgi?1499957600
chgMTMON_JSON_trigger={"severidade":"2","padrao":"1499957600"}
Conexao : OK|

/usr/local/Multitask/mtmon/plugin/MonitoraPaginaWEB.pl 'http://192.168.210.245:8080/cgi-bin/mtmon.cgi?{epoch}' '{epoch}'
200 OK
1499957600


Gerado por /usr/local/Multitask/mtmon/plugin/MonitoraPaginaWEB.pl em lhsl2017 as 13/07/2017 11:53:20
chgMTMON_JSON_classe=web
0

A sessão no mtmon_cron.conf pode ser configurada assim:

  [mon_web]
    aplicacao=web
    comando=MonitoraPaginaWEB.pl 'http://URL.com.br/script.php?{Epoch}' '{Epoch}'
    intervalo=* */5

Quando a página monitorada é controlada por um servidor Windows e necessita de autenticação, pode ser necessário instalar o módulo Authen::NTLM.

Pode ser instalado via perl -MCPAN -e shell ou nos servidores linux CentOS com o comando abaixo:

  yum install perl-NTLM.noarch

21.9. Monitoração do event log do Windows (backup Veeam)

A primeira etapa para monitorar o event log, é necessário extrair a informação da base do Windows.

Por exemplo, para recuperar as informações do Veeam Backup, use o comando abaixo:

     C:\Multitask\mtmon\plugin\eventLog.pl "Veeam Backup"

Será criado um arquivo chamado C:\Multitask\mtmon\tmp\event.log, que possuirá o seguinte conteúdo:

---------------------------------------------------------------------------
LogFile:       veeam backup
Computer:      veeam01.dns.local
Source:        Veeam MP
RecordNumber:  43512
Category:      0
Event ID:      110
EventType:     4
Time: Thu Jan  1 10:05:12 1970
User:
Strings: 0f62831c-aa92-466a-a9de-2dfe1f456096 eaddf1ac-297b-49ae-ab3f-ecdef3454997 0 0 0              1 Backup job 'Job 1' has been started.
---------------------------------------------------------------------------
LogFile:       veeam backup
Computer:      veeam01.dns.local
Source:        Veeam Backup
RecordNumber:  43513
Category:      0
Event ID:      1
EventType:     4
Time: Thu Jan  1 10:05:13 1970
User:
Strings: VM (file01) VM backup job "Job 1" is started
ID: 3536135f-7c18-439d-b06e-220772561343
---------------------------------------------------------------------------

Este log será usado identificar problemas no backup.

Se quiser incluir outros logs do Windows na verificação, poderá chamar usando a sintaxe abaixo:

     C:\Multitask\mtmon\plugin\eventLog.pl "Veeam Backup" system application

Observe que o log Veeam Backup, tem espaços no nome do log, por isso, deve ser informado entre aspas duplas (").

O log de alertas do Windows pode conter muita informação e para cada mensagem que atender ao padrão definido, será gerado um evento no MTMON.

Para evitar a geração indesejada de eventos, podem ser tomadas uma de duas ações:

Zerar o event log no windows. Por exemplo: Veeam Backup, system ou application
Executar o comando abaixo para ignorar as mensagens anteriores:

   C:\Multitask\mtmon\plugin\mtmon_eventlog.pl --arquivo C:\Multitask\mtmon\tmp\event.log --preview

A opção --preview não gera nenhum evento. Se desejar verificar quais eventos serão gerados, use a opção --debug.

O plugin obedece às instruções definidas no arquivo mtmon_eventlog.conf. Por default, serão verificadas as mensagens dos logs system e application do event log. Outros logs podem ser incluídas para verificação alterando a opção script:

[Global]
   ignoracase=1
   aplicacao=eventlog
   PadraoInicioBloco=^LogFile:\s
   severidade=0
   script=C:/Multitask/mtmon/plugin/eventLog.pl "Veeam Backup" system application

Os ajustes para o tratamento das mensagens, é feito nas demais sessões do arquivo mtmon_eventlog.conf.

Criar uma entrada no MTMONbase/etc/mtmon_cron.conf usando a definição abaixo:

[mon_eventlog]
   aplicacao=mon_eventlog
   comando=mtmon_eventlog.pl --arquivo C:/Multitask/mtmon/tmp/event.log
   intervalo=* */5

21.10. Monitoração de serviços

O plugin winServices.pl verifica se os serviços estão ativos.

Configure o arquivo mtmon_winservices.conf com os serviços desejados. O comando C:\Multitask\mtmon\plugin\winServices.pl --lista gera um template completo dos serviços disponíveis:

C:\strawberry\perl\bin\perl.exe C:\Multitask\mtmon\plugin\winServices.pl --sessoes --autocheck > C:\Multitask\mtmon\etc\mtmon_winservices.conf

notepad C:\Multitask\mtmon\etc\mtmon_winservices.conf

Ajuste o arquivo criado ativando as sessões que representam os serviços que deseja monitorar.

O template cria as sessões com Ativo=0. Altere a opção para ativar a monitoração.

Para iniciar a monitoração de serviços, inclua no arquivo de configuração MTMONbase/etc/mtmon_cron.conf a sessão abaixo:

[mon_winservice]
   aplicacao=mon_winservice
   ativo=1
   comando=winServices.pl
   intervalo=* */5

21.11. Configuração de plugin em VBS para Windows

A configuração de plugin em VBS (Visual Basic Script) pode ser feita no arquivo de configuração MTMONbase/etc/mtmon_cron.conf usando a definição abaixo:

[mon_vbs]
   aplicacao=mon_vbs
   ativo=0
   comando=C:\WINDOWS\system32\cscript.exe //Nologo C:\Multitask\mtmon\plugin\teste.vbs
   intervalo=* */5

O script deve ser chamado com o executável C:\WINDOWS\system32\cscript.exe.

O plugin teste.vbs pode ser construido como um plugin do Nagios, retornando a mensagem na primeira linha e o return code com os valores 0, 1 ou 2, ou chamando o comando mtmon_evento.pl.

Exemplo:

Set objShell = CreateObject("Wscript.Shell")
Set objExec = objShell.Exec("C:\strawberry\perl\bin\perl.exe C:\Multitask\mtmon\bin\mtmon_evento.pl --aplicacao=teste --debug --mensagem=""Teste de conexao"" --eventual --severidade=0")

Observações:

A mensagem deve estar entre 2 aspas ("") para que os espaços sejam considerados.
O comando mtmon_evento.pl pode ser chamado com todas as opções desejadas.

21.12. Eliminar processos parados

Eventualmente alguns processos do agente podem ficar travados. Para eliminar de forma segura estes processos, use o comando:

  C:\Multitask\mtmon\bin\winEliminaProcessosParados.pl

Se o objetivo é apenas identificar os processos do agente do MTMON, use a opção --lista, que apresentará os processos desejados.

Nenhum processo é eliminado com a opção --lista.

C:\Multitask> C:\Multitask\mtmon\bin\winEliminaProcessosParados.pl --lista
6304     25/05/2011 16:55:20    cmd /c ""C:\Multitask\mtmon\bin\ChamaMTMON.cmd" "
4260     25/05/2011 16:55:20    C:\strawberry\perl\bin\perl.exe C:\Multitask\mtmon\bin\mtmon_cron.pl
4700     25/05/2011 16:57:00    cmd.exe /x/d/c "C:/Multitask/mtmon/plugin/mtmon_sinaliza_live.pl --tempo=1 2>&1"
6192     25/05/2011 16:57:00    "C:\strawberry\perl\bin\perl.exe"  "C:\Multitask\mtmon\plugin\mtmon_sinaliza_live.pl"  --tempo=1

C:\Multitask>

A opção --debug apresentará a lista completa e os processos com mais de 28 minutos serão eliminados.

Você poderá automatizar esta verificação com o comando abaixo:

   schtasks /create /F /sc MINUTE /mo 15 /tn VerificaMTMON /tr "C:\strawberry\perl\bin\perl.exe C:\Multitask\mtmon\bin\winEliminaProcessosParados.pl --pskill" /st 00:00 /du 0024:00 /RU {USUARIO} /RP {SENHA}

21.13. Verificação de áreas de DATA STORE de vSphere

O plugin para monitorar os DATA STORE de vSphere, é o mtmon_disco.pl. Ele usa um arquivo .df gerado pelo script C:\Multitask\mtmon\plugin\vSphere_DF.pl.

É necessário instalar o vSphere PowerCLI para disponibilizar os executáveis usados pelo plugin.

Execute o comando abaixo para validar a criação do arquivo de controle usado:

   C:/Multitask/mtmon/plugin/vSphere_DF.pl --servidor=srv_vcenter --vihost=srv_vsphere --datacenter=NOME_AMBIENTE

onde:

servidor=srv_vcenter - é o servidor vCenter monitorado
vihosts=srv_vsphere - servidor onde o vCenter está instalado
datacenter=NOME_AMBIENTE - nome do vCenter
{USUARIO}/{SENHA} - usuário do Schedule Task que executará o comando. Este usuário deve ter a permissão de acesso ao vCenter.

Depois da execução, verifique se foi criado o arquivo C:\Multitask\mtmon\tmp\NOME_AMBIENTE.df.

A configuração no TASKK SCHEDULER do windows pode ser feita com o comando abaixo:

   schtasks /create /F /sc MINUTE /mo 15 /tn gera_vSphere_df /tr "C:\strawberry\perl\bin\perl.exe C:\Multitask\mtmon\plugin\vSphere_DF.pl --servidor=srv_vcenter --vihost=srv_vsphere --datacenter=NOME_AMBIENTE" /st 00:00 /du 0024:00 /ed 12/31/2050 /RU {USUARIO} /RP {SENHA}

É importante monitorar a criação do arquivo de controle. Para isso, usamos o plugin mtmon_cda.pl que pode ser configurado no arquivo mtmon_cda.conf com a sessao abaixo:

[NOME_AMBIENTE.df]
  Ativo=1
  NotFoundOK=0
  Arquivo=C:/Multitask/mtmon/tmp/NOME_AMBIENTE.df
  Objeto=NOME_AMBIENTE_df
  Severidade=2
  Tempo=50 minutos

Lembre de habilitar o plugin mtmon_cda no mtmon_cron.conf.

Finalmente, crie uma entrada no mtmmon_cron.conf para usar o arquivo que foi criado acima:

[mon_vsphere]
   aplicacao=mon_vsphere
   ativo=1
   comando=mtmon_disco.pl --config mtmon_vsphere.conf --dffile C:/Multitask/mtmon/tmp/NOME_AMBIENTE.df
   intervalo=* */15

22. Alternativas de Monitoração do Windows

O Windows também pode ser monitorado usando os plugins do Nagios - NRPE.

A monitoração sempre é iniciada por um servidor UNIX (HP-UX, AIX, Linux, …) e é necessário instalar os plugins do NRPE.

O NRPE pode ser obtido no site do [Nagios http://www.nagios.org/download/]. Não confundir o NRPE com os plugins no Nagios. Os dois softwares estão disponíveis no endereço do Nagios.

Nos servidores Linux, instale o pacote do nagios-plugins-nrpe, que automaticamente instalará as dependências necessárias.

Estão disponíveis 2 versões de agente para ser instalado no Windows:

NRPE
NSClient++

22.1. NRPE

Fazer o download do nrpe.zip
Descompactar o nrpe.zip no C:\. O diretório deverá ter a aparência abaixo:

 C:\nrpe>dir
  Volume in drive C has no label.
  Volume Serial Number is 0CEF-3F4F

  Directory of C:\nrpe

 04/26/2007  15:06    <DIR>          .
 04/26/2007  15:06    <DIR>          ..
 01/26/2004  11:28            61,440 cpuload_nrpe_nt.exe
 01/22/2004  20:13            57,344 diskspace_nrpe_nt.exe
 01/26/2004  10:09            57,344 eventlog_nrpe_nt.exe
 07/07/2005  20:25         1,060,864 libeay32.dll
 01/26/2004  09:14            49,152 memload_nrpe_nt.exe
 04/26/2007  15:38             3,727 nrpe.cfg
 02/16/2006  21:20            40,960 NRPE_NT.exe
 04/24/2007  15:17             1,472 nrpe_nt.log
 06/19/2003  20:05           491,792 NTDLL.DLL
 01/22/2004  22:18            49,152 service_nrpe_nt.exe
 07/07/2005  20:25           200,704 ssleay32.dll
 05/23/2003  00:24                38 test.cmd
               12 File(s)      2,073,989 bytes
                2 Dir(s)  21,219,872,768 bytes free
 C:\nrpe>

Alterar no arquivo C:\nrpe\nrpe.cfg os parâmetros:

 allowed_hosts=L.L.L.L
 dont_blame_nrpe=1

L.L.L.L é o endereço do servidor UNIX que executará o comando check_nrpe.

O parâmetro dont_blame_nrpe permitirá que sejam definidos os limites da monitoração no comando check_nrpe executado no computador que monitora o windows.

Os serviços disponíveis por default são:

  command[nt_check_disk]=C:\nrpe\diskspace_nrpe_nt.exe $ARG1$ $ARG2$ $ARG3$
  command[nt_cpuload]=C:\nrpe\cpuload_nrpe_nt.exe 50 80
  command[nt_memload]=C:\nrpe\memload_nrpe_nt.exe 70 90
  command[srv_DP]=C:\nrpe\service_nrpe_nt.exe "Data Protector Inet"
  command[srv_DP_CRS]=C:\nrpe\service_nrpe_nt.exe "Data Protector CRS"
  command[srv_DP_RDS]=C:\nrpe\service_nrpe_nt.exe "Data Protector RDS"
  command[srv_IIS]=C:\nrpe\service_nrpe_nt.exe "IIS Admin Service"
  command[srv_DNS]=C:\nrpe\service_nrpe_nt.exe "DNS Server"
  command[srv_DHCP]=C:\nrpe\service_nrpe_nt.exe "DHCP Server"
  command[Exchange_IMAP4]=C:\nrpe\service_nrpe_nt.exe "Microsoft Exchange IMAP4"
  command[Exchange_IS]=C:\nrpe\service_nrpe_nt.exe "Microsoft Exchange Information Store"
  command[Exchange_MGR]=C:\nrpe\service_nrpe_nt.exe "Microsoft Exchange Management"
  command[Exchange_MTA]=C:\nrpe\service_nrpe_nt.exe "Microsoft Exchange MTA Stacks"
  command[Exchange_Routing]=C:\nrpe\service_nrpe_nt.exe "Microsoft Exchange Routing Engine"
  command[Exchange_SA]=C:\nrpe\service_nrpe_nt.exe "Microsoft Exchange System Attendant"
  command[Exchange_IIS]=C:\nrpe\service_nrpe_nt.exe "World Wide Web Publishing Service"
  command[Exchange_SMTP]=C:\nrpe\service_nrpe_nt.exe "Simple Mail Transfer Protocol (SMTP)"

O nome do serviço, ex. nt_check_disk, não pode ser maior do que 32 caracteres.

diskspace_nrpe_nt.exe - O plugin tem 3 argumentos: disco monitorado, limite para alerta e limite para evento crítico.
service_nrpe_nt.exe - No exemplo acima, Microsoft Exchange IMAP4 é o nome do serviço monitorado no Windows.

Depois de instalado o serviço, sempre que for alterada alguma configuração dos serviços no arquivo nrpe.cfg, é necessário reiniciar o serviço no Windows.

Cadastrar o serviço NRPE no Windows.

O comando abaixo deve ser iniciado dentro do diretório C:\NRPE

  C:\nrpe> nrpe_nt -i

Entrar na tela de serviços do Windows e iniciar o serviço Nagios Remote Plugin Executor for NT/W2K.
No servidor UNIX, testar o plugin do Windows (W.W.W.W é o endereço do servidor Windows) com o comando abaixo:

  /usr/lib/nagios/plugins/check_nrpe -H W.W.W.W -c nt_check_disk_c

Se ocorrer um dos seguintes erros: CHECK_NRPE: Socket timeout after 10 seconds ou Connection refused by host, avalie as alternativas abaixo:

verificar se o serviço está iniciado no Windows. Consulte o log de eventos para mensagens de erros.
verificar se o iptables do Linux está liberando a porta 5666 para conexão no servidor Windows
verificar se o parâmetro allowed_hosts no arquivo C:\NRPE\nrpe.cfg está configurado corretamente com o endereço do servidor UNIX. Se alterar este arquivo, é necessário reiniciar o serviço Nagios Remote Plugin Executor for NT/W2K.
verificar se a porta 5666 do firewall do Windows está liberada. Para liberar a porta no Windows, siga os passos abaixo:
Iniciar o programa Firewall do Windows no painel de controle.
Selecionar a aba: Exceções
Adicionar porta (Nome da porta: mtmon, Número da porta: 5666)
verificar se existem mensagens de erro no arquivo C:\NRPE\nrpe.log
Incluir no arquivo MTMONbase/etc/mtmon_cron.conf uma entrada para cada serviço monitorado no servidor Windows.

  [SRVW01_dskC]
    Nagios=1
    Intervalo=* */15
    Comando=/usr/lib/nagios/plugins/check_nrpe -H W.W.W.W -c nt_check_disk -a 'C:!70!90'
    Servidor=windows
    Aplicacao=disco
    Objeto=C

  [SRVW01_dskD]
    Nagios=1
    Intervalo=* */15
    Comando=/usr/lib/nagios/plugins/check_nrpe -H W.W.W.W -c nt_check_disk -a 'D:!70!80'
    Servidor=windows
    Aplicacao=disco
    Objeto=D

  [SRVW01_cpuload]
    Nagios=1
    Intervalo=* */5
    Comando=/usr/lib/nagios/plugins/check_nrpe -H W.W.W.W -c nt_cpuload
    Servidor=windows
    Aplicacao=load

  [SRVW01_memload]
    Nagios=1
    Intervalo=* */5
    Comando=/usr/lib/nagios/plugins/check_nrpe -H W.W.W.W -c nt_memload
    Servidor=windows
    Aplicacao=memoria

No exemplo acima, será gerado evento de alerta quando a área usada do disco C: for maior ou igual à 70% e evento crítico quando a área superar 89%.

22.2. NSClient++

O serviço a ser instalado no servidor Windows pode ser obtido no link abaixo:

https://nsclient.org

23. Monitoração BGP - MikroTik

Para acessar o roteador, é necessário informar o usuário e senha. Para proteger a senha, recomendamos que crie uma entrada no arquivo que é usado na proteção da senha. O arquivo é MTADMbase/etc/mtadm_salt.conf. Abaixo o diretório será referenciado por MTMONbase/….

[mikrotik]
  salt=XMU%Ss.,BaLaW-

A seqüência definida pelo salt é usada como chave para ofuscar a senha. O objetivo é apenas não deixar a senha totalmente aberta no arquivo de configuração.

No exemplo apresentado abaixo, vamos configurar um roteador cujo nome é roteador_bgp.

Crie um arquivo com o nome MTMONbase/etc/mikrotik_roteador_bgp.conf com o conteúdo:

[default]
   severidade=1
   timeout=10

[eBGP-CTINET-v4]
   debug=0
   host=45.224.80.1
   porta=4792
   user=fbmon
   pwd=PWD_7908671d1b0b6277046559073a3a0e07193424531a2e
   servidor=roteador-BGP
   salt=mikrotik

Onde:

debug: incrementa as informações que o roteador devolve na comunicação com o plugin
host: IP ou nome do roteador que será monitorado
porta: Porta de conexão
user: Nome do usuário de conexão
pwd: Senha correspondente. Na configuração inicial, pode ser informada a senha aberta. Na primeira execução, a senha será ofuscada com o salt definido anteriormente
servidor: É o nome que será usado para gerar o evento na console do MTMON. As letras maiúsculas serão convertidas para minusculas, e qualquer outro caracter que não seja alfanumérico, será convertido para '_'
salt: usado para ofuscar a senha informada
severidade: define com que severidade o evento será gerado na console do MTMON. Para testes, recomendamos severidade=1, pois a operação não faz acionamentos para eventos de alerta
timeout: tempo em segundos que o plugin aguarda para completar a conexão com o roteador.

Uma vez que o arquivo de configuração foi definido, podemos chamar o plugin na linha de comando para validar os parâmetros:

$MTMON/plugin/mtmon_bgp_mikrotik.pl --config mikrotik_roteador_bgp.conf --debug --reset

Informando o caminho relativo com a opção --config, o plugin assume que o arquivo de configuração está no diretório MTMONbase/etc.

A opção --reset é usada para definir inicialmente os valores de prefix-count e disabled que estão configurados no roteador. Pode ser executado mais de 1x, pois o reset não destroi as informações adicionais que existem no arquivo de configuração.

Ao executar o --reset, é criado um outro arquivo com as definições encontradas no roteador. Estas informações serão ajustadas pelo analista para atender as expectativas da monitoração. O arquivo gerado será MTMONbase/etc/mtmon_bgp_mikrotik_roteador_bgp.conf e terá a seguinte estrutura:

[default]
   tolerancia=15%

[peer1]
   nome=Peer1
   prefix-count=710137

[ip_peer2]
   nome=IP-peer2
   prefix-count=695283

[outro_peer]
   nome=Outro-PEER
   prefix-count=401

[peer_ignorado]
   ignora=1
   nome=PEER-Ignorado

[peer_ipv6]
   ignora=1
   nome=PEER.IPV6

O plugin usará as informações acima para definir o que monitorar. Se o roteador está configurado com o peer disabled=true ou address-families!=ip, será definido para o plugin ignorar este peer.

Na monitoração, se o campo state não contém o valor established, é gerado um evento com a severidade definida no arquivo MTMONbase/etc/mikrotik_roteador_bgp.conf.

Se o prefix-count for menor que o percentual definido na tolerancia, será gerado um evento com a severidade definida.

Se o prefix-count for maior que o percentual definido na tolerancia, será gerado um evento com a severidade 1 (alerta / amarelo), pois é apenas um aviso da mudança de situação do roteador. Para assumir que os valores correntes configurados no roteador são os desejados, execute o plugin com a opção --reset e os valores serão substituidos no arquivo de configuração.

Quando as configurações foram validadas, inclua no arquivo MTMONbase/etc/mtmon_cron.conf a seguinte entrada:

[mon_roteador_bgp]
   aplicacao=mon_roteador_bgp
   comando=mtmon_bgp_mikrotik.pl
   intervalo=* */3
   notifica=acionar
   delay=7 minutos

24. Monitoração HP ILO

Criar um usuário read-only para acessar a console da ILO.

Na tela de administração, selecionar:

Administration -> User Administration

LOCAL Users -> NEW

   User Name:	 	mtmon
   Login Name:	 	mtmon
   Password:	 	SENHA
   Password Confirm:	SENHA

             Add User

Selecionar Administration → Security:

Selecione o usuário mtmon e clique em Authorize New Key:

Colar a chave no campo Public Key Import Data

Paste the PEM encoded public key in the area below, and click 'Import Public Key'


ssh-rsa AAAAB3NzaC1yc2EAAAAD ... AABAQ0VEVTpn8zliwlN Chave Publica MTMON

Na sequência, conecte na CLI do HP ILO:

root@mtmon:/root# ssh mtmon@HP-ILO
The authenticity of host 'HP-ILO (10.10.10.10)' can't be established.
RSA key fingerprint is SHA256:jWN7hdYH4IHSL06DYHjz/VTGdOVm53TW5SgiE53cGEg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'HP-ILO' (RSA) to the list of known hosts.
mtmon@HP-ILO's password:
User:mtmon logged-in to iLO-StoreOnce5100.(HP-ILO / DE87::9698:82FA:F36E:9564)

iLO Advanced 2.54 at  Jun 11 2019
Server Name: HP5UN2345D01
Server Power: On

</>hpiLO->

Incluir em MTMONbase/etc/devices.conf as informações para o plugin monitorar o HP ILO:

[10.0.10.10]
   nome=ilo-storeonce5100
   conexao=mtmon@10.10.10.10
   tipo=ilo4

No arquivo MTMONbase/etc/mtmon_cron.conf incluir a entrada abaixo:

[mon_HP_ILO]
   aplicacao=mon_hp_ilo
   ativo=1
   comando=monitora_HP_ILO.pl
   intervalo=* 5,35

25. Integração do Data Protector

O Data Protector pode ser configurado para gerar eventos no MTMON quando ocorrer incidentes de backup.

Para configurar basta incluir no arquivo de configuração do Data Protector as sessões que definem as ações para os incidentes.

Consulte a sessão correspondente para configurar o Data Protector:

Arquivo de configuração para Windows
Arquivo de configuração para HP-UX

25.1. Monitoração de Data Protector (Windows)

Para monitorar os eventos gerados pelo Data Protector usando a ferramenta de notificação dele, editar o arquivo $DATAPROTECTOR/config/server/Notifications, adicionando as linhas abaixo de acordo com a necessidade:

NOTIFICATION "MT_MON_MountRequest"
{
	-event "MountRequest"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 2 MountRequest"
	-parameter LEVEL "Warning"
	-parameter DEVICE "*"
}

NOTIFICATION "MT_MON_BackupError"
{
	-event "BackupError"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 2 BackupError"
	-parameter LEVEL "Major"
	-parameter SINGLEMSGLEVEL "Major"
	-parameter SESSIONTYPE "Backup"
}

NOTIFICATION "MT_MON_IDBCorrupted"
{
	-event "DbCorrupted"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 2 IDBCorrupted"
	-parameter LEVEL "Critical"
}

NOTIFICATION "MT_MON_IDBSpaceLow"
{
	-event "DbSpaceLow"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 1 IDBSpaceLow"
	-parameter LEVEL "Major"
	-parameter VSLIMIT "250"
	-parameter VDSLIMIT "50"
	-parameter DCBFSLIMIT "250"
}

NOTIFICATION "MT_MON_IDBTableSpaceLow"
{
	-event "DbTablespaceLow"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 1 IDBTableSpaceLow"
	-parameter LEVEL "Major"
	-parameter TBLSPACETHRESHOLD "85"
}

NOTIFICATION "MT_MON_NotEnoughFreeMedia"
{
	-event "NotEnoughFreeMedia"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 1 NotEnoughFreeMedia"
	-parameter LEVEL "Warning"
	-parameter POOL "*"
	-parameter NUMFREEMEDIA "1"
}

NOTIFICATION "MT_MON_UnexpectedEvents"
{
	-event "UnexpectedEvents"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 1 UnexpectedEvents"
	-parameter LEVEL "Warning"
	-parameter NUMEVENT "*"
}

NOTIFICATION "MT_MON_EndOfSession"
{
	-event "EndOfSession"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 1 EndOfSession"
	-parameter LEVEL "Warning"
	-parameter DATALIST "*"
	-parameter SESSSTAT "CompletedErrors"
	-parameter SESSIONTYPE "Backup"
}

NOTIFICATION "MT_MON_DeviceError"
{
	-event "DeviceError"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 2 DeviceError"
	-parameter LEVEL "Critical"
	-parameter DEVICE "*"
}

NOTIFICATION "MT_MON_MailSlotFull"
{
	-event "MailSlotsFull"
	-external "C:\Multitask\mtmon\bin\DataProtector.bat 1 MailSlotFull"
	-parameter LEVEL "Warning"
	-parameter DEVICE "*"
}

NOTIFICATION "MT_MON_Controle"
{
         -event "EndOfSession"
         -external "C:\Multitask\mtmon\bin\DataProtector.bat 0 Controle"
         -parameter LEVEL "Normal"
         -parameter DATALIST "*"
         -parameter SESSSTAT "*"
         -parameter SESSIONTYPE "Backup"
}

25.2. Monitoração de Data Protector (HP-UX)

NOTIFICATION "MT_MON_MountRequest"
{
	-event "MountRequest"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 2 MountRequest"
	-parameter LEVEL "Warning"
	-parameter DEVICE "*"
}

NOTIFICATION "MT_MON_BackupError"
{
	-event "BackupError"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 2 BackupError"
	-parameter LEVEL "Major"
	-parameter SINGLEMSGLEVEL "Major"
	-parameter SESSIONTYPE "Backup"
}

NOTIFICATION "MT_MON_IDBCorrupted"
{
	-event "DbCorrupted"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 2 IDBCorrupted"
	-parameter LEVEL "Critical"
}

NOTIFICATION "MT_MON_IDBSpaceLow"
{
	-event "DbSpaceLow"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 1 IDBSpaceLow"
	-parameter LEVEL "Major"
	-parameter VSLIMIT "250"
	-parameter VDSLIMIT "50"
	-parameter DCBFSLIMIT "250"
}

NOTIFICATION "MT_MON_IDBTableSpaceLow"
{
	-event "DbTablespaceLow"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 1 IDBTableSpaceLow"
	-parameter LEVEL "Major"
	-parameter TBLSPACETHRESHOLD "85"
}

NOTIFICATION "MT_MON_NotEnoughFreeMedia"
{
	-event "NotEnoughFreeMedia"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 1 NotEnoughFreeMedia"
	-parameter LEVEL "Warning"
	-parameter POOL "*"
	-parameter NUMFREEMEDIA "1"
}

NOTIFICATION "MT_MON_UnexpectedEvents"
{
	-event "UnexpectedEvents"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 1 UnexpectedEvents"
	-parameter LEVEL "Warning"
	-parameter NUMEVENT "*"
}

NOTIFICATION "MT_MON_EndOfSession"
{
	-event "EndOfSession"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 1 EndOfSession"
	-parameter LEVEL "Warning"
	-parameter DATALIST "*"
	-parameter SESSSTAT "CompletedErrors"
	-parameter SESSIONTYPE "Backup"
}

NOTIFICATION "MT_MON_DeviceError"
{
	-event "DeviceError"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 2 DeviceError"
	-parameter LEVEL "Critical"
	-parameter DEVICE "*"
}

NOTIFICATION "MT_MON_MailSlotFull"
{
	-event "MailSlotsFull"
	-external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 1 MailSlotFull"
	-parameter LEVEL "Warning"
	-parameter DEVICE "*"
}

NOTIFICATION "MT_MON_Controle"
{
         -event "EndOfSession"
         -external "/usr/local/Multitask/mtmon/bin/DataProtector.sh 0 Controle"
         -parameter LEVEL "Normal"
         -parameter DATALIST "*"
         -parameter SESSSTAT "*"
         -parameter SESSIONTYPE "Backup"
}

26. Monitoração de instâncias do sap usando sapcontrol

Execute o script MTMONbase/bin/ConfiguraColeta_sapcontrol.sh para definir as configurações iniciais para monitoração do SAP.

As informações da instância são geradas pelo script mtmon_sapcontrol.sh, que deve ser executado pelo usuário de administração da instância do SAP.

Incluir na crontab do usuario XXXadm a linha abaixo:

* * * * * /usr/local/Multitask/mtmon/bin/mtmon_sapcontrol.sh #

Verifique se no HOME do usuário foi criado o arquivo sapcontrol.txt e sapcontrol.log, que serão usados como base pelo plugin Monitora_sapcontrol.sh.

Se o arquivo foi criado com sucesso, incluir no MTMONbase/etc/mtmon_cron.conf a sessao abaixo:

[sapcontrol]
   Aplicacao=sapcontrol
   Ativo=1
   Comando=Monitora_sapcontrol.sh
   ctrlExecucao=/usr/sap/.InformacoesDoFileSystem.Ctrl
   Delay=2 minutos
   Intervalo=* *
   Nagios=1
   Notifica=sap

27. Dicas e truques

Configurações específicas usadas em alguns clientes.

Monitoração de servidores windows.

27.1. checkNagios.sh

O arquivo MTMONbase/plugin/checkNagios.sh é um script que filtra erros de conexão com servidor Windows.

No arquivo MTMONbase/etc/mtmon_cron.conf, incluir antes do plugin do Nagios, script:

  [pluginNagios]
    Aplicacao=filesystem
    Comando=checkNagios.sh check_nt -H 172.16.1.10 -v USEDDISKSPACE -l C -w 90 -c 95
    Intervalo=* */15
    Nagios=1
    Notifica=windows
    Objeto=c
    Email=user@dominio.com

A opção Nagios=1 deve ser definida para que a mensagem seja coerente com o resultado da monitoração.

27.2. Recuperação do SPOOLER do HP-UX

# /usr/sam/lbin/lpmgr -R -xsavedir=/usr/local/Multitask/mtmon/var/local/lp/

Verifique se a data dos arquivos é compatível com a configuração desejada.

Além desta versão, são preservadas as últimas 6 cópias no diretório MTADMbase/var/local, que podem ser recuperadas da seguinte maneira:

# cd /usr/local/Multitask/mtmon/var/local
# ls -l spool.cpio.*
-rwxrwxrwx   1 root       sys          12617 Sep  6 23:51 spool.cpio.3.gz
-rwxrwxrwx   1 root       sys          12624 Sep  7 23:51 spool.cpio.4.gz
-rwxrwxrwx   1 root       sys          12619 Sep  8 23:51 spool.cpio.5.gz
# rm -rf lp.old
# mv lp lp.old
# gunzip -c spool.cpio.4.gz | cpio -icxvdum
# /usr/sam/lbin/lpmgr -R -xsavedir=/usr/local/Multitask/mtmon/var/local/lp/

Se os arquivos no diretório acima forem removidos, uma cópia da última configuração está disponível no site do MTMON, seguindo a seqüência:

  Origem -> Servidor -> Relatórios -> Upload -> spool.cpio.gz
***

Neste mesmo diretório existem vários arquivos relevantes para recuperação do ambiente dos Sistemas Operacionais.

27.3. Configuração do Mapa de Links

O mapa de links é o recurso usado para monitorar servidores ou serviços.

Antes de liberar qualquer plugin para este tipo de monitoração, é necessário que os módulos Bundle::CPAN, LWP e Net::Ping estejam atualizados. O Net::Ping com versão anterior à 2.35 tem um bug e não funciona com o MTMON. Consulte a sessão de pré-requisitos para obter informações sobre configuração.

A configuração inicial é realizada no arquivo MTMONbase/etc/mtmon_servico_remoto.conf:

  [172.16.2.74]
    ativo=1
    endereco=172.16.2.74
    servidor=nome
    mapa=1
    endereco=Rua da fabrica, 34 - Joinville - SC
    link_pri=ARI 8181818
    link_sec=ARI 1818181
    show=endereco, link_pri, link_sec, telefone, responsavel
    telefone=0800-123 456 - selecionar suporte à link
    responsavel=José da Silva

É necessário criar uma sessão para cada endereço IP que será monitorado. Pode ser também configurado o parâmetro servico, que define os serviços que serão verificados no IP.

A opção mapa=1, informa que o IP deve aparecer no mapa de links.

Na seqüencia, incluir no arquivo MTMONbase/etc/mtmon_cron.conf a sessão:

  [mon_servico_remoto]
    Ativo=1
    base=servidor
    Intervalo=* */5
    Comando=mtmon_servico_remoto.pl
    Aplicacao=mon_servico_remoto
    email=endereco@dominio.com.br

Assim que o mtmon_servico_remoto.pl é executado na primeira vez, já é possível abrir uma janela na administração do MTMON e consultar o Mapa de Links.

O arquivo de configuração mapa_links.conf permite que sejam incluidas informações relacionadas ao link monitorado.

A opção que define quais campos serão apresentados no Mapa de Links é show.

As opções endereco, link_pri e link_sec já são pré-definidas.

endereco é o endereço de correspondencia onde o IP está fisicamente instalado.
link_pri e link_sec definem informações usadas para abrir chamado no fornecedor do link, que pode ser o número do contrato ou do link contratado.

Se não desejar usar estas opções é só remover a referencia na opção show.

Podem ser criadas outras opções usando o conceito variavel=valor, e incluir a variavel na opção show. No exemplo acima, telefone e responsavel foram criadas e serão apresentadas no janela do mapa de link quando o mouse é posicionado sobre o icone que representa o link monitorado.

Observe que o formato é livre e pode ser usado de forma que facilite a apresentação da informação.

27.4. Alterando atributos do evento

Existem situações onde é necessário redefinir alguns atributos do evento que está sendo gerado. Por exemplo, podemos estabelecer que depois das 18:00 até às 07:30 da manhã seguinte, as notificações sejam alteradas incluindo um sufixo 24x7.

O roteiro abaixo pode ser usado para este propósito.

  ScriptClient=/Users/user/projetos/mtmon/src/teste_client.sh
  ScriptClientCheck=1

Quando a opção pScriptClientCheck está definida, o script teste_client.sh será chamado 2x na criação de um novo evento. Na primeira execução é facultada a oportunidade de alterar os atributos do evento.

Por exemplo, se o script finalizar com código de retorno diferente de 0 (ex. exit 1), o evento não será enviado para o servidor do MTMON. O código de retorno será repassado para o programa que está gerando o evento, fornecendo assim informações para novos acionamentos.

Outra caracteristica que pode ser configurada no script, é alterar as variáveis internas usadas pelo programa mtmon_evento.pl. Para isso, o script deverá gerar linhas com a seguinte sintaxe:

  MTMON_Variavel=novoValor

onde Variavel pode ser qualquer opção disponível na geração de eventos.

Ex.: Severidade, Notifica, Aplicacao, Objeto

O script abaixo:

Se o nome computador monitorado for teste, o evento não será encaminhado para o servidor do MTMON.
Alterará o atributo Notifica=unix,oracle para Notifica=unix,oracle24x7 depois das 18:00 até 08:00.
Durante o horário comercial, a severidade será forçada para 1 (warning).

  #!/bin/sh
  if [ -z "$MTMON_EventoCadastrado" ]
  then
    [ "$MTMON_Servidor" = "teste" ] && exit 1
    if [ $(date +%H) -gt 18 ]
    then
       echo MTMON_Notifica=$(echo $MTMON_Notifica | sed -e s/oracle/oracle24x7/)
    elif [ $(date +%H) -lt 08 ]
    then
       echo MTMON_Notifica=$(echo $MTMON_Notifica | sed -e s/oracle/oracle24x7/)
    else
       echo MTMON_Severidade=1
    fi
  fi
  exit 0

Consulte a sessão de configuração do arquivo manutencao.conf para outras abordagens no tratamento de eventos.

27.5. Incluindo arquivo locais na documentação

O programa mtmon_doc.pl gera um arquivo HTML com a saída de vários comandos e arquivos de configuração dos pricipais software instalados no ambiente.

Eventualmente, pode ser importante incluir outros arquivos que sejam específicos do Sistema Operacional.

Para isso podemos incluir a lista destes arquivo em MTMONbase/etc/mtmon_doc.lista.

Ex.:

  /opt/omni/newconfig/etc/opt/omni/server/Notifications

Os arquivos devem ser definidos com o PATHNAME absoluto, um arquivo em cada linha.

No MTMON, podemos consultar estes arquivos, em Informações do Sistema Operacional, na sessão LOCAL.

28. Estrutura interna do MTMON (SERVER)

O MTMON concentra todos os seus arquivos debaixo do diretório MTMONbase, que será referenciado como MTMON.

Aqui é apresentada a estrutura interna do MTMON, útil para localizar as informações para extrair relatórios.

Arquivos e diretórios principais do MTMON Server:

28.1. Log de ciente e acionamentos

Os arquivos ciente.{SERVER}.{AAAAMM}.log e acionamentos.{SERVER}.{AAAAMM}.log, são listas contendos informações das ações dos operadores do NOC, com o objetivo de agilizar a apresentação de relatórios e Dashboards em relatórios na WEB.

Os arquivos são criados no diretório MTMONbase/log.

O nome dos arquivos contém 2 variáveis:

{SERVER}: é o nome do servidor em foi dado o Ciente.
{AAAAMM}: é a data de quando a ação foi realizada e não a data do evento em si.

Formato do arquivo acionamentos.{SERVER}.{AAAAMM}.log:

data: data no formato dd/mm/AAAA HH:MM:SS
operador: operador do NOC que realizou o acionamento
origem: empresa à que pertence o evento acionado (Origem)
ativo: ativo relacionado ao evento
contato: pessoa contatada
string: tipo de acionamento realizado
eventos: entre colchetes a lista de eventos envolvidos no acionamento

Exemplo de uma linha no arquivo:

22/06/2020 16:52:17,frede,cliente,pip,Analista de Suporte,contatado via WhatsApp,[202006/22/1592854807.0.cliente.pip.brarchive.saparch.2335.dir]

Formato do arquivo ciente.{SERVER}.{AAAAMM}.log:

hora do clique: epoch em que o ciente foi clicado (Hora do servidor MTMON)
hora do evento: epoch em que o evento chegou no servidor MTMON
operador: operador do NOC que realizou o acionamento
diretório do evento: Caminho relativo ao diretório MTMON/eventos que contém as informações do evento.

Exemplo de uma linha no arquivo:

1592858570;1592858293;william;202006/22/1592858345.2.cliente8.agencia.link.mtmon.148791.dir

29. Estrutura interna do MTMON (Client)

O diretório que contém arquivos de controle no agente do mtmon é MTMON/var/local.

29.1. Diretórios relevantes

30. Arquivos usados pelo MTMON

O software foi desenvolvido usando o diretório MTMONbase como base. Quando da necessidade de alterar este diretório, criar um link simbólico ligando o novo diretório com o caminho padrão usado pelo sistema.

Por exemplo, para configurar o MTMON no diretório /mtmon, pode usar os comandos abaixo:

 # bdf | grep mtmon
 /dev/vg09/mtmon   52428800  845488 51181672    2% /mtmon
 # ln -s /mtmon /usr/local/Multitask/mtmon
 # ll /usr/local/Multitask/mtmon
 lrwxrwxrwx   1 root       sys              6 Nov 16 15:52 /usr/local/Multitask/mtmon -> /mtmon

Neste documento, $MTMON aponta para o diretório /usr/local/Multitask/mtmon. Os seguintes arquivos são usados pelo MTMON para definir a configuração.

Arquivo mtmon.conf
Arquivo passwd.conf

31. Definições gerais do MTMON

Estes arquivos de configuração são o coração do MTMON. Aqui são definidas as principais variáveis que afetam as funcionalidades e apresentação do software.

O caminho completo dos arquivos é MTADMbase/etc/mtadm.conf e MTMONbase/etc/mtmon.conf.

32. Arquivo mtadm.conf

As váriaveis de conexão ao servidor MTMON estão definidas em MTADM/etc/mtadm.conf. São elas:

32.1. Origem

É um código usado para identificar a origem do evento. Pode ter qualquer seqüência de caracteres e deve estar configurado com a mesma seqüência de caracteres no cliente e no servidor do MTMON. Veja uma explanação detalhada na sessão Entendendo o TransKEY. Pode estar em branco.

Se a origem for a mesma, normalmente associada à uma mesma empresa, todos os pTransKEY deverão ser iguais no arquivo de configuração dos computadores cliente. A variável pServer distinguirá os diferentes servidores.

32.2. Server

Quando definida esta variável, o parâmetro --servidor passa a ser opcional no comando mtmon_evento.pl. O objetivo é qualificar o nome do servidor que está gerando o evento.

32.3. ServerMTMON

É o endereço que será usado para o cliente conectar usando o protocolo HTTP para criar um evento. No servidor do MTMON, pode ser usado o IP da rede ou o loopback (127.0.0.1).

Este parâmetro aceita uma lista de IP’s separados por vírgula, que definem endereços de acesso ao servidor MTMON. Sempre que ocorrer um erro de conexão no servidor MTMON, o cliente tentará usar o próximo IP definido nesta variável. Todos os endereços definidos nesta opção podem ser usados, sendo que a escolha do IP que será efetivamente usado é aleatório, permitindo assim que não ocorra uma sobrecarga em um determinado IP, enquanto os demais permanecem ociosos.

32.4. TransKEY

É uma chave usada para autenticar a origem do evento. Pode ter 8 caracteres quaisquer que serão usados pelo programa de cadastro de eventos. Veja uma explanação detalhada na sessão Entendendo o TransKEY.

32.5. Proxy

Define a URL usada para acessar o proxy para acesso à internet. Se for necessária uma autenticação, use a sintaxe abaixo:

   Proxy=http://usuario:senha@Endereco:porta

Se a autenticação não é necessária, informe apenas:

   Proxy=http://Endereco:porta

Criar um usuário no proxy com regra que só libere acesso ao endereço do servidor do MTMON ou criar um mecanismo que permita a acesso ao servidor do MTMON sem proxy usando redirecionamento de porta TCP/IP. O objetivo é evitar o uso deste usuário de proxy para outras atividades.

Quando ocorrer o erro:

    501 Protocol scheme 'endereco' is not supported

Incluir o protocolo no início do endereco: http://endereco:porta

33. Arquivo mtmon.conf

As variáveis definidas no arquivo MTMONbase/etc/mtmon.conf e suas respectivas atribuições são esclarecidas abaixo:

33.1. Cliente

Nome que será apresentado no título do browser junto com a versão do MTMON. Só configurado na versão instalada no servidor do MTMON.

33.2. ArquivoControleRefresh

Sempre que o browser faz uma chamada para apresentar os eventos não finalizados, a data deste arquivo é atualizada. Assim é possível validar se o browser não está travado ou que inadvertidamente foi fechado. Se a data do arquivo for maior do que 5 minutos, o programa mtmon_audit.pl acionará os mecanismos definidos para alertar o operador.

33.3. ArquivoLock

Arquivo usado para controlar o acesso aos arquivos de eventos.

33.4. AutenticaComKRB5

O MTMON pode autenticar o usuário no Windows AD. Para isso, verifique o procedimento Autenticação via kerberos

33.5. AutenticaComPAM

Nos servidores que possuem o PAM configurado, é preferível fazer a autenticação por este meio. O item é explanado na sessão Autenticação via PAM

33.6. Debug

Quando Debug=1, são gravados na saída para o browser tags <COMMENT> que ajudam na identificação de problemas de configuração.

33.7. htmlDir

Páginas HTML, programas em JavaScript, imagens e área temporária usadas pelo MTMON são definidas aqui. O Apache é configurado para usar este diretório como área de htdocs.

33.8. httpTimeout

Define o tempo de espera que o cliente MTMON aguarda para estabelecer a conexão com o servidor MTMON.

33.9. HTML_FormFeed

Quando um relatório é apresentado no browser, esta seqüência define a quebra de páginas na impressão. Se não desejar a quebra de páginas, defina esta variável com nulo ''.

33.10. Idiomas

O MTMON pode apresentar as mensagens e telas nos idiomas definidos nesta variável. Verifique o procedimento para incluir outros idiomas na sessão gettext.

33.11. Limite

Define critérios para a criação de eventos, limitando um overflow de mensagens. A idéia é gerar um número inicial de n eventos, e depois repetir de m em m. Consulte a sessão --limite para mais informações.

33.12. logoEmpresa

Imagem que aparece na janela inicial do MTMON. Assim é possível customizar o software para apresentar a imagem com o logotipo do cliente.

O logo da Multitask tem a altura de 51 pixels.
Por isso sugerimos que as imagens sejam ajustadas com esta dimensão.

33.13. padraoCSS

Para alterar o aspecto geral das páginas, pode ser alterado o documento .css por um do próprio cliente. Evite alterar o conteúdo do documento mtmon.css, pois sempre que o software MTMON é atualizado, um nova versão do documento é gravada. O caminho apontado nesta variável é a URL usada para o browser solicitar o documento.

33.14. padraoIcone

Na barra de URL, pode ser incluído uma pequena figura.

33.15. PasswdFile

Arquivo auxiliar usado para estender as permissões de acesso dos usuários.

33.16. ScriptClient

Quando o conteúdo desta variável aponta para um script, este é chamado pelo mtmon_evento.pl e executado no servidor monitorado com o UID do usuário que o acionou. Veja a sessão Variáveis repassadas para ScriptServer e ScriptClient para uma explanação detalhada das variáveis repassadas para o script.

33.17. ScriptClientCheck

Se está variável é verdadeira, o script definido em pScriptClient é chamado antes de enviar os dados para a criação do evento no servidor MTMON. Se o return code for diferente de 0, o evento não será criado.

Esta função pode ser usada para definir uma lógica no momento da criação do evento. Por exemplo, se um evento pode ser ignorado durante o horário comercial, o script poderia identificar esta situação e não criar o evento por finalizar com rc diferente de zero. O script pode usar as variáveis definidas pelo MTMON para decidir sobre quais eventos o procedimento será adotado.

Consulte a sessão alterando atributos do evento para obter um exemplo prático.

33.18. ScriptServer

Quando o conteúdo desta variável aponta para um script, este é chamado pelo mtmon_novo_evento.pl e executado com o UID do APACHE no computador que é o servidor do MTMON. Veja a sessão Variáveis repassadas para ScriptServer e ScriptClient para uma explanação detalhada das variáveis repassadas para o script.

33.19. SufixoInfo

Quando a CONSOLE procura arquivos para criar o link de --notifica ou --informacao, e não existe um arquivo com o nome informado, a busca é ampliada com os sufixos definidos neste parâmetro. Consulte a definição de dirInfo para esclarecimentos.

33.20. TMP

As chaves com as autorizações nas sessões WEB são guardadas neste diretório. É importante que este diretório não esteja abaixo do Document Root do Apache, pois isso poderia comprometer a segurança do servidor.

33.21. tamMaxDump

Define o tamanhi máximo permitido para envio de um arquivo de dump para o servidor do MTMON. Quando o arquivo de dump é maior do que o limite definido nesta opção, o arquivo é copiado para um diretório local do computador cliente e a informação repassada no evento.

33.22. TabelaOrigem

Tabela usada para identificar o pTransKEY e o nome da origem do evento. O nome da origem pode ser um cliente, uma filial e/ou departamento que está sendo monitorado e é usado na apresentação do evento na janela de monitoração.

33.23. TempoDePing

O programa mtmon_cron.pl faz uma conexão no servidor no intervalo (em minutos) definido por esta variável. Neste processo, é atualizado um arquivo de controle que informa que o servidor cliente está ativo e comunicando. Também é verificado se existem atualizações nas definições de monitoração ou de programas e plugins para o computador cliente.

33.24. TempoDeRefresh

A janela de monitoração é atualizada pelo número de segundos definido aqui.

33.25. UsuarioWEB

Quando um evento é cadastrado, o dono do arquivo que o contém será definido com este valor.

34. Arquivo manutencao.conf

O arquivo MTMON/etc/manuntencao.conf define os critérios para que eventos não sejam enviados ao servidor MTMON. Este arquivo é configurado no cliente e uma cópia é enviada automaticamente para o servidor do MTMON.

Nenhuma opção é obrigatória, mas no caso de não haver nenhum critério, é assumido que o sistema está em manutenção e todos os eventos são igorados. Um log é gerado em MTMON/log/mtmon.AAAAMMDD.manut, com o formato abaixo:

dd/mm/aaaa hh:mm:ss [Sessao de dd/mm/aaaa hh:mm:ss ate dd/mm/aaaa hh:mm:ss] Mensagem do evento

O arquivo de log registrará todos os eventos que foram identificados e não enviados para o servidor, sendo útil para debug.

Consulte a sessão alterando atributos do evento com um outro exemplo de controle na criação evento.

O arquivo manutencao.conf pode conter as seguintes opções:

34.1. Periodo

Define o período de manutenção.

    Periodo=dd[[/mm[/aaaa]],[hh:mm]][,dd[[/mm[/aaaa]],[hh:mm]]]

O formato da opção é data e hora de início e fim da manutenção. Se a hora não for definida, o hora inicial é assumida como 0:00 e a hora final como 23:59:59.

Se periodo não for definido, assume que o sistema está em manutenção para as opções no arquivo de configuração.

Consulte os exemplos abaixo para maiores esclarecimentos.

34.2. Servidor

Esta opção é necessária quando o servidor em manutenção é remoto, como por exemplo um computador com windows monitorado por plugins do Nagios.

34.3. Aplicacao

Define a aplicação que será filtrada, ou seja, eventos com esta aplicação não serão enviados para o servidor do MTMON. Os demais eventos continuam sendo enviando normalmente.

34.4. Objeto

Define o objeto que será filtrado, ou seja, eventos com este objeto não serão enviados para o servidor do MTMON. Os demais eventos continuam sendo enviando normalmente.

Se o algum critério não é informado (Servidor, Aplicação ou Objeto), o sistema assume que todos eventos deste critério estão em manutenção e serão filtrados.

34.5. Notifica

Útil para filtrar eventos de um Grupo de Solução, cujo procedimento é acionar quando o evento ocorre.

34.6. Classe

A classe agrupa alguns itens de monitoração. Por exemplo, podemos definir uma classe /oracle/ e quando o Oracle no ambiente estiver em manutenção, podemos ignorar todos os incidentes relacionados com mínimo esforço.

34.7. Exemplos

O exemplo abaixo apresenta o arquivo de configuração com 3 sessões:

[oracle]
   periodo=24/12 12:00, 31/12
   aplicacao=oracle

[windows]
   periodo=01/2, 10/2
   servidor=windows

[catraca]
  periodo=10
  aplicacao=catraca

[oracle]
  periodo=08/08/2020 12:00, 10/08/2020 16:00
  notifica=oracle

No exemplo acima, os eventos da aplicacao oracle serão ignorados no dia 24/12 das 12:00 até o dia 31/12. Observe que não foi informado o ano não foi informado, este critério será válido em todos os anos.

Para o servidor windows serão ignorados os eventos do dia 01/02 das 00:00 até o dia 10/02 às 23:59:59. Observe que o ano não foi informado. Neste caso, o critério é válido para todos os anos.

No terceiro exemplo, o critério é atendido sempre no dia 10 de cada mês das 00:00 até às 23:59:59.

O quarto exemplo define que os eventos cujos acionamentos são para o procedimento oracle, não sejam gerados. Poderia ser também usada a opção classe, dependendo da configuração do ambiente.

Se forem informados os dois argumentos, notifica e classe, somente os eventos que atendem aos dois critérios serão considerados em manutenção. Esta situação pode ocorrer no exemplo acima. O nome da sessão é oracle em duas definições. Quando o arquivo de configuração é carregado, as definições da sessão oracle serão agrupadas e neste caso ocorrerá a referida situação. Por isso, na tela de definição dos períodos de manutenção, é incluído o epoch e o nome do usuário que está conectado na sessão do MTMON.

A definição do arquivo ficaria assim:

[catraca]
   aplicacao=catraca
   periodo=10

[oracle]
   aplicacao=oracle
   notifica=oracle
   periodo=08/08/2020 12:00, 10/08/2020 16:00

[windows]
   periodo=01/2, 10/2
   servidor=windows

35. Arquivo Origem.conf

O arquivo MTMONbase/etc/Origem.conf é usado na obtenção de informações do código da origem do evento.

35.1. Formato do arquivo

O arquivo pode ter definidos os seguintes campos:

  [Origem]
     Transkey=abcd1234
     Nome=Empresa Origem do Evento
     Email=administrador@empresa.origem.com.br, outro.email@gmail.com
     Email=mais.um.email@gmail.com
     VARIAVEL=exemplo
     outraVariavel=exemplo

onde:

Transkey: Toda origem tem associado um pTransKEY, que é usado para validar a origem do evento. Se a origem não for autenticada, qualquer individuo poderia gerar eventos falsos e incluir o registro no sistema do MTMON. No computador cliente do MTMON, o pTransKEY é definido no arquivo de parâmetros, sendo que este código é validado no arquivo Origem.conf no computador servidor do MTMON.
Nome: Descrição do nome da empresa, do departamento ou qualquer identificação que se deseja atribuir à origem do evento.
Email / noEmail: Os emails associados à origem são repassados ao pScriptServer nas variáveis de ambiente do shell MTMON_email e MTMON_noemail. Consulte a sessão variáveis repassadas para $ScriptServer e $ScriptClient para mais informações.

As várias entradas numa mesma sessão de origem são cumulativas. No exemplo acima, os três emails serão repassados para pScriptServer.

É possível definir os endereços de email de acordo com o tipo de evento gerado. As seguintes opções estão disponíveis:

nAAAA: se o evento incluir a notificação AAAA, serão incluídos estes endereços de email
sB: severidade for B
aCCCC: se a aplicação é CCCC
oDDDD: se o objeto é DDDD
tSSSS: se o tipo do Sistema Operacional é SSSS. Para identificar o valor que o Sistema Operacional assume no servidor monitorado, execute o comando abaixo:

 # perl -e 'print "$^O\n"'
 linux

Exemplos:

     Email_s2=gerente@dominio.com.br
     Email_nunix=outro@gmail.com
     Email_nmswin32=email_windows@gmail.com
     Email_aoracle=oracle@gmail.com

No primeiro exemplo, os eventos com severidade 2 serão enviados para gerente@dominio.com.br.

nunix indica que eventos com notificação unix, serão enviados para outro@gmail.com.

No terceiro exemplo, quando a aplicação for oracle, o email será enviado para outro@gmail.com.

     Email_taix=infra.aix@gmail.com, gestor@gmail.com
     noemail_s1=gestor@gmail.com
     noemail_nsap=infra.aix@gmail.com

Acima temos uma definição mais complexa. Eventos do Sistema Operacional AIX serão encaminhados via email para: infra.aix@gmail.com, gestor@gmail.com. Mas se o evento é de severidade 1 (não crítico), o email não será entregue para gestor@gmail.com. No caso de --notifica=sap, o email não é entregue para infra.aix@gmail.com.

Assim é possível definir filtros de negação de entrega de email’s à partir de definições gerais.

As últimas linhas definem que a aplicação oracle enviará email para outro@gmail.com.

Todos os parâmetros informados no arquivo serão repassados para os scripts na forma de variáveis de SHELL.

No exemplo acima, as seguintes variáveis estarão disponíveis para os scripts:

  MTMON_nome=Empresa Origem do Evento
  MTMON_email=administrador@empresa.origem.com.br,outro.email@gmail.com,mais.um.email@gmail.com
  MTMON_VARIAVEL=exemplo
  MTMON_outraVariavel=exemplo

Atente para o fato que o nome da variável preserva as letras maiúsculas e minúsculas dos parâmetros informados no arquivo Origem.conf, facilitando assim a identificação e uso das mesmas.

36. Descrição de comandos e plugins

36.1. Comando mtmon_evento.pl

Este é o comando usado para incluir um evento no MTMON. Pode ser acionado com os seguintes parâmetros:

  --aplicacao
  --debug
  --dump
  --email
  --eventual
  --finaliza
  --limite
  --informacao ou --info
  --mensagem
  --notifica
  --objeto
  --origem
  --repete
  --servidor
  --severidade

Os campos obrigatórios são: --servidor, --aplicacao, --severidade e --mensagem.

--origem (não obrigatório): Origem ou cliente ao qual está associado o evento gerado.

Colocar o arquivo com a definição da origem no arquivo MTMONbase/etc/Origem/{origem}.conf. {origem} normalmente é o nome do cliente.

Ex.: cliente.conf

  [cliente]
    email_asefaz=exemplo@cliente.com.br, operadores@cliente.com.br
    email_hpux=suporte@cliente.com.br, sperati@multitask.com.br
    finaliza=0
    nome=Cia Hering
    transkey=6py$SZwJzi.Mr

Para cada cliente deve ser definido um arquivo, que pode ser copiado do servidor MTMON.

--servidor: É o nome do servidor/equipamento onde ocorreu o fato gerador do evento. O nome é livre e pode ser usado qualquer seqüência de letras e números. Não é realizada nenhuma verificação de IP e/ou DNS. O objetivo é que o MTMON seja flexível e usado em aplicações que podem ter uma nomenclatura não relacionada com TI.

Se definida a variável pServer no arquivo de parâmetros, então --servidor é opcional, pois o comando recuperará a informação do mesmo.

--aplicacao: Também livre a ser definido pelo administrador do MTMON.
--severidade: Todos eventos devem ter um severidade definida. Existem 3 níveis de severidade e os procedimentos e ações à serem tomadas em cada caso, devem ser definidas pelo Administrador do MTMON. A severidade segue o padrão definido para os plugins do Nagios. Consulte o link do [Nagios http://www.nagios.org] para maiores informações. Estes plugins podem ser usados para monitorar eventos.

O Nagios não é pré-requisito para o MTMON. Cada usuário pode desenvolver seus plugins e finalizar os scripts com return code igual a 0, 1 ou 2, que determinará a severidade associada ao evento:

0 Normal

Este evento é informativo e aparece na janela de monitoração na cor verde. Não exige nenhuma ação do operador e pode ser finalizada sem incluir nenhuma nota. Se o evento foi cadastrado com a opção --finaliza, então este é copiado automaticamente para histórico e está disponível para consulta usando o botão Histórico.

1 Atenção

O padrão é que eventos com severidade neste nível, estão potencialmente comprometidos, mas ainda realizam as tarefas sob sua responsabilidade. Aparecem na cor amarela.

No exemplo da fresadora descrito no ítem --servidor, o evento poderia ser um aviso de que existe variação na qualidade da energia elétrica que alimenta o equipamento, mas dentro da tolerância definida pelo fabricante.

Num ambiente de TI, poderia ser um alerta de que um file system está próximo do limite da capacidade ou um link está com tempo de resposta abaixo do aceitável.

2 Crítico

Define que a gravidade exige a intervenção de alguém responsável o mais rápido possível. Neste caso, os parâmetros --informacao e --dump podem ser muito úteis para um diagnóstico rápido e eficiente do ocorrido e agilizar na resolução do problema. Aparecem na cor vermelha.

Os critérios sobre que severidade deve ser atribuída para cada evento é produto de um planejamento entre o Administrador do MTMON e as áreas envolvidas no processo monitorado. A documentação dos eventos e os procedimentos a serem adotados fazem a diferença quando o fato gerador ocorre. A pró-atividade resultante deste planejamento gera economia, pois o tempo de identificação até o endereçamento de uma solução minimizará o prejuízo resultante da parada do processo.

Se uma severidade diferente de 0, 1 ou 2 for informada, o MTMON o converte para 2, pois um sério erro de definição ocorreu. Neste caso, não há como definir a real situação do fato gerador e isso deve ser obrigatóriamente corrigido.

36.1.1. --mensagem

Mensagem de identificação do fato gerador do evento. É apenas uma linha que descreve de forma objetiva o ocorrido. Se existem outras informações relevantes ao evento, salve estas informações numa arquivo e encaminhe junto com a opção --dump.

36.1.2. --debug

Incrementa o número de informações apresentadas no cadastramento do evento.

36.1.3. --dump

Informa um nome de arquivo que será anexo ao evento e que poderá ser consultado via browser na janela de monitoração. Se o nome informado é o caracter - (traço), então a entrada padrão é usada para montar o arquivo de dump. O dump se relaciona com o evento único que está sendo gerado. Se a variável pScriptClient está definindo um script com permissão de execução, a variável $MTMON_Dump poderá ser usada para tratar o dump recebido.

O sistema MTMON está preparado para receber o anexo de --dump em qualquer formato disponível, pois os dados são transferidos para o servidor no formato binário.

36.1.4. --email

Repassa para os scripts os emails que podem ser usados para acionar alguém responsável pelo evento. Os emails serão repassados via variáveis de shell.

36.1.5. --eventual

Um incidente pode ser do tipo contínuo ou eventual.

Incidentes contínuos são do tipo que a mudança de estado estabelece uma parada no serviço, como por exemplo um link de dados.

A opção --eventual define que o incidente é pontual, ou seja, não tem qualquer relação com qualquer outro incidente passado ou futuro.

Por exemplo, o cancelamento de um programa numa rotina batch pode gerar um evento único que não tem qualquer relação com as demais execuções da mesma rotina.

36.1.6. --informacao

Informa um parâmetro que é o nome de um arquivo que existe no diretório dirInfo. Na janela de monitoração é criado um link que permitirá consultar o arquivo ou a URL informada. Se o arquivo não existe, a informação é apresentada sem link.

Só é permitida a definição de 1 argumento para --informacao.

O arquivo pode ser de qualquer tipo suportado pelo sistema operacional que está com a janela de monitoração, como por exemplo, .pdf ou .doc. Consulte a definição de pSufixoInfo para maiores informações.

Exemplos:

  --informacao links.pdf

  --informacao links

  --informacao http://www.endereco.com/programa.cgi?param1=1+param2=2

Se existir um arquivo chamado dirInfo/links.pdf, este poderá ser consultado na janela de monitoração pelo operador.

O segundo exemplo procura no diretório dirInfo por um arquivo chamado links. Se não encontrar, continua a busca com os sufixos definidos no parâmetro pSufixoInfo do arquivo mtmon.conf.

O terceiro exemplo abre uma janela com a URL definida na opção. Sempre que o parâmetro iniciar com http: ou https:, a CONSOLE interpreta como uma URL que será chamada numa nova janela.

Este procedimento pode minimizar a necessidade de acionar recursos desnecessários, uma vez que pode conter dicas, diretrizes e/ou procedimentos para tratar o fato gerador do evento.

No caso de um evento que monitora um link de comunicação, o arquivo poderia conter o número do telefone para abrir um chamado em caso de queda do link, pessoas de contato que devem ser acionadas, procedimentos de validação e/ou recuperação do link, etc. O conteúdo do arquivo é de responsabilidade do administrador do MTMON.

Vale salientar que --dump e --informacao são complementares, pois enquanto --dump disponibiliza uma informação relevante a um evento específico, o parâmetro --informacao define um procedimento para resolver o problema, podendo usar as informações disponibilizadas via --dump.

36.1.7. --finaliza

Quando o evento é de severidade 0 (normal) ele pode ser finalizado no momento do cadastro. Este tipo de evento pode ser usado para gerar um registro do fato gerador relacionado ao evento. Neste caso fica definido que não é necessária nenhuma ação da parte do operador que monitora o MTMON, e o evento pode ser consultado via browser clicando no botão Histórico.

Eventos com severidade 1 (alerta) ou 2 (crítico) não admitem a finalização automática. Neste caso, o parâmetro é ignorado. Isto ocorre porque para estes níveis de severidade uma ação do operador é exigida (por exemplo ligar para o responsável) e um registro sobre o procedimento adotado deve ser incluído clicando no botão Nota.

36.1.8. --limite n,m

Define quantos eventos serão gerados quando a severidade é maior que 0. O programa enviará os primeiros n eventos para o servidor e depois com periodicidade m. Para converter o tempo em m, divida o tempo desejado pela periodicidade que a monitoração é realizada.

Exemplos:

  --limite 3,36

Se a monitoração é realizada à cada 5 minutos, serão gerados 3 eventos iniciais nos minutos 0, 5 e 10. Depois de 36 x 5min = 180min (3 horas), se a severidade do evento não foi alterada, será gerado um novo evento. Eventos serão criados de 3 em 3 horas. Se a severidade diminuir, 1 evento novo será gerado. Se a severidade aumentar, 3 novos eventos serão gerados e o ciclo de 3 horas é reiniciado.

  --limite 2,9

Se a monitoração é realizada à cada 20 minutos, serão gerados 2 eventos iniciais nos minutos 0 e 20. Depois de 9 x 20min = 180min (3 horas), se a severidade do evento não foi alterada, será gerado um novo evento.

36.1.9. --notifica

Este parâmetro se relaciona com os parâmetros pScriptServer e/ou pScriptClient definidos no arquivo de parâmetros. Quando o script é chamado, uma das variáveis definidas é MTMON_Notifica. O script pode assim identificar eventuais usuários/responsáveis pelo evento que está gerando a notificação.

Além desta função, na CONSOLE de monitoração é criado um link de define o procedimento que o operador deve executar. Este procedimento é realizado consultando o link que é gerado.

O script poderia ter o seguinte código:

  for Grupo in $MTMON_Notifica
  do
    case "$Grupo" in
    ORACLE) echo "Manda SMS para responsavel do ORACLE"
            ...
    ;;
    UNIX) echo "Manda email para responsavel do UNIX"
            ...
    ;;
    esac
  done

Observe que se --notifica não for informado, a variável $MTMON_Notifica estará em branco e o script não enviará nenhum email.

36.1.10. --objeto

Livre a ser definido pelo administrador do MTMON. Permite uma identificação mais precisa do equipamento/módulo/função onde ocorreu o fato gerador do evento.

36.1.11. --repete

Quando a severidade do evento é a mesma que o evento anterior e repete=0, o evento não será gerado. Se repete=1, serão aplicadas as verifições de tempo, definido em --limite.

36.2. Variáveis repassadas para ScriptServer e ScriptClient

O objetivo das variáveis pScriptServer e pScriptClient é permitir uma ação no computador que está gerando o evento (Client) ou no computador servidor do MTMON (Server). Esta ação pode ser enviar um email ou SMS para o responsável pelo evento, acionar algum recurso ou gerar um registro em outro software de gerência, como por exemplo o [Nagios http://www.nagios.org], IBM Tivoli, HP OpenView, CA Unicenter ou BMC Patrol.

Quando o script definido é acionado, estão disponíveis as seguintes variáveis de SHELL:

MTMON_Origem: Conteúdo da variável pOrigem no cliente
MTMON_Empresa: Nome da empresa onde o mtmon_client está instalado identificado em Origem.conf
MTMON_Servidor: --servidor
MTMON_Aplicacao: --aplicacao
MTMON_Objeto: --objeto
MTMON_Mensagem: --mensagem
MTMON_Severidade: --severidade
MTMON_Debug: --debug
MTMON_Dump: --dump
MTMON_Finaliza: --finaliza
MTMON_Info: --informacao
MTMON_Notifica: --notifica
MTMON_Repete: --repete
MTMON_Email: Emails associados à origem do evento. Configurado no arquivo Origem.conf
MTMON_email: Emails informados na linha de comando com o parâmetro --email MTMON_EventoCadastrado`` - Código do evento gerado no servidor MTMON

Além dessas variáveis definidas pelo MTMON, todos os parâmetros configurados na pTabelaOrigem são repassados para os script, gerando uma variável de ambiente chamada MTMON_parametro.

As variáveis repassadas ao script podem ser verificadas incluindo a seguinte linha de comando no script:

  env | grep "^MTMON" | sort

A variável MTMON_Origem é recuperada do arquivo de parâmetros instalado no computador cliente do MTMON. A variável MTMON_Empresa é definida no arquivo pTabelaOrigem configurada no computador servidor do MTMTON usando a pOrigem definida no computador cliente do MTMON. As demais variáveis são informadas na chamada do mtmon_evento.pl.

É importante entender que o script definido na variável pScriptClient é executado no computador cliente com o UID do usuário que está criando o evento ao passo que o script definido na variável pScriptServer é executado no computador que é o servidor do MTMON, com o UID do APACHE lá definido. Desta forma, podemos acionar recursos locais e/ou remotos, permitindo assim inúmeras implementações de forma bastante simples.

Na linha do tempo, o pScriptServer é executado antes de pScriptClient. Isso ocorre por que os scripts são executados após o cadastro do evento e o pScriptClient só é executado depois do retorno do processamento no servidor do MTMON.

Esta abordagem é interessante quando o servidor do MTMON é controlado por uma empresa diferente de onde o processo é monitorado. Neste caso, o pScriptClient acionaria recursos locais da empresa monitorada, como por exemplo gerar entradas no [nagios http://www.nagios.org] local.

Por outro lado, pScriptServer define os acionamentos que ocorrerão na empresa monitoradora, como por exemplo, acionar algum analista sobre o fato do file system estar com a disponibilidade de área comprometida. As ações executadas por pScriptServer e/ou pScriptClient ocorrem em background, sem que o operador que está acompanhando o monitoramento na janela do browser seja notificado, definindo assim um alto grau de pró-atividade.

36.2.1. Definição do script à ser executado

Os parâmetros pScriptServer e/ou pScriptClient definem o nome do script à ser executado na criação de eventos no MTMON. No entanto, o sistema faz uma verificação para identificar scripts personalizados para pOrigem e pServer.

Por exemplo, se o parâmetro pScriptServer está configurado com o conteúdo:

  Server='Proxy';
  Origem='Empresa';
  ScriptServer='/usr/local/Multitask/mtmon/bin/teste_server.sh';

O MTMON procurará os seguintes script’s:

  /usr/local/Multitask/mtmon/bin/Proxy.Empresa.teste_server.sh
  /usr/local/Multitask/mtmon/bin/Empresa.teste_server.sh
  /usr/local/Multitask/mtmon/bin/teste_server.sh

Para o ambiente Windows, o recomenda-se que o script seja um executável ou um script em Perl.

O primeiro arquivo que for executável será usado para tratar o evento. Ou seja, se existir o arquivo Proxy.Empresa.teste_server.sh, todos os eventos gerados no servidor Proxy da origem Empresa serão tratados por este script. Se o arquivo não existe ou não tem permissão de execução, é verificado da mesma forma o arquivo Empresa.teste_server.sh. Se existir e é executável, este será usado para tratar os eventos da origem Empresa. Em último caso, testa a existencia do arquivo teste_server.sh, que será usado no tratamento de todos os eventos criados no servidor.

A idéia é que podemos definir scripts personalizados por pOrigem e pServer, diminuindo a complexidade dos scripts que tratam dos eventos.

O critério definido acima é válido para pScriptClient.

36.2.2. Definindo critérios para a criação do evento

Existem eventos que só devem ser criados em situações específicas, que são identificadas por meio de um processamento ou validação, é que não é possível definir em arquivos de configuração. Para estes casos, a opção pScriptClientCheck deve ser usada.

Se o script definido em pScriptClient retorna um valor diferente de 0, o evento não será enviado para o servidor MTMON e o mesmo não será criado. Esta funcionalidade simplifica o tratamento de geração de eventos, pois o programa que monitora algum recurso, se concentra na tarefa de gerar um evento quando determinado fato gerador ocorrer. Mas, muitas vezes, este fato gerador só deve ser reportado em determinadas horas do dia ou dias da semana, podendo nos demais períodos ser ignorados de forma segura.

É importante atentar para o fato que o script definido em pScriptClient será acionado 2 vezes. A primeira imediatamente antes de enviar o evento para o servidor MTMON e depois novamente após a criação do evento.

Na segunda chamada do script, a variável MTMON_EventoCadastrado estará definida com o código do evento gerado no servidor MTMON.

36.2.3. Exemplo de script em Perl (Windows)

Para o script abaixo:

  exit 0 if ($ENV{'MTMON_EVENTOCADASTRADO'});

  my $hora = (localtime(time))[2];
  exit 0 if ($hora > 17);
  exit 0 if ($hora < 8);
  print "MTMON_Finaliza=1\n";
  exit 0;

Se o nome do script é C:/Multitask/mtmon/bin/preExec.pl configure o parâmetro conforme abaixo:

  ScriptServer=C:/Multitask/mtmon/bin/preExec.pl

Observe que para o script acima, durante o horário comercial, o mesmo gera uma linha com o conteúdo MTMON_Finaliza=1. Esta linha informa o cliente do MTMON para finalizar o evento durante o horário comercial.

Podem ser geradas outras variáveis inciadas por MTMON_VARIAVEL=VALOR. Internamente, estas variáveis serão convertidas em argumentos para configurar o evento gerado no MTMON.

37. Comando mtmon_log.pl

Este comando apresenta os eventos criados no computador cliente monitorado. Para configurar a funcionalidade do comando, incluir no /etc/profile ou $HOME/.profile a seguinte chamada:

$MTMON/bin/mtmon_log.pl

Este comando verificará em cada login que for realizado, se existe no $HOME do usuário, um arquivo chamado .mtmon_log.conf. Se o arquivo não existe, o programa simplesmente finaliza.

Encontrando o arquivo, o programa mtmon_log.pl usa a data do arquivo como base para identificar os eventos gerados depois dela. Terminando a apresentação, a data do arquivo $HOME/.mtmon_log.conf é atualizada, e numa nova chamada, somente os novos eventos serão apresentados.

Opções disponíveis na linha de comando:

37.1. --1linha

Na apresentação do log dos eventos criados no MTMON, o padrão é usar 2 linhas, para melhor formatação num terminal de 80 colunas. O parâmetro --1linha, apresenta o log de cada evento numa única linha, que pode ser salva redirecionando a saída padrão.

37.2. --dias

O default para selecionar os eventos é a data do arquivo $HOME/.mtmon_log.conf. Cada usuário terá o seu arquivo de configuração. Se o comando mtmon_log.pl é chamado com esta opção, serão apresentados os eventos gerados desde a data que corresponde ao número de dias informado.

37.3. --paginar

O padrão é apresentar todos os eventos sem paginar. Com esta opção, um paginador equivalente ao comando pg é acionado.

37.4. --help

Apresenta informações de ajuda e as opções disponíveis que podem ser acionadas com a chamada do comando.

38. Arquivo .mtmon_log.conf

O arquivo $HOME/.mtmon_log.conf é usado para definir critérios de seleção na apresentação do log de eventos gerados no computador cliente do MTMON. Consulte a documentação do comando mtmon_log.pl para maiores informações.

O arquivo pode ter definidos os seguintes campos:

  severidade=1|2
  origem=dptoXYZ
  servidor=serv\d+
  aplicacao=Oracle
  objeto=obj
  mensagem=teste

Os campos são correspondentes ao eventos que o log representa.
TODOS OS CAMPOS SÃO OPCIONAIS, e se nenhum campo for definido, todos os eventos criados desde a última chamada do comando mtmon_log.pl pelo usuário serão apresentados.
Os critérios são cumulativos, ou seja, serão apresentados os eventos que atendem à todos os critérios definidos no arquivo de configuração.
Os critérios seguem o padrão de [expressões regulares do PERL http://perldoc.perl.org/perlintro.html#Regular-expressions]

39. Comando mtmon_checklog.pl

O objetivo deste programa é identificar padrões em arquivos de log.

A sessão Global define o padrão dos parâmetros não informados nas sessões de busca. As sessões são executadas na seqüencia definida pelo nome da sessão, com execessão da Global.

Para acionar o programa, inclua na crontab a seguinte linha:

  */2 * * * * /usr/local/Multitask/mtmon/bin/mtmon_checklog.pl #

O programa usa o arquivo de configuração $MTMON/etc/mtmon_checklog.conf para definir os padrões que serão usados para identificar as linhas no arquivo de log que serão usadas para a geração de alertas.

Opções disponíveis na linha de comando:

39.1. --arquivo

Nome do arquivo de configuração que define os padrões de busca no arquivo de log. Se não for informada esta opção, o programa usará o arquivo MTMONbase/etc/mtmon_checklog.conf.

39.2. --continua

O comportamento padrão do programa é varrer o arquivo de log e finalizar. Um registro da última linha processada é feito, e nas execuções subseqüentes a verificação é realiza à partir deste ponto do arquivo de log. O registro salva também o número de bytes do arquivo de log. Se o tamanho do arquivo não aumentou, nenhum processamento é realizado. Se o tamanho diminuiu, o programa entende que o arquivo de log é novo, e um reset é aplicado.

39.3. --reset

39.4. --debug

Um log detalhado das operações é apresentado na saída padrão. Se um nome de arquivo for informado, a saída do debug será gravado neste arquivo.

39.5. Arquivo mtmon_checklog.conf

É o arquivo de configuração do comando mtmon_checklog.pl, responsável por controlar a execução dos PLUGINS que automatizam a monitoração.

O formato do arquivo é:

 [Global]
 #  arquivo=/usr/local/Multitask/mtmon/log/messages
 #  arquivo=/usr/local/Multitask/mtmon/log/secure
 #  arquivo=/var/adm/syslog/syslog.log
   espera=5
   severidade=0
   ignoracase=1
   aplicacao=checklog

 #include templates/000ignore.conf
 #include templates/inetd.conf
 #include templates/sshd.conf
 #include templates/su.conf
 #include templates/sudo.conf
 #include templates/xntpd.conf
 #include templates/zzzERROSA.conf

40. Comando mtmon_snmplog.pl

Este programa garimpa mensagens de arquivo de log gerado via SNMP.

Opções disponíveis na linha de comando:

40.1. --config

Define o nome do arquivo de configuração que contem os padrões a serem usados na identificação das mensagens de alerta. Se não for informada esta opção, o programa usará o arquivo MTMONbase/etc/mtmon_snmp.conf.

40.2. --zeralog

Na criação de eventos identificando arquivos que atendem ao critério, é informado o parâmetro --notifica.

40.3. --debug

Um log detalhado das operações é apresentado na saída padrão. Se um nome de arquivo for informado, a saída do debug será gravado neste arquivo.

40.4. Arquivo mtmon_snmp.conf

O formato do arquivo é:

 [Global]
   Severidade=0
   Aplicacao=snmp

 [sessao1]
   Arquivo=/caminho/para/arquivo
   Objeto=objeto
   Severidade=2
   Tempo=2 dias

 [archive_PRD]
   Ativo=1
   Arquivo=/usr/local/Multitask/mtmon/log/backup/arch_tim.log
   Severidade=2
   Tempo=150 minutos

A primeira sessão é denominada Global e contém os valores padrão que serão assumidos nas sessões subseqüentes.

Cada sessão pode ter os seguintes parâmetros:

40.5. Arquivo

Define o nome do arquivo que será monitorado.

40.6. Tempo

Informa quanto tempo o arquivo pode ficar sem atualização antes de gerar um evento. A unidade de tempo informada pode ser uma das seguintes: minuto, hora ou dia. Omitindo a unidade de tempo, assume que o tempo informado é em segundos.

40.7. NotFoundOK

Se o arquivo monitorado não existir é gerado um evento com erro. Se for definida a opção notfoundok=1 e o arquivo não existir, será considerado que a monitoração está OK.

40.8. Severidade

Gera o evento com a --severidade informada.

40.9. Aplicacao

O evento é gerado com o nome da aplicação informado.

40.10. Objeto

O evento é gerado com o nome do --objeto informado. Se não for informada, o programa assume o nome da sessão como sendo o objeto.

40.11. Limite

O evento é gerado com o --limite informado.

40.12. Obs

Define uma observação que será usada para gerar um arquivo de DUMP para ajudar na solução do incidente.

41. Comando mtmon_audit.pl

Este programa identifica os seguintes problemas no sistema de arquivos:

Arquivos do SUID ligado, que permite um usuário assumir a identidade de outro ao executar o arquivo em questão
Arquivos com tamanho maior que o definido
Diretórios com mais de um determinado número de arquivos
Usuários usando muita área em disco
Usuários cadastrados no /etc/passwd com UID=0

Em função do tempo que leva para realizar esta verificação, recomenda-se que este programa seja incluído na crontab num horário de menor atividade do Sistema Operacional:

  15 3 * * * /usr/local/Multitask/mtmon/bin/mtmon_audit.pl #

Opções disponíveis na linha de comando:

41.1. --arquivo

Nome do arquivo de configuração que define os critérios usados na busca. Se não for informada esta opção, o programa usará o arquivo MTMONbase/etc/mtmon_audit.conf.

41.2. --notifica

Ao criar o evento, inclui o parâmetro --notifica.

41.3. --preview

Não cria eventos no servidor MTMON. É útil para inicializar os arquivos de controle numa primeira execução.

41.4. --gerarevento

O padrão do plugin é processar os arquivos e não gerar evento no MTMON. Quando a opção --gerarevento é informada, serão gerados eventos do tipo alerta, com severidade=1.

41.5. --debug

Um log detalhado das operações é apresentado na saída padrão. Se um nome de arquivo for informado, a saída do debug será gravado neste arquivo.

41.6. Arquivo de configuração mtmon_audit.conf

O arquivo de configuração pode ter as seguintes sessões:

[SUID]
  Arquivo=mtmon_suid.Ctrl
  notifica=

[BIGFILES]
  Ignorar=mtmon_bigfiles.Ignorar
  IgnorarDir=mtmon_bigfiles.IgnorarDir
  Arquivo=mtmon_bigfiles.Ctrl
  tamanho=100Mb
  alerta=20%
  critico=50%
  notifica=

[BIGDIR]
  Ignorar=mtmon_bigdir.Ignorar
  Arquivo=mtmon_bigdir.Ctrl
  limite=900
  alerta=20%
  critico=50%
  notifica=

[BIGUSER]
  IgnorarUID=0,
  limite=10Mb
  Arquivo=mtmon_biguser.Ctrl
  alerta=20%
  critico=50%
  notifica=

41.7. Sessão SUID

Esta sessão identifica os arquivos que possuem o SUID ou SGID ligados. Ao identificar os arquivos com o atributo, o checksum e chmod são salvos no arquivo definido na opção Arquivo da sessão, por default, mtmon_suid.Ctrl.

Na primeira execução, o arquivo mtmon_suid.Ctrl não existe e deve ser feita uma auditoria para identificar se os arquivos podem continuar com o atributo SUID ou SGID. Nas execuções subsequentes, o arquivo mtmon_suid.Ctrl será usado como base, e serão gerados eventos sempre que novos arquivos possuirem o atributo em questão ou se o checksum do arquivo foi alterado. O checksum pode ser alterado numa aplicação de PATCH ou atualização de software, mas existe o potencial de uma quebra de segurança no ambiente monitorado, que é o objetivo maior deste programa.

A sessão SUID pode ainda ter a opção Notifica, que tem a mesma função definida em --notifica.

41.8. Sessão BIGFILES

Identifica os arquivos com tamanho maior do que o valor definido na opção Tamanho.

O ciclo de pesquisa é semelhante ao descrito na sessão SUID acima, isto é, os valores default são salvos numa primeira execução e depois o novos arquivos que atendem o critério são incluídos na lista com o evento gerado. Um ponto importante na busca é que se um arquivo crescer mais do que o percentual definido nas opções alerta ou critico, um novo evento será gerado.

Quando se deseja ignorar determinados arquivos, por exemplo, datafiles de um banco de dados, eles podem ser incluídos no arquivo cujo nome é definido na opção Ignorar.

A opção IgnorarDir é usada para os diretórios que contém archives ou arquivos grandes, mas que já possuem alguma forma de controle.

IMPORTANTE: Subdiretórios de IgnorarDir serão pesquisados para identificar situações do tipo $DIR/old.

41.9. Sessão BIGDIR

A opção Limite define o número de arquivos que podem estar num diretório. Se algum diretório contém mais arquivos do que o definido, um evento é gerado.

41.10. Sessão BIGUSER

Identifica os usuários que consomem mais área em disco do que o definido na opção Limite.

Usuários cadastrados na opção IgnorarUID não serão contabilizados.

42. Comando mtmon_daemon.pl

Este plugin monitora os serviços disponíveis no ambiente.

Opções disponíveis na linha de comando:

42.1. --config

Define o nome do arquivo de configuração usado para verificar os serviços. O nome do arquivo de configuração padrão é MTMONbase/etc/mtmon_daemon.conf.

42.2. --dump

Anexa no evento gerado a saída do comando ps -ef usado para verificação dos serviços.

42.3. Arquivo mtmon_daemon.conf

O arquivo MTMONbase/etc/mtmon_daemon.conf é usado na definição dos critérios para verificação dos serviços configurados.

O arquivo pode ter definidos os seguintes campos:

  [smbd]
    ppid=1
    comando=smbd
    total=1

  [nmbd]
    ppid=1
    comando=nmbd
    total=1

  [oracle]
    ppid=1
    comando=oracle
    total=8 >=
    Mensagem=Processos na sessao {SESSAO}: {TOTAL}. Deveria ser mais de {COUNT}.
    MensagemOK=Processos Oracle OK.

  [cron]
    ppid=1
    comando=/usr/sbin/cron
    total=1
    Severidade=1

onde:

ppid: Estabelece que o programa verificado é filho do processo init, que é o dispatcher principal do ambiente UNIX.
comando: É o comando ou parte dele que identifica se o mesmo está em execução.
total: Define quantos processos devem estar em execução.

Se um segundo argumento for informado, define que a soma dos processos encontrados deve atender ao critério estabelecido. O argumento deve ser um dos seguintes: =, >, <, >=, ⇐.

Ex.: No arquivo de configuração acima, se forem encontrados 8 ou mais processos do oracle, cujo PPID é igual à 1, então o evento gerado será verde (OK). Se não existirem pelo menos 8 processos, um evento crítico será gerado.

severidade: Define com que severidade o evento será gerado.
Mensagem e MensagemOK: Mensagem que será usada no evento do MTMON. As variáveis serão substituidas pelo valor correspondente no momento da geração do evento.

Variáveis suportadas:

{TOTAL}: Número de processos definido na sessão correspondente.
{SESSAO}: Nome da sessão no arquivo de configuração.
{FLAG}: Segundo argumento da opção total, definido acima.
{COUNT}: Total de processos identificados com o padrão.

43. Programa para compactar arquivos antigos no Windows

No windows, existe um programa que pode ser usado para compactar arquivos com o comando COMPACT.

C:\Multitask\mtadm\bin\winCompactOldFile.pl [--dias 180] [--tamanho 4095] C:\diretorio1\subdir1\subdir2 [E:\] [G:\outro\dir]

O exemplo acima, selecionará os arquivos maiores que 4095 bytes, que foram criados à mais de 180 dias.

Para cada arquivo encontrado será executado o comando:

COMPACT /C arquivo

Quando é informado na sintaxe: E:\, o volume inteiro é processado, atendendo aos critérios informados.

Observe que 180 dias e 4095 bytes são os valores default se não forem informadas opções na linha de comando.

O tamanho sempre deve ser informado em bytes.

44. Comando mtmon_filesize.pl

Este plugin monitora os tamanho de arquivos. Se o tamanho é maior do que a definição gera o alerta.

Opções disponíveis na linha de comando:

44.1. --config

Define o nome do arquivo de configuração usado para verificar os serviços. O nome do arquivo de configuração padrão é MTMONbase/etc/mtmon_filesize.conf.

44.2. Arquivo mtmon_filesize.conf

O arquivo MTMONbase/etc/mtmon_filesize.conf é usado na definição dos critérios para verificação dos arquivos monitorados.

O arquivo pode ter definidos os seguintes campos:

[PRDalert_log]
   ativo=1
   arquivo=/oracle/PRD/admin/bdump/alert.log
   tamanho=10Mb
   objeto=PRDalert_log
   severidade=1

onde:

arquivo: Nome do arquivo monitorado.
tamanho: Define o tamanho máximo aceito para o arquivo. Se o arquivo for maior do que aqui definido, gera uma evento com a severidade definida na opção correspondente.

A opção poderá ser informada em Kb, Mb ou Gb.
severidade: Define com que severidade o evento será gerado.

45. Comando mtmon_link.pl

Este programa monitora o RTA de link’s usando o comando ping, e avalia se o RTA é maior do que o limite definido por mais de um período de tempo.

O programa usa os seguintes campos no arquivo de configuração mtmon_servico_remoto.conf:

45.1. RTA

Define o limite aceito para o RTA no comando PING executado para teste de link.

Exemplo:

   rta=100ms

A unidade de medida do RTA sempre será ms. A informação consta na definição para efeito de documentação.

45.2. Tempo

Informa por quanto tempo o RTA pode estar acima do limite.

Exemplo:

   tempo=5 min, 30 min

No exemplo acima, será gerado um evento de alerta (amarelo) ou crítico (vermelho) quando o RTA for maior do que o limite definido por mais de 5 minutos ou 30 minutos.

45.3. timeout

Tempo em segundos que o plugin espera um retorno do ping.

45.4. monitorarta

Esta opção criará um registro dos RTA obtidos na verificação e permitirá criar gráficos de performance.

45.5. aplicacao

Conceitualmente define a operadora que fornece o link.

Exemplo:

  BrT, GvT, Embratel

46. Comando mtmon_postqueue.pl

Este programa monitora a fila de envio de email’s do Postfix ou do sendmail.

Opções disponíveis na linha de comando:

46.1. --fila

Define o limite de mensagens para geração do evento.

46.2. --severidade

Define a severidade do evento que será gerado quando a fila tiver mais email’s do que o valor definido na opção --fila.

46.3. --sendmail

O padrão de verificação é o software Postfix. Para validar email’s do sendmail, usar a opção --sendmail.

46.4. --preview

Não gera evento na console do MTMON. Apresenta a mensagem do alerta na saída padrão.

No exemplo abaixo, será gerado um evento com severidade crítica quando a fila chegar à 250 email’s.

  # mtmon_posqueue.pl --fila 250 --severidade 2

47. Instalação e atualização do MTMON

Para instalar ou atualizar o MTMON no ambiente, são necessários dois programas, que devem ser executados com o super-usuário (root):

   inst_mtadm
   inst_mtmon_client
   inst_mtsend
   inst_mtsms

Faça o download no [MTGED da Multitask http://www.multitasknet.com.br/mtged] no diretório /Multitask/Software. Use o usuário/senha: guest/guest

O inst_mtadm define uma série de módulos e programas de apoio que são usados pelos softwares desenvolvidos pela Multitask.

Para os computadores que serão apenas clientes do MTMON, pode ser instalado o inst_mtmon_client, que possui apenas as funcionalidades necessárias para criar o evento no servidor.

O inst_mtsend é usado para envio de email com as informações do evento gerado.

O inst_mtsms pode enviar uma mensagem de texto para os celulares configurados no MTMON.

47.1. Exemplo de instalação do MTAdm

O script inst_mtadm irá produzir uma saída semelhante ao exemplo abaixo :

  [root@lhsl2006 src]# sh inst_mtadm
  x - created lock directory `_sh04033'.
  x - extracting mtSalvaChmod.pl (binary)
  x - extracting IdentificaLVs.sh (text)
  IdentificaLVs.sh: MD5 check failed
  x - extracting MTAdm.gettext.sh (text)
  x - extracting mtadm.de.UTF-8.mo (binary)
  x - extracting mtadm.de.mo (binary)
  x - extracting mtadm.de.ISO8859-1.mo (binary)
  x - extracting mtadm.en.UTF-8.mo (binary)
  x - extracting mtadm.en.mo (binary)
  x - extracting mtadm.en.ISO8859-1.mo (binary)
  x - extracting mtadm.es.UTF-8.mo (binary)
  x - extracting mtadm.es.mo (binary)
  x - extracting mtadm.es.ISO8859-1.mo (binary)
  x - extracting mtadm.pt_BR.UTF-8.mo (binary)
  x - extracting mtadm.pt_BR.mo (binary)
  x - extracting mtadm.pt_BR.ISO8859-1.mo (binary)
  x - extracting Customiza.pl (text)
  Customiza.pl: MD5 check failed
  x - extracting MTAdm.pm (binary)
  x - extracting MTAdmInst.pm (binary)
  x - extracting mtwdog_files.pl (binary)
  x - extracting Mensagens.pl (text)
  x - extracting ComandosMT.pl (binary)
  x - extracting ComandoRemoto.sh (text)
  x - removed lock directory `_sh04033'.
  Preservando arquivo MTAdm.gettext.sh.
  Nova copia em /usr/local/Multitask/mtadm/bin/MTAdm.gettext.sh.new
  ComandosMT.pl : $Revision: 3.25 $


  Variaveis no arquivo /usr/local/Multitask/mtadm/etc/Parametros.pl :

  $Base         Diretorio base para mtwdog_files.pl
  $Recursivo    Quando incluir na base 1 diretorio, descer recursivamente
                a arvore de diretorio
  $Sincronizar  Quando nao informa nenhum parametro sincroniza tudo
  $Compactar    Manter os arquivos da base compactados
  $Script       Chamado quando houver alteracao no arquivo controlado
  $ENV          Sao variaveis usadas para definir a linguagem da mensagens


  Programas incluidos no pacote :

  mtwdog_files.pl  : Mantem historico de alteracoes de arquivos do sistema
  mtSalvaChmod.pl  : Cria script de recuperacao de permissao de arquivos
  IdentificaLVs.sh : Cria no root do filesystem informacoes dos VG e LV
  ComandoRemoto.sh : Script geral para execucao remota de comandos

47.2. Exemplo de instalação do cliente do MTMon

O script inst_mtmon_client irá produzir uma saída semelhante ao exemplo abaixo:

  cliente:/home/root$ sh inst_mtmon_client
  x - created lock directory `_sh06284'.
  x - extracting mtmon_Versao.pl (binary)
  x - extracting MTMON.pm (binary)
  x - extracting ComandosMT.pl (binary)
  x - extracting Customiza.pl (binary)
  x - extracting passwd.conf (text)
  x - extracting mtmon_evento.pl (binary)
  x - extracting mtmon_cron.pl (binary)
  x - extracting mtmon_cron.cfg (text)
  x - extracting GeraSenha.pl (text)
  restoration warning:  size of GeraSenha.pl is not 329
  x - extracting mtwdog_files.sh (text)
  restoration warning:  size of mtwdog_files.sh is not 776
  x - removed lock directory `_sh06284'.
  ComandosMT.pl : $Revision: 3.25 $

  $Id: Customiza.pl,v 1.14 2006/06/17 00:04:55 fischer Liberado $
  . MTMON=/usr/local/Multitask/mtmon
  . Identificando diretorios do sistema.
  . Identificando os perl's disponiveis.
    /usr/bin/perl OK
    /usr/local/bin/perl OK
    /opt/perl/bin/perl OK
  . Identificando o PATH dos comandos.
    Salvando mtmon_evento.pl
    Instalando mtmon_evento.pl
    Salvando mtmon_cron.pl
    Instalando mtmon_cron.pl
    Salvando mtmon_Versao.pl
    Instalando mtmon_Versao.pl
    Salvando MTMON.pm
    Instalando MTMON.pm
    Salvando GeraSenha.pl
    Instalando GeraSenha.pl
    passwd.conf ja existe. Salvando passwd.conf.new
    mtmon_cron.cfg ja existe. Salvando mtmon_cron.cfg.new
    mtwdog_files.sh ja existe. Salvando mtwdog_files.sh.new
  . Modulo 'Authen::PAM' nao encontrado.
  . Modulo 'Authen::KRB5' nao encontrado.
  . Alterando permissao de /usr/local/Multitask/mtmon para 0444
  . Alterando permissao de /usr/local/Multitask/mtmon/bin para 0555
  . Alterando permissao de /usr/local/Multitask/mtmon/etc para 0755
  . Alterando permissao de /usr/local/Multitask/mtmon/tmp para 0700
  . Alterando permissao de /usr/local/Multitask/mtmon/var para 0700

48. gettext

O software GNU usado para tradução de mensagens em outros idiomas é o [gettext http://www.gnu.org/software/gettext/].

49. Configuração do MTMON

Após a instalação dos programas, é necessária a configuração dos seguintes softwares:

  Apache
  sudo

49.1. Configuração do Apache

Incluir no arquivo $APACHE/conf/httpd.conf as linhas abaixo:

  ScriptAlias /mtmon-cgi/ "/usr/local/Multitask/mtmon/cgi-bin/"
  Alias /mtmon "/usr/local/Multitask/mtmon/htdocs"

Se o caminho do MTMON foi alterado, Apache pode não seguir o link simbólico criado. Esta é uma diretiva do Apache para incrementar a segurança de acesso à documentos. Neste caso configure o arquivo com o diretório real do MTMON.

Por exemplo:

  ScriptAlias /mtmon-cgi/ "/mtmon/cgi-bin/"
  Alias /mtmon "/mtmon/htdocs"

Depois de alterado o httpd.conf é necessário reiniciar o APACHE.

49.2. Configuração do sudo

Consulte a sessão Métodos de autenticação para verificar a necessidade de configuração do sudo. Nesta sessão é definida a linha à ser incluída via visudo.

50. Métodos de autenticação

Para que o usuário possa acessar qualquer documento, é necessário que o mesmo se autentique para o MTMON. A autenticação é o procedimento de identificar e validar que, quem está se apresentando como o usuário, seja de fato o usuário autorizado. Para isso podemos usar os seguintes métodos:

Kerberos: Permite que o usuário e senha sejam os definidos no servidor Windows AD (Active Directory). Veja detalhes na sessão Autenticação via kerberos.
PAM: Plugglable Autentication Modules (Módulos de autenticação plugáveis) são um conjunto de bibliotecas usadas para fazer autenticação, gerenciamento de contas, controle de recursos dos usuários no sistema, em adição ao tradicional sistema de acesso baseado em usuários/grupos.
/etc/passwd: Para validar o usuário e senha, é necessário que o MTMON acesse a string com a senha criptografada com o comando crypt do UNIX. Num ambiente TRUST ou com /etc/shadow, apenas o super-usuário (root) tem permissão de acesso à esta informação. Para atender à necessidade de recuperar a senha criptografada, é possível configurar o sudo para que permita que o comando MTMONbase/cgi-bin/Login.cgi execute com a permissão de super-usuário (root). O entrada a ser definida no sudoers via comando visudo é:

   www  ALL = (ALL) NOPASSWD: /usr/local/Multitask/mtmon/cgi-bin/Login.cgi

Na instalação do mtmon (inst_mtmon), o próprio instalador identifica o Apache usado e já informa a string correta que deve ser colocada no sudoers. Esta não é a melhor forma de autenticação, pois permite uma vulnerabilidade que é a execução de um programa como super-usuário (root). Analise a possibilidade de usar os métodos mais seguros apresentados acima.

51. Autenticação via kerberos

Para que o usuário e senha seja autenticado no servidor Windows AD (Active Directory):

Instale o módulo Authen::Krb5::Simple

O módulo pode ser instalado usando o CPAN:

 # perl -MCPAN -e shell
 cpan> install Authen::Krb5::Simple

Para instalação sem acesso à internet, o módulo pode ser obtido no site oficial do CPAN.
Para instalar, consulte o arquivo README que acompanha o fonte do módulo.

Defina AutenticaComKRB5

Alterar no arquivo MTMONbase/etc/mtmon.conf, a variável AutenticaComKRB5=1.

Configurar o /etc/krb5.conf

O arquivo /etc/krb5.conf define as configurações necessárias para que o cliente do kerberos possa autenticar o usuário. No exemplo abaixo, altere a configuração de acordo com as definições do servidor local.

 [logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

 [libdefaults]
  ticket_lifetime = 24000
  default_tgs_enctypes = rc4-hmac-nt des-cbc-md5 des3-hmac-sha1 des-cbc-crc des-cbc-crc
  default_tkt_enctypes = rc4-hmac-nt des-cbc-md5 des3-hmac-sha1 des-cbc-crc des-cbc-crc
  default_realm = DOMINIO.CLIENTE.COM.BR
  dns_lookup_realm = false
  dns_lookup_kdc = true
  clockskew = 3000

 [realms]
  DOMINIO.CLIENTE.COM.BR = {
   kdc = 172.16.0.26:88
   kdc = 172.16.0.27:88
   admin_server = 172.16.0.26:749
   default_domain = dominio.cliente.com.br
  }

 [domain_realm]
  .dominio.cliente.com.br = DOMINIO.CLIENTE.COM.BR
  dominio.cliente.com.br = DOMINIO.CLIENTE.COM.BR

 [appdefaults]
  pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
  }

52. Autenticação via PAM

Para que o usuário e senha seja autenticado via PAM (Plugglable Autentication Modules/Módulos de autenticação plugáveis):

Instale o módulo Authen::PAM

O módulo pode ser instalado usando o CPAN:

 # perl -MCPAN -e shell
 cpan> install Authen::PAM

Para instalação sem acesso à internet, o módulo pode ser obtido no site oficial do CPAN.
Para instalar, consulte o arquivo README que acompanha o fonte do módulo.

Defina AutenticaComPAM

Altere no arquivo MTMONbase/etc/mtmon.conf, a variável AutenticaComPAM=1.

53. Arquivo passwd.conf

Arquivo (MTMONbase/etc/passwd.conf) usado para definir o usuário que não existe no ambiente do UNIX ou para definir as origens que o usuário terá acesso.

53.1. Formato do arquivo

O arquivo pode ter definidos os seguintes campos:

 [Usuario]
    senha=senha
    status=A
    limite=dd/mm/aaaa
    origem=origem1,origem2,origem3,...

onde:

Usuario: Usuário a ser autenticado/autorizado.
Senha: Senha no formato crypt, MD5 ou em branco. Se a senha não está definida, o MTMON irá validar a senha usando outro mecanismo de autenticação (veja sessão Métodos de autenticação). Esta senha tem prioridade sobre todos os outros métodos de autenticação.
Status: O único atributo possível por enquanto é A, que define o usuário como Administrador do MTMON podendo assim consultar todos os eventos registrados.
Limite: Para usuários temporários, pode-se informar a data limite que o acesso ao MTMON será autorizada. O formato do parâmetro é:

   Limite=dd/mm/aaaa [HH:MM]

Esta data define o momento limite para o login no MTMON. Isto significa que se for informada a data:

   Limite=12/01/2006 12:00

o usuário poderá fazer o login até ao meio-dia de 12/jan/2006 e usar o sistema até fechar a janela no Browser. É possível criar mecanismos que interrompam a autorização no horário definido no arquivo, mas a ação padrão é barrar apenas a entrada.

Origem: Define as origens que o usuário poderá consultar eventos. No exemplo abaixo, o usuário poderá consultar os eventos das origens origem1, origem2 e origem3:

   Origem=origem1,origem2,origem3

A sintaxe abaixo NEGA o acesso às origens definidas, ou seja, permite a consulta dos eventos que NÃO SÃO DESTAS ORIGENS:

   Origem!=origem1,origem2,origem3

O caracter '*' permite acesso à todos os eventos de todas as origens.

53.2. Exemplos

Abaixo alguns exemplos para esclarecer as definições das autorizações.

  [usuario1]
     Status=A

O usuario1 tem autorização de Administrador. O usuário deve estar obrigatóriamente definido em algum dos Métodos de autenticação.

  [usuario2]
     Senha=mtdbZbG1rXvHY

Cria o usuário usuario2 para o ambiente MTMON. Mesmo que usuario2 exista em outra base de dados (KRB5, PAM ou /etc/passwd), a senha solicitada será a senha definida neste arquivo.

  [usuario3]
     Limite=12/01/2006 12:00

O usuário usuario3 tem autorização de acesso até o dia 12/jan/2006 ao meio-dia. O usuário deve estar obrigatóriamente definido em algum dos Métodos de autenticação.

  [usuario4]
     Senha=mtdbZbG1rXvHY
     Limite=15/12

O usuário usuario4 tem autorização de acesso até o dia 15/dez.

Observe que nesta sintaxe, no dia 01/jan do ano seguinte o usuário volta a ter permissão de acesso, sendo que o bloqueio ao MTMON se dará apenas nos dias 16-31/dez. Não informando o ano o sistema assume o ano corrente.

54. Definição de dirInfo

Quando da criação de um evento é informado o parâmetro --informacao ou --notifica, esta informação é registrada junto no evento. A CONSOLE do MTMON, quando verifica a existência de arquivos para criar os links, consulta os diretórios na seguinte seqüência:

MTMONbase/htdocs/info/${Origem}/${Servidor}
MTMONbase/htdocs/info/${Origem}
MTMONbase/htdocs/info

Dentro de cada diretório, ele procura arquivos com o nome informado no comando mtmon_evento.pl. Se não encontrar, continua a busca no diretório com os sufixos definidos no parâmetro pSufixoInfo do arquivo mtmon.conf.

55. Testes

checked
also checked
not checked
normal list item

checked
also checked
not checked
normal list item

Cell in column 1, row 1

Cell in column 2, row 1

Cell in column 1, row 2

Cell in column 2, row 2

Cell in column 1, row 3

Cell in column 2, row 3

56. Créditos

Este sistema usa software desenvolvido sob a GPL - The GNU General Public License:

asciidoctor

apache

perl logo

Asciidoctor

Apache Software Fundation

The Perl Foundation