Embed Size (px)
Citation preview
IBM
Tivoli
Enterprise
Console
Referência
a
Conjuntos
de
Regras
S517-7882-00
���
IBM
Tivoli
Enterprise
Console
Referência
a
Conjuntos
de
Regras
S517-7882-00
���
Nota
Antes
de
utilizar
estas
informações
e
o
produto
suportado
por
elas,
consulte
as
informações
nos
“Avisos”
na
página
77.
Primeira
Edição
(Agosto
de
2003)
Esta
edição
aplica-se
à
versão
3,
release
9
do
IBM
Tivoli
Enterprise
Console
(número
do
produto
5698-TEC)
e
a
todos
os
releases
e
modificações
subseqüentes,
até
que
seja
indicado
de
outra
forma
em
novas
edições.
©
Copyright
International
Business
Machines
Corporation
2003.
Todos
os
direitos
reservados.
Índice
Sobre
Este
Guia
.
.
.
.
.
.
.
.
.
.
. v
Quem
Deve
Ler
Este
Guia
.
.
.
.
.
.
.
.
.
. v
Publicações
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. v
Biblioteca
do
IBM
Tivoli
Enterprise
Console
.
.
. v
Publicações
Relacionadas
.
.
.
.
.
.
.
.
. vi
Acessando
Publicações
On-line
.
.
.
.
.
.
. vi
Solicitando
Publicações
.
.
.
.
.
.
.
.
. vii
Entrando
em
Contato
com
o
Suporte
de
Software
vii
Participando
de
Newsgroups
.
.
.
.
.
.
.
. vii
Convenções
Utilizadas
neste
Guia
.
.
.
.
.
. viii
Convenções
de
Tipo
de
Caractere
.
.
.
.
.
. viii
Variáveis
e
Caminhos
que
Dependem
do
Sistema
Operacional
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Introdução
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Modificando
a
Base
de
Regra
.
.
.
.
.
.
.
.
. 2
Ativando
e
Desativando
Conjuntos
de
Regras
.
. 3
Seqüenciamento
e
Dependências
do
Conjunto
de
Regras
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Conjunto
de
Regras
de
Limpeza
(cleanup.rls)
.
.
.
.
.
.
.
.
.
.
.
.
. 5
Conjunto
de
Regras
de
Correlação
(correlation.rls)
.
.
.
.
.
.
.
.
.
.
.
. 7
Conjunto
de
Regras
de
Limpeza
do
Banco
de
Dados
(db_cleanup.rls)
.
.
. 11
Conjunto
de
Regras
de
Dependência
(dependency.rls)
.
.
.
.
.
.
.
.
.
. 13
Conjunto
de
Regras
de
e-business
(ebusiness.rls)
.
.
.
.
.
.
.
.
.
.
. 15
Conjunto
de
Regras
de
Escala
(escalate.rls)
.
.
.
.
.
.
.
.
.
.
.
. 25
Conjunto
de
Regras
de
Atividade
do
Evento
(event_activity.rls)
.
.
.
.
.
. 29
Conjunto
de
Regras
de
Filtragem
de
Eventos
(event_filtering.rls)
.
.
.
.
.
. 31
Conjunto
de
Regras
de
Limite
de
Eventos
(event_thresholds.rls)
.
.
.
. 33
Conjunto
de
Regras
de
Encaminhamento
(forwarding.rls)
.
.
. 35
Conjunto
de
Regras
de
Pulsação
(heartbeat.rls)
.
.
.
.
.
.
.
.
.
.
.
. 37
Conjunto
de
Regras
do
Modo
de
Manutenção
(maintenance_mode.rls)
.
. 41
Conjunto
de
Regras
do
NetView
(netview.rls)
.
.
.
.
.
.
.
.
.
.
.
. 45
Conjunto
de
Regras
de
Notificação
(notify.rls)
.
.
.
.
.
.
.
.
.
.
.
.
. 63
Conjunto
de
Regras
HP
OpenView
(ov_default.rls)
.
.
.
.
.
.
.
.
.
.
. 65
Conjunto
de
Regras
de
Encaminhamento
de
Eventos
do
NetView
para
z/OS
(tecad_nv390fwd.rls)
.
.
.
.
.
.
.
.
. 67
Conjunto
de
Regras
de
Mensagens
do
NetView
para
z/OS
(tecad_nv390msg.rls)
.
.
.
.
.
.
.
. 69
Regras
de
Eventos
SNA
tecad_snaevent.rls
.
.
.
.
.
.
.
.
. 71
Conjunto
de
Regras
do
Registro
de
Problemas
(troubleticket.rls)
.
.
.
.
. 73
Avisos
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 77
Marcas
Comerciais
.
.
.
.
.
.
.
.
.
.
.
. 79
Índice
Remissivo
.
.
.
.
.
.
.
.
.
. 81
©
Copyright
IBM
Corp.
2003
iii
iv
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Sobre
Este
Guia
O
produto
IBM
Tivoli
Enterprise
Console
é
um
aplicativo
de
gerenciamento
de
eventos
baseado
em
regras
que
integra
o
gerenciamento
de
sistemas,
redes,
bancos
de
dados
e
aplicativos
para
ajudar
a
assegurar
uma
disponibilidade
mais
favorável
dos
serviços
de
TI
de
uma
organização.
O
IBM
Tivoli
Enterprise
Console
-
Referência
a
Conjuntos
de
Regras
fornece
informações
sobre
os
conjuntos
de
regras
fornecidos
para
processamento
de
eventos
comuns
de
aplicativos
e
de
infra-estrutura.
Quem
Deve
Ler
Este
Guia
Este
guia
destina-se
a
administradores
que
precisam
implementar
regras
para
automatizar
o
gerenciamento
de
eventos
do
Tivoli
Enterprise
Console
recebidos
pelo
servidor
de
eventos
Tivoli
Enterprise
Console.
Os
leitores
devem
estar
familiarizados
com
os
seguintes
tópicos:
v
Os
sistemas
operacionais
e
aplicativos
de
e-business
utilizados
por
sua
empresa
v
O
Tivoli
Management
Framework
v
O
produto
IBM
Tivoli
NetView
v
O
produto
IBM
Tivoli
Enterprise
Console
Publicações
Esta
seção
lista
as
publicações
da
biblioteca
do
IBM
Tivoli
Enterprise
Console
e
documentos
relacionados.
Ela
também
descreve
como
acessar
publicações
on-line
da
Tivoli
e
como
solicitar
publicações
Tivoli.
Biblioteca
do
IBM
Tivoli
Enterprise
Console
Os
seguintes
documentos
estão
disponíveis
na
biblioteca
do
IBM
Tivoli
Enterprise
Console:
v
IBM
Tivoli
Enterprise
Console
-
Guia
de
Adaptadores,
S517-7725
Fornece
informações
sobre
adaptadores
suportados,
incluindo
como
instalar
e
configurar
esses
adaptadores.
v
IBM
Tivoli
Enterprise
Console
-
Referência
a
Comandos
e
Tarefas,
S517-7727
Fornece
detalhes
sobre
comandos
do
IBM
Tivoli
Enterprise
Console,
tarefas
predefinidas
que
são
fornecidas
na
biblioteca
de
tarefas
e
as
variáveis
de
ambiente
que
estão
disponíveis
para
tarefas
que
são
executadas
em
um
evento.
v
IBM
Tivoli
Enterprise
Console
-
Guia
de
Instalação,
S517-7726
Descreve
como
instalar,
fazer
upgrade
e
desinstalar
o
produto
IBM
Tivoli
Enterprise
Console.
v
IBM
Tivoli
Enterprise
Console
-
Notas
sobre
o
Release,
S517-7729
Fornece
informações
específicas
do
release
que
estarão
disponíveis
apenas
quando
o
produto
estiver
prestes
a
ser
comercializado.
v
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide,
SC32-1234
Descreve
como
desenvolver
regras
e
integrá-las
para
correlação
de
eventos
e
gerenciamento
de
eventos
automatizado.
v
IBM
Tivoli
Enterprise
Console
-
Referência
a
Conjuntos
de
Regras,
S517-7882
©
Copyright
IBM
Corp.
2003
v
Fornece
informações
de
referência
sobre
os
conjuntos
de
regras
do
IBM
Tivoli
Enterprise
Console.
v
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário,
S517-7728
Fornece
uma
visão
geral
do
produto
IBM
Tivoli
Enterprise
Console
e
descreve
como
configurar
e
utilizar
o
produto
IBM
Tivoli
Enterprise
Console
para
gerenciar
eventos.
v
IBM
Tivoli
Enterprise
Console
Warehouse
Enablement
Pack:
Implementation
Guide,
SC32-1236
Descreve
como
instalar
e
configurar
o
warehouse
enablement
pack
para
o
produto
IBM
Tivoli
Enterprise
Console
e
descreve
o
fluxo
de
dados
e
estruturas
que
são
utilizados
pelo
warehouse
pack.
v
Tivoli
Event
Integration
Facility
-
Referência,
S517-7724
Descreve
como
desenvolver
seus
próprios
adaptadores
de
eventos
que
são
ajustados
para
seu
ambiente
de
rede
e
as
necessidades
específicas
de
sua
empresa.
Essa
referência
também
descreve
como
filtrar
eventos
na
origem.
Publicações
Relacionadas
v
IBM
Tivoli
Monitoring:
Guia
do
Usuário,
S517-7446
v
IBM
Tivoli
Monitoring
para
Business
Integration:
WebSphere
MQ:
Guia
do
Usuário,
G517-7484
v
IBM
Tivoli
Monitoring
for
Business
Integration:
WebSphere
MQ:
Reference
Guide,
GC23-4715
v
IBM
Tivoli
Monitoring
for
Databases:
DB2:
Guia
do
Usuário,
S517-7512
v
IBM
Tivoli
Monitoring
for
Databases:
DB2:
Reference
Guide,
SC23-4727
v
IBM
Tivoli
Monitoring
for
Web
Infrastructure:
WebSphere
Application
Server:
Guia
do
Usuário,
S517-7496
v
IBM
Tivoli
Monitoring
for
Web
Infrastructure:
Reference
Guide,
GC23-4720
O
Tivoli
Software
Glossary
inclui
definições
de
muitos
termos
técnicos
relacionados
ao
software
Tivoli.
OTivoli
Software
Glossary
está
disponível,
apenas
em
inglês,
no
seguinte
Web
site
da
biblioteca
de
software
Tivoli:
http://www.ibm.com/software/tivoli/library/
Acesse
o
glossário
clicando
no
link
Glossary
no
painel
esquerdo
da
janela
da
biblioteca
do
software
Tivoli.
Acessando
Publicações
On-line
O
CD
de
documentação
contém
as
publicações
que
estão
na
biblioteca
do
produto.
O
formato
das
publicações
é
e/ou
HTML.
Consulte
o
arquivo
readme
no
CD
para
obter
instruções
sobre
como
acessar
a
documentação.
A
IBM
lança
publicações
para
este
e
outros
produtos
Tivoli,
conforme
tornam-se
disponíveis
e
sempre
que
são
atualizados,
no
Web
site
do
Tivoli
Software
Information
Center.
Acesse
o
Tivoli
Software
Information
Center
acessando
primeiro
a
biblioteca
de
software
Tivoli
no
seguinte
endereço
da
Web:
http://www.ibm.com/software/tivoli/library/
Role
para
baixo
e
clique
no
link
Product
manuals.
Na
janela
Tivoli
Technical
Product
Documents
Alphabetical
Listing,
clique
no
link
IBM
Tivoli
Enterprise
Console
para
acessar
a
biblioteca
de
produtos
no
Tivoli
Information
Center.
vi
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Nota:
Se
você
imprimir
documentos
em
papel
que
não
seja
tamanho
carta,
selecione
a
caixa
de
opções
Fit
to
page
na
janela
de
Impressão
do
Adobe
Acrobat.
Essa
opção
fica
disponível
quando
você
clica
em
File
→
Print.
A
opção
Fit
to
page
garante
que
as
dimensões
totais
de
uma
página
tamanho
carta
sejam
impressas
no
papel
que
você
está
utilizando.
Solicitando
Publicações
Você
pode
pedir
várias
publicações
Tivoli
online
no
seguinte
Web
site:
http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi
Também
é
possível
solicitar
publicações
por
telefone
ligando
para
um
destes
números:
v
Nos
Estados
Unidos:
800-879-2755
v
No
Brasil:
0800-787-378
Em
outros
países,
consulte
o
seguinte
Web
site
para
obter
uma
lista
de
números
de
telefones:
http://www.ibm.com/software/tivoli/order-lit/
Entrando
em
Contato
com
o
Suporte
de
Software
Se
tiver
algum
problema
com
o
produto
Tivoli,
consulte
o
seguinte
Web
site
de
Suporte
ao
Software
IBM:
http://www.ibm.com/software/sysmgmt/products/support/
Se
desejar
entrar
em
contato
com
o
suporte
ao
software,
consulte
o
IBM
Software
Support
Guide
no
seguinte
Web
site:
http://techsupport.services.ibm.com/guides/handbook.html
O
guia
fornece
informações
sobre
como
entrar
em
contato
com
o
Suporte
ao
Software
IBM,
dependendo
da
gravidade
do
problema,
e
as
seguintes
informações:
v
Registro
e
elegibilidade
v
Números
de
telefone
e
endereços
de
e-mail,
dependendo
do
país
em
que
você
estiver
localizado
v
Informações
que
você
deve
ter
disponíveis
antes
de
entrar
em
contato
com
o
Suporte
ao
Software
IBM
Participando
de
Newsgroups
Os
grupos
de
usuários
fornecem
a
profissionais
de
software
um
fórum
para
a
troca
de
informações,
conhecimento
técnico
e
experiências
relacionadas
ao
produto.
Eles
estão
localizados
na
Internet
e
estão
disponíveis
através
de
programas
padrão
de
leitura
de
notícias.
Primeiramente,
esses
grupos
são
destinados
à
comunicação
usuário
a
usuário,
e
não
substituem
o
suporte
tradicional.
Para
acessar
um
newsgroup,
utilize
as
instruções
apropriadas
para
seu
navegador.
Utilize
estas
instruções
para
um
navegador
Microsoft
Internet
Explorer.
1.
Abra
um
navegador
Internet
Explorer.
Sobre
Este
Guia
vii
2.
No
menu
Ferramentas,
clique
em
Opções
da
Internet.
3.
Na
janela
Opções
da
Internet,
clique
na
guia
Programas.
4.
Na
lista
Grupos
de
notícias,
clique
na
Seta
para
baixo
e,
em
seguida,
clique
em
Outlook
Express.
5.
Clique
em
OK.
6.
Feche
o
navegador
Internet
Explorer
e,
em
seguida,
abra-o
novamente.
7.
Recorte
e
cole
o
endereço
do
newsgroup
de
um
produto
no
campo
Endereço
do
navegador
e
pressione
Enter
para
abrir
o
newsgroup.
Utilize
estas
instruções
para
um
navegador
Netscape
Navigator.
1.
Abra
um
navegador
Netscape
Navigator.
2.
No
menu
Edit,
clique
em
Preferences.
A
janela
Preferences
é
exibida.
3.
Na
exibição
Category,
clique
em
&
Newsgroups
para
exibir
as
definições
de
&
Newsgroups.
4.
Selecione
a
caixa
de
opções
Use
Netscape
as
the
default
application.
5.
Clique
em
OK.
6.
Feche
o
navegador
Netscape
Navigator
e,
em
seguida,
abra-o
novamente.
7.
Recorte
e
cole
o
endereço
do
newsgroup
de
um
produto
no
campo
Address
do
navegador
e
pressione
Enter
para
abrir
o
newsgroup.
IBM
Tivoli
Enterprise
Console
news://news.software.ibm.com/ibm.software.tivoli.enterprise-console
IBM
Tivoli
NetView
para
UNIX
e
IBM
Tivoli
NetView
para
Windows
news://news.software.ibm.com/ibm.software.tivoli.netview-unix-windows
Convenções
Utilizadas
neste
Guia
Este
guia
utiliza
diversas
convenções
para
termos
e
ações
especiais,
comandos
e
caminhos
dependentes
do
sistema
operacional
e
gráficos
de
margem.
Convenções
de
Tipo
de
Caractere
Este
guia
utiliza
as
seguintes
convenções
tipográficas:
Negrito
v
Comandos
em
minúsculas
e
comandos
que
misturem
letras
minúsculas
e
maiúsculas
que
possam
ser
difíceis
de
serem
distinguidos
do
texto
ao
redor
v
Controles
de
interface
(caixas
de
opções,
botões
de
comando,
botões
de
opções,
botões
de
rotação,
campos,
pastas,
ícones,
quadros
de
listagem,
itens
dentro
de
quadros
de
listagem,
listas
com
várias
colunas,
contêineres,
opções
de
menu,
nomes
de
menus,
guias,
folhas
de
propriedade),
rótulos
(como
Dica:
e
Considerações
sobre
o
sistema
operacional:)
v
Títulos
de
colunas
em
uma
tabela
v
Palavras-chave
e
parâmetros
em
um
texto
Itálico
v
Citações
(títulos
de
manuais,
disquetes
e
CDs)
v
Palavras
definidas
no
texto
viii
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
v
Ênfase
de
palavras
(palavras
como
palavras)
v
Letras
como
letras
v
Novos
termos
no
texto
(exceto
em
uma
lista
de
definições)
v
Variáveis
e
valores
que
você
deve
fornecer
Monoespaçado
v
Exemplos
e
códigos
de
exemplos
v
Nomes
de
arquivos,
palavras-chave
de
programação
e
outros
elementos
que
são
difíceis
de
serem
distinguidos
do
texto
ao
redor
v
Texto
de
mensagem
e
prompts
dirigidos
ao
usuário
v
Texto
que
o
usuário
deve
digitar
v
Valores
para
argumentos
ou
opções
de
comando
Variáveis
e
Caminhos
que
Dependem
do
Sistema
Operacional
Este
guia
utiliza
a
convenção
UNIX
para
especificar
variáveis
de
ambiente
e
para
notação
de
diretório.
Ao
utilizar
a
linha
de
comandos
Windows,
substitua
$variável
por
%
variável%
para
variáveis
de
ambiente
e
substitua
cada
barra
(/)
por
uma
barra
invertida
(
\)
nos
caminhos
de
diretório.
Nota:
Se
você
estiver
utilizando
o
shell
bash
em
um
sistema
Windows,
será
possível
utilizar
as
convenções
UNIX.
Sobre
Este
Guia
ix
x
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Introdução
O
mecanismo
de
regras
do
Tivoli
Enterprise
Console
processa
eventos
com
base
em
regras
escritas
na
linguagem
de
regras
do
Tivoli
Enterprise
Console.
Uma
regra
define
um
conjunto
de
ações
que
são
executadas
quando
determinadas
condições
são
atendidas;
essas
condições
podem
incluir
a
chegada
de
uma
determinada
classe
de
eventos
(ou
um
evento
com
determinados
valores
de
atributos),
alterações
em
um
evento
ou
a
finalização
de
um
cronômetro.
Consulte
o
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide
para
obter
informações
adicionais
sobre
regras
e
a
linguagem
de
regras.
Um
conjunto
de
regras
é
um
arquivo
que
contém
um
grupo
de
regras
relacionadas
logicamente,
escritas
na
linguagem
de
regras,
enquanto
uma
base
de
regra
é
uma
coleção
de
conjuntos
de
regras
compilados
e
que
suportam
dados
(incluindo
definições
de
classes
e
predicados
Prolog)
utilizados
por
esses
conjuntos
de
regras.
A
base
de
regras
padrão
fornecida
com
o
produto
Tivoli
Enterprise
Console
inclui
vários
conjuntos
de
regras
pré-configurados
que
fornecem
suporte
para
o
processamento
de
eventos
de
aplicativos
e
infra-estrutura
comuns.
Essas
regras
fornecem
potentes
recursos
de
detecção
de
duplicação,
filtragem,
escalada,
notificação
e
correlação
sem
requerer
desenvolvimento
de
regras
adicionais.
As
regras
incluídas
na
base
de
regras
padrão
fornecem
funções
que
incluem
(mas
não
estão
limitadas)
a:
v
Análise
causal
de
infra-estrutura
de
rede
e
de
eventos
de
aplicativos
de
e-business
baseada
em
relacionamentos
de
impacto
de
serviço
e
de
dependência
v
Programação
de
janelas
de
manutenção
e
descarte
de
eventos
de
sistemas
atualmente
em
manutenção
v
Integração
com
sistemas
externos
de
registro
de
problemas
v
Monitoração
de
pulsação
e
detecção
de
pulsações
não-correspondentes
Alguns
dos
conjuntos
de
regras
na
base
de
regras
padrão
já
estão
ativados,
enquanto
outros
devem
estar
ativados
antes
da
utilização.
Além
disso,
alguns
dos
conjuntos
de
regras
devem
estar
configurados
para
seu
ambiente.
Em
geral,
a
configuração
requer
apenas
a
modificação
de
parâmetros
globais
definidos
na
regra
de
configuração
no
início
do
conjunto
de
regras;
outros
conjuntos
de
regras
podem
requerer
a
configuração
de
arquivos
externos.
As
seções
de
referência
deste
manual
fornecem
informações
específicas
sobre
configuração
para
cada
conjunto
de
regras.
Os
arquivos
do
conjunto
de
regras
estão
localizados
no
diretório
da
base
de
regras
padrão
($BINDIR/TME/TEC/default_rb).
A
tabela
a
seguir
lista
todos
os
conjuntos
de
regras
na
base
de
regras
padrão
e
indica
quais
já
estão
ativados,
como
também
quais
requerem
configuração
antes
da
utilização.
Tabela
1.
Conjuntos
de
Regras
Incluídos
na
Base
de
Regras
Padrão
Conjunto
de
regras
Descrição
Ativado
Configuração
requerida
cleanup.rls
Fecha
antigos
eventos
abertos
Sim
Não
correlation.rls
Correlação
de
eventos
Não
Sim
db_cleanup.rls
Exclui
antigos
eventos
fechados
Não
Não
dependency.rls
Define
relacionamentos
de
dependência
para
regras
de
e-business
Sim
Não
©
Copyright
IBM
Corp.
2003
1
Tabela
1.
Conjuntos
de
Regras
Incluídos
na
Base
de
Regras
Padrão
(continuação)
Conjunto
de
regras
Descrição
Ativado
Configuração
requerida
ebusiness.rls
Análise
causal
de
eventos
de
aplicativos
de
e-business
Sim
Sim
escalate.rls
Escalada
de
gravidade
automática
Não
Não
event_activity.rls
Geração
de
relatórios
de
atividades
de
eventos
Não
Não
event_filtering.rls
Filtragem
de
eventos
indesejados
Não
Sim
event_thresholds.rls
Escalada
de
gravidade
baseada
em
eventos
repetidos
Não
Sim
forwarding.rls
Encaminhamento
de
eventos
Não
Sim
heartbeat.rls
Monitoração
de
pulsação
Sim
Não1
maintenance_mode.rls
Suporte
ao
modo
de
manutenção
Sim
Não
netview.rls
Limpeza
e
sincronização
de
eventos
da
rede
Sim
Não
notify.rls
Notificação
por
ou
pager
Não
Sim
ov_default.rls
Processamento
de
eventos
HP
OpenView
Não
Não
tecad_nv390fwd.rls
Encaminhamento
de
eventos
do
NetView
para
z/OS
Não
Sim
tecad_nv390msg.rls
Processamento
de
eventos
do
Adaptador
de
Mensagens
do
NetView
para
OS/390
Não
Não
tecad_snaevent.rls
Processamento
de
eventos
de
alerta
de
SNA
Não
Não
troubleticket.rls
Integração
com
sistemas
de
registro
de
problemas
Não
Sim
Notas:
1.
A
configuração
é
requerida
para
notificação
por
e-mail.
Modificando
a
Base
de
Regra
Você
não
pode
modificar
diretamente
a
base
de
regras
padrão
fornecida
com
o
produto
Tivoli
Enterprise
Console.
Se
desejar
fazer
alterações
nessa
base
de
regra
(incluindo
a
ativação
ou
desativação
de
conjuntos
de
regras,
modificação
de
conjuntos
de
regras
ou
alteração
de
destinos
da
base
de
regra),
primeiro
será
necessário
fazer
o
seguinte:
1.
Criar
uma
nova
base
de
regra
utilizando
o
comando
wrb
–crtrb.
2.
Copiar
a
base
de
regras
padrão
para
a
nova
base
de
regra
utilizando
o
comando
wrb
–cprb.
Por
padrão,
esse
comando
copia
os
conjuntos
de
regras,
arquivos
BAROC,
gabaritos
Prolog
e
destinos
da
base
de
regra.
Ele
também
copia
o
arquivo
rule_sets,
que
lista
os
conjuntos
de
regras
na
base
de
regra
e
indica
quais
estão
ativos
(consulte
“Ativando
e
Desativando
Conjuntos
de
Regras”
na
página
3
para
obter
informações
adicionais).
Após
realizar
uma
cópia
da
base
de
regras
padrão,
será
possível
fazer
as
alterações
desejadas
na
cópia.
Em
geral,
siga
estas
etapas
para
modificar
a
base
de
regras:
1.
Faça
as
alterações
necessárias,
incluindo
qualquer
uma
das
seguintes:
v
Ativação
ou
desativação
de
conjuntos
de
regras
(consulte
“Ativando
e
Desativando
Conjuntos
de
Regras”
na
página
3)
v
Edição
do
conjunto
de
regras
ou
arquivos
BAROC
2
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
v
Criação
ou
exclusão
de
destinos
de
base
de
regras
utilizando
os
comandos
wrb
–crttarget
e
wrb
–delrbtarget
v
Importação
ou
exclusão
de
conjuntos
de
regras
em
destinos
de
base
de
regras
utilizando
os
comandos
wrb
–imptgtrule
e
wrb
–deltgtrule
2.
Compile
a
nova
base
de
regras
utilizando
o
comando
wrb
–comprules.
3.
Carregue
a
nova
base
de
regras
utilizando
o
comando
wrb
–loadrb.
Consulte
o
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide
para
obter
informações
adicionais
sobre
como
trabalhar
com
bases
de
regras
e
o
IBM
Tivoli
Enterprise
Console
-
Referência
a
Comandos
e
Tarefas
para
obter
informações
adicionais
sobre
o
comando
wrb.
Ativando
e
Desativando
Conjuntos
de
Regras
O
arquivo
rule_sets,
localizado
no
subdiretório
TEC_RULES
de
cada
base
de
regra,
lista
todos
os
conjuntos
de
regras
incluídos
nessa
base
de
regra.
Ele
também
indica
quais
conjuntos
de
regras
estão
ativos
e
quais
estão
inativos.
Todos
os
conjuntos
de
regras
listados
em
rule_sets
são
considerados
parte
da
base
de
regra
e
são
incluídos
quando
a
base
de
regra
é
copiada.
No
entanto,
apenas
os
conjuntos
de
regras
ativos
podem
ser
importados
para
destinos
da
base
de
regras.
O
conteúdo
do
arquivo
rule_sets
consiste
em
uma
série
de
instruções
Prolog,
cada
uma
no
seguinte
formato:
rule_set(label,
filename,
status).
Em
cada
instrução,
label
é
o
nome
utilizado
para
identificar
o
conjunto
de
regras
no
arquivo
de
rastreio,
filename
é
o
nome
do
arquivo
RLS
do
conjunto
de
regras
e
status
é
active
ou
inactive.
Por
exemplo,
a
instrução
a
seguir
define
dois
conjuntos
de
regras,
um
ativo
e
um
inativo:
rule_set(maintenance_mode,
’maintenance_mode.rls’,
active).
rule_set(correlation,
’correlation.rls’,
inactive).
Para
ativar
ou
desativar
conjuntos
de
regras,
siga
estas
etapas
(observe
que
você
não
pode
fazer
alterações
diretamente
na
base
de
regras
padrão;
consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais):
1.
Utilizando
um
editor
de
texto,
modifique
as
instruções
correspondentes
no
arquivo
rule_sets,
especificando
a
palavra-chave
active
ou
inactive,
conforme
apropriado.
2.
Se
estiver
ativando
conjuntos
de
regras,
utilize
o
comando
wrb
–imptgtrule
para
importar
esses
conjuntos
de
regras
para
um
ou
mais
destinos
da
base
de
regras.
3.
Se
estiver
desativando
conjuntos
de
regras,
utilize
o
comando
wrb
–deltgtrule
para
excluir
esses
conjuntos
de
regras
de
quaisquer
destinos
da
base
de
regras
que
os
contenham.
4.
Compile
novamente
a
base
de
regras
utilizando
o
comando
wrb
–comprules.
5.
Recarregue
a
base
de
regras
utilizando
o
comando
wrb
–loadrb.
Consulte
o
IBM
Tivoli
Enterprise
Console
-
Referência
a
Comandos
e
Tarefas
para
obter
informações
adicionais
sobre
o
comando
wrb.
Seqüenciamento
e
Dependências
do
Conjunto
de
Regras
O
mecanismo
de
regras
processa
os
conjuntos
de
regras
ativos
na
ordem
em
que
são
listados
no
arquivo
rule_sets
e,
em
alguns
casos,
esse
seqüenciamento
é
importante.
Além
disso,
alguns
conjuntos
de
regras
dependem
de
funções
de
Introdução
3
suporte
fornecidas
por
outros
conjuntos
de
regras.
Quando
fizer
alterações
no
arquivo
rule_sets,
considere
as
seguintes
diretrizes:
v
O
conjunto
de
regras
de
filtragem
de
eventos
(event_filtering.rls)
deve
estar
próximo
do
início
da
seqüência,
preferencialmente
na
primeira
posição.
Isso
evita
o
processamento
desnecessário
de
eventos
que
devem
ser
filtrados
por
esse
conjunto
de
regras.
v
O
conjunto
de
regras
do
modo
de
manutenção
(maintenance_mode.rls)
deve
estar
próximo
do
início
da
seqüência,
de
preferência,
imediatamente
após
event_filtering.rls.
Isso
evita
o
processamento
desnecessário
de
eventos
enviados
de
sistemas
no
modo
de
manutenção.
v
O
conjunto
de
regras
de
correlação
(correlation.rls)
deve
estar
próximo
do
final
da
seqüência.
Isso
assegura
que
quaisquer
regras
de
correlação
específicas
de
eventos
sejam
executadas
antes
das
regras
de
correlação
de
finalidade
geral.
v
O
conjunto
de
regras
de
correlação
(escalate.rls)
deve
estar
próximo
do
final
da
seqüência
e
deve
aparecer
após
correlation.rls.
Isso
assegura
que
as
gravidades
de
eventos
possam
ser
ajustadas
de
forma
apropriada,
após
a
ocorrência
de
outro
processamento.
v
O
conjunto
de
regras
de
e-business
(ebusiness.rls)
deve
estar
próximo
do
final
da
seqüência
e
deve
aparecer
após
o
conjunto
de
regras
NetView
(netview.rls)
e
quaisquer
outros
conjuntos
de
regras
que
processam
eventos
de
serviços
de
e-business
monitorados
por
produtos
IBM
Tivoli
Monitoring.
v
O
conjunto
de
regras
de
notificação
(notify.rls)
deve
estar
próximo
do
final
da
seqüência,
preferencialmente
na
última
posição.
Isso
assegura
que
a
notificação
seja
baseada
nas
informações
mais
atuais
sobre
o
evento.
v
O
conjunto
de
regras
de
escala
(escalate.rls)
depende
do
conjunto
de
regras
de
notificação
(notify.rls)
para
fornecer
notificação
por
de
eventos
escalados.
Se
desejar
utilizar
essa
função,
os
dois
conjuntos
de
regras
devem
ser
ativados.
v
O
conjunto
de
regras
de
e-business
(ebusiness.rls)
depende
do
conjunto
de
regras
de
dependência
(dependency.rls),
que
suporta
a
definição
de
relacionamentos
de
dependência.
Se
desejar
utilizar
as
regras
de
e-business,
os
dois
conjuntos
de
regras
devem
ser
ativados.
v
O
conjunto
de
regras
de
e-business
(ebusiness.rls)
gera
eventos
de
pulsação
não-correspondentes
em
resposta
a
alguns
eventos
da
rede.
Se
desejar
que
esses
eventos
sejam
tratados
corretamente,
o
conjunto
de
regras
de
pulsação
(heartbeat.rls)
também
deve
ser
ativado.
v
O
conjunto
de
regras
NetView
(netview.rls)
correlaciona
eventos
de
pulsação
com
outros
eventos
da
rede.
Se
desejar
que
ocorra
essa
correlação,
o
conjunto
de
regras
de
pulsação
(heartbeat.rls)
também
deverá
ser
ativado.
4
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Limpeza
(cleanup.rls)
Visão
Geral
O
conjunto
de
regras
de
limpeza
contém
as
regras
utilizadas
para
limpar
antigos
eventos
abertos
do
cache
de
eventos.
Em
geral,
os
eventos
que
permanecem
abertos
por
muito
tempo
sem
estar
sendo
abordados
devem
ser
fechados,
na
suposição
de
que
foram
resolvidos
ou,
de
outra
forma,
tornaram-se
inativos.
Geralmente,
uma
regra
desse
tipo
seria
aplicada
apenas
a
eventos
com
baixa
gravidade;
por
exemplo,
talvez
você
queira
fechar
automaticamente
qualquer
evento
HARMLESS
ou
UNKNOWN
que
tenha
permanecido
no
estado
OPEN
por
mais
de
48
horas.
Personalizando
esse
conjunto
de
regras,
você
pode
especificar
quais
eventos
deseja
fechar
e
quanto
tempo
deseja
aguardar
antes
de
fechá-los.
Uso
O
conjunto
de
regras
de
limpeza
já
está
ativado
na
base
de
regras
padrão.
Se
você
fizer
alterações
nesse
conjunto
de
regras,
então
é
necessário
recompilar
e
recarregar
a
base
de
regras.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
mais
informações.
Configuração
Opcional
O
conjunto
de
regras
de
limpeza
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
esse
conjunto
de
regras
modificando
instruções
na
regra
de
configuração
cleanup_start.
As
opções
a
seguir
são
configuráveis:
v
Limite
de
duração
para
eventos
abertos.
Você
pode
especificar
o
valor
de
tempo
limite
que
controla
qual
deve
ser
a
duração
de
eventos
abertos
antes
de
serem
fechados
automaticamente.
O
limite
de
duração
padrão
é
de
48
horas.
Para
alterar
o
limite
de
duração,
modifique
a
instrução
que
define
o
parâmetro
_default_span,
da
seguinte
forma:
_default_span
=
seconds,
seconds
é
o
período
de
tempo,
em
segundos,
que
você
deseja
permitir
que
os
eventos
permaneçam
abertos
antes
de
serem
automaticamente
fechados.
v
Freqüência
de
limpeza.
Você
pode
especificar
a
freqüência
com
que
deseja
que
as
regras
verifiquem
eventos
antigos
a
serem
fechados.
A
freqüência
padrão
é
a
cada
30
minutos.
Para
alterar
a
freqüência
de
limpeza,
modifique
a
instrução
que
define
o
parâmetro
_cleanup_interval,
da
seguinte
forma:
_cleanup_interval
=
seconds
seconds
é
o
período
de
tempo
desejado,
em
segundos,
entre
as
limpezas.
v
Gravidades
de
eventos
a
serem
fechados.
Você
pode
especificar
as
gravidades
de
eventos
que
deseja
que
sejam
fechados
imediatamente
quando
eles
alcançarem
a
duração
especificada.
O
comportamento
padrão
é
fechar
eventos
com
gravidades
de
HARMLESS
ou
UNKNOWN.
Para
alterar
esse
valor,
modifique
a
instrução
que
define
o
parâmetro
cleanup_list,
da
seguinte
forma:
_cleanup_list
=
[ev_sevs],
©
Copyright
IBM
Corp.
2003
5
ev_sevs
é
uma
lista
de
gravidades
de
eventos
válidas,
cada
uma
entre
aspas
simples
e
separadas
por
vírgulas.
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
as
regras
de
limpeza
fecharem
eventos
automaticamente.
O
nome
do
administrador
padrão
é
cleanup.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
o
parâmetro
cleanup_admin,
da
seguinte
forma:
_cleanup_admin
=
admin,
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
Regras
Regra
de
Inicialização
regra:
cleanup_start
A
regra
cleanup_start
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
parâmetros
globais
para
as
regras
de
limpeza
e,
em
seguida,
define
o
cronômetro
de
Limpeza
com
a
duração
especificada
pelo
parâmetro
_cleanup_interval.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
limpeza.
Consulte
“Uso”
na
página
5
para
mais
informações.
Regras
de
Limpeza
regra:
do_the_cleanup
A
regra
do_the_cleanup
é
executada
durante
o
recebimento
do
evento
TEC_Cleanup_event,
que
é
gerado
pela
regra
do
cronômetro
cleanup_old_events
para
acionar
limpezas
periódicas.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
os
eventos
abertos
que
correspondem
aos
critérios
de
limpeza
especificados
na
regra
cleanup_start.
Os
eventos
correspondentes
são
fechados.
O
evento
TEC_Cleanup_event
recebido
é
eliminado.
regra
do
cronômetro:
cleanup_old_events
A
regra
do
cronômetro
cleanup_old_events
é
executada
durante
a
expiração
do
cronômetro
de
Limpeza.
Essa
regra
gera
um
evento
TEC_Cleanup_event,
que
aciona
a
regra
do_the_cleanup.
Em
seguida,
ela
redefine
o
cronômetro
de
Limpeza
com
a
duração
especificada
pelo
parâmetro
_cleanup_interval
na
regra
de
configuração.
6
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Correlação
(correlation.rls)
Visão
Geral
O
conjunto
de
regras
de
correlação
contém
regras
que
correlacionam
eventos
de
entrada
com
base
em
relacionamentos
definidos
anteriormente.
Existem
dois
tipos
de
possíveis
relacionamentos:
Eventos
de
limpeza
Um
evento
de
limpeza
é
um
evento
que
resolve
um
evento
de
problema
anterior.
Por
exemplo,
um
evento
de
classe
Su_Failure
pode
ser
limpo
por
Su_Success
a
partir
do
mesmo
host
e
usuário.
Seqüências
de
eventos
Uma
seqüência
de
eventos
é
uma
série
de
eventos
que
estão
vinculados
por
relacionamentos
causais.
Em
uma
seqüência
de
eventos,
cada
evento
é
um
efeito
de
um
evento
anterior.
Por
exemplo,
o
evento
upsOnBattery
(indicando
que
uma
fonte
de
alimentação
ininterrupta
está
operando
com
a
energia
da
bateria)
pode
ser
a
causa
principal
de
uma
seqüência
de
eventos
que
também
inclui
o
evento
lowBattery
e,
finalmente,
o
evento
upsDischarged.
Uso
O
conjunto
de
regras
de
correlação
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Nota:
Se
ativado,
o
conjunto
de
regras
de
correlação
deve
ser
listado
próximo
do
final
do
arquivo
rule_sets.
Consulte
“Seqüenciamento
e
Dependências
do
Conjunto
de
Regras”
na
página
3
para
mais
informações.
Antes
de
utilizar
esse
conjunto
de
regras,
também
pode
ser
necessário
modificar
a
ação
correlation_parameters
da
regra
correlation_configure
para
definir
os
eventos
de
limpeza
e
as
seqüências
de
eventos
com
as
quais
você
deseja
que
as
regras
sejam
correlacionadas.
Para
definir
um
evento
de
limpeza,
utilize
o
predicado
create_clearing_event;
para
definir
uma
seqüência
de
eventos,
utilize
o
predicado
create_event_sequence
(consulte
o
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide
para
obter
informações
adicionais
sobre
estes
predicados).
Os
eventos
de
limpeza
e
as
seqüências
de
eventos
podem
ser
definidos
nesse
conjunto
de
regras
ou
em
qualquer
outro
conjunto
de
regras
ativo.
Nota:
Após
modificar
esse
conjunto
de
regras,
você
deve
recompilar
e
recarregar
a
base
de
regra.
Configuração
Opcional
Você
pode
personalizar
o
conjunto
de
regras
de
correlação
modificando
as
instruções
na
ação
correlation_parameters
da
regra
correlation_configure.
As
opções
a
seguir
são
configuráveis:
v
Latência.
Você
pode
especificar
o
intervalo
de
tempo,
ou
latência,
a
ser
utilizada
ao
pesquisar
no
cache
de
eventos
os
eventos
a
serem
correlacionados.
Por
padrão,
as
pesquisas
são
limitadas
em
dez
minutos
(600
segundos)
de
retrocesso
©
Copyright
IBM
Corp.
2003
7
no
cache
de
eventos.
Para
alterar
a
latência,
modifique
a
instrução
que
define
o
parâmetro
_correlation_time_window,
da
seguinte
forma:
_correlation_time_window
=
seconds,
seconds
é
o
número
de
segundos
que
representa
o
quanto
você
deseja
retroceder
para
pesquisar
eventos
no
cache.
Nota:
Esse
parâmetro
define
um
limite
superior
sobre
quanto
tempo
a
pesquisa
retrocederá,
mas
isso
não
garante
que
os
eventos
nesse
período
de
tempo
ainda
estarão
disponíveis.
Se
o
cache
de
eventos
for
muito
pequeno,
os
eventos
poderão
ser
descartados,
mesmo
se
forem
mais
recentes
do
que
o
tempo
especificado.
Se
isso
ocorrer,
aumente
o
tamanho
do
cache
de
eventos
(consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais).
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
confirmar
o
recebimento
ou
fechar
automaticamente
os
eventos.
O
nome
do
administrador
padrão
é
correlation.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
o
parâmetro
_correlation_admin,
da
seguinte
forma:
_correlation_admin
=
admin,
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
Regras
Regra
de
Inicialização
regra:
correlation_configure
A
regra
correlation_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
os
eventos
de
limpeza
e
as
seqüências
de
eventos
que
estão
correlacionados
pelas
regras
de
correlação;
ela
também
configura
o
parâmetro
_correlation_time_window,
que
define
a
latência
utilizada
para
pesquisas
de
eventos.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
correlação.
Consulte
“Uso”
na
página
7
para
mais
informações.
Regras
de
Correlação
regra:
clearing_event
A
regra
clearing_event
é
executada
durante
o
recebimento
de
qualquer
evento.
Se
o
evento
recebido
tiver
sido
definido
como
um
evento
de
limpeza
(utilizando
o
predicado
create_clearing_event),
os
eventos
limpos
no
cache
de
eventos
recebidos
na
janela
de
tempo
definida
pelo
parâmetro
_correlation_time_window
serão
fechados.
regra:
correlate
A
regra
correlate
é
executada
durante
o
recebimento
de
qualquer
evento.
Se
o
evento
recebido
tiver
sido
definido
como
parte
de
uma
seqüência
de
eventos,
a
regra
utilizará
o
predicado
first_related_event
para
pesquisar
no
cache
de
eventos
um
evento
relacionado
recebido
na
janela
de
tempo,
definida
pelo
parâmetro
_correlation_time_window.
Se
for
detectado
que
o
evento
recebido
é
um
efeito
de
um
evento
de
causa
recebido
anteriormente,
ele
será
correlacionado
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause.
O
evento
recebido
é
confirmado,
pois
ele
é
um
efeito
de
uma
causa
conhecida.
8
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Se
for
detectado
que
o
evento
recebido
é
uma
causa
de
um
evento
recebido
anteriormente,
o
evento
de
efeito
será
correlacionado
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause.
É
confirmado
o
recebimento
do
evento
de
efeito,
pois
ele
é
um
efeito
do
evento
de
causa
recebido
recentemente.
Conjunto
de
Regras
de
Correlação
(correlation.rls)
9
10
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Limpeza
do
Banco
de
Dados
(db_cleanup.rls)
Visão
Geral
O
conjunto
de
regras
de
limpeza
do
banco
de
dados
exclui
periodicamente
eventos
antigos
fechados
do
banco
de
dados
do
Tivoli
Enterprise
Console.
Esse
conjunto
de
regras
utiliza
uma
regra
do
cronômetro
para
gerar
periodicamente
eventos
DB_Cleanup_event.
Esses
eventos
também
podem
ser
enviados
de
outras
origens,
se
você
desejar
acionar
explicitamente
uma
limpeza
do
banco
de
dados.
Quando
o
DB_Cleanup_event
é
recebido,
o
comando
wtdbclear
é
utilizado
para
excluir
eventos
antigos
fechados
do
repositório
de
eventos,
do
repositório
de
tarefas,
da
tabela
de
atributos
de
eventos
estendidos
e
do
log
de
recepção.
Consulte
o
IBM
Tivoli
Enterprise
Console
-
Referência
a
Comandos
e
Tarefas
para
obter
informações
adicionais
sobre
o
comando
wtdbclear.
Uso
O
conjunto
de
regras
de
limpeza
do
banco
de
dados
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Configuração
Opcional
Você
pode
personalizar
o
conjunto
de
regras
de
limpeza
do
banco
de
dados
modificando
o
intervalo
do
cronômetro
que
determina
a
freqüência
em
que
ocorre
a
limpeza
do
banco
de
dados.
O
intervalo
padrão
é
uma
hora
(3600
segundos).
Para
alterar
esse
intervalo,
modifique
a
instrução
na
regra
db_cleanup_start
que
define
o
parâmetro
_cleanup_timer,
da
seguinte
forma:
_cleanup_timer
=
seconds,
seconds
é
o
período
de
tempo
(em
segundos)
que
você
deseja
que
passe
entre
limpezas
do
banco
de
dados.
Regras
Regra
de
Inicialização
regra:
db_cleanup_start
A
regra
db_cleanup_start
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
primeiro
o
parâmetro
_cleanup_timer
e,
em
seguida,
inicia
o
cronômetro
DB_Cleanup,
que
é
utilizado
para
gerar
periodicamente
eventos
DB_Cleanup_event.
Personalizando
essa
regra,
você
pode
configurar
a
duração
do
cronômetro
de
limpeza.
Consulte
“Uso”
para
mais
informações.
Regras
de
Limpeza
do
Banco
de
Dados
regra:
do_the_DB_cleanup
A
regra
do_the_DB_cleanup
é
executada
durante
o
recebimento
do
evento
DB_Cleanup_event.
Esse
evento
é
gerado
periodicamente
pela
regra
do
cronômetro
©
Copyright
IBM
Corp.
2003
11
time_to_cleanup_the_database
e
também
é
gerado
a
partir
de
outras
origens
para
acionar
uma
limpeza
do
banco
de
dados.
Quando
esse
evento
é
recebido,
a
regra
utiliza
o
seguinte
comando
para
excluir
eventos
fechados
que
são
anteriores
ao
período
de
tempo
especificado
pelo
parâmetro
_cleanup_timer
na
regra
de
configuração:
wtdbclear
-e
-l
-s
CLOSED
-t
seconds
-a
1000
seconds
é
o
valor
do
parâmetro
_cleanup_timer.
O
evento
recebido
DB_Cleanup_event
é
então
fechado.
regra
do
cronômetro:
time_to_cleanup_the_database
A
regra
do
cronômetro
time_to_cleanup_the_database
é
executada
quando
o
cronômetro
DB_Cleanup
expira.
Essa
regra
gera
um
evento
DB_Cleanup_event
para
acionar
a
regra
do_the_DB_cleanup.
Em
seguida,
ela
redefine
o
cronômetro.
12
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Dependência
(dependency.rls)
Visão
Geral
O
conjunto
de
regras
de
dependência
contém
regras
que
suportam
a
definição
de
relacionamentos
de
dependência
utilizados
pelo
conjunto
de
regras
de
e-business
(ebusiness.rls).
Essas
regras
processam
eventos
TEC_Dependency,
que
são
enviados
pelos
comandos
wrb
–imptdp
e
wrb
–deldp.
Consulte
“Conjunto
de
Regras
de
e-business
(ebusiness.rls)”
na
página
15
para
obter
informações
adicionais
sobre
relacionamentos
de
dependência.
Uso
O
conjunto
de
regras
de
dependência
já
está
ativado
na
base
de
regras
padrão.
Se
você
fizer
alterações
nesse
conjunto
de
regras,
então
é
necessário
recompilar
e
recarregar
a
base
de
regras.
Esse
conjunto
de
regras
deve
estar
ativo
se
o
conjunto
de
regras
de
e-business
estiver
ativo.
Nota:
Esse
conjunto
de
regras
fornece
suporte
requerido
para
o
conjunto
de
regras
de
e-business
(ebusiness.rls).
Se
o
conjunto
de
regras
de
e-business
estiver
ativo,
o
conjunto
de
regras
de
dependência
também
deve
estar
ativo.
Para
assegurar
o
funcionamento
correto
das
regras
de
e-business,
não
faça
alterações
nesse
conjunto
de
regras
separadamente
dos
parâmetros
de
configuração
opcionais
descritos
abaixo.
Configuração
Opcional
O
conjunto
de
regras
de
dependência
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
esse
conjunto
de
regras
modificando
as
instruções
na
ação
setup
da
regra
de
configuração
startup.
As
opções
a
seguir
são
configuráveis:
v
Nome
do
arquivo
de
fatos
de
dependência.
Você
pode
especificar
o
nome
do
arquivo
Prolog
que
é
utilizado
para
armazenar
fatos
de
dependência
na
base
de
conhecimento.
Você
pode
especificar
uma
localização
absoluta
para
o
arquivo
ou
especificar
apenas
o
nome
do
arquivo,
nesse
caso,
o
arquivo
será
criado
no
diretório
$DBDIR.
O
nome
do
arquivo
padrão
é
dependencies.pro.
Para
especificar
um
nome
de
arquivo
diferente,
modifique
a
instrução
que
define
o
parâmetro
_dependency_file,
da
seguinte
forma:
_dependency_file
=
filename,
filename
é
o
nome
do
arquivo
de
fatos
Prolog
que
você
deseja
utilizar,
opcionalmente,
incluindo
um
caminho
relativo
ou
absoluto,
e
colocado
entre
aspas
simples.
v
Registro
de
depuração.
Você
pode
especificar
se
deseja
depurar
as
informações
de
depuração
em
um
arquivo
de
log.
Isso
pode
ser
útil
se
você
estiver
modificando
o
conjunto
de
regras.
Essa
função
deve
ser
desativada
sempre
antes
de
o
conjunto
de
regras
ser
implementado
em
um
ambiente
de
produção,
pois
afeta
o
desempenho.
Para
alterar
esse
comportamento,
modifique
a
instrução
que
define
o
parâmetro
_dependency_debug,
da
seguinte
forma:
_dependency_debug
=
flag,
flag
é
’yes’
ou
’no’.
©
Copyright
IBM
Corp.
2003
13
v
Nome
do
arquivo
do
log
de
depuração.
Você
pode
especificar
o
nome
do
arquivo
utilizado
para
registrar
mensagens
de
depuração.
Esse
arquivo
será
utilizado
apenas
se
_dependency_debug
estiver
definido
como
yes.
Você
pode
especificar
uma
localização
absoluta
para
o
arquivo
ou
especificar
apenas
o
nome
do
arquivo,
nesse
caso,
o
arquivo
será
criado
no
diretório
$DBDIR.
O
valor
padrão
é
dependency.log.
Para
especificar
um
arquivo
diferente,
modifique
a
instrução
que
define
o
parâmetro
dependency_logger
da
seguinte
forma:
_dependency_logger
=
filename,
filename
é
o
nome
do
arquivo
de
log
que
você
deseja
utilizar,
opcionalmente,
incluindo
um
caminho
relativo
ou
absoluto,
e
colocado
entre
aspas
simples.
Regras
Regras
Startup
e
Shutdown
regra:
startup
A
regra
startup
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
primeiro
carrega
os
predicados
auxiliares
utilizados
pelas
regras
de
dependência
e
por
relacionamentos
de
dependência
persistentes
definidos
anteriormente;
em
seguida,
ela
define
parâmetros
globais
para
as
regras
de
dependência
e
inicializa
os
arquivos
de
log
para
o
conjunto
de
regras.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
dependência.
Consulte
“Uso”
na
página
13
para
mais
informações.
regra:
Shutdown
A
regra
shutdown
é
executada
no
recebimento
do
evento
TEC_Stop,
que
é
enviado
quando
o
servidor
de
eventos
é
encerrado.
Essa
regra
fecha
os
arquivos
de
log
abertos
para
o
conjunto
de
regras.
Regra
de
Processamento
de
Dependência
regra:
process_op
A
regra
process_op
processa
eventos
TEC_Dependency,
que
são
enviados
pelos
comandos
wrb
–imptdp
e
wrb
–deldp.
Quando
esse
evento
é
recebido,
a
regra
atualiza
a
base
de
conhecimento
de
dependência
de
acordo
(confirmando
ou
retirando
um
fato
de
dependência)
e,
em
seguida,
elimina
o
evento.
14
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
e-business
(ebusiness.rls)
Visão
Geral
O
conjunto
de
regras
de
e-business
analisa
eventos
relacionados
aos
recursos
de
e-business
para
determinar
se
eles
estão
causalmente
relacionados
uns
aos
outros
ou
aos
eventos
da
rede.
Essa
análise
depende
dos
relacionamentos
de
dependência
armazenados
como
fatos
na
base
de
conhecimento.
Esses
relacionamentos
definem
dependências
entre
serviços
de
e-business
em
execução
em
diferentes
hosts
em
seu
ambiente.
Os
serviços
de
e-business
suportados
incluem
os
fornecidos
pelos
softwares
IBM
WebSphere
Application
Server,
IBM
DB2
e
IBM
WebSphere
MQ.
Esses
serviços
freqüentemente
dependem
da
disponibilidade
de
outros
serviços
de
e-business.
Os
serviços
do
WebSphere
Application
Server
em
um
host
podem
depender
da
disponibilidade
dos
serviços
do
DB2
em
outro
host.
Da
mesma
forma,
cada
um
dos
dois
hosts
do
WebSphere
MQ
interconectados
depende
da
disponibilidade
do
outro.
Utilizando
o
conjunto
de
regras
de
e-business,
você
pode
identificar
essas
dependências,
permitindo
que
o
mecanismo
de
regras
identifique
relacionamentos
causais
entre
eventos
recebidos
desses
serviços
(consulte
“Uso”
na
página
18
para
obter
informações
sobre
estes
relacionamentos).
No
momento,
são
suportados
dois
tipos
de
relacionamentos
de
dependência:
WMQ_DEPENDS_ON_WMQ
Indica
que
um
recurso
do
WebSphere
MQ
em
um
host
depende
de
um
recurso
do
WebSphere
MQ
em
outro
host.
WAS_DEPENDS_ON_DB2
Indica
que
um
recurso
do
WebSphere
Application
Server
em
um
host
depende
de
um
recurso
do
DB2
em
outro
host
ou
no
mesmo
host.
Por
exemplo,
suponha
que
o
host
appserver
esteja
executando
serviços
do
WebSphere
Application
Server
que
dependem
de
serviços
do
DB2
no
host
dbserver.
Nesse
caso,
defina
o
fato
de
dependência
indicando
um
relacionamento
WAS_DEPENDS_ON_DB2
entre
os
dois
hosts.
Se
o
servidor
de
eventos
receber
um
evento
indicando
um
problema
com
os
serviços
do
DB2
no
dbserver
e,
posteriormente,
receber
um
evento
indicando
um
problema
de
disponibilidade
do
banco
de
dados
com
os
serviços
do
WebSphere
Application
Server
no
appserver,
é
provável
que
o
problema
do
DB2
seja
a
causa
do
problema
do
WebSphere
Application
Server.
Como
a
base
de
conhecimento
contém
um
fato
de
dependência
que
descreve
esse
relacionamento,
o
servidor
de
eventos
pode
associar
automaticamente
os
dois
eventos
como
causalmente
relacionados.
Da
mesma
forma,
o
servidor
de
eventos
pode
identificar
outros
eventos
de
causa
que
podem
afetar
a
disponibilidade
do
dbserver,
como
por
exemplo,
eventos
da
rede
de
impacto
de
serviços
e
eventos
de
manutenção.
©
Copyright
IBM
Corp.
2003
15
Além
disso,
as
regras
de
e-business
podem,
opcionalmente,
gerar
eventos
informativos
de
causa
provável
em
casos
nos
quais
um
provável
relacionamento
causal
é
encontrado,
mas
não
pode
ser
correspondido
a
um
fato
de
dependência
definido.
Isso
pode
acontecer
se
não
for
definido
nenhum
relacionamento
de
dependência
para
os
hosts
envolvidos,
ou
se
o
componente
NetView
não
estiver
configurado
para
gerar
eventos
de
impacto
de
serviços.
A
tabela
a
seguir
resume
as
categorias
de
possíveis
eventos
de
efeito
e
de
causa
(para
obter
informações
detalhadas
sobre
eventos
de
causa
e
efeito
específicos,
consulte
“Regras”
na
página
21).
Tabela
2.
Categorias
de
Eventos
de
Causa
e
de
Efeito
para
as
Regras
de
e-business
Eventos
de
efeito
Eventos
de
causa
e-business
rede
manutenção
Eventos
do
WebSphere
Application
Server
Eventos
do
DB2
Eventos
de
impacto
de
serviços
do
nó
NetView
(serviços
do
DB2)
TEC_Maintenance
Eventos
do
WebSphere
MQ
Eventos
do
WebSphere
MQ
Eventos
de
impacto
de
serviços
do
nó
do
NetView
(serviços
do
WebSphere
MQ)
Os
eventos
de
e-business
analisados
pelas
regras
de
e-business
são
gerados
pelos
seguintes
produtos:
v
IBM
Tivoli
Monitoring
for
Business
Integration:
WebSphere
MQ
(eventos
do
WebSphere
MQ)
v
IBM
Tivoli
Monitoring
for
Web
Infrastructure:
WebSphere
Application
Server
(eventos
do
WebSphere
Application
Server)
v
IBM
Tivoli
Monitoring
for
Databases:
DB2
(eventos
do
DB2)
Para
obter
informações
adicionais
sobre
eventos
de
e-business,
consulte
a
documentação
para
esses
produtos.
Além
de
associar
eventos
de
ebusiness
e
da
rede
causalmente
relacionados,
as
regras
de
e-business
também
geram
eventos
TEC_Heartbeat_missed
em
resposta
a
eventos
de
status
de
pulsação
a
partir
do
IBM
Tivoli
Monitoring.
Esse
evento
pode
ser
processado
pelo
conjunto
de
regras
de
pulsação
(heartbeat.rls)
ou
pelo
conjunto
de
regras
do
NetView
(netview.rls),
se
esses
conjuntos
de
regras
estiverem
ativos.
WAS DB2
appserver dbserver
Figura
1.
Relacionamento
de
Dependência
entre
os
Serviços
do
WebSphere
Application
Server
e
do
DB2
16
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Como
os
Eventos
São
Analisados
A
análise
principal
de
eventos
de
e-business
é
tratada
pelas
regras
na
seção
″Associação
de
Eventos″
do
conjunto
de
regras
de
e-business.
Essas
são
as
regras
que
identificam
relacionamentos
causais
entre
eventos
de
e-business
e
da
rede
baseados
nos
relacionamentos
de
dependência
definidos.
Quando
ocorre
um
evento
de
efeito
relacionado
aos
serviços
do
WebSphere
Application
Server
ou
do
WebSphere
MQ,
as
regras
de
e-business
pesquisam
na
base
de
conhecimento
um
fato
de
dependência
que
envolve
o
host
e
o
serviço
que
gerou
o
evento.
Se
o
evento
de
efeito
estiver
relacionado
aos
serviços
do
WebSphere
Application
Server,
a
regra
pesquisará
um
fato
de
dependência
WAS_DEPENDS_ON_DB2;
se
o
evento
de
efeito
estiver
relacionado
aos
serviços
do
WebSphere
MQ,
a
regra
pesquisará
um
fato
de
dependência
WMQ_DEPENDS_ON_WMQ.
Se
localizado,
o
fato
de
dependência
indicará
o
nome
completo
do
host
do
qual
o
serviço
de
e-business
depende
(o
host
que
fornece
os
serviços
requeridos
do
DB2
ou
do
WebSphere
MQ).
As
regras
então
pesquisam
no
cache
de
eventos
um
evento
de
causa
originário
do
host
especificado
e
que
afeta
o
serviço
relevante.
Existem
três
categorias
de
eventos
de
causa,
pesquisados
na
seguinte
ordem:
v
Um
evento
de
causa
de
e-business.
Um
evento
de
causa
de
e-business
é
um
evento
que
origina
o
serviço
do
host
e
de
e-business
identificado
por
um
fato
de
dependência.
Ele
pode
ser
um
evento
de
causa
do
DB2
enviado
pelo
IBM
Tivoli
Monitoring
for
Databases:
DB2
ou
um
evento
de
causa
do
WebSphere
MQ
enviado
pelo
IBM
Tivoli
Monitoring
for
Business
Integration:
WebSphere
MQ.
A
classe
específica
do
evento
de
causa
depende
da
classe
do
evento
de
efeito
e
do
tipo
de
dependência.
Se
for
localizado
um
evento
de
causa
de
e-business,
o
evento
de
efeito
será
associado
a
ele
utilizando
o
predicado
link_effect_to_cause.
v
Um
evento
de
causa
da
rede.
Um
evento
de
causa
da
rede
é
um
evento
de
impacto
de
serviços
do
nó
NetView
que
especifica
um
host
identificado
por
um
fato
de
dependência
e
que
afeta
o
serviço
relevante.
Pode
ser
um
evento
TEC_ITS_NODE_SERVICE_IMPACT
com
o
atributo
sub_source
igual
a
IBM_DB2
ou
IBM_WebSphere_MQ,
dependendo
do
tipo
de
dependência.
Se
for
localizado
um
evento
de
causa
de
impacto
de
serviços,
provavelmente
o
host
monitorado
não
poderá
enviar
um
evento
de
causa
de
e-business
devido
ao
problema
da
rede.
Portanto,
o
evento
de
impacto
de
serviços
é
considerado
o
evento
de
causa,
e
o
evento
de
efeito
é
associado
a
ele
utilizando
o
predicado
link_effect_to_cause.
Se
o
evento
de
efeito
tiver
gravidade
baixa
(HARMLESS
ou
UNKNOWN),
a
confirmação
de
seu
recebimento
também
será
feita
automaticamente.
v
Um
evento
de
causa
de
manutenção.
Esse
evento
indica
que
o
host
especificado
entrou
no
modo
de
manutenção.
Um
evento
de
causa
de
manutenção
é
um
evento
TEC_Maintenance
com
current_mode
igual
a
ON
e
que
especifica
um
host
identificado
por
um
fato
de
dependência.
Como
todos
os
demais
eventos
de
um
host
em
modo
de
manutenção
geralmente
são
descartados,
nesse
caso
o
próprio
evento
de
manutenção
é
considerado
o
evento
de
causa.
Se
for
localizado
um
evento
de
causa
de
manutenção,
o
evento
de
efeito
será
associado
a
ele
utilizando
o
predicado
link_effect_to_cause
(para
obter
informações
adicionais
sobre
como
tratar
eventos
de
manutenção,
consulte
“Conjunto
de
Regras
do
Modo
de
Manutenção
(maintenance_mode.rls)”
na
página
41).
Se
um
evento
de
causa
não
puder
ser
identificado
em
uma
dessas
três
categorias,
opcionalmente,
as
regras
continuarão
pesquisando
uma
indicação
de
um
provável
efeito
de
causa
(essa
função
é
ativada
ou
desativada
pelo
parâmetro
ebusiness_hints;
consulte
“Uso”
na
página
18
para
obter
informações
adicionais).
Se
essa
função
Conjunto
de
Regras
de
e-business
(ebusiness.rls)
17
estiver
ativada,
as
regras
continuarão
pesquisando
as
seguintes
categorias
de
prováveis
efeitos
de
causa
(na
seguinte
ordem):
v
Um
provável
evento
de
causa
da
rede.
Um
provável
evento
de
causa
da
rede
é
um
evento
TEC_ITS_NODE_STATUS
do
NetView
com
nodestatus
igual
a
MARGINAL
ou
DOWN
e
originário
de
um
host
identificado
por
um
fato
de
dependência.
Se
esse
evento
for
localizado,
ele
indicará
que
existe
um
problema
de
rede
com
o
host
especificado,
mas
o
componente
NetView
não
será
configurado
para
gerar
eventos
de
impacto
de
serviços.
Em
vez
disso,
as
regras
gerarão
um
evento
informativo
TEC_ITS_Not_Monitoring_eBusiness
que
especifica
o
evento
de
efeito
e
o
provável
evento
de
causa
da
rede.
Esse
evento
indica
que
o
NetView
precisa
ser
configurado
para
monitorar
o
serviço
de
e-business
relacionado.
v
Um
provável
evento
de
causa
de
e-business.
Um
provável
evento
de
causa
de
e-business
é
um
evento
originário
do
tipo
de
serviço
identificado
por
um
fato
de
dependência,
mas
não
de
um
host
correspondente.
Isso
pode
indicar
que
os
relacionamentos
de
dependência
corretos
não
foram
definidos.
Se
for
localizado
um
provável
evento
de
causa
de
e-business,
as
regras
gerarão
um
evento
informativo
TEC_PROBABLE_EVENT_ASSOCIATION
que
especifica
o
evento
de
efeito
e
o
provável
evento
de
causa.
Esse
evento
indica
que
os
relacionamentos
de
dependência
definidos
talvez
precisem
ser
atualizados.
Em
algumas
situações,
um
evento
de
efeito
pode
chegar
antes
do
evento
de
causa.
Se
isso
ocorrer,
as
regras
não
poderão
identificar
o
relacionamento
causal
quando
o
evento
de
efeito
chegar,
pois
o
evento
de
causa
ainda
não
está
no
cache
de
eventos.
Para
tratar
essa
situação,
quando
chega
um
provável
evento
de
causa,
as
regras
repetem
a
análise
de
dependência
para
quaisquer
possíveis
eventos
de
efeito
já
no
cache
de
eventos.
Nota:
Devido
ao
possível
impacto
no
desempenho,
não
ocorre
uma
nova
análise
para
os
eventos
TEC_Maintenance
ou
TEC_ITS_NODE_STATUS.
Para
que
ocorra
a
associação,
esses
eventos
já
devem
estar
no
cache
de
eventos
quando
chegarem
os
eventos
de
efeito
de
e-business.
Uso
O
conjunto
de
regras
de
e-business
já
está
ativado
na
base
de
regras
padrão.
Se
você
fizer
alterações
nesse
conjunto
de
regras,
então
é
necessário
recompilar
e
recarregar
a
base
de
regras.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
mais
informações.
Nota:
Se
ativado,
o
conjunto
de
regras
de
e-business
deverá
ser
listado
próximo
do
final
do
arquivo
rule_sets
(após
o
conjunto
de
regras
do
NetView,
se
esse
conjunto
de
regras
estiver
ativo).
Além
disso,
o
conjunto
de
regras
de
dependência
(dependency.rls)
fornece
o
suporte
requerido
para
o
conjunto
de
regras
de
e-business.
Se
o
conjunto
de
regras
de
e-business
estiver
ativo,
o
conjunto
de
regras
de
dependência
também
deve
estar
ativo.
Configuração
O
conjunto
de
regras
de
e-business
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
esse
conjunto
de
regras
modificando
as
instruções
na
regra
de
configuração
startup.
As
opções
a
seguir
são
configuráveis:
v
Geração
de
eventos
informativos.
Você
pode
especificar
se
deseja
que
as
regras
gerem
os
eventos
informativos
TEC_PROBABLE_EVENT_ASSOCIATION
e
TEC_ITS_Not_Monitoring_eBusiness.
Esses
eventos
são
gerados
em
casos
nos
quais
é
localizado
um
provável
evento
de
causa,
mas
existem
informações
18
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
insuficientes
para
uma
associação
causal
(consulte
“Como
os
Eventos
São
Analisados”
na
página
17
para
obter
informações
adicionais).
Por
padrão,
essa
função
fica
ativada;
se
você
desejar
alterar
essa
preferência,
modifique
a
instrução
que
define
o
parâmetro
ebusiness_hints,
da
seguinte
forma:
rerecord(ebusiness_hints,
’no’),
v
Registro
de
depuração.
Você
pode
especificar
se
deseja
depurar
as
informações
de
depuração
em
um
arquivo
de
log.
Isso
pode
ser
útil
para
testar
modificações
no
conjunto
de
regras.
Essa
função
deve
ser
desativada
sempre
antes
de
o
conjunto
de
regras
ser
implementado
em
um
ambiente
de
produção,
pois
afeta
o
desempenho.
Para
ativar
ou
desativar
mensagens
de
depuração,
modifique
a
instrução
que
define
o
parâmetro
ebusiness_debug,
da
seguinte
forma:
rerecord(ebusiness_debug,
flag),
flag
é
’yes’
ou
’no’.
v
Nome
do
arquivo
do
log
de
depuração.
Você
pode
especificar
o
nome
do
arquivo
utilizado
para
registrar
mensagens
de
depuração.
Esse
arquivo
será
utilizado
apenas
se
ebusiness_debug
estiver
definido
como
yes.
Você
pode
especificar
uma
localização
absoluta
para
o
arquivo
ou
especificar
apenas
o
nome
do
arquivo,
nesse
caso,
o
arquivo
será
criado
no
diretório
$DBDIR.
O
valor
padrão
é
ebusiness.log.
Para
especificar
um
arquivo
diferente,
modifique
a
instrução
que
define
o
parâmetro
ebusiness_logger,
da
seguinte
forma:
rerecord(ebusiness_logger,
filename),
filename
é
o
nome
do
arquivo
de
log
que
você
deseja
utilizar,
opcionalmente,
incluindo
um
caminho
relativo
ou
absoluto,
e
colocado
entre
aspas
simples.
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
as
regras
de
e-business
confirmarem
o
recebimento
ou
fecharem
eventos
automaticamente.
O
nome
do
administrador
padrão
é
ebusiness.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
o
parâmetro
ebusiness_admin,
da
seguinte
forma:
rerecord(ebusiness_admin,
admin),
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
v
Latência.
Você
pode
especificar
o
intervalo
de
tempo
a
ser
utilizado
quando
pesquisar
no
cache
de
eventos
os
eventos
a
serem
associados.
Esse
intervalo
de
tempo
afeta
pesquisas
de
eventos
de
retrocesso
ou
de
avanço.
Por
padrão,
as
pesquisas
são
limitadas
em
dez
minutos
(600
segundos)
de
retrocesso
ou
de
avanço
no
cache
de
eventos.
Para
alterar
a
latência,
modifique
a
instrução
que
define
o
parâmetro
ebusiness_latency,
da
seguinte
forma:
rerecord(ebusiness_latency,
seconds),
seconds
é
o
número
de
segundos
que
representa
o
quanto
você
deseja
retroceder
ou
avançar
para
pesquisar
eventos
no
cache.
Nota:
Esse
parâmetro
define
um
limite
superior
sobre
quanto
tempo
a
pesquisa
retrocederá,
mas
isso
não
garante
que
os
eventos
nesse
período
de
tempo
ainda
estarão
disponíveis.
Se
o
cache
de
eventos
for
muito
pequeno,
os
eventos
poderão
ser
descartados,
mesmo
se
forem
mais
recentes
do
que
o
tempo
especificado.
Se
isso
ocorrer,
aumente
o
tamanho
do
cache
de
eventos
(consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais).
Conjunto
de
Regras
de
e-business
(ebusiness.rls)
19
Definindo
Relacionamentos
de
Dependência
Antes
de
utilizar
o
conjunto
de
regras
de
e-business,
é
necessário
definir
os
relacionamentos
de
dependência
que
se
aplicam
aos
serviços
de
e-business
e
aos
recursos
de
rede
em
seu
ambiente.
Para
definir
esses
relacionamentos,
crie
um
arquivo
de
texto
contendo
uma
série
de
instruções
de
dependência,
sendo
que
cada
uma
será
convertida
em
um
fato
de
dependência
na
base
de
conhecimento.
Cada
instrução
de
dependência
está
em
uma
linha
separada,
e
cada
instrução
consiste
em
três
partes,
separadas
por
espaço
em
branco:
host_a
dependency_type
host_b
host_a
é
o
nome
completo
do
host
que
possui
uma
dependência
de
outro
host,
dependency_type
é
a
natureza
da
dependência
e
host_b
é
o
nome
completo
do
host
do
qual
host_a
depende.
O
exemplo
a
seguir
mostra
três
instruções
de
dependência:
mq1.raleigh.ibm.com
WMQ_DEPENDS_ON_WMQ
mq2.raleigh.ibm.com
mq2.raleigh.ibm.com
WMQ_DEPENDS_ON_WMQ
mq1.raleigh.ibm.com
appserver.raleigh.ibm.com
WAS_DEPENDS_ON_DB2
appserver.raleigh.ibm.com
Estas
instruções
definem
os
seguintes
relacionamentos
de
dependência
(consulte
a
Figura
2):
v
A
primeira
instrução
indica
que
os
serviços
do
WebSphere
MQ
em
mq1.raleigh.ibm.com
dependem
dos
serviços
do
WebSphere
MQ
em
mq2.raleigh.ibm.com.
v
A
segunda
instrução
indica
que
os
serviços
do
WebSphere
MQ
em
mq2.raleigh.ibm.com
dependem
dos
serviços
do
WebSphere
MQ
em
mq1.raleigh.ibm.com.
v
A
terceira
instrução
indica
que
os
serviços
do
WebSphere
Application
Server
em
appserver.raleigh.ibm.com
dependem
da
disponibilidade
dos
serviços
do
DB2
em
execução
no
mesmo
host.
Nota:
Cada
fato
de
dependência
representa
um
relacionamento
de
dependência
único,
unidirecional.
Portanto,
se
dois
hosts
interconectados
tiverem
WMQ WMQ
WAS
DB2
mq1.raleigh.ibm.com mq2.raleigh.ibm.com
appserver.raleigh.ibm.com
Figura
2.
Exemplo
de
Relacionamentos
de
Dependência.
Cada
seta
representa
um
relacionamento
unidirecional
″dependente″.
20
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
dependências
mútuas,
será
necessário
definir
um
fato
de
dependência
separado
para
cada
direção
do
relacionamento.
Geralmente,
esse
é
o
caso
de
relacionamentos
WMQ_DEPENDS_ON_WMQ,
conforme
no
exemplo
anterior.
Quando
concluir
a
definição
de
relacionamentos
de
dependência
no
arquivo
de
texto,
utilize
o
comando
wrb
–imptdp
para
carregar
esses
relacionamentos
para
a
base
de
conhecimento
como
fatos
de
dependência:
wrb
-imptdp
filename
filename
é
o
nome
do
arquivo
de
texto
que
contém
as
instruções
de
dependência.
Para
remover
relacionamentos
de
dependência,
utilize
o
comando
wrb
–deldp:
wrb
-deldp
filename
filename
é
o
nome
de
um
arquivo
de
texto
que
contém
instruções
de
dependência
que
você
deseja
remover
da
base
de
conhecimento.
Nota:
Antes
de
utilizar
wrb
–imptdp
ou
wrb
–deldp,
certifique-se
de
que
o
servidor
de
eventos
esteja
em
execução
e
de
que
o
conjunto
de
regras
de
dependência
(dependency.rls)
esteja
ativado.
Os
fatos
de
dependência
são
persistentes,
portanto,
não
é
necessário
recarregar
relacionamentos
de
dependência
após
parar
e
reiniciar
o
servidor
de
eventos.
Para
obter
informações
adicionais
sobre
os
comandos
wrb
–imptdp
ou
wrb
–deldp,
consulte
o
IBM
Tivoli
Enterprise
Console
-
Referência
a
Comandos
e
Tarefas.
Regras
Regras
Startup
e
Shutdown
regra:
startup
A
regra
startup
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
carrega
primeiro
os
predicados
auxiliares
utilizados
pelas
regras
de
e-business;
em
seguida,
ela
define
os
parâmetros
globais
para
as
regras
de
e-business
e
inicializa
os
arquivos
de
log
para
o
conjunto
de
regras.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
do
conjunto
de
regras
ebusiness.rls.
Consulte
“Uso”
na
página
18
para
mais
informações.
regra:
Shutdown
A
regra
shutdown
é
executada
no
recebimento
do
evento
TEC_Stop,
que
é
enviado
quando
o
servidor
de
eventos
é
encerrado.
Essa
regra
fecha
o
arquivo
de
log
para
o
conjunto
de
regras
de
e-business.
Regras
de
Pulsação
regra:
generate_heartbeat_missed
A
regra
generate_heartbeat_missed
gera
um
evento
TEC_Heartbeat_missed
quando
um
dos
seguintes
eventos
de
status
de
pulsação
é
recebido
do
produto
IBM
Tivoli
Monitoring:
v
HeartBeat_Off
v
HeartBeat_EndpointUnreachable
v
HeartBeat_DMAgentDown
Conjunto
de
Regras
de
e-business
(ebusiness.rls)
21
v
HeartBeat_ResourceModelsInError
Quando
um
desses
eventos
é
recebido,
a
regra
gera
um
evento
TEC_Heartbeat_missed,
duplicando
os
valores
de
atributos
a
partir
do
evento
recebido
(para
obter
informações
adicionais
sobre
eventos
de
status
de
pulsação,
consulte
a
documentação
do
IBM
Tivoli
Monitoring).
regra:
link_heartbeat_missed
A
regra
link_heartbeat_missed
associa
os
eventos
de
efeito
TEC_Heartbeat_missed
gerados
pela
regra
generate_heartbeat_missed
com
os
eventos
de
causa
recebidos
do
produto
IBM
Tivoli
Monitoring.
Os
eventos
de
efeito
estão
associados
aos
eventos
de
causa
utilizando
o
predicado
link_effect_to_cause.
Regras
de
Manipulação
de
Tipo
de
Letra
regra:
lower_itm
A
regra
lower_itm
é
executada
durante
o
recebimento
de
um
possível
evento
de
causa
ou
de
efeito
de
e-business
a
partir
de
um
serviço
de
e-business.
Essa
regra
converte
o
valor
do
atributo
fqhostname
em
todas
as
letras
minúsculas,
para
evitar
incompatibilidades
ao
executar
comparações
de
distinção
entre
maiúsculas
e
minúsculas.
regra:
lower_its
A
regra
lower_its
é
executada
durante
o
recebimento
de
um
possível
evento
de
causa
da
rede
a
partir
do
componente
NetView.
Isso
inclui
qualquer
evento
TEC_ITS_NODE_SERVICE_IMPACT
com
sub_source
igual
a
IBM_DB2
ou
IBM_WebSphere_MQ.
Essa
regra
converte
o
valor
do
atributo
fqhostname
em
todas
as
letras
minúsculas,
para
evitar
possíveis
incompatibilidades
ao
executar
comparações
de
distinção
entre
maiúsculas
e
minúsculas.
regra:
lower_tec
A
regra
lower_tec
é
executada
durante
o
recebimento
de
um
possível
evento
de
causa
de
manutenção.
Isso
inclui
qualquer
evento
TEC_Maintenance
com
current_mode
igual
a
ON.
Essa
regra
converte
o
valor
do
atributo
fqhostname
em
todas
as
letras
minúsculas,
para
evitar
possíveis
incompatibilidades
ao
executar
comparações
de
distinção
entre
maiúsculas
e
minúsculas.
regra:
lower_node
A
regra
lower_node
é
executada
durante
o
recebimento
de
um
possível
evento
de
causa
da
rede
a
partir
do
componente
NetView.
Isso
inclui
qualquer
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
MARGINAL
ou
DOWN.
Essa
regra
converte
o
valor
do
atributo
fqhostname
em
todas
as
letras
minúsculas,
para
evitar
possíveis
incompatibilidades
ao
executar
comparações
de
distinção
entre
maiúsculas
e
minúsculas.
Regras
de
Associação
de
Eventos
regra:
associate_wmq_wmq
A
regra
associate_wmq_wmq
é
executada
durante
o
recebimento
de
um
evento
de
efeito
de
um
serviço
do
WebSphere
MQ
e
tenta
associá-lo
a
um
evento
de
causa
que
corresponde
a
um
relacionamento
de
dependência
WMQ_DEPENDS_ON_WMQ
definido.
A
tabela
a
seguir
mostra
os
eventos
de
efeito
analisados
por
essa
regra
e
os
possíveis
eventos
de
causa
de
e-business.
22
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Tabela
3.
Eventos
de
Efeito
e
Causa
para
a
Regra
associate_wmq_wmq
Evento
de
efeito
Possíveis
eventos
de
causa
de
e-business
WebSphere_MQ_ChannelNotActivated
WebSphere_MQ_QueueManagerUnavailable
WebSphere_MQ_ChannelNotTransmitting
WebSphere_MQ_ChannelStartupError
WebSphere_MQ_ChannelThroughputProblem
WebSphere_MQ_QueueFilling
WebSphere_MQ_ChannelNotTransmitting
WebSphere_MQ_QueueManagerUnavailable
WebSphere_MQ_ChannelNotActivated
WebSphere_MQ_ChannelStartupError
WebSphere_MQ_QueueManagerUnavailable
WebSphere_MQ_ChannelNotActivated
Se
não
for
localizado
nenhum
evento
de
causa
de
e-business,
a
regra
tentará
localizar
um
evento
de
causa
da
rede
(TEC_ITS_NODE_SERVICE_IMPACT)
ou
de
manutenção
(TEC_Maintenance).
Se
não
for
localizado
nenhum
evento
de
causa,
mas
os
eventos
informativos
estiverem
ativados,
a
regra
tentará
localizar
um
provável
evento
de
causa.
Consulte
“Como
os
Eventos
São
Analisados”
na
página
17
para
mais
informações.
regra:
associate_was_db2
A
regra
associate_was_db2
é
executada
durante
o
recebimento
de
um
evento
de
efeito
de
um
serviço
do
WebSphere
Application
Server
e
tenta
associá-lo
a
um
evento
de
causa
que
corresponde
a
um
relacionamento
de
dependência
WAS_DEPENDS_ON_DB2
definido.
A
tabela
a
seguir
mostra
os
eventos
de
efeito
analisados
por
essa
regra
e
os
possíveis
eventos
de
causa
de
e-business.
Tabela
4.
Eventos
de
Efeito
e
Causa
para
a
Regra
associate_was_db2
Evento
de
efeito
Possíveis
eventos
de
causa
de
e-business
WebSphereAS_high_DBPool_faults
DB2_Down_Status
DB2_High_ConnectionErrors
WebSphereAS_high_DBPool_avgWaitTime
DB2_High_ConnWaitingForHost
DB2_High_MostRecentConnectResponse
DB2_High_DB2ApplicationAgent_TotUserCpuTime
DB2_High_ApplicationAgent_TotSystemCpuTime
WebSphereAS_high_Transaction_avg_response_time
DB2_High_HostTimePerStatement
DB2_High_NetworkTimePerStatement
DB2_High_TimePerStatement
DB2_High_InstanceAgents_PctAgentsWaiting
DB2_High_ApplicationAgents_Workload
DB2_High_InstanceAgents_AgentCreationRatio
DB2_High_DB2ApplicationAgent_TotUserCpuTime
DB2_High_ApplicationAgent_TotSystemCpuTime
WebSphereAS_high_Transaction_timeout_ratio
DB2_Down_Status
DB2_High_HostTimePerStatement
DB2_High_NetworkTimePerStatement
DB2_High_TimePerStatement
DB2_High_InstanceAgents_PctAgentsWaiting
DB2_High_ApplicationAgents_Workload
DB2_High_InstanceAgents_AgentCreationRatio
DB2_High_DB2ApplicationAgent_TotUserCpuTime
DB2_High_ApplicationAgent_TotSystemCpuTime
WebSphereAS_high_DBPool_percentUsed
DB2_High_PctConnectionsUsed
DB2_High_CurrentConnections
Se
não
for
localizado
nenhum
evento
de
causa
de
e-business,
a
regra
tentará
localizar
um
evento
de
causa
da
rede
(TEC_ITS_NODE_SERVICE_IMPACT)
ou
de
Conjunto
de
Regras
de
e-business
(ebusiness.rls)
23
manutenção
(TEC_Maintenance).
Se
não
for
localizado
nenhum
evento
de
causa,
mas
os
eventos
informativos
estiverem
ativados,
a
regra
tentará
localizar
um
provável
evento
de
causa.
Consulte
“Como
os
Eventos
São
Analisados”
na
página
17
para
mais
informações.
regra:
redo_its_wmq
A
regra
redo_its_wmq
trata
casos
em
que
os
eventos
de
causa
da
rede
e
os
eventos
de
efeito
do
WebSphere
MQ
chegam
fora
de
seqüência.
Essa
regra
é
executada
durante
o
recebimento
de
qualquer
evento
TEC_ITS_NODE_SERVICE_IMPACT
que
especifica
serviços
do
WebSphere
MQ.
Quando
esse
possível
evento
de
causa
é
recebido,
a
regra
utiliza
o
predicado
redo_analysis
para
solicitar
uma
nova
análise
de
possíveis
eventos
de
efeito
do
WebSphere
MQ
que
podem
ter
chegado
anteriormente,
para
determinar
se
eles
são
efeitos
do
evento
de
causa
recém-recebido.
Esses
eventos
de
efeito
são
os
analisados
pela
regra
associate_wmq_wmq.
regra:
redo_its_was
A
regra
redo_its_was
trata
casos
em
que
os
eventos
de
causa
da
rede
e
os
eventos
de
efeito
do
WebSphere
Application
Server
chegam
fora
de
seqüência.
Essa
regra
é
executada
durante
o
recebimento
de
qualquer
evento
TEC_ITS_NODE_SERVICE_IMPACT
que
especifica
serviços
do
WebSphere
Application
Server.
Quando
este
possível
evento
de
causa
é
recebido,
a
regra
utiliza
o
predicado
redo_analysis
para
solicitar
uma
nova
análise
de
possíveis
eventos
de
efeito
do
WebSphere
Application
Server
que
podem
ter
chegado
anteriormente,
para
determinar
se
eles
são
efeitos
do
evento
de
causa
recém-recebido.
Esses
eventos
de
efeito
são
os
analisados
pela
regra
associate_was_db2.
regra:
redo_wmq_wmq
A
regra
redo_wmq_wmq
trata
casos
em
que
os
eventos
de
causa
do
WebSphere
MQ
e
os
eventos
de
efeito
do
WebSphere
MQ
chegam
fora
de
seqüência.
Essa
regra
é
executada
durante
o
recebimento
de
um
evento
do
WebSphere
MQ
que
é
um
possível
evento
de
causa.
Quando
esse
evento
é
recebido,
a
regra
utiliza
o
predicado
redo_analysis
para
solicitar
uma
nova
análise
de
possíveis
eventos
de
efeito
do
WebSphere
MQ
que
podem
ter
chegado
anteriormente,
para
determinar
se
eles
são
efeitos
do
evento
de
causa
recém-recebido.
Os
eventos
de
causa
e
de
efeito
são
os
analisados
pela
regra
associate_wmq_wmq.
regra:
redo_db2_was
A
regra
redo_db2_was
trata
casos
em
que
os
eventos
de
causa
do
DB2
e
os
eventos
de
efeito
do
WebSphere
Application
Server
chegam
fora
de
seqüência.
Essa
regra
é
executada
durante
o
recebimento
de
um
evento
do
DB2
que
é
um
possível
evento
de
causa.
Quando
esse
evento
é
recebido,
a
regra
utiliza
o
predicado
redo_analysis
para
solicitar
uma
nova
análise
de
possíveis
eventos
de
efeito
do
WebSphere
Application
Server
que
podem
ter
chegado
anteriormente,
para
determinar
se
eles
são
efeitos
do
evento
de
causa
recém-recebido.
Os
eventos
de
causa
e
de
efeito
são
os
analisados
pela
regra
associate_was_db2.
24
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Escala
(escalate.rls)
Visão
Geral
O
conjunto
de
regras
de
escala
contém
regras
que
podem
aumentar
a
gravidade
de
eventos
que
não
foram
tratados
em
um
período
de
tempo
especificado.
Quando
utilizadas
com
o
conjunto
de
regras
de
notificação,
as
regras
de
escala
também
acionam
a
notificação
automática
por
ou
pager
da
escala
do
evento
(consulte
“Conjunto
de
Regras
de
Notificação
(notify.rls)”
na
página
63
para
obter
informações
adicionais
sobre
o
conjunto
de
regras
de
notificação).
Uso
O
conjunto
de
regras
de
escala
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Nota:
Se
ativado,
o
conjunto
de
regras
de
escala
deve
ser
listado
próximo
do
final
do
arquivo
rule_sets
(após
o
conjunto
de
regras
de
correlação,
se
esse
conjunto
de
regras
estiver
ativo).
Além
disso,
o
conjunto
de
regras
de
notificação
(notify.rls)
fornece
o
suporte
requerido
para
notificação
por
e-mail.
Se
desejar
que
as
regras
de
escala
acionem
a
notificação
por
e-mail,
notify.rls
também
deve
estar
ativo.
Consulte
“Seqüenciamento
e
Dependências
do
Conjunto
de
Regras”
na
página
3
para
mais
informações.
Configuração
Opcional
O
conjunto
de
regras
de
escala
está
pré-configurado
e
pronto
para
utilização.
Por
padrão,
esse
conjunto
de
regras
é
configurado
apenas
para
acionar
notificação
por
ou
por
pager
para
eventos
FATAL
que
requerem
escala;
essa
função
requer
que
o
conjunto
de
regras
de
notificação
(notify.rls)
também
esteja
configurado
e
ativo
(as
gravidades
não
são
aumentadas
porque
os
eventos
FATAL
já
estão
em
sua
gravidade
máxima).
Se
você
desejar
escalar
eventos
com
gravidades
diferentes
de
FATAL,
será
necessário
personalizar
o
conjunto
de
regras,
modificando
as
instruções
na
ação
escalate_parameters
da
regra
escalate_configure.
As
opções
a
seguir
são
configuráveis:
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
alterar
a
gravidade
do
evento.
O
nome
do
administrador
padrão
é
escalate.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
o
parâmetro
_escalate_admin,
da
seguinte
forma:
_escalate_admin
=
admin,
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
v
Freqüência
de
verificação
de
escala.
Você
pode
especificar
a
freqüência
com
que
deseja
que
as
regras
de
escala
verifiquem
no
cache
de
eventos
os
eventos
que
precisam
ser
escalados.
A
freqüência
padrão
é
a
cada
60
segundos.
Para
alterar
essa
freqüência,
modifique
a
instrução
que
define
o
parâmetro
_escalate_timer,
da
seguinte
forma:
_escalate_timer
=
seconds,
©
Copyright
IBM
Corp.
2003
25
seconds
é
o
período
de
tempo
(em
segundos)
que
você
deseja
que
decorra
entre
verificações
de
escala.
v
Latência.
Você
pode
especificar
o
quanto
deseja
retroceder
no
cache
de
eventos
para
pesquisar
eventos
a
serem
escalados.
O
padrão
é
30
dias.
Para
alterar
a
latência,
modifique
a
instrução
que
define
o
parâmetro
_esc_search_time,
da
seguinte
forma:
_escalate_search_time
=
seconds,
seconds
é
o
número
de
segundos
que
representa
o
quanto
você
deseja
retroceder
para
pesquisar
eventos
no
cache.
v
Freqüência
de
organização.
Você
pode
especificar
a
freqüência
com
que
deseja
que
as
regras
de
escala
removam
referências
a
eventos
escalados
que
não
mais
estão
no
cache
de
eventos.
Quando
um
evento
é
escalado,
as
regras
confirmam
um
fato
de
escala
na
base
de
conhecimento.
A
regra
de
remoção
verifica
periodicamente
para
assegurar
que
cada
fato
de
escala
refere-se
a
um
evento
que
ainda
está
no
cache
de
eventos.
Quando
um
evento
é
removido
do
cache
devido
à
sua
duração
ou
devido
a
limitações
de
espaço,
a
regra
de
remoção
remove
o
fato
de
escala
associado
da
base
de
conhecimento.
A
freqüência
de
remoção
padrão
é
de
86.400
segundos
(24
horas).
Para
alterar
essa
freqüência,
modifique
a
instrução
que
define
o
parâmetro
_esc_housekeeping_timer,
da
seguinte
forma:
_esc_housekeeping_timer
=
seconds,
seconds
é
o
período
de
tempo
(em
segundos)
que
você
deseja
que
decorra
entre
verificações
de
remoção.
v
Se
a
gravidade
do
evento
deve
ser
aumentada.
Você
pode
especificar
se
deseja
que
as
regras
aumentem
automaticamente
a
gravidade
do
evento
quando
um
evento
tiver
que
ser
escalado.
Se
essa
opção
estiver
desativada,
as
regras
de
escala
não
alterarão
a
gravidade
do
evento,
mas
ainda
acionarão
a
notificação
pelas
regras
de
notificação
(se
notify.rls
estiver
ativo).
Por
padrão,
as
regras
de
escala
não
alteram
a
gravidade
do
evento.
Para
alterar
esse
comportamento,
modifique
a
instrução
que
define
o
parâmetro
_escalate_increase_severity,
da
seguinte
forma:
_escalate_increase_severity
=
flag,
flag
é
’true’
ou
’false’.
v
Classes
a
serem
escaladas.
Você
pode
especificar
se
deseja
que
apenas
algumas
classes
de
eventos
sejam
escaladas.
Por
padrão,
as
regras
de
escala
são
aplicadas
apenas
aos
eventos
TEC_Error
e
TEC_DB.
Se
desejar
adicionar
outras
classes,
modifique
a
instrução
que
define
o
parâmetro
_escalate_class_list,
da
seguinte
forma:
rerecord(escalate_class_list,[
ev_classes
]
)
ev_classes
é
uma
lista
de
classes
de
eventos,
cada
uma
entre
aspas
simples,
separadas
por
vírgulas.
Se
desejar
aplicar
as
regras
de
escala
a
todas
as
classes,
transforme
essa
linha
em
comentário
e
deixe
_escalate_class_list
indefinido.
v
Limites
de
tempo
de
escala.
Você
pode
especificar
um
período
de
tempo
em
que
os
eventos
podem
permanecer
com
status
ACK
ou
OPEN
em
cada
nível
de
gravidade.
Para
cada
nível
de
gravidade
no
qual
você
deseja
que
ocorra
a
escala,
inclua
a
seguinte
instrução:
assert(escalate_severity_timers(severity,
open_ack_time,
ack_close_time)),
26
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
severity
é
o
nível
de
gravidade
colocado
entre
aspas
simples,
open_ack_time
é
o
número
de
segundos
que
um
evento
pode
permanecer
aberto
antes
da
escala
e
ack_close_time
é
o
número
de
segundos
que
um
evento
pode
permanecer
com
confirmação
de
recebimento
antes
da
escala.
Um
valor
zero
para
open_ack_time
ou
ack_close_time
não
especifica
nenhum
limite
de
tempo.
Por
padrão,
o
único
nível
de
gravidade
para
o
qual
os
limites
de
tempo
de
escala
estão
definidos
é
FATAL:
assert(escalate_severity_timers(’FATAL’,
43200,
0),
Essa
instrução
especifica
que
os
eventos
FATAL
podem
permanecer
no
estado
OPEN
por
12
horas
e
no
status
ACK
indefinidamente.
Para
alterar
esses
limite
de
tempo,
modifique
a
instrução
de
acordo.
Para
especificar
níveis
de
gravidade
adicionais
na
escala,
remova
os
comentários
das
instruções
correspondentes
e
modifique
os
limites
de
tempo,
se
necessário.
Regras
regra:
escalate_configure
A
regra
escalate_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
escala.
Consulte
“Uso”
na
página
25
para
mais
informações.
regra:
check_cache_for_escalation
A
regra
check_cache_for_escalation
é
executada
durante
o
recebimento
do
evento
Escalate_event,
que
é
gerado
periodicamente
pela
regra
do
cronômetro
escalate_old_events.
Quando
Escalate_event
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
quaisquer
eventos
que
tenham
permanecido
no
status
ACK
ou
OPEN
por
um
período
de
tempo
maior
do
que
o
permitido.
Se
uma
lista
de
classes
for
definida
utilizando
o
parâmetro
de
configuração
escalate_class_list,
essa
pesquisa
será
limitada
às
classes
especificadas
nessa
lista.
Para
cada
evento
de
monitoração,
a
regra
primeiro
verifica
na
base
de
conhecimento
um
fato
de
escala
correspondente
(que
indica
que
o
evento
já
foi
escalado).
Se
não
for
localizado
nenhum
fato
de
escala,
será
definido
um
cronômetro
com
duração
de
um
segundo,
para
acionar
a
escala
imediata
pela
regra
do
cronômetro
escalate_specific_event.
Um
fato
de
escala
é
então
confirmado
na
base
de
conhecimento
para
o
evento
escalado
e
o
evento
Escalate_event
recebido
é
eliminado.
regra
do
cronômetro:
escalate_old_events
A
regra
do
cronômetro
escalate_old_events
gera
periodicamente
eventos
Escalate_event,
que
acionam
a
regra
check_cache_for_escalation.
A
regra
então
redefine
o
cronômetro
Escalate
para
acionar
a
próxima
verificação.
A
duração
desse
cronômetro
é
determinada
pelo
parâmetro
_escalate_timer
na
regra
de
configuração
escalate_parameters.
regra
do
cronômetro:
escalate_specific_event
A
regra
escalate_specific_event
trata
a
escala.
Essa
regra
é
executada
durante
a
expiração
de
qualquer
cronômetro
Escalate_open
ou
Escalate_ack;
esse
cronômetro
é
definido
pela
regra
check_cache_for_escalation
quando
é
localizado
um
evento
que
permaneceu
no
status
ACK
ou
OPEN
por
muito
tempo.
Quando
o
Conjunto
de
Regras
de
Escala
(escalate.rls)
27
cronômetro
expirar,
a
regra
escalate_specific_event
primeiro
verifica
se
o
evento
foi
retirado
do
status
ACK
ou
OPEN
desde
a
definição
do
cronômetro.
Se
isso
tiver
ocorrido,
a
regra
retirará
o
fato
de
escala
associado
e,
em
seguida,
será
fechada.
Se
o
evento
ainda
estiver
no
status
ACK
ou
OPEN,
a
regra
executará
uma
das
seguintes
ações:
v
Se
o
parâmetro
_escalate_increase_severity
estiver
definido
como
true,
a
gravidade
do
evento
será
aumentada
(a
menos
que
já
seja
FATAL;
nesse
caso,
será
redefinida
como
FATAL).
v
Se
o
parâmetro
_escalate_increase_severity
estiver
definido
como
false,
a
gravidade
do
evento
será
redefinida
como
seu
valor
atual.
Em
qualquer
caso,
como
a
gravidade
foi
redefinida,
as
regras
de
alteração
no
conjunto
de
regras
de
notificação
serão
acionadas,
se
esse
conjunto
de
regras
estiver
ativo.
regra
do
cronômetro:
escalate_housekeeping
A
regra
escalate_housekeeping
é
executada
durante
a
expiração
do
cronômetro
Escalate_housekeeping,
que
é
definido
pela
regra
de
configuração
com
base
na
duração
especificada
pelo
parâmetro
_esc_housekeeping_timer.
Quando
o
cronômetro
expirar,
a
regra
escalate_housekeeping
verificará
no
cache
de
eventos
cada
evento
para
o
qual
existe
um
fato
de
escala
na
base
de
conhecimento.
Se
qualquer
um
dos
eventos
escalados
não
mais
estiver
no
cache
de
eventos,
a
regra
retirará
os
fatos
de
escala
correspondentes
da
base
de
conhecimento.
Em
seguida,
ela
redefine
o
cronômetro.
28
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Atividade
do
Evento
(event_activity.rls)
Visão
Geral
O
conjunto
de
regras
de
atividades
do
evento
contém
regras
que
suportam
a
geração
de
relatórios
de
atividade
de
eventos.
Uso
O
conjunto
de
regras
de
atividade
do
evento
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Configuração
Opcional
O
conjunto
de
regras
de
atividade
de
eventos
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
esse
conjunto
de
regras
modificando
as
instruções
na
ação
event_activity_parameters
da
regra
de
configuração
event_activity_start.
Essas
instruções
afetam
o
comportamento
do
conjunto
de
regras,
incluindo
os
argumentos
transmitidos
para
o
predicado
init_event_activity
(consulte
o
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide
para
obter
informações
adicionais
sobre
este
predicado
e
seus
argumentos).
As
opções
a
seguir
são
configuráveis:
v
Freqüência
de
relatórios.
Você
pode
especificar
a
freqüência
em
que
as
atualizações
são
gravadas
no
arquivo
de
saída
de
atividade
de
eventos.
A
freqüência
padrão
é
a
cada
20
segundos.
Para
alterar
a
freqüência,
modifique
a
instrução
que
define
o
parâmetro
_reporting_frequency,
da
seguinte
forma:
_reporting_frequency
=
seconds,
seconds
é
o
período
de
tempo,
em
segundos,
que
você
deseja
que
passe
entre
atualizações
no
arquivo
de
saída.
v
Nome
do
arquivo
de
saída.
Você
pode
especificar
o
nome
do
arquivo
de
saída
no
qual
o
relatório
de
atividade
de
eventos
é
gravado.
Esse
valor
é
transmitido
como
o
argumento
_file
do
predicado
init_event_activity.
O
arquivo
de
saída
padrão
é
/tmp/event_activity.log.
Para
alterar
o
nome
do
arquivo,
modifique
a
instrução
que
define
o
parâmetro
_reporting_file,
da
seguinte
forma:
_reporting_file
=
filename,
filename
é
o
nome
do
arquivo
de
saída
que
você
deseja
utilizar,
incluindo,
opcionalmente,
um
caminho
relativo
ou
absoluto
e
colocado
entre
aspas
simples.
v
Classes
a
serem
excluídas.
Você
pode
especificar
uma
lista
de
classes
de
eventos
que
não
deseja
incluir
no
log
de
atividade
de
eventos.
Esse
valor
é
transmitido
como
o
argumento
_event_exclusions
do
predicado
init_event_activity.
O
comportamento
padrão
é
excluir
os
eventos
TEC_Heartbeat
e
TEC_Maintenance.
Para
alterar
a
lista,
modifique
a
instrução
que
define
o
parâmetro
_do_not_report_classes,
da
seguinte
forma:
_do_not_report_classes
=
exclude_list
exclude_list
é
uma
lista
de
classes
de
eventos
válidas,
cada
um
entre
aspas
simples
e
separadas
por
vírgulas.
©
Copyright
IBM
Corp.
2003
29
v
Limite
de
contagem.
A
contagem
mínima
de
atributos
a
serem
incluídos
no
relatório
de
atividade.
Esse
valor
é
transmitido
como
o
argumento
_threshold
do
predicado
init_event_activity.
O
limite
padrão
é
5.
Para
alterar
esse
valor,
modifique
a
instrução
que
define
o
parâmetro
_do_not_report_count,
da
seguinte
forma:
_do_not_report_count
=
threshold,
threshold
é
a
contagem
mínima
que
você
deseja
incluir
no
relatório
de
atividade.
v
Critérios
de
relatórios.
Você
pode
especificar
a
lista
de
atributos
de
eventos
cujos
valores
deseja
que
sejam
contados
para
o
relatório
de
atividade
de
eventos.
Esse
valor
é
transmitido
como
o
argumento
_attribute_criteria
do
predicado
init_event_activity.
A
lista
padrão
é:
[source,
hostname,
severity,
status,
[hostname,
severity],
[class,
hostname]]
Para
alterar
esse
valor,
modifique
a
instrução
que
define
o
parâmetro
_reporting_criteria,
da
seguinte
forma:
_reporting_criteria
=
[criteria],
criteria
é
uma
lista
que
contém
atributos
simples
ou
grupos
de
vários
atributos.
Para
obter
informações
adicionais
sobre
como
especificar
os
critérios
do
atributo,
consulte
a
descrição
do
predicado
init_event_activity
no
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide.
Regras
Regra
de
Inicialização
regra:
event_activity_configure
A
regra
event_activity_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
escala.
Consulte
“Uso”
na
página
29
para
mais
informações.
Regras
de
Atividade
do
Evento
regra:
update_event_activity
A
regra
update_event_activity
é
executada
durante
o
recebimento
de
qualquer
evento.
Ela
coleta
estatísticas
de
atividades
de
eventos
com
base
nos
critérios
especificados
na
regra
event_activity_configure.
regra
do
cronômetro:
reset_event_activity
A
regra
do
cronômetro
reset_event_activity
grava
periodicamente
as
estatísticas
de
atividade
de
eventos
no
arquivo
de
saída,
com
base
na
freqüência
e
no
nome
do
arquivo
especificado
na
regra
event_activity_configure.
Após
a
gravação
do
relatório,
todas
as
estatísticas
são
zeradas.
30
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Filtragem
de
Eventos
(event_filtering.rls)
Visão
Geral
O
conjunto
de
regras
de
filtragem
de
eventos
contém
regras
que
filtram
eventos
indesejados
com
base
nos
critérios
personalizáveis.
Os
eventos
filtrados
não
aparecem
em
nenhum
console
e
não
são
armazenados
no
cache
de
eventos.
Uso
O
conjunto
de
regras
de
filtragem
de
eventos
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Nota:
Se
ativado,
o
conjunto
de
regras
de
filtragem
de
eventos
deve
ser
listado
próximo
do
início
do
arquivo
rule_sets,
preferencialmente
na
primeira
posição.
Consulte
“Seqüenciamento
e
Dependências
do
Conjunto
de
Regras”
na
página
3
para
mais
informações.
Antes
de
utilizar
esse
conjunto
de
regras,
também
é
necessário
modificar
a
ação
event_filtering_parameters
da
regra
event_filtering_configure
para
especificar
critérios
de
eventos
adicionais
que
deseja
utilizar
para
filtrar
eventos.
Esses
critérios
são
definidos
utilizando
o
predicado
create_event_criteria
(consulte
o
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide
para
obter
informações
adicionais
sobre
esse
predicado).
Cada
instrução
create_event_criteria
define
um
filtro
denominado
que
especifica
um
nome
de
classe,
gravidade,
valores
de
atributos
e
outros
critérios;
os
eventos
de
entrada
podem
ser
comparados
a
esse
filtro
para
determinar
se
eles
devem
ser
eliminados.
Como
exemplo,
são
definidos
dois
critérios
de
filtragem
no
conjunto
de
regras:
harmless_heartbeat
Eventos
de
classe
TEC_Heartbeat
com
gravidade
HARMLESS
harmless_maintenance
Eventos
de
classe
TEC_Maintenance
com
gravidade
HARMLESS
Para
definir
critérios
adicionais,
adicione
instruções
utilizando
o
predicado
create_event_criteria.
Nota:
Após
modificar
esse
conjunto
de
regras,
você
deve
recompilar
e
recarregar
a
base
de
regra.
Regras
Regra
de
Inicialização
regra:
event_filtering_configure
A
regra
event_filtering_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
procedimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
utiliza
o
predicado
create_event_criteria
para
definir
os
critérios
para
a
filtragem
de
eventos.
©
Copyright
IBM
Corp.
2003
31
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
filtragem
de
eventos.
Consulte
“Uso”
na
página
31
para
mais
informações.
Regra
de
Filtragem
de
Eventos
regra:
filter_event
A
regra
filter_event
é
executada
durante
o
recebimento
de
qualquer
evento.
Quando
um
evento
é
recebido,
a
regra
verifica
se
o
evento
corresponde
a
qualquer
um
dos
critérios
definidos
na
regra
event_filtering_configure.
Qualquer
evento
correspondente
é
eliminado.
32
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Limite
de
Eventos
(event_thresholds.rls)
Visão
Geral
O
conjunto
de
regras
de
limite
de
eventos
contém
regras
que
verificam
um
determinado
número
de
eventos
duplicados
em
um
período
de
tempo
especificado.
Se
essa
contagem
for
excedida,
a
gravidade
do
evento
atual
será
aumentada.
Uso
O
conjunto
de
regras
de
limite
de
eventos
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Antes
de
utilizar
esse
conjunto
de
regras,
também
é
necessário
modificar
a
ação
event_thresholds_parameters
da
regra
event_thresholds_configure
para
definir
os
limites
utilizados
pelo
conjunto
de
regras.
Cada
limite
exclusivo
requer
três
instruções
separadas:
v
O
predicado
create_event_criteria
define
um
filtro
denominado
que
especifica
o
tipo
de
evento
que
você
deseja
verificar.
Para
obter
informações
adicionais,
consulte
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide.
v
O
predicado
create_cache_search_criteria
define
uma
pesquisa
do
cache
de
eventos
denominado,
especificando
os
critérios
de
eventos
definidos
anteriormente
e
outros
parâmetros
de
pesquisa.
Para
obter
informações
adicionais,
consulte
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide.
v
O
predicado
create_threshold
define
um
limite
que,
quando
excedido,
aciona
um
aumento
da
gravidade
do
evento
atual.
O
limite
especifica
um
período
de
tempo
(em
segundos)
e
uma
contagem
de
limites
de
eventos;
se
for
recebido
um
número
de
eventos
correspondente
maior
do
que
o
especificado
no
período
de
tempo
especificado,
o
limite
será
excedido.
Para
obter
informações
adicionais,
consulte
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide.
Por
padrão,
a
regra
event_thresholds_configure
configura
dois
limites:
v
Cinco
eventos
CRITICAL
duplicados
em
60
segundos.
v
Dez
eventos
MINOR
duplicados
em
60
segundos.
Para
definir
limites
adicionais,
adicione
instruções
à
regra
event_thresholds_configure
utilizando
os
predicados
create_event_criteria,
create_cache_search_criteria
e
create_threshold.
Nota:
Após
modificar
esse
conjunto
de
regras,
você
deve
recompilar
e
recarregar
a
base
de
regra.
©
Copyright
IBM
Corp.
2003
33
Regras
Regra
de
Inicialização
regra:
event_thresholds_configure
A
regra
event_thresholds_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
os
limites
para
o
conjunto
de
regras.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
limites
de
eventos.
Consulte
“Uso”
na
página
33
para
mais
informações.
Regra
de
Limite
regra:
threshold_rule
A
regra
threshold_rule
é
executada
durante
o
recebimento
de
qualquer
evento.
Quando
um
evento
é
recebido,
a
regra
aplica
os
critérios
de
limite
definidos
na
regra
de
configuração
event_thresholds_configure
e,
se
um
limite
for
excedido,
aumentará
a
gravidade
do
evento.
Além
disso,
a
regra
atualiza
o
atributo
repeat_count
do
evento
atual
para
refletir
o
número
de
eventos
duplicados.
34
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Encaminhamento
(forwarding.rls)
Visão
Geral
O
conjunto
de
regras
de
encaminhamento
de
eventos
que
implementa
o
encaminhamento
automático
de
eventos
para
outro
servidor
de
eventos.
Uso
O
conjunto
de
regras
de
encaminhamento
de
eventos
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Também
é
necessário
definir
a
localização
do
servidor
de
eventos
para
o
qual
os
eventos
são
encaminhados.
O
servidor
de
destino
para
a
função
de
encaminhamento
de
eventos
é
especificado
pelo
arquivo
de
configuração
tec_forward.conf.
Por
padrão,
esse
arquivo
especifica
que
a
função
de
encaminhamento
de
eventos
deve
operar
no
modo
de
teste,
que
envia
eventos
para
um
arquivo.
Para
especificar
um
servidor,
é
necessário
modificar
o
valor
da
palavra-chave
ServerLocation
para
especificar
o
servidor
de
destino.
Também
é
necessário
especificar
TestMode=NO
ou
transformar
a
palavra-chave
TestMode
totalmente
em
um
comentário.
Para
obter
informações
adicionais
sobre
palavras-chave
do
arquivo
de
configuração,
consulte
o
IBM
Tivoli
Enterprise
Console
Event
Integration
Facility
-
Referência.
Também
é
necessário
modificar
a
ação
forwarding_parameters
da
regra
forwarding_configure
para
especificar
os
critérios
de
eventos
que
você
deseja
determinar
quais
eventos
serão
encaminhados.
Esses
critérios
são
definidos
utilizando
o
predicado
create_event_criteria
(consulte
o
IBM
Tivoli
Enterprise
Console
Rule
Developer’s
Guide
para
obter
informações
adicionais
sobre
esse
predicado).
Cada
instrução
create_event_criteria
define
um
filtro
denominado
que
especifica
um
nome
de
classe,
gravidade,
valores
de
atributos
e
outros
critérios;
os
eventos
de
entrada
podem
ser
comparados
a
esse
filtro
para
determinar
se
eles
devem
ser
encaminhados.
Como
exemplo,
são
definidos
dois
critérios
de
encaminhamento
no
conjunto
de
regras:
ups_fatal_forwarding
Eventos
da
classe
upsDischarged
com
gravidade
FATAL
temp_alarm_forwarding
Eventos
da
classe
chassisAlarmOffTempAlarm
com
gravidade
WARNING
ou
FATAL
Para
definir
seus
próprios
critérios,
adicione
instruções
utilizando
o
predicado
create_event_criteria.
Nota:
Após
modificar
esse
conjunto
de
regras,
você
deve
recompilar
e
recarregar
a
base
de
regra.
©
Copyright
IBM
Corp.
2003
35
Regras
Regra
de
Inicialização
regra:
forwarding_configure
A
regra
forwarding_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
utiliza
o
predicado
create_event_criteria
para
definir
os
critérios
para
o
encaminhamento
de
eventos.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
encaminhamento
de
eventos.
Consulte
“Uso”
na
página
35
para
mais
informações.
Regra
de
Encaminhamento
de
Eventos
regra:
forwarding_events
A
regra
forwarding_events
é
executada
durante
o
recebimento
de
qualquer
evento.
Quando
um
evento
é
recebido,
a
regra
verifica
se
ele
corresponde
a
qualquer
um
dos
critérios
definidos
na
regra
forwarding_configure.
Qualquer
evento
correspondente
é
encaminhado
para
o
servidor
de
eventos
especificado
no
arquivo
de
configuração
tec_forward.conf.
36
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Pulsação
(heartbeat.rls)
Visão
Geral
O
conjunto
de
regras
de
pulsação
contém
regras
que
suportam
a
monitoração
de
pulsação.
Essas
regras
processam
eventos
de
atividade
do
sistema
TEC_Heartbeat
de
entrada
enviados
de
hosts
monitorados.
Se
uma
atividade
do
sistema
esperada
não
for
correspondente,
a
notificação
será
enviada
para
o
console
e
também
para
um
administrador
por
e-mail.
A
monitoração
de
pulsação
para
um
determinado
host
começa
durante
o
recebimento
do
primeiro
evento
TEC_Heartbeat
a
partir
desse
host.
Existem
cinco
possíveis
níveis
de
monitoração
de
pulsação:
o
nível
de
monitoração
para
um
determinado
host
é
determinado
pelo
valor
do
atributo
level
dos
eventos
TEC_Heartbeat
a
partir
desse
host
(esse
valor
é
do
tipo
enumerado
HEARTBEAT_LEVEL,
que
é
definido
no
arquivo
tec.baroc).
O
nível
de
monitoração
controla
a
freqüência
com
que
são
esperadas
as
pulsações,
além
da
gravidade
de
eventos
de
pulsação
não-correspondentes.
Os
possíveis
níveis
são:
Tabela
5.
Níveis
de
Monitoração
de
Pulsação
Nível
Freqüência
de
atividade
do
sistema
Gravidade
da
atividade
do
sistema
não
correspondidas
UM
Cada
60
segundos
FATAL
DOIS
Cada
5
minutos
CRITICAL
TRÊS
Cada
10
minutos
MINOR
QUATRO
Cada
30
minutos
WARNING
CINCO
Cada
60
minutos
HARMLESS
Você
pode
alterar
esses
valores
modificando
a
regra
heartbeat_configure.
Quando
uma
atividade
do
sistema
de
pulsação
esperada
é
recebida
de
um
host
monitorado,
o
servidor
de
eventos
registra
o
tempo
da
atividade
do
sistema
e
elimina
o
evento.
Desde
que
não
existam
pulsações
não-correspondentes,
nenhum
evento
será
roteado
para
o
console.
Se
uma
atividade
do
sistema
de
pulsação
esperada
não
for
recebida
de
um
host
monitorado,
as
regras
gerarão
um
evento
TEC_Heartbeat_missed
cujo
atributo
msg
indica
que
uma
atividade
do
sistema
não
é
correspondente,
utilizando
a
gravidade
indicada
pelo
nível
de
monitoração
em
vigor
para
o
host
monitorado.
Como
esse
evento
não
é
eliminado,
ele
aparece
no
console,
notificando
o
operador
de
que
um
sistema
monitorado
pode
estar
inativo.
Além
disso,
é
enviada
uma
notificação
por
para
o
administrador
especificado
na
regra
de
configuração.
A
monitoração
de
pulsação
para
o
host
especificado
é
então
descontinuada
até
que
seja
recebida
outra
atividade
do
sistema
de
pulsação.
Quando
é
feito
um
novo
backup
do
sistema
monitorado,
o
primeiro
evento
de
atividade
do
sistema
TEC_Heartbeat
recebido
pelo
servidor
de
eventos
faz
com
que
o
evento
TEC_Heartbeat_missed
anterior
seja
fechado.
Além
disso,
é
enviada
uma
notificação
por
para
o
administrador
indicando
que
foi
feito
backup
do
sistema
monitorado.
Em
seguida,
é
retomada
a
monitoração
de
pulsação
para
o
sistema.
©
Copyright
IBM
Corp.
2003
37
Uso
Um
conjunto
de
regras
de
pulsação
já
está
ativado
na
base
de
regras
padrão.
Se
você
fizer
alterações
nesse
conjunto
de
regras,
então
é
necessário
recompilar
e
recarregar
a
base
de
regras.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
mais
informações.
Configuração
Opcional
O
conjunto
de
regras
de
pulsação
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
esse
conjunto
de
regras
modificando
as
instruções
na
ação
heartbeat_parameters
da
regra
de
configuração
heartbeat_configure.
Nota:
Embora
o
conjunto
de
regras
de
pulsação
possa
ser
utilizado
sem
nenhuma
personalização,
a
notificação
por
não
funcionará,
a
menos
que
o
endereço
de
do
administrador
seja
definido
utilizando
o
parâmetro
admin_email
conforme
descrito
abaixo.As
opções
a
seguir
são
configuráveis:
v
Níveis
de
monitoração.
Você
pode
especificar
as
freqüências
de
atividade
do
sistema
e
as
gravidades
de
atividades
do
sistema
não-correspondentes
para
os
níveis
de
monitoração.
Os
valores
padrão
estão
descritos
em
“Visão
Geral”
na
página
37.
Para
alterar
os
valores
para
um
nível
de
monitoração,
modifique
a
instrução
rerecord
correspondente,
da
seguinte
forma:
rerecord(heartbeat,
level,
[
seconds,
sev
]),
level
é
o
nome
de
um
dos
cinco
níveis
de
monitoração
colocado
entre
aspas
simples,
seconds
é
o
intervalo
entre
as
atividades
do
sistema
esperadas
e
sev
é
a
gravidade
a
ser
utilizada
para
eventos
de
pulsação
não-correspondentes.
Os
cinco
níveis
de
monitoração
são
UM,
DOIS,
TRÊS,
QUATRO
e
CINCO.
Se
desejar
adicionar
níveis
de
monitoração
adicionais,
também
será
necessário
modificar
a
enumeração
HEARTBEAT_LEVEL
em
tec.baroc.
v
Latência.
Você
pode
especificar
o
período
de
tempo
a
ser
utilizado
quando
pesquisar
no
cache
de
eventos
para
localizar
eventos
a
serem
limpos
quando
é
feito
backup
de
um
host
monitorado.
Por
padrão,
se
um
TEC_Heartbeat
recebido
for
um
evento
de
limpeza,
o
servidor
de
eventos
pesquisará
no
cache
os
eventos
limpos
recebidos
nos
30
minutos
anteriores.
Para
alterar
esse
intervalo,
modifique
a
instrução
que
define
o
parâmetro
heartbeat_timelag,
da
seguinte
forma:
rerecord(heartbeat_timelag,
seconds),
seconds
é
o
número
de
segundos
que
representa
o
quanto
você
deseja
retroceder
para
pesquisar
no
cache
os
eventos
limpos.
Nota:
Esse
parâmetro
define
um
limite
superior
sobre
quanto
tempo
a
pesquisa
retrocederá,
mas
isso
não
garante
que
os
eventos
nesse
período
de
tempo
ainda
estarão
disponíveis.
Se
o
cache
de
eventos
for
muito
pequeno,
os
eventos
poderão
ser
descartados,
mesmo
se
forem
mais
recentes
do
que
o
tempo
especificado.
Se
isso
ocorrer,
considere
aumentar
o
tamanho
do
cache
de
eventos
(consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais).
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
as
regras
de
pulsação
fecharem
eventos
automaticamente.
O
nome
do
administrador
padrão
é
heartbeat.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
o
parâmetro
heartbeat_admin,
da
seguinte
forma:
38
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
rerecord(heartbeat_admin,
admin),
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
v
Endereço
de
do
administrador.
Você
pode
especificar
o
endereço
de
do
administrador
a
ser
notificado
em
caso
de
atividades
do
sistema
de
pulsações
não-correspondentes.
Esse
endereço
é
transmitido
para
a
tarefa
Send_Email
(consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais
sobre
essa
tarefa).
Para
especificar
o
endereço
de
e-mail,
modifique
a
instrução
que
define
o
parâmetro
admin_email,
da
seguinte
forma:
rerecord(admin_email,
email_addr),
email_addr
é
o
endereço
de
que
você
deseja
utilizar,
colocado
entre
aspas
simples.
Regras
Regra
de
Inicialização
regra:
heartbeat_configure
A
regra
heartbeat_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Ela
também
inicia
o
cronômetro
utilizado
para
detectar
pulsações
não-correspondentes
e
define
TEC_Heartbeat
como
um
evento
de
limpeza
para
TEC_Heartbeat_missed
quando
os
dois
eventos
são
provenientes
do
mesmo
host.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
das
regras
de
pulsação.
Consulte
“Uso”
na
página
38
para
mais
informações.
Regras
de
Pulsação
regra:
pulse_received
A
regra
pulse_received
é
executada
durante
o
recebimento
do
evento
TEC_Heartbeat
com
o
atributo
msg
igual
a
pulse,
indicando
uma
atividade
do
sistema
de
pulsação
esperada
de
um
host
monitorado.
Quando
esse
evento
é
recebido,
o
tempo
da
pulsação
é
registrado
e
o
evento
é
eliminado.
O
nível
de
monitoração
em
utilização
para
o
host
de
origem
também
é
atualizado
com
base
no
valor
do
atributo
level.
A
regra
então
verifica
se
o
evento
de
pulsação
recebido
é
um
evento
de
limpeza
para
qualquer
evento
TEC_Heartbeat_missed
anterior
(dentro
do
período
de
tempo
especificado
por
heartbeat_timelag).
Se
for,
o
evento
limpo
será
fechado.
regra
do
cronômetro:
check_heartbeats
A
regra
do
cronômetro
check_heartbeats
verifica
periodicamente
pulsações
não-correspondentes,
com
base
nos
intervalos
de
tempo
especificados
para
os
níveis
de
monitoração
de
pulsação
na
regra
heartbeat_configure.
Ela
primeiro
verifica
o
tempo
atual
do
sistema
e,
em
seguida,
compara
esse
tempo
com
o
tempo
do
evento
de
atividade
do
sistema
de
pulsação
mais
recente
de
cada
host
monitorado.
Se
o
tempo
decorrido
for
maior
do
que
o
período
de
tempo
definido
para
o
nível
de
monitoração
em
vigor
para
esse
host
e
o
sistema
monitorado
não
estiver
no
modo
de
manutenção,
a
regra
gerará
um
evento
TEC_Heartbeat
não-correspondente
para
alertar
o
operador
e
o
administrador.
O
atributo
msg
do
evento
gerado
é
definido
como
o
seguinte:
Nenhuma
Pulsação
recebida
do
host:
hostname
em
seconds
segundos.
Conjunto
de
Regras
de
Pulsação
(heartbeat.rls)
39
hostname
é
o
nome
completo
do
host
monitorado
e
seconds
é
o
tempo
decorrido
desde
a
última
atividade
do
sistema
de
pulsação
recebida
do
host.
A
gravidade
do
evento
é
definida
como
o
valor
apropriado
para
o
nível
de
monitoração
em
vigor
para
o
host.
Nota:
O
tempo
decorrido
pode
ser
maior
do
que
o
período
de
tempo
definido
para
o
nível
de
monitoração.
Uma
pulsação
não-correspondente
não
será
detectada
até
a
próxima
execução
da
regra
do
cronômetro,
que
pode
ocorrer
vários
segundos
após
o
tempo
esperado
para
a
chegada
da
pulsação.
Após
a
geração
desses
eventos,
a
monitoração
para
o
host
será
descontinuada
até
que
seja
recebida
uma
atividade
do
sistema
de
pulsação.
regra:
heartbeat_missed
A
regra
heartbeat_missed
é
executada
durante
o
recebimento
de
um
evento
TEC_Heartbeat_missed,
que
é
gerado
quando
uma
atividade
do
sistema
de
pulsação
esperada
não
chega.
Essa
regra
utiliza
a
tarefa
Send_Email
para
enviar
uma
notificação
por
para
o
administrador
especificado
na
regra
heartbeat_configure.
regra:
heartbeat_restored
A
regra
de
alteração
heartbeat_restored
é
executada
quando
um
evento
TEC_Heartbeat_missed
é
fechado.
Isso
ocorre
quando
um
novo
evento
TEC_Heartbeat
é
recebido,
indicando
que
foi
feito
backup
do
host
monitorado.
Essa
regra
utiliza
a
tarefa
Send_Email
para
enviar
uma
notificação
por
ao
administrador
especificado
na
regra
heartbeat_configure,
indicando
que
foi
recebida
uma
pulsação.
40
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
do
Modo
de
Manutenção
(maintenance_mode.rls)
Visão
Geral
O
conjunto
de
regras
do
modo
de
manutenção
fornece
um
processamento
de
eventos
automatizado
que
pode
ser
utilizado
para
indicar
que
um
sistema
monitorado
está
sendo
colocado
no
modo
de
manutenção
por
um
período
de
tempo
especificado.
Modo
de
manutenção
é
o
estado
de
qualquer
sistema
que
está
recebendo
atualizações
de
softwares,
reinicializações
do
sistema
ou
outras
atividades
de
manutenção
que
podem
gerar
eventos
que
você
não
deseja
que
sejam
processados
pelo
mecanismo
de
regras.
O
início
do
modo
de
manutenção
é
indicado
por
um
evento
de
classe
TEC_Maintenance
cujo
atributo
current_mode
é
igual
a
ON.
Esse
evento
é
enviado
pelo
script
wstartmaint.sh
ou
pela
tarefa
Start_Maintenance.
Quando
esse
evento
chega,
as
regras
registram
um
fato
de
manutenção
na
base
de
conhecimento.
Esse
fato
registra
as
seguintes
informações:
v
O
nome
completo
do
host
do
sistema
que
está
sendo
colocado
em
modo
de
manutenção.
Se
o
atributo
fqhostname
do
evento
TEC_Maintenance
for
igual
a
um
único
asterisco
(*),
isso
indica
que
todos
os
sistemas
monitorados
(exceto
o
servidor
de
eventos)
estão
sendo
colocados
em
modo
de
manutenção.
v
A
hora
de
início
da
manutenção
ou
a
hora
em
que
está
programada
para
iniciar.
Se
nenhuma
hora
de
início
for
especificada,
será
assumida
a
hora
atual.
v
A
duração
máxima
permitida
da
janela
de
manutenção
(o
período
de
tempo
durante
o
qual
o
sistema
está
em
modo
de
manutenção).
Se
a
hora
de
início
para
a
janela
de
manutenção
for
a
hora
atual
(ou
uma
hora
já
passada),
isso
indica
que
o
sistema
especificado
está
sendo
colocado
no
modo
de
manutenção
imediatamente.
Se
a
hora
de
início
estiver
no
futuro,
isso
indica
que
o
sistema
está
programado
para
manutenção
em
alguma
hora
no
futuro.
Em
qualquer
caso,
o
atributo
msg
do
evento
TEC_Maintenance
gerado
indica
que
uma
janela
de
manutenção
foi
iniciada
ou
foi
programada.
Durante
a
janela
de
manutenção,
os
eventos
recebidos
do
sistema
(diferentes
dos
eventos
TEC_Maintenance)
serão
ignorados.
Esses
eventos
serão
fechados
ou
eliminados,
dependendo
de
como
o
conjunto
de
regras
está
configurado
(consulte
“Uso”
na
página
42
para
obter
informações
adicionais).
Quando
tiver
decorrido
a
duração
máxima
permitida
da
janela
de
manutenção
(indicada
pelo
cronômetro
de
manutenção),
o
sistema
monitorado
não
será
mais
considerado
no
modo
de
manutenção
e
será
enviada
uma
mensagem
para
o
console
indicando
que
a
janela
de
manutenção
foi
finalizada.
Se
for
recebido
um
evento
TEC_Maintenance
com
current_mode
igual
a
OFF,
isso
indica
que
um
sistema
concluiu
a
manutenção
ou
que
uma
janela
de
manutenção
programada
foi
cancelada.
Esse
evento
pode
ser
gerado
pelas
regras
do
modo
de
manutenção,
se
a
duração
máxima
de
uma
janela
de
manutenção
tiver
passado,
ou
pode
ser
enviado
pelo
script
wstopmaint.sh
no
sistema
monitorado.
O
tratamento
específico
desse
evento
depende
do
valor
do
atributo
start_time:
v
Se
a
hora
de
início
corresponder
a
uma
janela
de
manutenção
que
está
em
andamento,
a
janela
de
manutenção
será
finalizada
imediatamente.
©
Copyright
IBM
Corp.
2003
41
v
Se
a
hora
de
início
corresponder
a
uma
janela
de
manutenção
que
ainda
não
foi
iniciada,
a
futura
janela
de
manutenção
será
cancelada.
v
Se
a
hora
de
início
não
for
especificada,
todas
as
janelas
de
manutenção
atuais
e
futuras
para
o
sistema
serão
canceladas.
Após
a
finalização
(ou
cancelamento)
de
uma
janela
de
manutenção,
o
fato
de
manutenção
relevante
permanecerá
na
base
de
conhecimento
por
um
período
de
tempo
configurável,
para
permitir
o
processamento
de
eventos
que
chegam
posteriormente.
Quando
tiver
decorrido
esse
período
de
tempo,
qualquer
fato
de
manutenção
relacionado
a
uma
janela
de
manutenção
que
tenha
sido
encerrada
será
retirado
da
base
de
conhecimento.
Uso
O
conjunto
de
regras
do
modo
de
manutenção
já
está
ativado
na
base
de
regras
padrão.
Se
você
fizer
alterações
nesse
conjunto
de
regras,
então
é
necessário
recompilar
e
recarregar
a
base
de
regras.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
mais
informações.
Nota:
Se
ativado,
o
conjunto
de
regras
do
modo
deverá
ser
listado
próximo
do
início
do
arquivo
rule_sets.
Consulte
“Seqüenciamento
e
Dependências
do
Conjunto
de
Regras”
na
página
3
para
mais
informações.
Configuração
Opcional
O
conjunto
de
regras
do
modo
de
manutenção
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
esse
conjunto
de
regras
modificando
as
instruções
na
regra
de
configuração
maintenance_mode_configure.
As
opções
a
seguir
são
configuráveis:
v
Latência.
Você
pode
especificar
por
quanto
tempo
deseja
que
cada
fato
de
manutenção
permaneça
na
base
de
conhecimento
após
a
finalização
da
janela
de
manutenção
correspondente,
para
permitir
o
processamento
de
eventos
que
foram
enviados
durante
uma
janela
de
manutenção,
mas
que
chegaram
depois.
A
latência
padrão
é
de
uma
hora.
Para
alterar
esse
intervalo,
modifique
a
instrução
que
define
a
variável
_over_time,
da
seguinte
forma:
_over_time
=
otime
otime
é
o
período
de
tempo
(em
segundos)
que
você
deseja
manter
fatos
de
manutenção
na
base
de
conhecimento
após
a
finalização
da
manutenção.
v
Gravidade
de
eventos
de
manutenção.
Você
pode
especificar
a
gravidade
de
eventos
TEC_Maintenance
gerado
pelas
regras
do
modo
de
manutenção.
Esses
eventos
são
gerados
quando
uma
janela
de
manutenção
é
finalizada.
A
gravidade
padrão
é
HARMLESS.
Para
alterar
a
gravidade
de
eventos
TEC_Maintenance
gerados,
modifique
a
instrução
que
define
a
variável
_severity,
da
seguinte
forma:
_severity
=
msev
msev
é
uma
gravidade
válida
para
a
classe
de
eventos
TEC_Maintenance.
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
para
utilizar
quando
estiver
reconhecendo
ou
fechando
automaticamente
eventos
TEC_Maintenance
recebidos.
O
nome
do
administrador
padrão
é
maintenance_mode.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
a
variável
_maint_admin,
da
seguinte
forma:
_maint_admin
=
admin
42
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
admin
é
o
nome
do
administrador
a
ser
utilizado.
v
Nome
do
arquivo
de
fatos.
Você
pode
especificar
o
nome
do
arquivo
a
ser
utilizado
para
armazenar
fatos
de
manutenção
na
base
de
conhecimento.
Você
pode
especificar
uma
localização
absoluta
para
o
arquivo
ou
especificar
apenas
o
nome
do
arquivo,
nesse
caso,
o
arquivo
será
criado
no
diretório
$DBDIR.
O
nome
do
arquivo
padrão
é
maintenance_mode.pro.
Para
alterar
o
nome
do
arquivo,
modifique
a
instrução
que
define
a
variável
_maintenance_file,
da
seguinte
forma:
_maintenance_file
=
filename
filename
é
o
nome
do
arquivo
de
fatos
que
você
deseja
utilizar,
incluindo,
opcionalmente,
um
caminho
relativo
ou
absoluto
e
colocado
entre
aspas
simples.
v
Tratamento
de
eventos.
Você
pode
especificar
como
deseja
tratar
eventos
recebidos
de
um
sistema
que
está
em
modo
de
manutenção.
Esses
eventos
podem
ser
fechados
ou
eliminados.
A
ação
padrão
é
fechá-los;
para
alterar
esse
comportamento,
modifique
a
instrução
que
define
a
variável
_maint_action,
da
seguinte
forma:
_maint_action
=
action
action
é
’CLOSE’
ou
’DROP’.
Regras
Regra
de
Inicialização
regra:
maintenance_mode_configure
A
regra
maintenance_mode_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
do
conjunto
de
regras
maintenance_mode.rls.
Consulte
“Uso”
na
página
42
para
mais
informações.
Além
da
definição
de
parâmetros
globais
para
regras
do
modo
de
manutenção,
a
regra
maintenance_mode_configure
também
reinicia
os
cronômetros
de
manutenção
para
quaisquer
janelas
de
manutenção
pendentes
ou
contínuas
que
foram
interrompidas
por
um
reinício
do
servidor
de
eventos.
Regras
de
Manutenção
regra:
maintenance_received
A
regra
maintenance_received
gerencia
janelas
de
manutenção
programadas
para
sistemas
monitorados.
Quando
é
recebido
um
evento
TEC_Maintenance
com
o
atributo
current_mode
definido
como
ON,
essa
regra
registra
um
fato
de
manutenção
que
especifica
a
hora
de
início
e
a
duração
da
janela
de
manutenção
(se
a
duração
especificada
for
0,
essa
regra
gerará
uma
mensagem
de
erro
e
fechará
o
evento
recebido
TEC_Maintenance
sem
executar
nenhuma
ação
adicional).
Se
a
hora
de
início
para
a
janela
de
manutenção
estiver
no
futuro,
essa
regra
iniciará
um
cronômetro
que
expira
no
momento
do
início
da
janela
de
manutenção.
Quando
é
recebido
um
evento
TEC_Maintenance
com
current_mode
definido
como
OFF,
essa
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_Maintenance
correspondente
que
especifica
o
mesmo
sistema
e
a
mesma
hora
de
início.
Qualquer
evento
correspondente
é
fechado.
Qualquer
janela
de
manutenção
em
andamento
para
o
sistema
é
cancelada.
Se
não
for
especificada
nenhuma
hora
de
Conjunto
de
Regras
do
Modo
de
Manutenção
(maintenance_mode.rls)
43
início
pelo
evento
TEC_Maintenance
recebido,
todas
as
janelas
de
manutenção
atuais
e
futuras
para
o
sistema
especificado
serão
canceladas.
regra:
check_maintenance_mode
A
regra
check_maintenance_mode
é
executada
durante
o
recebimento
de
qualquer
evento.
Ela
verifica
se
o
sistema
que
gerou
o
evento
está
no
modo
de
manutenção
(ou
seja,
a
hora
de
início
de
uma
janela
de
manutenção
passou,
mas
a
duração
da
janela
de
manutenção
ainda
não
passou).
Se
o
sistema
estiver
no
modo
de
manutenção,
o
evento
recebido
será
fechado
ou
eliminado
(dependendo
da
configuração)
sem
nenhuma
ação
adicional.
Nota:
Essa
regra
não
elimina
nem
fecha
eventos
do
servidor
de
eventos.
O
servidor
de
eventos
não
pode
ser
colocado
no
modo
de
manutenção.
Regras
do
Cronômetro
regra
do
cronômetro:
check_maintenance_timeout
A
regra
do
cronômetro
check_maintenance_timeout
verifica
periodicamente
para
determinar
se
algum
sistema
permaneceu
no
modo
de
manutenção
por
um
período
de
tempo
maior
do
que
o
máximo
permitido
para
a
janela
de
manutenção.
Se
a
duração
máxima
da
janela
de
manutenção
tiver
passado
e
o
sistema
ainda
estiver
no
modo
de
manutenção,
essa
regra
finalizará
a
janela
de
manutenção
e
gerará
uma
mensagem
indicando
que
isso
ocorreu.
Além
disso,
ela
gerará
um
evento
TEC_Maintenance
com
current_mode
definido
como
OFF.
regra
do
cronômetro:
start_maintenance_timer
A
regra
do
cronômetro
start_maintenance_timer
verificará
se
chegou
a
hora
de
início
para
qualquer
janela
de
manutenção
programada.
Essa
regra
é
acionada
pela
expiração
de
um
cronômetro
de
manutenção
definido
pela
regra
maintenance_received;
esse
cronômetro
é
definido
durante
o
recebimento
de
um
evento
TEC_Maintenance
que
especifica
uma
janela
de
manutenção
no
futuro.
Se
qualquer
sistema
estiver
programado
para
iniciar
uma
janela
de
manutenção,
a
regra
start_maintenance_timer
gerará
uma
mensagem
indicando
que
o
sistema
especificado
entrou
no
modo
de
manutenção
e
iniciará
um
cronômetro
que
expira
quando
tiver
passado
a
duração
máxima
da
janela
de
manutenção.
regra
do
cronômetro:
check_overtime_timer
A
regra
do
cronômetro
check_overtime_timer
verifica
se
é
hora
de
retirar
quaisquer
fatos
de
manutenção
da
base
de
conhecimento.
Os
fatos
de
manutenção
são
mantidos
na
base
de
conhecimento
por
um
período
de
tempo
configurável
após
a
finalização
da
janela
de
manutenção,
para
permitir
o
tratamento
de
eventos
relacionados
que
chegam
posteriormente.
Esse
intervalo
é
determinado
pelo
parâmetro
_over_time
na
regra
de
configuração
maintenance_mode_configure.
Quando
tiver
passado
o
período
de
tempo
especificado
desde
a
finalização
da
janela
de
manutenção,
a
regra
check_overtime_timer
retirará
o
fato
de
manutenção
relevante
da
base
de
conhecimento.
44
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
do
NetView
(netview.rls)
Visão
Geral
O
conjunto
de
regras
do
NetView
contém
regras
que
tratam
eventos
a
partir
do
componente
do
NetView.
Essas
regras
correlacionam
eventos
do
NetView
relacionados
e
gerenciam
a
sincronização
do
servidor
de
eventos
com
o
componente
NetView.
As
regras
do
NetView
podem
ser
divididas
em
quatro
categorias
principais,
sendo
que
cada
uma
delas
executa
uma
função
diferente:
v
Regras
de
baixa
gravidade
v
Regras
de
limpeza
de
eventos
v
Regras
de
sincronização
v
Regras
de
correlação
Regras
de
Ajuste
de
Gravidade
As
regras
de
ajuste
de
gravidade
modificam
a
gravidade
de
eventos
recebido
para
refletir
mais
precisamente
se
eles
representam
problemas
na
rede.
Por
padrão,
os
eventos
recebidos
do
componente
NetView
possuem
uma
gravidade
WARNING.
No
entanto,
alguns
desses
eventos
são,
na
realidade,
eventos
de
limpeza,
indicando
a
resolução
de
um
problema
em
vez
de
um
novo
problema.
Isso
inclui
vários
eventos
de
status
indicando
um
status
de
UP,
além
de
eventos
de
limite
rearmados.
Além
disso,
alguns
eventos
são
informativos
e
não
representam
problemas,
tais
como
eventos
″adicionados″
indicando
que
a
monitoração
foi
iniciada
para
um
recurso
de
rede
recém-adicionado.
As
regras
de
ajuste
de
gravidade
no
conjunto
de
regras
NetView
detectam
esses
eventos
e
reduzem
sua
gravidade
para
HARMLESS.
Além
disso,
essas
regras
geram
a
gravidade
de
eventos
de
status
do
roteador,
indicando
um
status
DOWN.
Regras
de
Limpeza
de
Eventos
As
regras
de
limpeza
de
eventos
tratam
eventos
que
atualizam
eventos
de
status
recebidos
anteriormente.
Em
alguns
casos,
esses
são
eventos
de
limpeza
que
indicam
a
resolução
de
um
problema
anterior.
Por
exemplo,
um
evento
TEC_ITS_NODE_STATUS
com
o
atributo
nodestatus
igual
a
UP
limpa
os
eventos
TEC_ITS_NODE_STATUS
ou
TEC_ITS_NODE_SERVICE_IMPACT
recebidos
anteriormente
do
mesmo
nó.
Em
outros
casos,
o
evento
recém-recebido
pode
indicar
a
continuação
de
um
problema
anterior
ou
pode
indicar
que
um
nó
ou
interface
foi
excluída
e
não
está
mais
sendo
monitorada.
Quando
é
recebido
um
desses
eventos
de
status,
as
regras
de
limpeza
de
eventos
pesquisam
quaisquer
eventos
recebidos
anteriormente,
limpos
pelo
novo
evento.
Será
feito
downgrade
de
eventos
limpos
para
HARMLESS
e
eles
serão
fechados,
assegurando
que
apenas
o
evento
com
status
mais
atual
permanece
aberto.
Se
o
novo
evento
indicar
a
continuação
de
um
problema
anterior,
a
gravidade
do
novo
evento
será
aumentada.
Regras
de
Sincronização
As
regras
de
sincronização
mantêm
eventos
do
Tivoli
Enterprise
Console
sincronizados
com
o
componente
NetView.
Essas
regras
processam
alterações
no
©
Copyright
IBM
Corp.
2003
45
status
de
alguns
eventos
do
NetView
e
enviam
traps
de
sincronização
SNMP
para
o
componente
NetView
para
manter
o
console
do
NetView
atualizado.
Essas
regras
são
acionadas
quando
o
status
de
um
nó
do
NetView,
roteador
ou
evento
de
status
da
interface
é
alterado
para
ACK
ou
CLOSED
ou
é
alterado
de
ACK
para
qualquer
outro
status.
Quando
isso
ocorre,
a
alteração
é
armazenada
em
buffer
para
sincronização.
Periodicamente,
as
regras
enviam
traps
de
sincronização
para
o
componente
NetView
para
sincronizar
o
status
desses
eventos.
Você
pode
personalizar
a
freqüência
desses
traps
de
sincronização;
consulte
“Uso”
na
página
47
para
obter
informações
adicionais.
Regras
de
Correlação
As
regras
de
correlação
processam
eventos
da
rede
para
identificar
relacionamentos
causais.
Quando
é
detectado
que
um
evento
é
efeito
de
outro
evento,
os
dois
eventos
são
vinculados
utilizando
o
predicado
link_effect_to_cause.
Dependendo
de
classes
específicas
dos
eventos
de
causa
e
de
efeito,
também
pode
ocorrer
processamento
adicional,
tal
como
downgrade
e
fechamento
de
eventos
de
efeito
ou
upgrade
da
gravidade
dos
eventos
de
causa.
Para
que
os
eventos
do
NetView
sejam
correlacionados,
os
dois
eventos
devem
ser
provenientes
do
mesmo
servidor
NetView.
Os
eventos
correlacionados
por
essas
regras
estão
em
várias
categorias
amplas:
v
Eventos
de
impacto
de
serviços
da
rede.
Esses
eventos
indicam
condições
da
rede
que
afetam
os
serviços
monitorados
pelo
IBM
Tivoli
Monitoring.
v
Eventos
da
rede
nível
2.
Esses
eventos
indicam
condições
de
rede
de
nível
inferior
detectadas
pelo
produto
IBM
Tivoli
Switch
Analyzer.
v
Eventos
da
rede
nível
3.
Esses
eventos
indicam
condições
de
rede
detectadas
pelo
componente
NetView.
v
Eventos
de
pulsações
não-correspondentes.
Esses
eventos
indicam
atividades
do
sistema
não-correspondentes
e
são
gerados
pelo
conjunto
de
regras
de
pulsação
(heartbeat.rls).
A
tabela
a
seguir
resume
os
eventos
de
efeito
e
possíveis
eventos
de
causa
correlacionados
pelo
conjunto
de
regras
do
NetView.
Tabela
6.
Evento
de
efeito
Possíveis
eventos
de
causa
TEC_ITS_NODE_SERVICE_IMPACT
v
TEC_ITS_NODE_STATUS
(nodestatus=DOWN,
MARGINAL
ou
UNREACHABLE)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=DOWN,
MARGINAL
ou
UNREACHABLE)
TEC_ITS_SUBNET_SERVICE_IMPACT
v
TEC_ITS_SUBNET_CONNECTIVITY
(reachability=UNREACHABLE)
TEC_ITS_SA_STATUS
(sastatus=nodeDown,
nodeMarginal
ou
ifDown)
v
TEC_ITS_NODE_STATUS
(nodestatus=DOWN,
MARGINAL
ou
UNREACHABLE)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=DOWN,
MARGINAL
ou
UNREACHABLE)
TEC_ITS_SA_STATUS
(sastatus=nodeUp
ou
ifUp)
v
TEC_ITS_NODE_STATUS
(nodestatus=UP)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=UP)
TEC_ITS_L2_NODE_STATUS
v
TEC_ITS_SA_STATUS
TEC_ITS_SUBNET_CONNECTIVITY
(reachability=UNREACHABLE)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=DOWN,
MARGINAL
ou
UNREACHABLE)
46
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Tabela
6.
(continuação)
Evento
de
efeito
Possíveis
eventos
de
causa
TEC_ITS_INTERFACE_STATUS
(ifstatus=DOWN,
ADMIN_DOWN
ou
UNREACHABLE)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=DOWN)
v
TEC_ITS_NODE_STATUS
(nodestatus=DOWN,
MARGINAL
ou
UNREACHABLE)
v
TEC_ITS_L2_NODE_STATUS
TEC_ITS_ROUTER_STATUS
(routerstatus=MARGINAL
ou
UNREACHABLE)
v
TEC_ITS_INTERFACE_STATUS
(ifstatus=DOWN,
ADMIN_DOWN
ou
UNREACHABLE)
TEC_ITS_SUBNET_CONNECTIVITY
(reachability=REACHABLE_AGAIN)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=UP)
TEC_ITS_INTERFACE_STATUS
(ifstatus=UP)
v
TEC_ITS_ROUTER_STATUS
(routerstatus=UP)
v
TEC_ITS_NODE_STATUS
(nodestatus=UP)
TEC_ITS_UNREACHABLE
v
TEC_ITS_SUBNET_CONNECTIVITY
(reachability=UNREACHABLE)
TEC_Heartbeat_missed
v
TEC_ITS_SUBNET_CONNECTIVITY
(reachability=UNREACHABLE)
v
TEC_ITS_NODE_STATUS
(nodestatus
não
UP)
v
TEC_ITS_ROUTER_STATUS
(routerstatus
não
UP)
Uso
O
conjunto
de
regras
do
NetView
já
está
ativado
na
base
de
regras
padrão.
Se
você
fizer
alterações
nesse
conjunto
de
regras,
deverá
recompilar
e
recarregar
a
base
de
regra
e
reiniciar
o
servidor
de
eventos.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
mais
informações.
Configuração
Opcional
O
conjunto
de
regras
do
NetView
está
pré-configurado
e
pronto
para
utilização.
No
entanto,
você
pode
personalizar
essa
regra
modificando
instruções
na
ação
netview_rules_parms
da
regra
de
configuração
netview_configure.
As
opções
a
seguir
são
configuráveis:
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
confirmar
o
recebimento
ou
fechar
automaticamente
os
eventos.
O
nome
do
administrador
padrão
é
netview.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
na
ação
netview_rules_parms
que
define
o
parâmetro
netview_admin:
rerecord(netview_admin,
admin),
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
v
Latência.
Você
pode
especificar
o
intervalo
de
tempo
a
ser
utilizado
quando
pesquisar
eventos
no
cache
de
eventos.
Esse
intervalo
de
tempo,
ou
latência,
afeta
pesquisas
de
eventos
de
retrocesso
e
de
avanço.
Por
padrão,
as
pesquisas
são
limitadas
em
dez
minutos
(600
segundos)
de
retrocesso
ou
de
avanço
no
cache
de
eventos.
Para
alterar
a
latência,
modifique
a
instrução
na
ação
netview_rules_parms
que
define
o
parâmetro
nv_latency:
rerecord(nv_latency,
seconds),
seconds
é
o
número
de
segundos
que
representa
o
quanto
você
deseja
retroceder
ou
avançar
para
pesquisar
eventos
no
cache.
Nota:
Esse
parâmetro
define
um
limite
superior
sobre
quanto
tempo
a
pesquisa
retrocederá,
mas
isso
não
garante
que
os
eventos
nesse
período
de
tempo
Conjunto
de
Regras
do
NetView
(netview.rls)
47
ainda
estarão
disponíveis.
Se
o
cache
de
eventos
for
muito
pequeno,
os
eventos
poderão
ser
descartados,
mesmo
se
forem
mais
recentes
do
que
o
tempo
especificado.
Se
isso
ocorrer,
considere
aumentar
o
tamanho
do
cache
de
eventos
(consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais).
v
Tempo
limite
do
buffer
de
sincronização.
Você
pode
especificar
o
valor
de
tempo
limite
para
sincronizar
batches
de
eventos
do
NetView
armazenados
em
buffer.
Os
eventos
que
precisam
ser
sincronizados
com
o
componente
NetView
são
armazenados
em
buffer
parar
sincronização
em
batches.
Periodicamente,
as
regras
do
NetView
enviam
um
trap
SNMP
para
cada
host
do
NetView
afetado,
acionando
a
sincronização.
O
intervalo
padrão
entre
batches
de
sincronização
é
de
30
segundos.
Para
alterar
esse
intervalo,
modifique
a
instrução
na
ação
netview_rules_parms
que
define
o
parâmetro
nvsync_timeout:
rerecord(nvsync_timeout,
seconds),
seconds
é
o
período
de
tempo
(em
segundos)
que
você
deseja
armazenar
em
buffer
eventos
antes
de
cada
batch
de
sincronização.
v
Porta
de
trap
SNMP.
Você
pode
especificar
a
porta
TCP/IP
a
ser
utilizada
para
enviar
traps
SNMP
para
o
componente
NetView.
A
porta
padrão
é
162.
Para
alterar
a
porta
SNMP,
modifique
a
instrução
na
ação
netview_rules_parms
que
define
o
parâmetro
nvsync_port:
rerecord(nvsync_port,
port),
port
é
o
número
da
porta
a
ser
utilizada.
v
Hosts
por
batch
de
sincronização.
Você
pode
especificar
o
número
máximo
de
hosts
a
serem
incluídos
em
um
único
batch
de
sincronização.
Cada
batch
de
sincronização
é
tratado
por
uma
única
tarefa
com
argumentos
da
linha
de
comandos
que
especificam
os
hosts
que
estão
recebendo
traps
SNMP.
Como
alguns
sistemas
operacionais
possuem
limitações
no
comprimento
de
cadeias
da
linha
de
comandos,
você
pode
limitar
o
número
de
hosts
que
podem
ser
incluídos
em
um
único
batch.
Quando
um
evento
é
armazenado
em
buffer
para
sincronização,
as
regras
verificam
se
foi
alcançado
o
número
máximo
de
hosts
distintos.
Se
tiver
sido,
os
eventos
armazenados
em
buffer
serão
imediatamente
sincronizados,
mesmo
que
o
período
de
tempo
limite
de
sincronização
ainda
não
tenha
passado
desde
a
última
sincronização.
O
máximo
padrão
é
de
10
hosts
distintos.
Para
alterar
esse
máximo,
modifique
a
instrução
na
ação
netview_rules_parms
que
define
o
parâmetro
nvsync_maxhosts:
rerecord(nvsync_maxhosts,
hosts),
hosts
é
o
número
máximo
de
hosts.
v
Registro
de
depuração.
Você
pode
especificar
se
deseja
depurar
as
informações
de
depuração
em
um
arquivo
de
log.
Isso
pode
ser
útil
se
você
estiver
modificando
o
conjunto
de
regras.
Essa
função
deve
ser
desativada
sempre
antes
de
o
conjunto
de
regras
ser
implementado
em
um
ambiente
de
produção,
pois
afeta
o
desempenho.
Para
ativar
a
depuração
de
mensagens,
modifique
a
instrução
na
ação
debug_setup
que
define
o
parâmetro
netview_debug:
rerecord(netview_debug,
’yes’),
v
Nome
do
arquivo
do
log
de
depuração.
Você
pode
especificar
o
nome
do
arquivo
de
log
utilizado
para
depurar
mensagens.
Esse
arquivo
será
utilizado
apenas
se
netview_debug
estiver
definido
como
yes.
Você
pode
especificar
uma
localização
absoluta
para
o
arquivo
ou
especificar
apenas
o
nome
do
arquivo;
nesse
caso,
o
arquivo
será
criado
no
diretório
$DBDIR.
O
valor
padrão
é
netview.log.
Para
especificar
um
arquivo
diferente,
modifique
a
instrução
na
ação
debug_setup
que
define
o
parâmetro
netview_logfile:
48
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
rerecord(netview_logfile,
filename),
filename
é
o
nome
do
arquivo
de
log
que
você
deseja
utilizar,
colocado
entre
aspas
simples.
Regras
Regras
de
Inicialização
e
Encerramento
regra:
netview_configure
A
regra
netview_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
parâmetros
globais
para
as
regras
do
NetView,
confirma
os
predicados
auxiliares
para
utilização
interna
e
inicializa
os
arquivos
de
log
para
o
conjunto
de
regras.
Personalizando
essa
regra,
você
pode
configurar
o
comportamento
do
conjunto
de
regras
netview.rls.
Consulte
“Uso”
na
página
47
para
mais
informações.
regra:
shutdown
A
regra
shutdown
é
executada
no
recebimento
do
evento
TEC_Stop,
que
é
enviado
quando
o
servidor
de
eventos
é
encerrado.
Essa
regra
finaliza
os
arquivos
de
log
abertos
para
o
conjunto
de
regras.
Regras
de
Ajuste
de
Gravidade
regra:
router_raise
A
regra
router_raise
é
executada
durante
o
recebimento
do
evento
TEC_ITS_ROUTER_STATUS.
Se
o
atributo
routerstatus
do
evento
recebido
for
igual
a
DOWN,
a
gravidade
do
evento
será
definida
como
CRITICAL.
regra:
interface_lower
A
regra
interface_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_INTERFACE_STATUS.
Se
o
atributo
ifstatus
do
evento
recebido
for
igual
a
UP,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
isdn_lower
A
regra
isdn_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_ISDN_STATUS.
Se
o
atributo
isdnstatus
do
evento
recebido
for
igual
a
ACTIVE,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
snmp_lower
A
regra
snmp_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SNMPCOLLECT_THRESHOLD.
Se
o
atributo
snmpstatus
do
evento
recebido
for
igual
a
REARMED,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
node_lower
A
regra
node_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_STATUS.
Se
o
atributo
nodestatus
do
evento
recebido
for
igual
a
UP,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
router_lower
A
regra
router_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_ROUTER_STATUS.
Se
o
atributo
routerstatus
do
evento
recebido
for
igual
a
UP,
a
gravidade
do
evento
será
definida
como
HARMLESS.
Conjunto
de
Regras
do
NetView
(netview.rls)
49
regra:
subnet_lower
A
regra
subnet_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SUBNET_CONNECTIVITY.
Se
o
atributo
reachability
do
evento
recebido
for
igual
a
REACHABLE_AGAIN,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
interface_added_lower
A
regra
interface_added_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_INTERFACE_ADDED.
Se
o
atributo
action
do
evento
recebido
for
igual
a
ADDED,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
interface_managed_lower
A
regra
interface_managed_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_INTERFACE_MANAGE.
Se
o
atributo
manage
do
evento
recebido
for
igual
a
MANAGE,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
node_added_lower
A
regra
node_added_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_ADDED.
Se
o
atributo
action
do
evento
recebido
for
igual
a
ADDED,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
node_managed_lower
A
regra
node_managed_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_MANAGE.
Se
o
atributo
manage
do
evento
recebido
for
igual
a
MANAGE,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
sa_status_lower
A
regra
sa_status_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SA_STATUS.
Se
o
atributo
sastatus
do
evento
recebido
for
igual
a
ifUp,
nodeUp
ou
nodeResolved,
a
gravidade
do
evento
será
definida
como
HARMLESS.
regra:
l2_status_lower
A
regra
l2_status_lower
é
executada
durante
o
recebimento
do
evento
TEC_ITS_L2_NODE_STATUS.
Se
o
atributo
l2status
do
evento
recebido
for
igual
a
UP,
a
gravidade
do
evento
será
definida
como
HARMLESS.
Regras
de
Limpeza
de
Eventos
regra:
interface_clearing
A
regra
interface_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_INTERFACE_STATUS.
Quando
esse
evento
for
recebido,
será
feito
downgrade
de
eventos
de
status
anteriores
para
a
mesma
interface
para
HARMLESS
e
eles
serão
fechados.
regra:
isdn_clearing
A
regra
isdn_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_ISDN_STATUS.
Quando
esse
evento
for
recebido,
será
feito
downgrade
de
eventos
de
status
anteriores
para
a
mesma
interface
ISDN
para
HARMLESS
e
eles
serão
fechados.
regra:
snmp_clearing
A
regra
snmp_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SNMPCOLLECT_THRESHOLD.
Quando
esse
evento
for
recebido,
será
feito
downgrade
dos
eventos
de
limites
anteriores
para
o
mesmo
daemon
de
coleção
SNMP
para
HARMLESS
e
eles
serão
fechados.
50
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
regra:
node_clearing
A
regra
node_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_STATUS.
Quando
esse
evento
for
recebido,
será
feito
downgrade
dos
eventos
de
status
anteriores
para
o
mesmo
nó
para
HARMLESS
e
eles
serão
fechados.
Se
o
atributo
nodestatus
do
evento
recebido
for
igual
a
UP,
será
feito
o
downgrade
dos
eventos
TEC_ITS_NODE_SERVICE_IMPACT
anteriores
para
o
mesmo
nó
para
HARMLESS
e
eles
serão
fechados.
regra:
router_clearing
A
regra
router_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_ROUTER_STATUS.
Quando
esse
evento
for
recebido,
será
feito
downgrade
dos
eventos
de
status
anteriores
para
o
mesmo
roteador
para
HARMLESS
e
eles
serão
fechados.
Se
o
atributo
routerstatus
do
evento
recebido
for
igual
a
UP,
será
feito
downgrade
dos
eventos
TEC_ITS_NODE_SERVICE_IMPACT
anteriores
para
o
mesmo
host
para
HARMLESS
e
eles
serão
fechados.
regra:
subnet_clearing
A
regra
subnet_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SUBNET_CONNECTIVITY.
Quando
esse
evento
for
recebido,
será
feito
downgrade
dos
eventos
de
conectividade
anteriores
para
a
mesma
sub-rede
para
HARMLESS
e
eles
serão
fechados.
Se
o
atributo
reachability
do
evento
recebido
for
igual
a
REACHABLE_AGAIN,
será
feito
downgrade
dos
eventos
TEC_ITS_SUBNET_SERVICE_IMPACT
anteriores
para
a
mesma
sub-rede
para
HARMLESS
e
eles
serão
fechados.
regra:
l2_status_clearing
A
regra
l2_status_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_L2_NODE_STATUS.
Quando
esse
evento
for
recebido,
será
feito
downgrade
dos
eventos
de
status
L2
anteriores
para
o
mesmo
nó
para
HARMLESS
e
eles
serão
fechados.
regra:
node_service_impact_clearing
A
regra
node_service_impact_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_SERVICE_IMPACT.
Quando
esse
evento
for
recebido,
será
feito
downgrade
dos
eventos
de
impacto
de
serviços
anteriores
para
o
mesmo
nó
e
serviço
para
HARMLESS
e
eles
serão
fechados.
regra:
subnet_service_impact_clearing
A
regra
subnet_service_impact_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SUBNET_SERVICE_IMPACT.
Quando
esse
evento
for
recebido,
será
feito
downgrade
de
eventos
de
impacto
de
serviços
anteriores
para
a
mesma
sub-rede
e
serviço
para
HARMLESS
e
eles
serão
fechados.
regra:
sa_status_clearing
A
regra
sa_status_clearing
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SA_STATUS.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
os
eventos
TE_ITS_SA_STATUS
recebidos
anteriormente
para
o
mesmo
host
e
com
o
mesmo
valor
de
atributo
saticketnumber.
Se
forem
localizados
eventos
correspondentes,
será
feito
downgrade
deles
para
HARMLESS
e
eles
serão
fechados.
Além
disso,
se
os
atributos
sastatus
do
evento
recebido
anteriormente
forem
iguais
a
ifDown,
nodeDown
ou
nodeMarginal
e
o
atributo
sastatus
do
novo
evento
também
será
igual
a
ifDown,
nodeDown
ou
nodeMarginal,
a
gravidade
do
novo
evento
será
aumentada
para
CRITICAL.
Conjunto
de
Regras
do
NetView
(netview.rls)
51
regra:
interface_deleted
A
regra
interface_deleted
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_INTERFACE_ADDED
com
action
igual
a
DELETED.
Quando
esse
evento
é
recebido,
essa
regra
fecha
os
eventos
de
status
anteriores
da
mesma
interface
e,
em
seguida,
elimina
o
evento
recebido.
regra:
interface_unmanaged
A
regra
interface_unmanaged
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_INTERFACE_MANAGE
com
manage
igual
a
UNMANAGE.
Quando
esse
evento
é
recebido,
essa
regra
fecha
os
eventos
de
status
anteriores
da
mesma
interface
e,
em
seguida,
elimina
o
evento
recebido.
regra:
node_deleted
A
regra
node_deleted
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_ADDED
com
action
igual
a
DELETED.
Quando
esse
evento
é
recebido,
essa
regra
fecha
quaisquer
eventos
de
status
anteriores
do
nó,
de
status
do
roteador
ou
de
eventos
de
status
de
interface
no
mesmo
host
e,
em
seguida,
elimina
o
evento
recebido.
regra:
node_unmanaged
A
regra
node_unmanaged
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_MANAGE
com
manage
igual
a
UNMANAGE.
Quando
esse
evento
é
recebido,
essa
regra
fecha
quaisquer
eventos
de
status
anteriores
do
nó,
de
status
do
roteador
ou
de
eventos
de
status
de
interface
no
mesmo
host
e,
em
seguida,
elimina
o
evento
recebido.
Regras
de
Sincronização
regra
de
alteração:
interface_synchronization
A
regra
de
alteração
interface_synchronization
é
executada
quando
o
status
de
um
evento
TEC_ITS_INTERFACE_STATUS
é
alterado.
Quando
isso
ocorre,
o
evento
é
armazenado
em
buffer
para
sincronização
com
o
componente
NetView.
São
armazenados
em
buffer
três
tipos
de
alterações:
acknowledged
status
agora
é
igual
a
ACK.
unacknowledged
status
anteriormente
era
igual
a
ACK,
mas
foi
alterado
para
um
outro
status
(diferente
de
CLOSED).
closed
status
foi
alterado
para
CLOSED.
regra
do
cronômetro:
flush_if_ack
A
regra
do
cronômetro
flush_if_ack
limpa
periodicamente
os
eventos
de
interface
com
confirmação
de
recebimento
e
sincroniza-os
com
o
componente
NetView.
regra
do
cronômetro:
flush_if_unack
A
regra
do
cronômetro
flush_if_unack
limpa
periodicamente
os
eventos
da
interface
sem
confirmação
de
recebimento
e
sincroniza-os
com
o
componente
NetView.
regra
do
cronômetro:
flush_if_close
A
regra
do
cronômetro
flush_if_close
limpa
periodicamente
os
eventos
de
interface
fechados
e
sincroniza-os
com
o
componente
NetView.
regra
de
alteração:
node_synchronization
A
regra
de
alteração
node_synchronization
é
executada
quando
o
status
de
um
evento
TEC_ITS_NODE_STATUS
ou
TEC_ITS_ROUTER_STATUS
é
alterado.
52
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Quando
isso
ocorre,
o
evento
é
armazenado
em
buffer
para
sincronização
com
o
componente
NetView.
São
armazenados
em
buffer
três
tipos
de
alterações:
acknowledged
status
agora
é
igual
a
ACK.
unacknowledged
status
anteriormente
era
igual
a
ACK,
mas
foi
alterado
para
um
outro
status
(diferente
de
CLOSED).
closed
status
foi
alterado
para
CLOSED.
regra
do
cronômetro:
flush_node_ack
A
regra
do
cronômetro
flush_node_ack
limpa
periodicamente
eventos
do
nó
ou
do
roteador
com
confirmação
de
recebimento
e
sincroniza-os
com
o
componente
NetView.
regra
do
cronômetro:
flush_node_unack
A
regra
do
cronômetro
flush_node_unack
limpa
periodicamente
eventos
do
nó
ou
do
roteador
sem
confirmação
de
recebimento
e
sincroniza-os
com
o
componente
NetView.
regra
do
cronômetro:
flush_node_close
A
regra
do
cronômetro
flush_node_close
limpa
periodicamente
eventos
do
nó
ou
do
roteador
fechados
e
sincroniza-os
com
o
componente
NetView.
Regras
de
Correlação
regra:
service_impact_link_node
A
regra
service_impact_link_node
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_SERVICE_IMPACT.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_ITS_NODE_STATUS
aberto
para
o
mesmo
nó
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause
e
o
evento
de
efeito
(TEC_ITS_NODE_SERVICE_IMPACT)
terá
confirmação
de
recebimento.
A
gravidade
do
evento
de
causa
(TEC_ITS_NODE_STATUS)
recebe
upgrade.
A
nova
gravidade
será
FATAL
se
o
IBM
Tivoli
Monitoring
relatar
um
impacto
de
serviços;
de
outra
maneira,
será
CRITICAL
(se
a
gravidade
já
for
FATAL,
ela
não
é
alterada).
Se
o
evento
TEC_ITS_NODE_STATUS
estiver
vinculado
a
um
evento
de
causa
do
NetView
aberto,
a
nova
gravidade
do
evento
do
roteador
será
propagada
para
seu
evento
de
causa.
regra:
node_link_service_impact
A
regra
node_link_service_impact
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_NODE_SERVICE_IMPACT
abertos
para
o
mesmo
nó.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause
e,
em
seguida,
terão
seu
recebimento
confirmado.
A
gravidade
do
evento
de
causa
(TEC_ITS_NODE_STATUS)
recebe
upgrade.
A
nova
gravidade
é
FATAL
se
o
IBM
Tivoli
Monitoring
relatar
um
impacto
de
serviço;
caso
contrário,
ela
é
CRITICAL
(se
a
gravidade
já
for
FATAL,
ela
não
é
alterada).
Conjunto
de
Regras
do
NetView
(netview.rls)
53
Se
o
evento
TEC_ITS_NODE_STATUS
estiver
vinculado
a
um
evento
de
causa
do
NetView
aberto,
a
nova
gravidade
do
evento
do
roteador
será
propagada
para
seu
evento
de
causa.
regra:
service_impact_link_router
A
regra
service_impact_link_router
é
executada
durante
o
recebimento
do
evento
TEC_ITS_NODE_SERVICE_IMPACT.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
aberto
para
o
mesmo
host
com
routerstatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause
e
o
evento
de
efeito
(TEC_ITS_NODE_SERVICE_IMPACT)
terá
confirmação
de
recebimento.
A
gravidade
do
evento
de
causa
(TEC_ITS_ROUTER_STATUS)
recebe
upgrade.
A
nova
gravidade
será
FATAL
se
o
IBM
Tivoli
Monitoring
relatar
um
impacto
de
serviços;
de
outra
maneira,
será
CRITICAL
(se
a
gravidade
já
for
FATAL,
ela
não
é
alterada).
Se
o
routerstatus
do
evento
TEC_ITS_ROUTER_STATUS
for
igual
a
MARGINAL
ou
UNREACHABLE
e
ele
mesmo
estiver
vinculado
a
um
evento
de
causa
do
NetView
aberto,
a
nova
gravidade
do
evento
do
roteador
será
propagada
para
seu
evento
de
causa.
regra:
router_link_service_impact
A
regra
router_link_service_impact
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_NODE_SERVICE_IMPACT
abertos
para
o
mesmo
host.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause
e
terão
seu
recebimento
confirmado.
A
gravidade
do
evento
de
causa
(TEC_ITS_ROUTER_STATUS)
recebe
upgrade.
A
nova
gravidade
será
FATAL
se
o
IBM
Tivoli
Monitoring
relatar
um
impacto
de
serviços;
de
outra
maneira,
será
CRITICAL
(se
a
gravidade
já
for
FATAL,
ela
não
é
alterada).
Se
o
routerstatus
do
evento
TEC_ITS_ROUTER_STATUS
for
igual
a
MARGINAL
ou
UNREACHABLE
e
o
evento
estiver
vinculado
a
um
evento
de
causa
do
NetView
fechado,
a
nova
gravidade
do
evento
do
roteador
será
propagada
para
seu
evento
de
causa.
regra:
service_impact_link_subnet
A
regra
service_impact_link_subnet
é
executada
durante
o
recebimento
do
evento
TEC_ITS_SUBNET_SERVICE_IMPACT.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_ITS_SUBNET_CONNECTIVITY
aberto
para
a
mesma
sub-rede
com
reachability
igual
a
UNREACHABLE.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause
e
o
evento
de
efeito
(TEC_ITS_NODE_SERVICE_IMPACT)
terá
confirmação
de
recebimento.
A
gravidade
do
evento
de
causa
(TEC_ITS_SUBNET_CONNECTIVITY)
recebe
upgrade.
A
nova
gravidade
será
FATAL
se
o
IBM
Tivoli
Monitoring
relatar
um
impacto
de
serviços;
de
outra
maneira,
será
CRITICAL
(se
a
gravidade
já
for
FATAL,
ela
não
é
alterada).
Se
o
próprio
evento
TEC_ITS_SUBNET_CONNECTIVITY
estiver
vinculado
a
um
evento
de
causa
do
NetView
aberto,
a
nova
gravidade
do
evento
de
sub-rede
será
propagada
para
seu
evento
de
causa.
Se
esse
evento
de
causa
não
estiver
fechado
e
estiver
vinculado
a
um
evento
de
causa
raiz,
a
nova
gravidade
será
propagada
para
o
evento
de
causa
raiz.
54
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
regra:
subnet_link_service_impact
A
regra
subnet_link_service_impact
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SUBNET_CONNECTIVITY
com
reachability
igual
a
UNREACHABLE.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_SUBNET_SERVICE_IMPACT
abertos
para
o
mesmo
host.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause
e
terão
seu
recebimento
confirmado.
A
gravidade
do
evento
de
causa
(TEC_ITS_SUBNET_CONNECTIVITY)
recebe
upgrade.
A
nova
gravidade
será
FATAL
se
o
IBM
Tivoli
Monitoring
relatar
um
impacto
de
serviços;
de
outra
maneira,
será
CRITICAL
(se
a
gravidade
já
for
FATAL,
ela
não
é
alterada).
Se
o
próprio
evento
TEC_ITS_SUBNET_CONNECTIVITY
estiver
vinculado
a
um
evento
de
causa
do
NetView
aberto,
a
nova
gravidade
do
evento
de
sub-rede
será
propagada
para
seu
evento
de
causa.
Se
esse
evento
de
causa
não
estiver
fechado
e
estiver
vinculado
a
um
evento
de
causa
raiz,
a
nova
gravidade
será
propagada
para
o
evento
de
causa
raiz.
regra:
node_correlate_sa
A
regra
node_correlate_sa
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_ITS_SA_STATUS
para
o
mesmo
host
com
o
atributo
sastatus
igual
a
nodeDown,
nodeMarginal
ou
ifDown.
Se
tal
evento
de
causa
for
localizado,
serão
executadas
as
seguintes
ações:
v
O
evento
TEC_ITS_NODE_STATUS
recebido
é
vinculado
como
um
efeito
do
evento
de
causa
TEC_ITS_SA_STATUS
utilizando
o
predicado
link_effect_to_cause.
v
Se
o
atributo
sastatus
do
evento
de
causa
TEC_ITS_SA_STATUS
for
igual
a
nodeDown
ou
nodeMarginal,
a
gravidade
do
evento
de
efeito
(TEC_ITS_NODE_STATUS)
será
definida
como
HARMLESS
e
o
status
do
evento
de
efeito
será
definido
como
RESPONSE.
Então
é
definido
um
cronômetro
para
o
fechamento
em
atraso
do
evento
de
efeito
após
toda
a
correlação
ser
concluída
(a
duração
do
cronômetro
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
Esse
processamento
não
ocorrerá
se
sastatus
for
igual
a
ifDown.
v
A
gravidade
do
evento
de
efeito
TEC_ITS_NODE_STATUS
recebido
será
propagada
para
o
evento
de
causa
TEC_ITS_SA_STATUS.
regra:
sa_correlate_node
A
regra
sa_correlate_node
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
satatus
igual
a
nodeDown,
nodeMarginal
ou
ifDown.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_ITS_NODE_STATUS
para
o
mesmo
host
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Se
tal
evento
de
efeito
for
localizado,
serão
executadas
as
seguintes
ações:
v
O
evento
de
efeito
TEC_ITS_NODE_STATUS
é
vinculado
ao
evento
de
causa
TEC_ITS_SA_STATUS
utilizando
o
predicado
link_effect_to_cause.
v
Se
o
atributo
sastatus
do
evento
de
causa
TEC_ITS_SA_STATUS
for
igual
a
nodeDown
ou
nodeMarginal,
a
gravidade
do
evento
de
efeito
(TEC_ITS_NODE_STATUS)
será
definida
como
HARMLESS
e
o
status
do
evento
de
efeito
será
definido
como
RESPONSE.
Então
é
definido
um
cronômetro
para
o
fechamento
em
atraso
do
evento
de
efeito
após
toda
a
correlação
ser
concluída
(a
duração
do
cronômetro
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
Esse
processamento
não
ocorrerá
se
sastatus
for
igual
a
ifDown.
Conjunto
de
Regras
do
NetView
(netview.rls)
55
v
A
gravidade
do
evento
de
efeito
TEC_ITS_NODE_STATUS
recebido
será
propagada
para
o
evento
de
causa
TEC_ITS_SA_STATUS.
regra:
node_up_correlate_sa
A
regra
node_up_correlate_sa
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
UP.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
eventos
TEC_ITS_SA_STATUS
para
o
mesmo
host
com
o
atributo
sastatus
igual
a
nodeUp
ou
ifUp.
Se
forem
localizados
tais
eventos
de
causa,
eles
serão
correlacionados
com
o
evento
de
efeito
utilizando
o
predicado
link_effect_to_cause.
É
feito
downgrade
do
evento
de
efeito
para
HARMLESS,
seu
status
será
definido
como
RESPONSE,
e
um
cronômetro
será
definido
para
fechamento
atrasado
do
evento
após
a
conclusão
de
toda
a
correlação
(a
duração
do
cronômetro
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
regra:
sa_correlate_node_up
A
regra
sa_correlate_node_up
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
satatus
igual
a
nodeUp
ou
ifUp.
Quando
esse
evento
é
recebido,
a
regra
pesquisa
no
cache
de
eventos
um
evento
TEC_ITS_NODE_STATUS
aberto
para
o
mesmo
host
com
nodestatus
igual
a
UP.
Se
for
localizado
tal
evento
de
efeito,
ele
será
correlacionado
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause.
É
feito
downgrade
do
evento
de
efeito
para
HARMLESS,
seu
status
será
definido
como
RESPONSE,
e
um
cronômetro
será
definido
para
fechamento
atrasado
do
evento
após
a
conclusão
de
toda
a
correlação
(a
duração
do
cronômetro
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
regra:
l2_correlate_sa
A
regra
l2_correlate_sa
é
executada
durante
o
recebimento
do
evento
TEC_ITS_L2_NODE_STATUS.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_SA_STATUS
para
o
mesmo
host.
Se
tal
evento
de
causa
for
localizado,
os
dois
eventos
serão
correlacionados.
Além
disso,
será
executada
uma
das
seguintes
ações:
v
Se
o
evento
de
causa
tiver
o
atributo
sastatus
igual
a
ifDown,
nodeDown
ou
nodeMarginal,
será
feito
seu
upgrade
para
CRITICAL.
v
Se
o
evento
de
causa
tiver
o
atributo
sastatus
igual
a
ifUp,
nodeUp
ou
nodeResolved,
será
feito
seu
downgrade
para
HARMLESS.
v
Se
o
evento
de
causa
tiver
o
atributo
sastatus
igual
a
ifUnmanaged,
ifDeleted,
nodeUnmanaged
ou
nodeDeleted,
será
feito
seu
upgrade
para
WARNING.
Será
feito
o
downgrade
do
evento
de
efeito
(TEC_ITS_L2_NODE_STATUS)
para
HARMLESS
e
ele
será
fechado.
regra:
sa_correlate_l2_1
A
regra
sa_correlate_l2_1
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
o
atributo
sastatus
igual
a
ifDown,
nodeDown
ou
nodeMarginal.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_L2_NODE_STATUS
para
o
mesmo
host.
Se
tal
evento
de
efeito
for
localizado,
ele
será
correlacionado
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
ele
será
fechado.
Será
feito
upgrade
do
evento
de
causa
(TEC_ITS_SA_STATUS)
para
CRITICAL.
regra:
sa_correlate_l2_2
A
regra
sa_correlate_l2_2
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
o
atributo
sastatus
igual
a
ifUp,
nodeUp
ou
nodeResolved.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
56
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
um
evento
TEC_ITS_L2_NODE_STATUS
para
o
mesmo
host.
Se
tal
evento
de
efeito
for
localizado,
ele
será
correlacionado
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
ele
será
fechado.
Será
feito
downgrade
do
evento
de
causa
(TEC_ITS_SA_STATUS)
para
HARMLESS.
regra:
sa_correlate_l2_3
A
regra
sa_correlate_l2_3
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
o
atributo
sastatus
igual
a
ifUnmanaged,
ifDeleted,
nodeUnmanaged
ou
nodeDeleted.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_L2_NODE_STATUS
para
o
mesmo
host.
Se
tal
evento
de
efeito
for
localizado,
ele
será
correlacionado
com
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
ele
será
fechado.
O
evento
de
causa
(TEC_ITS_SA_STATUS)
será
definido
como
WARNING.
regra:
router_correlate_sa
A
regra
router_correlate_sa
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_SA_STATUS
para
o
mesmo
host
com
o
atributo
sastatus
igual
a
nodeDown,
nodeMarginal
ou
ifDown.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
regra:
sa_correlate_router
A
regra
sa_correlate_router
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
o
atributo
sastatus
igual
a
nodeDown,
nodeMarginal
ou
ifDown.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
para
o
mesmo
host
com
routerstatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados;
será
feito
downgrade
do
evento
de
efeito
(TEC_ITS_SA_STATUS)
para
HARMLESS
e
ele
será
fechado.
regra:
router_up_correlate_sa
A
regra
router_up_correlate_sa
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
UP.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_SA_STATUS
para
o
mesmo
host
com
o
atributo
sastatus
igual
a
nodeUp
ou
ifUp.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
com
o
evento
de
causa,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
regra:
sa_correlate_router_up
A
regra
sa_correlate_router
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SA_STATUS
com
o
atributo
sastatus
igual
a
nodeUp
ou
ifUp.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
para
o
mesmo
host
com
routerstatus
igual
a
UP.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados;
será
feito
downgrade
do
evento
de
efeito
(TEC_ITS_SA_STATUS)
para
HARMLESS
e
ele
será
fechado.
regra:
router_correlate_subnet
A
regra
router_correlate_subnet
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_SUBNET_CONNECTIVITY
com
reachability
igual
a
UNREACHABLE.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
Conjunto
de
Regras
do
NetView
(netview.rls)
57
utilizando
o
predicado
link_effect_to_cause.
É
feito
downgrade
dos
eventos
de
efeito
(TEC_ITS_SUBNET_CONNECTIVITY)
para
HARMLESS,
seu
status
é
alterado
para
RESPONSE
e
é
definido
um
cronômetro
para
o
fechamento
atrasado
do
evento
de
efeito
após
a
conclusão
de
toda
a
correlação
(a
duração
do
atraso
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
A
gravidade
do
evento
de
efeito
era
maior
do
que
a
gravidade
do
evento
de
causa
TEC_ITS_ROUTER_STATUS
e
a
gravidade
maior
é
propagada
para
o
evento
de
causa.
Se
routerstatus
for
igual
a
MARGINAL
ou
UNREACHABLE
e
o
evento
do
roteador
estiver
vinculado
a
um
evento
de
causa
adicional
do
NetView,
a
gravidade
será
propagada
para
esse
evento
de
causa.
regra:
subnet_correlate_router
A
regra
subnet_correlate_router
é
executada
durante
o
recebimento
de
um
evento
com
reachability
igual
a
UNREACHABLE.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause.
É
feito
downgrade
do
evento
de
efeito
(TEC_ITS_SUBNET_CONNECTIVITY)
para
HARMLESS,
seu
status
é
alterado
para
RESPONSE
e
é
definido
um
cronômetro
para
o
fechamento
atrasado
do
evento
de
efeito
após
a
conclusão
de
toda
a
correlação
(a
duração
do
atraso
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
A
gravidade
do
evento
de
efeito
era
maior
do
que
a
gravidade
do
evento
de
causa
TEC_ITS_ROUTER_STATUS
e
a
gravidade
maior
é
propagada
para
o
evento
de
causa.
Se
routerstatus
for
igual
a
MARGINAL
ou
UNREACHABLE
e
o
evento
do
roteador
estiver
vinculado
a
um
evento
de
causa
adicional
do
NetView,
a
gravidade
será
propagada
para
esse
evento
de
causa.
regra:
interface_correlate_router
A
regra
interface_correlate_router
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_INTERFACE_STATUS
com
ifstatus
igual
a
DOWN,
ADMIN_DOWN
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
a
partir
do
mesmo
host.
Se
for
localizado
tal
evento,
será
executada
uma
das
seguintes
ações:
v
Se
o
evento
TEC_ITS_ROUTER_STATUS
tiver
routerstatus
igual
a
MARGINAL
ou
UNREACHABLE,
ele
será
correlacionado
como
um
evento
de
efeito
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
seu
status
será
definido
como
RESPONSE.
Então
é
definido
um
cronômetro
para
o
fechamento
em
atraso
do
evento
de
efeito
após
toda
a
correlação
ser
concluída
(a
duração
do
atraso
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
A
gravidade
do
evento
de
efeito
era
maior
do
que
a
gravidade
do
evento
de
causa
TEC_ITS_INTERFACE_STATUS
e
a
gravidade
maior
é
propagada
para
o
evento
de
causa.
v
Se
o
evento
TEC_ITS_ROUTER_STATUS
tiver
routerstatus
igual
a
DOWN,
ele
será
correlacionado
como
um
evento
de
causa
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
do
evento
de
efeito
(TEC_ITS_INTERFACE_STATUS)
para
HARMLESS
e
ele
será
fechado.
regra:
router_correlate_interface
A
regra
router_correlate_interface
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
for
recebido,
será
executada
uma
das
seguintes
ações:
58
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
v
Se
routerstatus
for
igual
a
DOWN,
serão
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_INTERFACE_STATUS
com
ifstatus
igual
a
DOWN,
ADMIN_DOWN
ou
UNREACHABLE.
Se
forem
localizados,
eles
serão
correlacionados
como
eventos
de
efeito
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
desses
eventos
de
efeito
para
HARMLESS
e
eles
serão
fechados.
v
Se
routerstatus
não
for
igual
a
DOWN,
será
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_INTERFACE_STATUS
com
ifstatus
igual
a
DOWN,
ADMIN_DOWN
ou
UNREACHABLE.
Se
for
localizado
tal
evento,
ele
será
correlacionado
como
o
evento
de
causa
utilizando
o
predicado
link_effect_to_cause.
Será
feito
downgrade
do
evento
de
efeito
(TEC_ITS_ROUTER_STATUS)
para
HARMLESS,
seu
status
será
alterado
para
RESPONSE
e
um
cronômetro
será
definido
para
o
fechamento
atrasado
do
evento
de
efeito
após
a
conclusão
de
toda
a
correlação
(a
duração
do
atraso
é
determinada
pelo
valor
do
parâmetro
global
nv_latency).
A
gravidade
do
evento
de
efeito
era
maior
do
que
a
gravidade
do
evento
de
causa
TEC_ITS_INTERFACE_STATUS
e
a
gravidade
maior
é
propagada
para
o
evento
de
causa.
regra:
interface_correlate_node
A
regra
interface_correlate_node
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_INTERFACE_STATUS
com
ifstatus
igual
a
DOWN,
ADMIN_DOWN
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_NODE_STATUS
para
o
mesmo
host
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
do
evento
de
efeito
(TEC_ITS_INTERFACE_STATUS)
para
HARMLESS
e
ele
será
fechado.
regra:
node_correlate_interface
A
regra
node_correlate_interface
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
DOWN,
MARGINAL
ou
UNREACHABLE.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
quaisquer
eventos
TEC_ITS_INTERFACE_STATUS
para
o
mesmo
host
com
ifstatus
igual
a
DOWN,
ADMIN_DOWN
ou
UNREACHABLE.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
regra:
router_up_correlate_subnet
A
regra
router_up_correlate_subnet
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
UP.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
quaisquer
eventos
TEC_ITS_SUBNET_CONNECTIVITY
com
reachability
igual
a
REACHABLE_AGAIN.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
de
eventos
de
efeito
(TEC_ITS_SUBNET_CONNECTIVITY)
para
HARMLESS
e
eles
serão
fechados.
regra:
subnet_correlate_router_up
A
regra
subnet_correlate_router_up
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SUBNET_CONNECTIVITY
com
reachability
igual
a
REACHABLE_AGAIN.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
UP.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
do
evento
de
efeito
(TEC_ITS_SUBNET_CONNECTIVITY)
para
HARMLESS
e
ele
será
fechado.
Conjunto
de
Regras
do
NetView
(netview.rls)
59
regra:
interface_up_correlate_router_up
A
regra
interface_up_correlate_router_up
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_INTERFACE_STATUS
com
ifstatus
igual
a
UP.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
para
o
mesmo
host
com
routerstatus
igual
a
UP.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
do
evento
de
efeito
para
HARMLESS
e
ele
será
fechado.
regra:
interface_up_correlate_node_up
A
regra
interface_up_correlate_node_up
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_INTERFACE_STATUS
com
ifstatus
igual
a
UP.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_NODE_STATUS
para
o
mesmo
host
com
nodestatus
igual
a
UP.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
do
evento
de
efeito
(TEC_ITS_INTERFACE_STATUS)
para
HARMLESS
e
ele
será
fechado.
regra:
node_up_correlate_interface_up
A
regra
node_up_correlate_interface_up
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
UP.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_INTERFACE_STATUS
para
o
mesmo
host
com
ifstatus
igual
a
UP.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
regra:
router_up_correlate_interface_up
A
regra
router_up_correlate_interface_up
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
UP.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_INTERFACE_STATUS
para
o
mesmo
host
com
ifstatus
igual
a
UP.
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
correlacionados
utilizando
o
predicado
link_effect_to_cause,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
regra:
subnet_correlate_unreachable
A
regra
subnet_correlate_unreachable
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_SUBNET_CONNECTIVITY.
Quando
esse
evento
for
recebido,
serão
executadas
as
seguintes
ações:
v
Se
o
atributo
reachability
do
evento
recebido
for
igual
a
UNREACHABLE,
será
confirmado
um
fato
não-acessível
de
sub-rede
na
base
de
conhecimento.
Se
reachability
for
igual
a
REACHABLE_AGAIN,
o
fato
não-acessível
de
sub-rede
será
retirado.
v
Se
o
atributo
reachability
do
evento
recebido
for
igual
a
UNREACHABLE,
serão
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_ITS_UNREACHABLE
da
mesma
sub-rede.
Se
forem
localizados
tais
eventos,
eles
serão
correlacionados
como
eventos
de
efeito,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
v
Se
o
atributo
reachability
do
evento
recebido
for
igual
a
UNREACHABLE,
serão
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_Heartbeat_missed
da
mesma
sub-rede.
Se
forem
localizados
tais
eventos,
eles
serão
correlacionados
como
eventos
de
efeito,
será
feito
seu
downgrade
para
HARMLESS
e
eles
serão
fechados.
60
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
regra:
unreachable_correlate_subnet
A
regra
unreachable_correlate_subnet
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_UNREACHABLE.
Quando
esse
evento
for
recebido,
serão
verificados
na
base
de
conhecimento
quaisquer
fatos
não-acessíveis
da
sub-rede
relacionados
à
sub-rede
do
endereço
IP
que
não
esteja
acessível.
Se
for
localizado
um
fato
não-acessível
da
sub-rede,
será
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_SUBNET_CONNECTIVITY
relacionado
à
sub-rede
especificada.
Se
for
localizado
esse
evento
de
causa,
ele
será
correlacionado
com
o
evento
de
efeito
TEC_ITS_UNREACHABLE
utilizando
o
predicado
link_effect_to_cause.
Será
feito
o
downgrade
do
evento
de
efeito
para
HARMLESS
e
ele
será
fechado.
regra:
heartbeat_missed_link_subnet
A
regra
heartbeat_missed_link_subnet
é
executada
durante
o
recebimento
de
um
evento
TEC_Heartbeat_missed.
Quando
esse
evento
for
recebido,
serão
verificados
na
base
de
conhecimento
quaisquer
fatos
não-acessíveis
da
sub-rede
relacionados
à
sub-rede
do
endereço
IP
que
enviou
o
evento.
Se
for
localizado
um
fato
não-acessível
da
sub-rede,
será
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_SUBNET_CONNECTIVITY
relacionado
à
sub-rede
especificada.
Se
for
localizado
esse
evento
de
causa,
ele
será
associado
ao
evento
de
efeito
TEC_Heartbeat_missed
utilizando
o
predicado
link_effect_to_cause.
regra:
node_link_heartbeat_missed
A
regra
node_link_heartbeat_missed
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_NODE_STATUS
com
nodestatus
igual
a
qualquer
valor
diferente
de
UP.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_Heartbeat_missed
para
o
mesmo
host
(se
o
evento
TEC_ITS_NODE_STATUS
não
tiver
um
valor
para
o
atributo
fqhostname,
o
atributo
hostname
será
comparado
com
o
atributo
fqhostname
do
evento
de
pulsação.
Essa
comparação
não
faz
distinção
entre
letras
maiúsculas
e
minúsculas).
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
associados
utilizando
o
predicado
link_effect_to_cause.
regra:
heartbeat_missed_link_node
A
regra
heartbeat_missed_link_node
é
executada
durante
o
recebimento
de
um
evento
TEC_Heartbeat_missed.
Quando
esse
evento
é
recebido,
é
pesquisado
no
cache
de
eventos
um
evento
TEC_ITS_NODE_STATUS
para
o
mesmo
host
com
nodestatus
igual
a
qualquer
valor
diferente
de
UP.
(se
o
evento
TEC_ITS_NODE_STATUS
não
tiver
um
valor
para
o
atributo
fqhostname,
o
atributo
hostname
será
comparado
com
o
atributo
fqhostname
do
evento
de
pulsação.
Essa
comparação
não
faz
distinção
entre
letras
maiúsculas
e
minúsculas).
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
associados
utilizando
o
predicado
link_effect_to_cause.
regra:
router_link_heartbeat_missed
A
regra
router_link_heartbeat_missed
é
executada
durante
o
recebimento
de
um
evento
TEC_ITS_ROUTER_STATUS
com
routerstatus
igual
a
qualquer
valor
diferente
de
UP.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
TEC_Heartbeat_missed
para
o
mesmo
host
(se
o
evento
TEC_ITS_ROUTER_STATUS
não
tiver
um
valor
para
o
atributo
fqhostname,
o
atributo
hostname
será
comparado
com
o
atributo
fqhostname
do
evento
de
pulsação.
Essa
comparação
não
faz
distinção
entre
letras
maiúsculas
e
minúsculas).
Se
forem
localizados
tais
eventos
de
efeito,
eles
serão
associados
utilizando
o
predicado
link_effect_to_cause.
regra:
heartbeat_missed_link_router
A
regra
heartbeat_missed_link_router
é
executada
durante
o
recebimento
de
um
evento
TEC_Heartbeat_missed.
Quando
esse
evento
é
recebido,
é
pesquisado
no
Conjunto
de
Regras
do
NetView
(netview.rls)
61
cache
de
eventos
um
evento
TEC_ITS_ROUTER_STATUS
para
o
mesmo
host
com
routerstatus
igual
a
qualquer
valor
diferente
de
UP.
(se
o
evento
TEC_ITS_ROUTER_STATUS
não
tiver
um
valor
para
o
atributo
fqhostname,
o
atributo
hostname
será
comparado
com
o
atributo
fqhostname
do
evento
de
pulsação.
Essa
comparação
não
faz
distinção
entre
letras
maiúsculas
e
minúsculas).
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
associados
utilizando
o
predicado
link_effect_to_cause.
regra
do
cronômetro:
delayed_close
É
feito
o
downgrade
da
regra
do
cronômetro
delayed_close
para
HARMLESS
e
é
fechado
qualquer
evento
que
foi
programado
para
fechamento
atrasado
pendente
da
conclusão
da
correlação.
62
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Notificação
(notify.rls)
Visão
Geral
O
conjunto
de
regras
de
notificação
contém
regras
que
suportam
o
envio
de
notificação
para
a
equipe
de
suporte
sobre
eventos
novos
ou
alterados.
Uso
O
conjunto
de
regras
de
notificação
não
está
ativado
na
base
de
regras
padrão.
Antes
de
ativar
esse
conjunto
de
regras,
é
necessário
configurá-lo
para
especificar
as
informações
de
contato
(incluindo
endereços
de
ou
números
de
pagers)
a
serem
utilizadas
para
notificação.
Se
você
desejar
utilizar
a
notificação
por
pager,
também
será
necessário
personalizar
o
predicado
assert_notify
no
arquivo
notify.pro
para
especificar
um
script
que
implemente
o
recurso
de
pager.
Esse
arquivo
está
localizado
em
$BINDIR/TME/TEC/default_rb/TEC_TEMPLATES
(a
notificação
por
é
implementada
utilizando
a
tarefa
Send_Email;
consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais
sobre
essa
tarefa).
Quando
você
concluir
a
personalização
do
conjunto
de
regras,
será
necessário
ativá-lo;
consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
como
ativar
conjuntos
de
regras.
Nota:
Se
ativado,
o
conjunto
de
regras
de
notificação
deve
ser
listado
próximo
do
final
do
arquivo
rule_sets,
preferencialmente
na
última
posição.
Consulte
“Seqüenciamento
e
Dependências
do
Conjunto
de
Regras”
na
página
3
para
mais
informações.
Especificando
Informações
de
Contato
Por
padrão,
o
conjunto
de
regras
de
notificação
envia
notificação
por
para
qualquer
novo
evento
cuja
gravidade
seja
FATAL,
CRITICAL
ou
MINOR
e
para
qualquer
evento
aberto
cuja
gravidade
seja
alterada
para
FATAL,
CRITICAL
ou
MINOR.
Antes
de
utilizar
esse
conjunto
de
regras,
é
necessário
modificar
a
ação
notify_parameters
da
regra
notify_configure
para
especificar
as
informações
de
contato
e
o
tipo
de
notificação
a
ser
utilizado
ou
pager).
As
informações
de
contato
devem
ser
especificadas
para
cada
classe
de
evento
para
a
qual
você
deseja
acionar
a
notificação.
Especifique
informações
de
contato,
da
seguinte
forma:
rerecord(notify_list,
class,
[notification,
username,
address]),
v
class
é
a
classe
de
eventos,
colocada
entre
aspas
simples.
v
notification
é
o
tipo
de
notificação,
’MAIL’
ou
’PAGE’.
v
username
é
o
nome
do
usuário
da
pessoa
a
ser
notificada,
colocado
entre
aspas
simples.
v
address
é
o
endereço
de
ou
do
número
do
pager
da
pessoa
a
ser
notificada,
colocado
entre
aspas
simples.
©
Copyright
IBM
Corp.
2003
63
Regras
Regra
de
Inicialização
regra:
notify_configure
A
regra
notify_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
os
critérios
de
eventos
que
resultam
no
envio
da
notificação
para
a
equipe
de
suporte.
Consulte
“Uso”
na
página
63
para
obter
informações
adicionais
sobre
como
definir
critérios
de
eventos.
Regras
de
Notificação
regra:
notify_for_fatal_events
A
regra
notify_for_fatal_events
é
executada
durante
o
recebimento
de
qualquer
evento
com
gravidade
FATAL.
A
primeira
regra
pesquisa
no
cache
de
eventos
para
verificar
se
o
evento
recém-recebido
é
uma
duplicata
de
um
evento
aberto
recebido
anteriormente;
se
for,
o
novo
evento
será
fechado.
Se
o
novo
evento
não
for
uma
duplicata,
o
predicado
assert_notify
será
utilizado
para
enviar
uma
notificação
para
o
destinatário
apropriado,
conforme
definido
pela
regra
notify_configure.
Nota:
A
notificação
é
sempre
enviada
para
eventos
FATAL,
mesmo
que
não
existam
informações
sobre
configuração
específicas
para
a
classe
de
eventos.
Se
não
houver
informações
de
contato
disponíveis
para
o
evento,
as
informações
para
a
classe
EVENT
serão
utilizadas.
regra:
notify_for_new_events
A
regra
notify_for_new_events
é
executada
durante
o
recebimento
de
qualquer
evento
com
gravidade
MINOR
ou
CRITICAL.
A
primeira
regra
pesquisa
no
cache
de
eventos
para
verificar
se
o
evento
recém-recebido
é
uma
duplicata
de
um
evento
aberto
recebido
anteriormente;
se
for,
o
novo
evento
será
fechado.
Se
o
novo
evento
não
for
uma
duplicata,
o
predicado
assert_notify
será
utilizado
para
enviar
uma
notificação
para
o
destinatário
apropriado,
conforme
definido
pela
regra
notify_configure.
regra
de
alteração:
notify_for_change_fatal
A
regra
notify_for_change_fatal
é
executada
quando
a
gravidade
de
qualquer
evento
aberto
é
alterada
para
FATAL,
desde
que
a
classe
de
eventos
seja
especificada
pelo
parâmetro
_notify_list.
Quando
isso
ocorre,
o
predicado
assert_notify
é
utilizado
para
enviar
notificação
para
o
destinatário
apropriado,
conforme
definido
pela
regra
notify_configure.
regra
de
alteração:
notify_for_severity_change
A
regra
notify_for_severity_change
é
executada
quando
a
gravidade
de
um
evento
aberto
é
alterada
para
MINOR
ou
CRITICAL,
desde
que
a
classe
de
eventos
seja
especificada
pelo
parâmetro
_notify_list.
Quando
isso
ocorre,
o
predicado
assert_notify
é
utilizado
para
enviar
notificação
para
o
destinatário
apropriado,
conforme
definido
pela
regra
notify_configure.
regra
de
alteração:
notify_for_status_change
A
regra
notify_for_status_change
é
executada
quando
o
status
de
qualquer
evento
com
gravidade
maior
que
WARNING
é
alterado
para
OPEN.
Quando
isso
ocorre,
o
predicado
assert_notify
é
utilizado
para
enviar
notificação
para
o
destinatário
apropriado,
conforme
definido
pela
regra
notify_configure.
64
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
HP
OpenView
(ov_default.rls)
Visão
Geral
O
conjunto
de
regras
HP
OpenView
contém
regras
que
processam
eventos
a
partir
do
adaptador
HP
OpenView.
Essas
regras
tratam
o
fechamento
automático
de
eventos
não-importantes
e
da
correlação
de
eventos
da
interface
e
do
nó.
Uso
O
conjunto
de
regras
HP
OpenView
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Regras
Regra
de
Fechamento
de
Eventos
regra:
phys_addr
A
regra
phys_addr
é
executada
durante
o
recebimento
de
qualquer
um
dos
seguintes
eventos:
v
OV_Phys_Addr_Mismatch
v
OV_Phys_Addr_Chg
v
OV_Sys_Descr_Chg
v
OV_Sys_Contact_Chg
v
OV_Sys_Location_Chg
Quando
um
desses
eventos
é
recebido,
a
regra
define
um
cronômetro
que
expira
em
uma
hora.
Esse
cronômetro
é
utilizado
pela
regra
do
cronômetro
timer_phys_addr
para
fechar
automaticamente
o
evento,
se
ele
ainda
estiver
aberto.
Regras
de
Correlação
regra:
link_if_down
A
regra
link_if_down
é
executada
durante
o
recebimento
do
evento
OV_IF_Down.
Quando
esse
evento
é
recebido,
a
regra
verifica
se
ele
é
uma
duplicata
de
qualquer
evento
aberto
recebido
anteriormente.
Se
for,
o
atributo
repeat_count
do
evento
recebido
anteriormente
será
incrementado
e
o
evento
recém-recebido
será
eliminado.
Se
o
evento
recebido
não
for
uma
duplicata,
a
regra
repetirá
a
análise
de
quaisquer
eventos
OV_Node_Down
abertos
recebidos
do
mesmo
host
nos
dez
minutos
anteriores
para
identificar
possíveis
eventos
de
efeito.
regra:
link_if_node_down
A
regra
link_if_node_down
é
executada
durante
o
recebimento
do
evento
OV_Node_Down.
Quando
esse
evento
é
recebido,
a
regra
verifica
se
ele
é
uma
duplicata
de
qualquer
evento
aberto
recebido
anteriormente.
Se
for,
o
atributo
repeat_count
do
evento
recebido
anteriormente
será
incrementado
e
o
evento
recém-recebido
será
eliminado.
Se
o
evento
recebido
não
for
uma
duplicata,
a
regra
verificará
no
cache
de
eventos
um
evento
OV_IF_Down
aberto
recebido
do
mesmo
host
nos
dez
minutos
anteriores.
Se
for
localizado
tal
evento
de
causa,
os
dois
eventos
serão
associados
utilizando
o
predicado
link_effect_to_cause.
O
status
do
©
Copyright
IBM
Corp.
2003
65
evento
OV_Node_Down
recebido
é
então
alterado
para
corresponder
ao
status
do
evento
OV_IF_Down
e
a
gravidade
do
evento
OV_IF_Down
será
definida
como
HARMLESS.
regra
de
alteração:
change_status_if_down
A
regra
de
alteração
change_status_if_down
é
executada
sempre
que
existe
uma
alteração
no
status
de
um
evento
OV_Node_Down.
Quando
isso
ocorre,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
OV_IF_Down
que
estão
associados
ao
evento
recebido.
Se
forem
localizados
tais
eventos,
o
novo
status
será
propagado
também
para
esses
eventos.
regra
de
alteração:
change_status_node_down
A
regra
de
alteração
change_status_if_down
é
executada
sempre
que
existe
uma
alteração
no
status
de
um
evento
OV_IF_Down.
Quando
isso
ocorre,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
OV_Node_Down
que
estão
associados
ao
evento
recebido.
Se
forem
localizados
tais
eventos,
o
novo
status
será
propagado
também
para
esses
eventos.
Regra
do
Cronômetro
regra
do
cronômetro:
timer_phys_addr
A
regra
do
cronômetro
timer_phys_addr
é
executada
durante
a
expiração
do
cronômetro
definido
pela
regra
phys_addr.
Essa
regra
fecha
qualquer
um
dos
eventos
especificados
nessa
regra
se
eles
ainda
estiverem
abertos
após
uma
hora.
66
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Encaminhamento
de
Eventos
do
NetView
para
z/OS
(tecad_nv390fwd.rls)
Visão
Geral
O
conjunto
de
regras
de
encaminhamento
de
eventos
do
NetView
para
z/OS
contém
regras
que
suportam
o
encaminhamento
de
eventos
do
adaptador
de
mensagens
ou
do
adaptador
de
alertas
do
NetView
para
z/OS
para
outro
servidor
de
eventos.
Uso
O
conjunto
de
regras
de
encaminhamento
de
eventos
do
Netview
para
z/OS
não
está
ativado
na
base
de
regras
padrão.
Antes
de
utilizar
esse
conjunto
de
regras,
é
necessário
configurar
a
função
de
encaminhamento
definindo
o
servidor
para
o
qual
os
eventos
devem
ser
encaminhados.
Em
seguida,
é
necessário
ativar
o
conjunto
de
regras.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Também
é
necessário
definir
a
localização
do
servidor
de
eventos
para
o
qual
os
eventos
são
encaminhados.
O
servidor
de
destino
para
a
função
de
encaminhamento
de
eventos
é
especificado
pelo
arquivo
de
configuração
tec_forward.conf.
Por
padrão,
esse
arquivo
especifica
que
a
função
de
encaminhamento
de
eventos
deve
operar
no
modo
de
teste,
que
envia
eventos
para
um
arquivo.
Para
especificar
um
servidor,
é
necessário
modificar
o
valor
da
palavra-chave
ServerLocation
para
especificar
o
servidor
de
destino.
Também
é
necessário
especificar
TestMode=NO
ou
transformar
a
palavra-chave
TestMode
totalmente
em
um
comentário.
Para
obter
informações
adicionais
sobre
palavras-chave
do
arquivo
de
configuração,
consulte
o
IBM
Tivoli
Enterprise
Console
Event
Integration
Facility
-
Referência.
Regras
Regras
de
Encaminhamento
de
Eventos
regra:
fwd_to_nv390
A
regra
fwd_to_nv390
é
executada
durante
o
recebimento
de
qualquer
evento
CRITICAL
ou
FATAL
não-originado
de
um
adaptador
do
NetView
para
z/OS.
Quando
esse
evento
é
recebido,
a
regra
utiliza
o
predicado
forward_event
para
encaminhar
o
evento
para
o
servidor
especificado
no
arquivo
de
configuração
tec_forward.conf.
regra
de
alteração:
fwd_closed_to_nv390
A
regra
de
alteração
fwd_closed_to_nv390
é
executada
quando
um
evento
CRITICAL
ou
FATAL
não-originado
de
um
adaptador
do
NetView
para
z/OS
é
fechado.
Quando
isso
ocorre,
a
regra
utiliza
o
predicado
forward_event
para
encaminhar
o
evento
alterado
para
o
servidor
especificado
no
arquivo
de
configuração
tec_forward.conf.
regra
de
alteração:
fwd_severity_to_nv390
A
regra
de
alteração
fwd_severity_to_nv390
é
executada
sempre
que
o
status
de
um
evento
não-originado
de
um
adaptador
do
NetView
para
z/OS
é
alterado
para
©
Copyright
IBM
Corp.
2003
67
CRITICAL
ou
FATAL.
Quando
isso
ocorre,
a
regra
utiliza
o
predicado
forward_event
para
encaminhar
o
evento
para
o
servidor
especificado
no
arquivo
de
configuração
tec_forward.conf.
68
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
de
Mensagens
do
NetView
para
z/OS
(tecad_nv390msg.rls)
Visão
Geral
O
conjunto
de
regras
de
mensagens
do
NetView
para
z/OS
processa
eventos
a
partir
do
Adaptador
de
Mensagens
do
NetView
para
z/OS.
Uso
O
conjunto
de
regras
de
mensagens
do
z/OS
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Regras
Regra
de
Detecção
de
Duplicatas
regra:
nv390msg_dup_event
A
regra
nv390msg_dup_event
é
executada
durante
o
recebimento
de
qualquer
evento
de
classe
NV390MSG_EVENT.
Quando
esse
evento
é
recebido,
a
regra
verifica
se
ele
é
uma
duplicata
de
qualquer
evento
aberto
recebido
anteriormente.
Se
for,
o
atributo
repeat_count
do
evento
recebido
anteriormente
será
incrementado
e
o
evento
recém-recebido
será
eliminado.
©
Copyright
IBM
Corp.
2003
69
70
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Regras
de
Eventos
SNA
tecad_snaevent.rls
Visão
Geral
O
conjunto
de
regras
de
eventos
SNA
processa
eventos
relacionados
a
alertas
SNA.
Esses
eventos
são
enviados
pelo
Adaptador
de
Alertas
SNA
do
Tivoli
Enterprise
Console
AS/400
e
do
NetView
para
z/OS.
Uso
O
conjunto
de
regras
de
eventos
SNA
não
está
ativado
na
base
de
regras
padrão.
Antes
de
poder
utilizar
esse
conjunto
de
regras,
você
deve
ativá-lo.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
a
ativação
dos
conjuntos
de
regras.
Regras
Regras
de
Detecção
de
Correlação
e
de
Duplicatas
regra:
sna_dup_event
A
regra
sna_dup_event
é
executada
durante
o
recebimento
de
qualquer
evento
de
classe
SNA_Event.
Quando
esse
evento
é
recebido,
a
regra
verifica
se
ele
é
uma
duplicata
de
qualquer
evento
aberto
recebido
anteriormente.
Se
for,
o
atributo
repeat_count
do
evento
recebido
anteriormente
será
incrementado
e
o
evento
recém-recebido
será
eliminado.
regra:
sna_correlated_event
A
regra
sna_correlated_event
é
executada
durante
o
recebimento
de
qualquer
evento
de
classe
SNA_Event
com
event_correl
igual
a
qualquer
valor
diferente
de
N/A.
Quando
esse
evento
é
recebido,
a
regra
verifica
se
ele
está
correlacionado
com
um
evento
de
alerta
SNA
aberto
recebido
anteriormente,
conforme
indicado
pelas
informações
do
subvetor
47
de
alerta
SNA
no
atributo
event_correl.
Se
for,
o
atributo
repeat_count
do
evento
recebido
anteriormente
será
incrementado
e
o
evento
recém-recebido
será
eliminado
(consulte
o
manual
IBM
SNA
Formats
para
obter
informações
adicionais
sobre
o
subvetor
47).
Regras
de
Resolução
de
Alertas
Genéricos
regra:
sna_Mv0002_Resolution
A
regra
sna_Mv0002_Resolution
é
executada
durante
o
recebimento
de
um
evento
de
classe
SNA_Event
com
arch_type
igual
a
GENERIC_RESOLUTION
e
incident_correl
diferente
de
N/A.
Esse
evento
indica
uma
resolução
de
vetor
0002
SNA
principal.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
eventos
abertos
associados
a
alertas
genéricos
do
vetor
0000
SNA
principal
que
são
resolvidos
pela
resolução
especificada.
Se
forem
localizados
tais
eventos,
eles
serão
fechados
(consulte
o
manual
IBM
SNA
Formats
para
obter
informações
adicionais).
regra:
sna_Mv0000_Generic_Alert
A
regra
sna_Mv0000_Generic_Alert
é
executada
durante
o
recebimento
de
qualquer
evento
SNA_Event
com
arch_type
igual
a
GENERIC_ALERT
e
incident_correl
diferente
de
N/A,
indicando
um
alerta
genérico
do
Vetor
0000
SNA
Principal.
Quando
esse
evento
é
recebido,
são
pesquisados
no
cache
de
eventos
quaisquer
©
Copyright
IBM
Corp.
2003
71
eventos
de
resolução
genérica
do
Vetor
0002
Principal
recebidos
anteriormente
que
resolveram
o
alerta
recém-recebido.
Se
for
localizado
um
evento
de
resolução,
a
regra
solicitará
uma
nova
análise
do
evento
de
resolução
para
que
o
evento
de
alerta
possa
ser
fechado.
72
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Conjunto
de
Regras
do
Registro
de
Problemas
(troubleticket.rls)
Visão
Geral
O
conjunto
de
regras
de
registro
de
problemas
contém
regras
que
suportam
a
integração
do
produto
Tivoli
Enterprise
Console
com
sistemas
de
registro
de
problemas.
Essas
regras
abrem
automaticamente
registros
de
problemas
para
novos
eventos
que
correspondem
aos
critérios
definidos
pelo
usuário,
além
de
associar
eventos
existentes
a
registros
de
problema
abertos
pelo
sistema
de
registro
de
problemas.
Quando
um
registro
de
problema
é
aberto,
as
regras
fornecem
sincronização
de
duas
vias
entre
o
produto
Tivoli
Enterprise
Console
e
o
sistema
de
registro
de
problemas
externo.
Essa
sincronização
inclui:
v
Se
for
alterado
o
status
ou
gravidade
de
um
evento,
qualquer
registro
de
problema
associado
será
automaticamente
atualizado
para
refletir
as
novas
informações.
v
Se
um
registro
de
problema
for
alterado,
quaisquer
eventos
associados
serão
automaticamente
atualizados
para
refletir
as
novas
informações.
v
Se
um
evento
for
fechado,
qualquer
registro
de
problema
associado
será
automaticamente
fechado.
v
Se
um
registro
de
problema
for
fechado,
quaisquer
eventos
associados
serão
automaticamente
fechados.
Consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais
sobre
como
integrar
o
produto
Tivoli
Enterprise
Console
com
sistemas
de
registro
de
problemas.
Uso
O
conjunto
de
regras
do
registro
de
problema
não
está
ativado
na
base
de
regras
padrão.
Antes
de
utilizar
esse
conjunto
de
regras,
é
necessário
configurá-lo
para
seu
ambiente,
definindo
os
critérios
de
eventos
que
serão
utilizados
para
abertura
automática
de
registros
de
problemas.
Em
seguida,
é
necessário
ativar
o
conjunto
de
regras.
Consulte
“Modificando
a
Base
de
Regra”
na
página
2
para
obter
informações
adicionais
sobre
como
importar
conjuntos
de
regras
para
a
base
de
regra.
Definindo
Critérios
de
Eventos
A
regra
de
configuração
tt_configure
define
os
critérios
de
eventos
que
acionam
a
abertura
automática
de
registros
de
problemas.
Esses
critérios
são
definidos
utilizando
uma
série
de
instruções
assert_tt,
cada
uma
especificando
os
critérios
para
um
tipo
de
evento
que
deve
fazer
com
que
um
registro
de
problema
seja
aberto
automaticamente.
O
formato
da
instrução
assert_tt
é
o
seguinte:
assert_tt(ev_class,ev_sev,ev_host)
ev_class
é
a
classe
do
evento,
ev_sev
é
a
gravidade
do
evento
e
ev_host
é
o
nome
completo
do
host
de
origem
(especificado
pelo
atributo
fqhostname).
Cada
valor
deve
ser
colocado
entre
aspas
simples.
Um
sublinhado
(_)
representa
qualquer
valor.
Por
exemplo:
©
Copyright
IBM
Corp.
2003
73
assert_tt(’TEC_Error’,’FATAL’,_)
%
all
FATAL
TEC_Error
events
from
any
host
assert_tt(_,’CRITICAL’,_)
%
all
CRITICAL
events
from
any
host
assert_tt(_,_,’myhost.raleigh.ibm.com’)
%
all
events
from
myhost.raleigh.ibm.com
Adicione
essas
instruções
assert_tt
à
ação
configure_knowledge_base
da
regra
tt_configure.
Configuração
Opcional
Você
pode
personalizar
o
conjunto
de
regras
de
registro
de
problema
modificando
as
instruções
na
ação
tt_parameters
da
regra
de
configuração
tt_configure.
As
opções
a
seguir
são
configuráveis:
v
Nome
do
administrador.
Você
pode
especificar
o
nome
do
administrador
a
ser
utilizado
quando
confirmar
o
recebimento
ou
fechar
automaticamente
os
eventos.
O
nome
do
administrador
padrão
é
troubleticket.rls.
Para
alterar
o
nome
do
administrador,
modifique
a
instrução
que
define
o
parâmetro
_tt_admin,
da
seguinte
forma:
_tt_admin
=
admin,
admin
é
o
nome
do
administrador
a
ser
utilizado,
colocado
entre
aspas
simples.
v
Arquivo
de
log
de
erros.
Você
pode
especificar
o
nome
do
arquivo
utilizado
para
registrar
mensagens
de
erros.
O
valor
padrão
é
/tmp/troubleticket.err.
Para
especificar
um
arquivo
diferente,
modifique
a
instrução
que
define
o
parâmetro
_tt_err_log,
da
seguinte
forma:
_tt_err_log
=
filename,
filename
é
o
nome
do
arquivo
de
log
que
você
deseja
utilizar,
opcionalmente,
incluindo
um
caminho
relativo
ou
absoluto,
e
colocado
entre
aspas
simples.
v
Vários
registros
de
problemas
de
eventos.
Você
pode
especificar
se
deseja
permitir
que
vários
eventos
sejam
associados
a
um
único
registro
de
problema.
Se
essa
opção
estiver
desativada,
será
aberto
um
novo
registro
de
problema
para
cada
evento
correspondente
aos
critérios
definidos
para
a
abertura
de
um
registro
de
problema,
mesmo
que
um
registro
de
problema
semelhante
já
esteja
aberto.
Por
padrão,
essa
opção
fica
ativada;
para
alterar
esse
valor,
modifique
a
instrução
que
define
o
parâmetro
_assoc_flag,
da
seguinte
forma:
_assoc_flag
=
flag
flag
é
’ON’
ou
’OFF’.
v
Arquivo
de
fatos.
Você
pode
especificar
o
nome
do
arquivo
a
ser
utilizado
para
armazenar
fatos
de
registro
de
problema
na
base
de
conhecimento.
Você
pode
especificar
uma
localização
absoluta
para
o
arquivo
ou
especificar
apenas
o
nome
do
arquivo;
nesse
caso,
o
arquivo
será
criado
no
diretório
$DBDIR.
O
nome
do
arquivo
padrão
é
troubleticket.pro.
Para
alterar
o
nome
do
arquivo,
modifique
a
instrução
que
define
a
variável
_kbase_file,
da
seguinte
forma:
_kbase_file
=
filename
filename
é
o
nome
do
arquivo
de
fatos
que
você
deseja
utilizar,
incluindo,
opcionalmente,
um
caminho
relativo
ou
absoluto
e
colocado
entre
aspas
simples.
v
Latência.
Você
pode
especificar
o
intervalo
de
tempo
a
ser
utilizado
quando
pesquisar
no
cache
de
eventos
os
eventos
associados
a
registros
de
problemas.
Esse
intervalo
de
tempo,
ou
latência,
afeta
pesquisas
de
eventos
de
retrocesso
e
de
avanço.
Por
padrão,
as
pesquisas
são
limitadas
a
uma
semana
(604.800
segundos)
de
retrocesso
ou
de
avanço
no
cache
de
eventos.
Para
alterar
a
latência,
modifique
a
instrução
que
define
o
parâmetro
_tt_elapsed,
da
seguinte
forma:
74
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
_tt_elapsed
=
seconds
seconds
é
o
número
de
segundos
que
representa
o
quanto
você
deseja
retroceder
ou
avançar
para
pesquisar
eventos
no
cache.
Nota:
Esse
parâmetro
define
um
limite
superior
sobre
quanto
tempo
a
pesquisa
retrocederá,
mas
isso
não
garante
que
os
eventos
nesse
período
de
tempo
ainda
estarão
disponíveis.
Se
o
cache
de
eventos
for
muito
pequeno,
os
eventos
poderão
ser
descartados,
mesmo
se
forem
mais
recentes
do
que
o
tempo
especificado.
Se
isso
ocorrer,
considere
aumentar
o
tamanho
do
cache
de
eventos
(consulte
o
IBM
Tivoli
Enterprise
Console
-
Guia
do
Usuário
para
obter
informações
adicionais).
Regras
Regra
de
Inicialização
regra:
tt_configure
A
regra
tt_configure
é
uma
regra
de
configuração
que
é
executada
durante
o
recebimento
do
evento
TEC_Start,
que
é
enviado
durante
a
inicialização
do
servidor
de
eventos.
Essa
regra
define
parâmetros
globais
para
as
regras
de
registro
de
problemas
e
inicializa
o
arquivo
de
fatos
para
o
conjunto
de
regras.
Além
disso,
essa
regra
confirma
os
fatos
na
base
de
conhecimento
que
definem
os
critérios
de
eventos
utilizados
para
gerar
automaticamente
registros
de
problemas.
É
necessário
configurar
essa
regra
antes
de
utilizar
o
conjunto
de
regras
de
registro
de
problema;
consulte
“Uso”
na
página
73
para
obter
informações
adicionais.
Regras
de
Abertura
do
Registro
de
Problema
regra:
process_tt_task_complete
A
regra
process_tt_task_complete
é
executada
durante
o
recebimento
de
um
evento
TASK_COMPLETE
com
task_name
igual
a
open_tt,
que
indica
que
um
registro
de
problema
foi
aberto.
Quando
esse
evento
for
recebido,
a
regra
lerá
os
resultados
da
tarefa
para
identificar
o
novo
ID
do
registro
de
problema
e
o
evento
que
conduziu
ao
registro
de
problema.
O
atributo
ttid
do
evento
associado
é
definido
como
o
novo
ID
do
registro
de
problema.
regra:
open_tt
A
regra
open_tt
é
executada
durante
o
recebimento
de
qualquer
evento
que
atenda
os
critériaos
definidos
para
a
abertura
automática
de
um
registro
de
problema.
Esses
critérios
são
armazenados
na
base
de
conhecimento
e
são
configurados
pela
regra
de
configuração
tt_configure.
Quando
chega
um
evento
correspondente,
a
regra
executa
uma
das
seguintes
ações:
v
Se
o
parâmetro
_assoc_flag
estiver
definido
como
ON,
a
regra
verificará
se
um
registro
de
problema
aberto
já
está
associado
a
outro
evento
da
mesma
classe,
do
mesmo
host
e
com
a
mesma
gravidade.
Se
tal
registro
de
problema
já
existir,
o
evento
recém-recebido
será
associado
ao
registro
de
problema
existente.
O
atributo
ttid
do
novo
evento
será
definido
como
o
ID
do
registro
de
problema
e
o
script
TroubleTicket.sh
será
utilizado
para
adicionar
uma
mensagem
ao
registro
de
problema
existente
especificando
o
novo
evento.
v
Se
ainda
não
houver
nenhum
registro
de
problema
semelhante
aberto,
ou
se
o
parâmetro
_assoc_flag
estiver
definido
como
OFF,
o
script
TroubleTicket.sh
será
utilizado
para
abrir
um
novo
registro
de
problema.
O
atributo
ttid
do
novo
evento
será
definido
como
o
ID
do
novo
registro
de
problema.
Conjunto
de
Regras
do
Registro
de
Problemas
(troubleticket.rls)
75
regra:
process_tt_open_event
A
regra
process_tt_open_event
é
executada
durante
o
recebimento
de
um
evento
TT_Open_Event,
que
é
enviado
pelo
sistema
de
registro
de
problema
para
indicar
que
foi
aberto
um
registro
de
problema
para
um
evento.
Quando
TT_Open_Event
é
recebido,
o
atributo
ttid
do
evento
associado
é
definido
como
o
ID
do
registro
de
problema
especificado.
O
evento
TT_Open_Event
recebido
é
então
eliminado.
Regras
de
Sincronização
do
Registro
de
Problema
regra:
process_tt_update_event
A
regra
process_tt_update_event
é
executada
durante
o
recebimento
de
um
evento
TT_Update_Event,
que
é
enviado
pelo
sistema
de
registro
de
problema
para
indicar
que
um
registro
de
problema
foi
atualizado.
Se
o
evento
TT_Update_Event
especificar
um
evento
associado,
esse
evento
será
atualizado
com
as
novas
informações;
de
outra
maneira,
todos
os
eventos
associados
ao
registro
de
problema
serão
atualizados.
O
atributo
slotvector
do
evento
recebido
contém
os
pares
nome
e
valor
que
especificam
quais
alterações
devem
ser
feitas
nos
atributos
de
eventos
associados.
O
evento
TT_Update_Event
recebido
é
então
eliminado.
regra:
process_tt_close_event
A
regra
process_tt_close_event
é
executada
durante
o
recebimento
de
um
evento
TT_Close_Event,
que
é
enviado
pelo
sistema
de
registro
de
problemas
para
indicar
que
um
registro
de
problema
foi
fechado.
Quando
esse
evento
for
recebido,
os
eventos
abertos
associados
ao
registro
de
problema
fechado
serão
fechados
automaticamente.
O
evento
TT_Close_Event
recebido
será
então
eliminado.
regra
de
alteração:
update_status_tt
A
regra
de
alteração
update_status_tt
é
executada
quando
o
status
de
um
evento
associado
a
um
registro
de
problema
é
alterado
para
qualquer
valor
diferente
de
CLOSED.
Quando
isso
ocorre,
o
script
TroubleTicket.sh
é
utilizado
para
atualizar
o
registro
de
problema
para
refletir
o
status
alterado.
regra
de
alteração:
update_severity_tt
A
regra
de
alteração
update_severity_tt
é
executada
quando
existe
uma
alteração
na
gravidade
de
qualquer
evento
que
esteja
associado
a
um
registro
de
problema.
Quando
isso
ocorre,
o
script
TroubleTicket.sh
é
utilizado
para
atualizar
o
registro
de
problema
para
refletir
a
gravidade
alterada.
regra
de
alteração:
close_tt
A
regra
de
alteração
close_tt
é
executada
quando
um
evento
associado
a
um
registro
de
problema
é
fechado.
Quando
isso
ocorre,
a
regra
executa
uma
das
seguintes
ações:
v
Se
o
parâmetro
global
_assoc_flag
estiver
definido
como
OFF,
o
registro
de
problema
associado
será
fechado.
v
Se
o
parâmetro
global
_assoc_flag
estiver
definido
como
ON,
serão
pesquisados
no
cache
de
eventos
outros
eventos
associados
ao
mesmo
registro
de
problema.
Se
forem
localizados
outros
eventos
associados,
o
registro
de
problema
será
atualizado
para
refletir
o
evento
fechado.
Se
não
forem
localizados
outros
eventos
associados,
o
registro
de
problema
será
fechado.
76
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Avisos
Estas
informações
foram
desenvolvidas
para
produtos
e
serviços
oferecidos
nos
Estados
Unidos.
É
possível
que
a
IBM
não
ofereça
os
produtos,
serviços
ou
recursos
discutidos
nesta
publicação
em
outros
países.
Consulte
um
representante
IBM
local
para
obter
informações
sobre
produtos
e
serviços
disponíveis
atualmente
em
sua
área.
Qualquer
referência
a
produtos,
programas
ou
serviços
IBM
não
significa
que
apenas
os
produtos,
programas
ou
serviços
IBM
possam
ser
utilizados.
Qualquer
produto,
programa
ou
serviço
funcionalmente
equivalente,
que
não
infrinja
nenhum
direito
de
propriedade
intelectual
da
IBM,
poderá
ser
utilizado
em
substituição
a
este
produto,
programa
ou
serviço.
Entretanto,
a
avaliação
e
verificação
da
operação
de
qualquer
produto,
programa
ou
serviço
não-IBM
são
de
responsabilidade
do
Cliente.
A
IBM
pode
ter
patentes
ou
solicitações
de
patentes
pendentes
relativas
a
assuntos
tratados
nesta
publicação.
O
fornecimento
desta
publicação
não
garante
ao
Cliente
nenhum
direito
sobre
tais
patentes.
Pedidos
de
licença
devem
ser
enviados,
por
escrito,
para:
Gerência
de
Relações
Comerciais
e
Industriais
da
IBM
Brasil
Av.
Pasteur
138/146
Botafogo
Rio
de
Janeiro
CEP
22290-240
Para
pedidos
de
licença
relacionados
a
informações
de
DBCS
(Conjunto
de
Caracteres
de
Byte
Duplo),
entre
em
contato
com
o
Departamento
de
Propriedade
Intelectual
da
IBM
em
seu
país
ou
envie
pedidos
de
licença,
por
escrito,
para:
IBM
World
Trade
Asia
Corporation
Licensing
2-31
Roppongi
3-chome,
Minato-ku
Tokyo
106,
Japan
O
parágrafo
a
seguir
não
se
aplica
a
nenhum
país
em
que
tais
disposições
não
estejam
de
acordo
a
legislação
local:
A
INTERNATIONAL
BUSINESS
MACHINES
CORPORATION
FORNECE
ESTA
PUBLICAÇÃO
″NO
ESTADO
EM
QUE
SE
ENCONTRA″,
SEM
GARANTIA
DE
NENHUM
TIPO,
SEJA
EXPRESSA
OU
IMPLÍCITA,
INCLUINDO,
MAS
NÃO
SE
LIMITANDO
ÀS
GARANTIAS
IMPLÍCITAS
DE
NÃO-VIOLAÇÃO,
MERCADO
OU
ADEQUAÇÃO
A
UM
DETERMINADO
PROPÓSITO.
Alguns
países
não
permitem
a
exclusão
de
garantias
expressas
ou
implícitas
em
certas
transações;
portanto,
esta
disposição
pode
não
se
aplicar
ao
Cliente.
Esta
publicação
pode
incluir
imprecisões
técnicas
ou
erros
tipográficos.
Periodicamente,
são
feitas
alterações
nas
informações
aqui
contidas;
tais
alterações
serão
incorporadas
em
futuras
edições
desta
publicação.
A
IBM
pode,
a
qualquer
momento,
aperfeiçoar
e/ou
alterar
os
produtos
e/ou
programas
descritos
nesta
publicação,
sem
aviso
prévio.
©
Copyright
IBM
Corp.
2003
77
Referências
nestas
informações
a
Web
sites
não-IBM
são
fornecidas
apenas
por
conveniência
e
não
representam
de
forma
alguma
um
endosso
a
esses
Web
sites.
Os
materiais
contidos
nestes
da
Web
sites
não
fazem
parte
dos
materiais
deste
produto
IBM
e
a
utilização
destes
Web
sites
é
de
inteira
responsabilidade
do
Cliente.
A
IBM
pode
utilizar
ou
distribuir
as
informações
fornecidas
da
forma
que
julgar
apropriada
sem
incorrer
em
qualquer
obrigação
para
com
o
Cliente.
Licenciados
deste
programa
que
desejam
obter
informações
sobre
este
assunto
com
objetivo
de
permitir:
(i)
a
troca
de
informações
entre
programas
criados
independentemente
e
outros
programas
(incluindo
este)
e
(ii)
a
utilização
mútua
das
informações
trocadas,
devem
entrar
em
contato
com:
Gerência
de
Relações
Comerciais
e
Industriais
da
IBM
Brasil
Av.
Pasteur,
138/146
Botafogo
Rio
de
Janeiro,
RJ
CEP
22290-240
Tais
informações
podem
estar
disponíveis,
sujeitas
a
termos
e
condições
apropriadas,
incluindo
em
alguns
casos
o
pagamento
de
uma
taxa.
O
programa
licenciado
descrito
neste
documento
e
todo
o
material
licenciado
disponível
são
fornecidos
pela
IBM
sob
os
termos
do
Contrato
com
o
Cliente
IBM,
do
Contrato
de
Licença
do
Programa
Internacional
IBM
ou
de
qualquer
outro
contrato
equivalente.
Quaisquer
dados
de
desempenho
contidos
neste
documento
foram
determinados
em
um
ambiente
controlado.
Portanto,
os
resultados
obtidos
em
outros
ambientes
operacionais
podem
variar
significativamente.
Algumas
medições
foram
feitas
em
sistemas
de
nível
de
desenvolvimento
e
não
há
garantia
de
que
serão
as
mesmas
em
sistemas
geralmente
disponíveis.
Além
disso,
algumas
medições
podem
ser
resultado
de
estimativas
feitas
por
inferência.
Os
resultados
reais
podem
variar.
O
usuário
deste
documento
deve
verificar
os
dados
aplicáveis
ao
seu
ambiente
específico.
As
informações
relativas
a
produtos
não-IBM
foram
obtidas
junto
aos
fornecedores
dos
respectivos
produtos,
de
seus
anúncios
publicados
ou
de
outras
fontes
disponíveis
publicamente.
A
IBM
não
testou
estes
produtos
e
não
pode
confirmar
a
precisão
de
seu
desempenho,
compatibilidade
nem
qualquer
outra
reivindicação
relacionada
a
produtos
não-IBM.
Dúvidas
sobre
os
recursos
de
produtos
não-IBM
devem
ser
encaminhadas
diretamente
a
seus
fornecedores.
Todas
as
declarações
relacionadas
aos
objetivos
e
intenções
futuras
da
IBM
estão
sujeitas
a
alterações
ou
cancelamento
sem
aviso
prévio,
e
representam
apenas
metas
e
objetivos.
Esta
publicação
contém
exemplos
de
dados
e
relatórios
utilizados
em
operações
diárias
de
negócios.
Para
ilustrá-los
da
forma
mais
completa
possível,
os
exemplos
podem
incluir
nomes
de
indivíduos,
empresas,
marcas
e
produtos.
Todos
estes
nomes
são
fictícios
e
qualquer
semelhança
com
nomes
e
endereços
utilizados
por
uma
empresa
real
é
mera
coincidência.
Estas
informações
contêm
programas
aplicativos
de
amostra
no
idioma
de
origem,
os
quais
ilustram
técnicas
de
programação
em
várias
plataformas
operacionais.
O
78
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
cliente
pode
copiar,
modificar
e
distribuir
esses
programas
de
amostra
de
qualquer
forma,
sem
pagamentos
para
a
IBM,
para
fins
de
desenvolvimento,
uso,
marketing
ou
distribuição
de
programas
aplicativos,
de
acordo
com
a
interface
de
programação
de
aplicativo
da
plataforma
operacional
na
qual
os
programas
de
amostra
são
gravados.
Esses
exemplos
não
foram
inteiramente
testados
sob
todas
as
condições.
Portanto,
a
IBM
não
pode
garantir
nem
sugerir
confiabilidade,
utilidade
ou
função
desses
programas.
O
Cliente
pode
copiar,
modificar
e
distribuir
esses
exemplos
de
programas
de
qualquer
forma,
sem
pagamento
à
IBM,
com
o
objetivo
de
desenvolver,
utilizar,
vender
ou
distribuir
programas
aplicativos
de
acordo
com
a
interfaces
de
programação
de
aplicativo
da
plataforma
operacional
para
a
qual
os
exemplos
de
programas
são
escritos.
Se
estas
informações
estiverem
sendo
exibidas
em
cópia
eletrônica,
as
fotografias
e
ilustrações
coloridas
podem
não
aparecer.
Marcas
Comerciais
Os
termos
a
seguir
são
marcas
comerciais
da
International
Business
Machines
Corporation
nos
Estados
Unidos
e/ou
em
outros
países:
v
IBM
v
Logotipo
IBM
v
Tivoli
v
Logotipo
Tivoli
v
DB2
v
IBMLink
v
NetView
v
Tivoli
Enterprise
Console
v
TME
Java
e
todas
as
marcas
comerciais
e
logotipos
baseados
em
Java
são
marcas
comerciais
ou
marcas
registradas
da
Sun
Microsystems,
Inc.
nos
Estados
Unidos
e/ou
em
outros
países.
Microsoft
e
Windows
NT
são
marcas
registradas
da
Microsoft
Corporation
nos
Estados
Unidos
e/ou
em
outros
países.
Java
e
todas
as
marcas
comerciais
e
logotipos
baseados
em
Java
são
marcas
comerciais
ou
marcas
registradas
da
Sun
Microsystems,
Inc.
nos
Estados
Unidos
e/ou
em
outros
países.
UNIX
é
uma
marca
registrada
do
The
Open
Group
nos
Estados
Unidos
e
em
outros
países.
Outros
nomes
de
empresas,
produtos
e
serviços
podem
ser
marcas
comerciais
ou
marcas
de
serviço
de
terceiros.
Avisos
79
80
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
Índice
Remissivo
Aadaptador
de
alerta
do
NetView
para
z/OS
67,
71
adaptador
de
alertas
SNA
do
AS/400
71
adaptador
de
mensagens
do
NetView
para
z/OS
67,
69
adaptador
HP
OpenView
65
arquivo
activity.log
29
arquivo
dependencies.pro
13
arquivo
dependency.log
14
arquivo
ebusiness.log
19
arquivo
maintenance_mode.pro
43
arquivo
netview.log
48
arquivo
notify.pro
63
arquivo
rule_sets
3
arquivo
tec_forward.conf
35,
67
arquivo
troubleticket.err
74
arquivo
troubleticket.pro
74
atividade
do
sistema
de
pulsação
37,
39
aumentando
a
gravidade
do
evento
25,
33
Bbase
de
regras
1
conjuntos
de
regras
de
seqüenciamento
3,
7,
18,
25,
31,
42,
63
modificando
2
padrão
1
base
de
regras
padrão
1
directory
1
Ccache
de
eventos
5
limpando
antigos
eventos
abertos
5
cancelando
a
manutenção
41
cleanup.rls
5
comando
wrb
–deldp
13,
14,
21
comando
wrb
–imptdp
13,
14,
21
comando
wtdbclear
11
componente
NetView
17,
45
enviando
traps
do
SNMP
para
45,
48
Evento
nível
2
46
Evento
nível
3
46
eventos
de
correlação
46
gravidade
do
evento
45
limpeza
de
eventos
45
sincronizando
com
45,
48
conjunto
de
regras
1
ativando
1
cleanup.rls
5
configuração
1
correlation.rls
4
corrlation.rls
7
db_cleanup.rls
11
dependency.rls
13,
18
desativando
3
ebusiness.rls
13,
15
escalate.rls
4,
25
event_activity.rls
29
event_filtering.rls
4,
31
event_thresholds.rls
33
conjunto
de
regras
(continuação)forwarding.rls
35
heartbeat.rls
37
localização
de
arquivo
1
maintenance_mode.rls
4,
41
modificando
2
netview.rls
45
notify.rls
4,
25,
63
ov_default.rls
65
pré-configurado
1
seqüenciamento
3,
7,
18,
25,
31,
42,
63
tecad_nv390.rls
69
tecad_nv390fwd.rls
67
tecad_snaevent.rls
71
troubleticket.rls
73
conjuntos
de
regras
de
seqüenciamento
3
convençõesfonte
viii
convenções
referentes
a
tipos
de
caracteres
viii
correlacionando
eventos
46
correlation.rls
4,
7
Ddb_cleanup.rls
11
definindo
relacionamentos
de
dependência
20
dependency.rls
4,
13,
18
desativando
conjuntos
de
regras
3
Eebusiness.rls
4,
13,
15
enumeração
HEARTBEAT_LEVEL
37
escalate.rls
4,
25
event_activity.rls
29
event_filtering.rls
4,
31
event_thresholds.rls
33
evento
5
analisando
com
base
em
relacionamentos
de
dependência
17
associando
com
base
em
relacionamentos
de
dependência
15
aumentando
a
gravidade
25,
33
correlacionando
7,
46
DB_Cleanup_event
11,
12
DB2_Down_Status
23
DB2_High_ApplicationAgent_TotSystemCpuTime
23
DB2_High_ApplicationAgents_Workload
23
DB2_High_ConnectionErrors
23
DB2_High_ConnWaitingForHost
23
DB2_High_CurrentConnections
23
DB2_High_DB2ApplicationAgent_TotUserCpuTime
23
DB2_High_HostTimePerStatement
23
DB2_High_InstanceAgents_AgentCreationRatio
23
DB2_High_InstanceAgents_PctAgentsWaiting
23
DB2_High_MostRecentConnectResponse
23
DB2_High_NetworkTimePerStatement
23
DB2_High_PctConnectionsUsed
23
DB2_High_TimePerStatement
23
encaminhando
para
outro
servidor
de
eventos
35,
67
©
Copyright
IBM
Corp.
2003
81
evento
(continuação)escalando
25,
33
Escalate_event
27
evento
de
causa
16
evento
de
causa
da
rede
17
evento
de
causa
de
e-business
17
evento
de
causa
de
manutenção
17
evento
de
limpeza
7
excluindo
antigos
eventos
fechados
11
fechando
antigos
eventos
abertos
5
HeartBeat_DMAgentDown
21
HeartBeat_EndpointUnreachable
21
HeartBeat_Off
21
HeartBeat_ResourceModelsInError
21
impacto
de
serviços
17,
46
informativo
16
NV390MSG_EVENT
69
OV_IF_Down
65,
66
OV_Node_Down
65,
66
OV_Phys_Addr_Chg
65
OV_Phys_Addr_Mismatch
65
OV_Sys_Contact_Chg
65
OV_Sys_Descr_Chg
65
OV_Sys_Location_Chg
65
provável
causa
17
provável
evento
de
causa
16
relatório
de
atividade
29
seqüência
de
eventos
7
SNA_Event
71
TASK_COMPLETE
75
TEC_Cleanup_event
6
TEC_Dependency
13,
14
TEC_Heartbeat
29,
31,
37,
39
TEC_Heartbeat_missed
16,
21,
22,
37,
39,
40,
46,
60,
61
TEC_ITS_INTERFACE_ADDED
50,
52
TEC_ITS_INTERFACE_MANAGE
50,
52
TEC_ITS_INTERFACE_STATUS
46,
49,
50,
52,
58,
59,
60
TEC_ITS_ISDN_STATUS
49,
50
TEC_ITS_L2_NODE_STATUS
46,
50,
51,
56,
57
TEC_ITS_NODE_ADDED
50,
52
TEC_ITS_NODE_MANAGE
50,
52
TEC_ITS_NODE_SERVICE_IMPACT
17,
22,
23,
24,
46,
51,
53,
54
TEC_ITS_NODE_STATUS
18,
22,
46,
49,
51,
52,
53,
55,
56,
59,
60,
61
TEC_ITS_Not_Monitoring_eBusiness
18
TEC_ITS_ROUTER_STATUS
46,
49,
51,
52,
54,
57,
58,
59,
60,
61
TEC_ITS_SA_STATUS
46,
50,
51,
55,
56,
57
TEC_ITS_SNMPCOLLECT_THRESHOLD
49,
50
TEC_ITS_SUBNET_CONNECTIVITY
46,
50,
51,
54,
55,
57,
58,
59,
60,
61
TEC_ITS_SUBNET_SERVICE_IMPACT
46,
51,
54,
55
TEC_ITS_UNREACHABLE
46,
60,
61
TEC_Maintenance
17,
18,
22,
23,
29,
31,
41,
43,
44
TEC_PROBABLE_EVENT_ASSOCIATION
18
TEC_Start
6,
8,
11,
14,
21,
27,
30,
31,
34,
36,
39,
43,
49,
64,
75
TEC_Stop
14,
21,
49
TT_Close_Event
76
TT_Open_Event
76
TT_Update_Event
76
WebSphere_MQ_ChannelNotActivated
22
WebSphere_MQ_ChannelNotTransmitting
22
WebSphere_MQ_ChannelStartupError
22
WebSphere_MQ_ChannelThroughputProblem
22
WebSphere_MQ_QueueFilling
22
evento
(continuação)WebSphere_MQ_QueueManagerUnavailable
22
WebSphereAS_high_DBPool_avgWaitTime
23
WebSphereAS_high_DBPool_faults
23
WebSphereAS_high_DBPool_percentUsed
23
WebSphereAS_high_Transaction_avg_response_time
23
WebSphereAS_high_Transaction_timeout_ratio
23
Evento
da
rede
nível
2
46
Evento
da
rede
nível
3
46
evento
DB_Cleanup_event
11,
12
evento
DB2_Down_Status
23
evento
DB2_High_ApplicationAgent_TotSystemCpuTime
23
evento
DB2_High_ApplicationAgents_Workload
23
evento
DB2_High_ConnectionErrors
23
evento
DB2_High_ConnWaitingForHost
23
evento
DB2_High_CurrentConnections
23
evento
DB2_High_DB2ApplicationAgent_TotUserCpuTime
23
evento
DB2_High_HostTimePerStatement
23
evento
DB2_High_InstanceAgents_AgentCreationRatio
23
evento
DB2_High_InstanceAgents_PctAgentsWaiting
23
evento
DB2_High_MostRecentConnectResponse
23
evento
DB2_High_NetworkTimePerStatement
23
evento
DB2_High_PctConnectionsUsed
23
evento
DB2_High_TimePerStatement
23
evento
de
causa
da
rede
17
evento
de
causa
de
e-business
17
evento
de
causa
de
manutenção
17
evento
de
impacto
de
serviços
17,
46
evento
de
limpeza
7
evento
Escalate_event
27
evento
HeartBeat_DMAgentDown
21
evento
HeartBeat_EndpointUnreachable
21
evento
HeartBeat_Off
21
evento
HeartBeat_ResourceModelsInError
21
evento
informativo
16
evento
NV390MSG_EVENT
69
evento
OV_IF_Down
65,
66
evento
OV_Node_Down
65,
66
evento
OV_Phys_Addr_Chg
65
evento
OV_Phys_Addr_Mismatch
65
evento
OV_Sys_Contact_Chg
65
evento
OV_Sys_Descr_Chg
65
evento
OV_Sys_Location_Chg
65
evento
SNA_Event
71
evento
TASK_COMPLETE
75
evento
TEC_Cleanup_event
6
evento
TEC_Dependency
13,
14
evento
TEC_Heartbeat
29,
31,
37,
39
evento
TEC_Heartbeat_missed
16,
21,
22,
37,
39,
40,
46,
60,
61
evento
TEC_ITS_INTERFACE_ADDED
50,
52
evento
TEC_ITS_INTERFACE_MANAGE
50,
52
evento
TEC_ITS_INTERFACE_STATUS
46,
49,
50,
52,
58,
59,
60
evento
TEC_ITS_ISDN_STATUS
49,
50
evento
TEC_ITS_L2_NODE_STATUS
46,
50,
51,
56,
57
evento
TEC_ITS_NODE_ADDED
50,
52
evento
TEC_ITS_NODE_MANAGE
50,
52
evento
TEC_ITS_NODE_SERVICE_IMPACT
17,
22,
23,
24,
46,
51,
53,
54
evento
TEC_ITS_NODE_STATUS
18,
22,
46,
49,
51,
52,
53,
55,
56,
59,
60,
61
evento
TEC_ITS_Not_Monitoring_eBusiness
18
evento
TEC_ITS_ROUTER_STATUS
46,
49,
51,
52,
54,
57,
58,
59,
60,
61
evento
TEC_ITS_SA_STATUS
46,
50,
51,
55,
56,
57
evento
TEC_ITS_SNMPCOLLECT_THRESHOLD
49,
50
82
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
evento
TEC_ITS_SUBNET_CONNECTIVITY
46,
50,
51,
54,
55,
57,
58,
59,
60,
61
evento
TEC_ITS_SUBNET_SERVICE_IMPACT
46,
51,
54,
55
evento
TEC_ITS_UNREACHABLE
46,
60,
61
evento
TEC_Maintenance
17,
18,
22,
23,
29,
31,
41,
43,
44
evento
TEC_PROBABLE_EVENT_ASSOCIATION
18
evento
TEC_Start
6,
8,
11,
14,
21,
27,
30,
31,
34,
36,
39,
43,
49,
64,
75
evento
TEC_Stop
14,
21,
49
evento
TT_Close_Event
76
evento
TT_Open_Event
76
evento
TT_Update_Event
76
evento
WebSphere_MQ_ChannelNotActivated
22
evento
WebSphere_MQ_ChannelNotTransmitting
22
evento
WebSphere_MQ_ChannelStartupError
22
evento
WebSphere_MQ_ChannelThroughputProblem
22
evento
WebSphere_MQ_QueueFilling
22
evento
WebSphere_MQ_QueueManagerUnavailable
22
evento
WebSphereAS_high_DBPool_avgWaitTime
23
evento
WebSphereAS_high_DBPool_faults
23
evento
WebSphereAS_high_DBPool_percentUsed
23
evento
WebSphereAS_high_Transaction_avg_response_time
23
evento
WebSphereAS_high_Transaction_timeout_ratio
23
excluindo
antigos
eventos
fechados
11
Fforwarding.rls
35
Hheartbeat.rls
4,
37
IIBM
Tivoli
Monitoring
16,
21
IBM
Tivoli
Monitoring
for
Business
Integration
16,
17
IBM
Tivoli
Monitoring
for
Databases
16
IBM
Tivoli
Monitoring
for
Web
Infrastructure
16
IBM
WebSphere
Application
Server
15,
23,
24
IBM
WebSphere
MQ
15,
17,
22,
24
integrando
com
sistemas
de
registro
de
problemas
73
Llimite,
evento
33
limpeza
do
banco
de
dados
11
Mmaintenance_mode.rls
4,
41
manuaisconsulte
publicações
v,
vi
modo
de
manutenção
17,
39,
41
entrando
41
saindo
41
monitorando
pulsações
37
Nnetview.rls
4,
45
newsgroups
vii
nome
de
caminhos,
notação
ix
nomes
de
diretórios,
notação
ix
notaçãofonte
ix
nomes
de
caminhos
ix
variáveis
de
ambiente
ix
notificação
por
25,
37,
38,
40,
63
notificação
por
pager
25
notify.rls
4,
25,
63
Oov_default.rls
65
Ppedindo
publicações
vii
programando
a
manutenção
41
provável
evento
de
causa
16,
17
publicações
v
acessando
on-line
vi
solicitando
vii
publicações
onlineacessando
vi
pulsação
46
pulsação
não-correspondente
46
Rrelacionamento
de
dependência
13,
15
analisando
eventos
com
base
em
17
correlacionando
eventos
com
base
em
15
definindo
13,
15,
20
tipos
15
WAS_DEPENDS_ON_DB2
15
WMQ_DEPENDS_ON_WMQ
15
relatório
de
atividade
29
Sscript
wstopmaint.sh
41
serviços
de
e-business
15,
20
definindo
relacionamentos
de
dependência
20
IBM
WebSphere
Application
Server
15
IBM
WebSphere
MQ
15
software
IBM
DB2
15
sincronizando
com
o
componente
NetView
45,
48
SNA
71
software
DB2Veja
software
IBM
DB2
software
IBM
DB2
15,
17,
23,
24
suporte
ao
clienteconsulte
o
suporte
ao
software
vii
suporte
de
softwareentrando
em
contato
vii
Ttarefa
Start_Maintenance
41
TEC_ITS_NODE_SERVICE_IMPACT
54
TEC_ITS_NODE_STATUS
18
tecad_nv390fwd.rls
67
tecad_nv390msg.rls
69
tecad_snaevent.rls
71
Índice
Remissivo
83
Tivoli
MonitoringVeja
IBM
Tivoli
Monitoring
Tivoli
Software
Information
Center
vi
trap
do
SNMP
45,
48
troubleticket.rls
73
Vvariáveis,
notação
para
ix
variáveis
de
ambiente,
notação
ix
WWebsphere
Application
ServerVeja
IBM
WebSphere
Application
Server
WebSphere
MQVeja
IBM
WebSphere
MQ
wstartmaint.sh
script
41
84
IBM
Tivoli
Enterprise
Console:
Referência
a
Conjuntos
de
Regras
���
Impresso
em
Brazil
S517-7882-00
