Objetivo
O objetivo destes documento é que ele seja utilizado como base para o desenvolvimento, manutenção e compreensão dos modelos.
Público-alvo
Administradores ou usuários do OpMon que necessitam desenvolver, fornecer manutenção ou compreender sobre o funcionamento dos modelos.
Estrutura de diretórios dos modelos
Cada modelo deve seguir a seguinte estrutura de diretórios:
Diretório principal do modelo: O nome deste diretório deve ser o nome do modelo ao qual está sendo criado, onde é possível utilizar qualquer caractere alfanumérico e underscore (substituir pelos espaços que possam haver no nome). Ex.: model_name.
Subdiretório “agents”: Neste subdiretório, você deve inserir todos os scripts/plugins que o modelo necessita para que seja executado.
Subdiretório “manager”: Se uma configuração de plugin/script necessitar de acesso a fontes de dados externas, você deve codificar esse acesso. Por exemplo, se um determinado script/plugin necessitar de uma lista de pontos de montagem válidos, é necessário que estas informações sejam disponibilizadas. Este é o lugar onde você vai programar o acesso e devolvê-lo ao OpMon.
Subdiretório “icon”: Neste subdiretório você deverá inserir o ícone a ser utilizado pelo modelo (ícone de identificação do modelo via interface).
Arquivo “.json”: Este é o arquivo que descreve a configuração do modelo. Todos os metadados do modelo devem ser declarados dentro deste arquivo e, como o nome do arquivo sugere, ele é um arquivo json codificado.
Arquivo “.spec”: Este é o arquivo utilizado para criar o pacote rpm.
Propriedades do JSON
Para o funcionamento do modelo algumas propriedades básicas são mandatórias, são elas:
Propriedades de parâmetros gerais: Responsável por fornecer ao JSON as informações que serão utilizadas como referência para o modelo,como por exemplo, nome, versão, tags, comandos que serão utilizados, caminhos para os subdiretórios específicos do modelo, dentre outras.
Propriedades de parâmetros globais: Trata-se dos parâmetros que serão compartilhados entre todos os serviços deste modelo. Por exemplo, em um modelo que realiza o monitoramento em um banco de dados Oracle onde temos 3 serviços diferentes sendo monitorados, faz sentido que tenhamos o usuário e senha do banco definido nos parâmetros globais do modelo, haja vista que estes parâmetros serão uteis para os 3 serviços do modelo, sendo necessário apenas declará-los em cada serviço que for utilizar tais parâmetros. A seguir, veja o exemplo de como ficarão as propriedades globais do modelo (este é apenas um exemplo, cada modelo pode exigir características diferentes).
Importante destacar que os nomes dos parâmetros globais, de serviços e as identificações de Warning e Critical devem conter nomes exclusivos. Caso estes nomes não sejam exclusivos (únicos) o modelos não passarão pelo processo automático de validação.
Parâmetro createHost
Aproveite para observar que é possível utilizar, se necessário, o parâmetro “createHost” para os casos onde for necessário criar novos hosts a partir de uma seleção específica de elementos. Por exemplo, ao utilizar um modelo de maquina virtual, é possível que cada guest (cada sistema virtual) seja um host no OpMon. Importante destacar que ao utilizar este parâmetro todos os Hosts selecionados via interface herdarão os serviços selecionados no modelo, ou seja, se houverem 4 serviços no modelo e 3 hosts, ao final do processo serão adicionados um total de 12 serviços, haja vista que cada host possuirá 4 serviços. Veja o exemplo abaixo:
Parâmetro dependency
Ainda utilizando o mesmo exemplo, observe o parâmetro “dependency”, onde esta é responsável por elencar as dependências para que um determinado parâmetro seja ou não carregado:
Utilizando fonte de dados interna
É possível utilizar fontes de dados internas e externas, quando falamos em fonte de dados externa estamos indiretamente falando da criação de uma classe manager contendo toda a lógica relativa ao uso da fonte de dados. Porém, existe uma forma mais simples de utilizar fonte de dados, trata-se do uso de fonte de dados interna, onde é possível utilizar os dados definidos diretamente no JSON em detrimento ao uso de uma solução remota para uma fonte de dados específica.
Para que seja possível utilizar uma fonte de dados interna é mandatório que o tipo de campo utilizado seja do tipo “multiple” e que haja o parâmetro “data” contendo em seu array um store com chave e valor dos respectivos valores da fonte de dados, conforme o exemplo abaixo ilustrado:
Propriedades de serviços: Aqui são declarados todos os serviços do modelo, para cada serviço é possível que este possua não só propriedades de parâmetros locais como também propriedades de parâmetros globais. Abaixo é demonstrado um exemplo de parâmetros de serviços onde são utilizados parâmetros globais (declaração de um ou mais parâmetros globais do modelo diretamente no serviço em específico) e parâmetros locais:
Tipos de campos
|
userpassauth: campo onde o usuário pode selecionar uma autenticação já cadastrada no OpMon ou ainda cadastrar uma nova. |
snmpauth: tipo de campo que o usuário pode selecionar uma comunidade SNMP já cadastrada ou cadastrar uma nova. |
|
query: Campo do tipo _textbox_ onde o usuário pode entrar com um numero maior de caracteres. Deve suportar múltiplas linhas. |
text: campo de entrada simples, uma linha, um input field normal, sem limite quanto ao numero de caracteres. |
|
password: campo quase idêntico ao campo de _text_ porem ocultando os caracteres digitados. |
integer: Gera um “stepper” para inteiros, ou seja, o usuário pode aumentar e diminuir um valor. |
|
float: Um outro “stepper” porem com delta de avanço configurável(agora em float). |
multiple: combobox que permite a seleção de mais do que um elemento. Requer um data source. |
|
select: Gera um select permitindo a seleção de apenas *uma* opção, diferentemente do campo _multiple_. Requer um data source. |
hidden: Não gera o campo na interface e necessita da propriedade default definida. |
|
hostaddress: Este campo herda a informação relativa ao host selecionado, podendo concatenar um ou mais hosts dentro do mesmo campo. |
Abaixo veja exemplos de estruturação dos tipos de campos e como eles são exibidos via interface:
{
"name": "credential",
"description": {
"en_US": "Administrative credential to be used during WMI authentication",
"en_US_ITIL": "Administrative credential to be used during WMI authentication",
"pt_BR": "credenciais de administrador para autenticação WMI",
"pt_BR_ITIL": "credenciais de administrador para autenticação WMI"
},
"mandatory": true,
"label": {
"en_US": "User and password",
"en_US_ITIL": "User and password",
"pt_BR": "Usuário e senha",
"pt_BR_ITIL": "Usuário e senha"
},
"type": "userpassauth"
}
}
{
"name": "password",
"mandatory": true,
"label": {
"en_US": "Password",
"en_US_ITIL": "Password",
"pt_BR": "Senha",
"pt_BR_ITIL": "Senha"
},
"type": "password",
"description": {
"en_US": "The password to connect to Xen Server",
"en_US_ITIL": "The password to connect to Xen Server",
"pt_BR": "Senha de acesso",
"pt_BR_ITIL": "Senha de acesso"
}
}
{
"name": "SQL",
"description": {
"en_US": "Query SQL",
"en_US_ITIL": "Query SQL",
"pt_BR": "Query SQL",
"pt_BR_ITIL": "Query SQL"
},
"mandatory": true,
"label": {
"en_US": "Query SQL",
"en_US_ITIL": "Query SQL",
"pt_BR": "Query SQL",
"pt_BR_ITIL": "Query SQL"
},
"type": "query",
"as": 5
}
{
"name": "username",
"description": {
"en_US": "The username to use to connect to Xen Server",
"en_US_ITIL": "The username to use to connect to Xen Server",
"pt_BR": "The username to use to connect to Xen Server",
"pt_BR_ITIL": "The username to use to connect to Xen Server"
},
"mandatory": true,
"label": {
"en_US": "Username",
"en_US_ITIL": "Username",
"pt_BR": "Username",
"pt_BR_ITIL": "Username"
},
"type": "text",
"as": 6
},
{
"name": "warning",
"description": {
"en_US": "Threshold for Warning alert",
"en_US_ITIL": "Threshold for Warning alert",
"pt_BR": "Determine o valor para Warning",
"pt_BR_ITIL": "Determine o valor para Warning"
},
"mandatory": true,
"label": {
"en_US": "Warning",
"en_US_ITIL": "Warning",
"pt_BR": "Warning",
"pt_BR_ITIL": "Warning"
},
"type": "float",
"as": 5
}
{
"name": "oscounter",
"description": {
"en_US": "Operating System counter's name",
"en_US_ITIL": "Operating System counter's name",
"pt_BR": "Nome do contador",
"pt_BR_ITIL": "Nome do contador"
},
"mandatory": true,
"label": {
"en_US": "Counter",
"en_US_ITIL": "Counter",
"pt_BR": "Contador",
"pt_BR_ITIL": "Contador"
},
"type": "multiple",
"as": 4
}
{
"name": "host",
"description": {
"en_US": "Microsoft™ Windows server's IP address",
"en_US_ITIL": "Microsoft™ Windows server's IP address",
"pt_BR": "Endereço IP do servidor Microsoft™ Windows",
"pt_BR_ITIL": "Endereço IP do servidor Microsoft™ Windows"
},
"mandatory": true,
"label": {
"en_US": "IP address",
"en_US_ITIL": "IP address",
"pt_BR": "Endereço IP",
"pt_BR_ITIL": "Endereço IP"
},
"type": "hostaddress"
}
{
"name": "warning",
"description": {
"en_US": "Threshold for Warning alert",
"en_US_ITIL": "Threshold for Warning alert",
"pt_BR": "Limite para alerta Warning",
"pt_BR_ITIL": "Limite para alerta Warning"
},
"mandatory": true,
"default": 80,
"label": {
"en_US": "Warning",
"en_US_ITIL": "Warning",
"pt_BR": "Alerta",
"pt_BR_ITIL": "Alerta"
},
"type": "hidden",
"as": 5
},
IMPORTANTE: O campo do tipo hidden não é visual, e necessita obrigatoriamente que um valor default seja definido.
{
"name": "warning",
"description": {
"en_US": "Threshold for Warning alert",
"en_US_ITIL": "Threshold for Warning alert",
"pt_BR": "Determine o valor para Warning",
"pt_BR_ITIL": "Determine o valor para Warning"
},
"mandatory": true,
"label": {
"en_US": "Warning",
"en_US_ITIL": "Warning",
"pt_BR": "Warning",
"pt_BR_ITIL": "Warning"
},
"type": "integer",
"as": 5
},
Definição de Diretórios
Toda a estrutura do modelo deve ser criada dentro do seguinte diretório:
/usr/local/opmon/libexec/modelgroups/nome_do_modelo
As pastas “manager” e “icon” devem ser copiadas para o seguinte diretórios:
/usr/local/opmon/share/modelgroups/nome_do_modelo
Instalando o modelo manualmente
Utilize os seguintes comandos para registrar e desregistrar o seu modelo enquanto estiver em fase de criação e validação:
- Para registrar
opmon-models --register=nome_do_modelo --model-version=1.0
- Para desregistrar
opmon-models --unregister=nome_do_modelo
Esta explicação foi elaborada levando em consideração a criação de um modelo básico, onde não é necessário um manager. Porém, ela serve como base para a criação de modelos mais complexos que exijam acesso a fontes externas (necessitam de manager), para saber como utilizar o manager clique aqui.
Você pode utilizar o seguinte site para facilitar na escrita do json, onde é possível fazer a validação da sintaxe em tempo real. Clique aqui para acessá-lo.