Áú»¢¶Ä²©

3 Descoberta de baixo n¨ªvel (LLD)

Vis?o geral

O processo de LLD fornece uma forma autom¨¢tica de criar itens, triggers, gr¨¢ficos para os diferentes objetos descobertos no dispositivo monitorado. Por exemplo, o Áú»¢¶Ä²© pode come?ar automaticamente a monitorar os sistemas de arquivo ou interfaces de rede de um servidor, sem precisar que sejam criados manualmente itens para cada um deles. Adicionalmente, o Áú»¢¶Ä²© tamb¨¦m pode remove-los automaticamente tamb¨¦m ap¨®s determinado per¨ªodo consecutivo em que eles n?o sejam mais encontrados.

Nativamente no Áú»¢¶Ä²©, s?o suportados seis tipos de LLD:

• descoberta de sistemas de arquivo;
• descoberta de interfaces de rede;
• descoberta de CPUs seus n¨²cleos;
• descoberta de ¨¢rvores de OID SNMP;acesse
• descoberta usando consultas SQL/ODBC;
• descoberta de servi?os Windows.

O usu¨¢rio pode estender estas descobertas atrav¨¦s de seus pr¨®prios scripts, contando que estes forne?am o dado em um formato em particular usando o protocolo JSON.

A arquitetura geral do processo de descoberto pode ser definido assim:

• Primeiro um usu¨¢rio cria uma regra de descoberta em Configura??o ¡ú Templates" ou Configura??o ¡ú Hosts e clica no link Descoberta da linha do host/template que se desejar. A configura??o de um LLD pode ser separada em duas fases:
  • Defini??o de um item capaz de descobrir os elementos de configura??o de interesse (por exemplo, sistemas de arquivo ou interfaces de rede);
  • Defini??o dos prot¨®tipos de itens, triggers e gr¨¢ficos que poder?o ser criados dinamicamente usando as informa??es descobertas.

Um item que descobre os elementos necess¨¢rios ¨¦ como qualquer outro item: O Áú»¢¶Ä²© solicita ao Áú»¢¶Ä²© Agent (ou atrav¨¦s de qualquer outro tipo de item) um valor para o item, e o agente responde com um valor textual. A diferen?a aqui ¨¦ que o valor cont¨ºm uma lista de elementos descobertos no formato JSON. Enquanto os detalhes deste formato s?o importantes somente para quem for implementar uma regra customizada de descoberta, ¨¦ necess¨¢rio que se saiba que o valor retornado conter¨¢ uma lista de pares no padr?o macro ¡ú valor. Por exemplo, o item net.if.discovery pode retornar dois pares: "{#IFNAME}" ¡ú "lo" e "{#IFNAME}" ¡ú "eth0".

As macros usadas nos nomes, chaves e outros campos de prot¨®tipos ser?o substitu¨ªdas pelos seus valores descobertos quando as entidades reais (itens, triggers, gr¨¢ficos, ou at¨¦ mesmo outros hosts) forem criados. Consulte a lista completa de op??es para as macros LLD.

Quando o Áú»¢¶Ä²© Server recebe um valor de um item de descoberta, ele consulta os pares macro ¡ú valor para criar as entidades, conforme prot¨®tipos definidos na regra. No exemplo anterior, com o "net.if.discovery", o Áú»¢¶Ä²© Server ir¨¢ criar um conjunto de itens, triggers e graphs para a interface de 'loopback' e outro para a interface "eth0".

As pr¨®ximas se??es v?o demonstrar o processo em detalhes e servem como um "how-to" para configurar todos os tipos de descoberta antes citados. A ¨²ltima se??o descreve o formato JSON para itens de descoberta e prov¨º um exemplo de como implementar a sua pr¨®pria regra de descoberta de sistema de arquivos usando um script Perl.

3.1 Descoberta de sistemas de arquivos

Para descobrir um sistema de arquivos:

• Acesse Configura??o ¡ú Templates
• Clique no link Descoberta da linha apropriada

• Clique no bot?o Criar regra de descoberta situado no canto direito da barra de t¨ªtulo
• Preencha o formul¨¢rio com os detalhes necess¨¢rios

A aba Regra de descoberta cont¨ºm atributos gerais da regra de descoberta (do item de descoberta):

A aba Filtros cont¨ºm as defini??es de filtros a serem aplicados ap¨®s a coleta do item de descoberta e antes da cria??o das entidades:

Uma vez que uma regra tenha sido criada, v¨¢ para use o link Prot¨®tipos de item, dispon¨ªvel na lista de regras de descoberta do host/template, e clique no bot?o Criar prot¨®tipo de item. Observe que a macro {#FSNAME} ser¨¢ utilizada aqui, seu uso neste ¨¦ obrigat¨®rio, pois cada item a ser criado dever¨¢ ser diferente do item criado anteriormente.

O campo Prot¨®tipo de aplica??o ¨¦ uma op??o dispon¨ªvel especificamente nos prot¨®tipos de itens. Um prot¨®tipo de aplica??o permite que voc¨º crie dinamicamente as aplica??es e as associe aos itens. Consulte mais nas notas sobre descoberta de aplica??es.

N¨®s podemos criar v¨¢rios prot¨®tipos de item para cada m¨¦trica de sistema de arquivo que nos interesse:

Ent?o, criamos prot¨®tipos de trigger de forma similar:

Voc¨º pode definir »å±ð±è±ð²Ô»å¨º²Ô³¦¾±²¹²õ entre prot¨®tipos de trigger tamb¨¦m (suportado desde o Áú»¢¶Ä²© 3.0). Para fazer isso, acesse a ¶Ù±ð±è±ð²Ô»å¨º²Ô³¦¾±²¹²õ. Um prot¨®tipo de trigger poder¨¢ depender de outro prot¨®tipo de trigger da mesma regra de descoberta ou de outra trigger normal. N?o ¨¦ poss¨ªvel criar rela??es de depend¨ºncia entre prot¨®tipos de trigger de diferentes regras de descoberta. Um prot¨®tipo de trigger em n¨ªvel de host n?o poder¨¢ depender de uma trigger em n¨ªvel de template.

N¨®s podemos criar prot¨®tipos de gr¨¢fico tamb¨¦m:

Finalmente, n¨®s criamos a regra de descoberta e tudo parece que ir¨¢ funcionar. Temos cinco prot¨®tipos de itens, dois prot¨®tipos de trigger e um prot¨®tipo de gr¨¢fico.

Nota: Para configurar um prot¨®tipo de host consulte o manual de prot¨®tipos de host na ¨¢rea de monitora??o de m¨¢quinas virtuais.

As telas a seguir ilustram como itens, triggers e gr¨¢ficos que foram criados pelo processo de descoberta ir?o se parecer na tela de configura??o de um host. As entidades descobertas ser?o prefixadas por um link laranja com o nome de sua regra de descoberta de origem.

Observe que n?o ser?o criadas entidades para recursos caso j¨¢ exista outra entidade com o mesmo crit¨¦rio de unicidade (por exemplo outro item com a mesma chave, ou gr¨¢fico com o mesmo nome).

Os itens (de forma similar ¨¤s triggers e gr¨¢ficos) criados por um LLD n?o poder?o ser exclu¨ªdos manualmente. Entretanto, poder?o ser exclu¨ªdos automaticamente se a regra de descoberta n?o conseguir mais localizar o recurso, ou se seu filtro excluir o recurso da lista. Neste caso os itens, triggers e gr¨¢ficos ser?o apagados ap¨®s o per¨ªodo definido no campo Manter dados de recursos perdidos por (em dias).

Quando as entidades passam para o estado 'N?o foi mais descoberto', um indicador do tempo restante de vida ser¨¢ apresentado para o item na lista. Ao posicionar o mouse sobre o ¨ªcone de alerta ser¨¢ apresentada uma mensagem indicando quanto tempo falta para o item e seu hist¨®rico serem exclu¨ªdos.

Se as entidades forem marcadas para exclus?o, mas n?o forem exclu¨ªdas no momento previsto (por exemplo por causa da regra de descoberta ter sido inativada), eles ser?o exclu¨ªdos no pr¨®ximo momento que a regra for processada.

3.2 Descoberta de interfaces de rede

A descoberta de interfaces de rede ¨¦ feita exatamente da mesma forma que a descoberta de sistemas de arquivos. O que muda ¨¦ o nome da chave buscada ("net.if.discovery" ao inv¨¦s de "vfs.fs.discovery") e o nome das macros retornadas ({#IFNAME} ao inv¨¦s de {#FSNAME}).

Exemplos de prot¨®tipos de item que voc¨º definir usando a chave "net.if.discovery": "net.if.in[{#IFNAME},bytes]", "net.if.out[{#IFNAME},bytes]". Clique aqui para maiores detalhes.

3.3 Descoberta de CPUs e n¨²cleos de CPU

A descoberta de CPUs e n¨²cleos de CPU da mesma forma que as anteriores, mudando novamente a chave de descoberta: "system.cpu.discovery". Ela tamb¨¦m retorna duas macros: {#CPU.NUMBER} e {#CPU.STATUS}, respectivamente o n¨²mero de sequencia da CPU e seu status. Pode n?o ser poss¨ªvel uma distin??o clara entre processadores f¨ªsicos, n¨²cleos e 'hyperthreads'. Em ambientes Linux, UNIX e BSD a macro {#CPU.STATUS} retorna o status do processador, que poder¨¢ ser "online" ou "offline". Em ambientes Windows, esta macro poder¨¢ conter um terceiro valor - "unknown" - que indicar¨¢ que o processador foi detectado mas nenhuma informa??o foi coletada ainda sobre ele.

A descoberta de CPU utiliza estat¨ªsticas dos processos de coleta do agente para manter a consist¨ºncia dos dados providos e economizar recursos ao obter os dados. Isso afeta a coleta desta chave quando se tenta utilizar a op??o '-t' na linha de comando com o bin¨¢rio do agente diretamente, esta chave ser¨¢ devolvida com o status de NOT_SUPPORTED, acompanhada da mensagem que o coletor n?o foi iniciado.

Os prot¨®tipos de item que podem ser criados com esta descoberta incluem "system.cpu.load[{#CPU.NUMBER}, <mode>]", "system.cpu.util[{#CPU.NUMBER}, <type>, <mode>]", dentre outros.

3.4 Descoberta de OIDs SNMP

Neste exemplo, n¨®s vamos executar a descoberta SNMP em um switch. Acesse Configura??o ¡ú Templates.

Para editar as regras de descoberta do template desejado, clique no link Descoberta de sua linha.

Para criar uma nova regra de descoberta, use o bot?o Criar regra de descoberta localizado no canto direito da barra de t¨ªtulo.

Diferentemente das descobertas de sistemas de arquivos e de interfaces de rede, esta regra n?o necessita de uma chave "snmp.discovery", o uso do tipo SNMP agent ¨¦ suficiente.

Os OIDs ser?o descobertos no seguinte formato: discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, ¡­,]

Onde {#MACRO1}, {#MACRO2} ¡­ s?o nomes v¨¢lidos de macro e oid1, oid2... s?o identificadores OIDs capazes de gerar valores para estas macros. Uma macro pr¨¦-definida {#SNMPINDEX} conter¨¢ o ¨ªndice do OID descoberto que poder¨¢ ser aplicado aos recursos descobertos. Os recursos estar?o agrupados atrav¨¦s da macro {#SNMPINDEX}.

Para entender o que isso significa, vamos executar alguns snmpwalks em nosso switch:

$ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB::ifDescr
       IF-MIB::ifDescr.1 = STRING: WAN
       IF-MIB::ifDescr.2 = STRING: LAN1
       IF-MIB::ifDescr.3 = STRING: LAN2
       
       $ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB::ifPhysAddress
       IF-MIB::ifPhysAddress.1 = STRING: 8:0:27:90:7a:75
       IF-MIB::ifPhysAddress.2 = STRING: 8:0:27:90:7a:76
       IF-MIB::ifPhysAddress.3 = STRING: 8:0:27:2b:af:9e

E definir o OID SNMP para: discovery[{#IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress]

Agora esta regra ir¨¢ descobrir os recursos com as macros {#IFDESCR} definidas como WAN, LAN1 e LAN2, as macros {#IFPHYSADDRESS} ter¨¢ os valores 8:0:27:90:7a:75, 8:0:27:90:7a:76, e 8:0:27:2b:af:9e, e as macros {#SNMPINDEX} com os ¨ªndices 1, 2 e 3:

{
           "data": [
               {
                   "{#SNMPINDEX}": "1",
                   "{#IFDESCR}": "WAN",
                   "{#IFPHYSADDRESS}": "8:0:27:90:7a:75"
               },
               {
                   "{#SNMPINDEX}": "2",
                   "{#IFDESCR}": "LAN1",
                   "{#IFPHYSADDRESS}": "8:0:27:90:7a:75"
               },
               {
                   "{#SNMPINDEX}": "3",
                   "{#IFDESCR}": "LAN2",
                   "{#IFPHYSADDRESS}": "8:0:27:2b:af:9e"
               }
           ]
       }

Se um recurso n?o existir no OID especificado ent?o a macro correspondente para ele ser¨¢ omitida, por exemplo:

ifDescr.1 "Interface #1"
       ifDescr.2 "Interface #2"
       ifDescr.4 "Interface #4"
       
       ifAlias.1 "eth0"
       ifAlias.2 "eth1"
       ifAlias.3 "eth2"
       ifAlias.5 "eth4"

Ent?o, neste caso, a descoberta SNMP discovery[{#IFDESCR}, ifDescr, {#IFALIAS}, ifAlias] retornar¨¢ a seguinte estrutura JSON:

{
           "data": [
               {
                   "{#SNMPINDEX}": 1,
                   "{#IFDESCR}": "Interface #1",
                   "{#IFALIAS}": "eth0"
               },
               {
                   "{#SNMPINDEX}": 2,
                   "{#IFDESCR}": "Interface #2",
                   "{#IFALIAS}": "eth1"
               },
               {
                   "{#SNMPINDEX}": 3,
                   "{#IFALIAS}": "eth2"
               },
               {
                   "{#SNMPINDEX}": 4,
                   "{#IFDESCR}": "Interface #4"
               },
               {
                   "{#SNMPINDEX}": 5,
                   "{#IFALIAS}": "eth4"
               }
           ]
       }  

Estas telas ilustram como as macros podem ser utilizadas em prot¨®tipos de item:

Da mesma forma, criando quantos itens quanto o necess¨¢rio:

Prot¨®tipos de trigger:

Prot¨®tipos de gr¨¢fico:

Um sum¨¢rio de nossa regra de descoberta:

Quando o servidor executa, ele cria itens, triggers e gr¨¢ficos reais a partir dos valores retornados pela descoberta SNMP. Na configura??o do host eles estar?o prefixados com o nome da regra de descoberta que os originou e na cor laranja.

3.5 Descoberta usando consultas SQL/ODBC

Este tipo de descoberta ¨¦ feito atrav¨¦s de consultas SQL, cujos resultados s?o transformados automaticamente em um objeto JSON aceit¨¢vel pelo LLD. As consultas SQL s?o executadas com items do tipo "Monitora??o de banco de dados". Consulte o manual sobre monitora??o ODBC para maiores detalhes de como trabalhar com este tipo de item, a ¨²nica diferen?a ¨¦ que a chave a ser utilizada ser¨¢ "db.odbc.discovery[<description>,<dsn>]" ao inv¨¦s de "db.odbc.select[<description>,<dsn>]".

Um exemplo pr¨¢tico de como as consultas SQL s?o transformadas em um JSON pode ser a descoberta atrav¨¦s de um proxy com consultas OBDC no banco do Áú»¢¶Ä²©. Isso pode ser ¨²til para a cria??o autom¨¢tica de itens internos para monitorar os proxies "zabbix[proxy,<name>,lastaccess]", verificando se est?o ativos.

Vamos come?ar com a configura??o da regra de descoberta:

Aqui vamos usar conex?o direta com o BD do Áú»¢¶Ä²© para localizar todos os proxies, junto com a quantidade de hosts que eles monitoram. A quantidade de hosts pode ser utilizada, por exemplo, para filtrar proxies que n?o tem carga de monitora??o sobre s¨ª:

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;
       +---------+-------+
       | host    | count |
       +---------+-------+
       | Japan 1 |     5 |
       | Japan 2 |    12 |
       | Latvia  |     3 |
       +---------+-------+
       3 rows in set (0.01 sec)

Internamente a chave "db.odbc.discovery[]" ir¨¢ receber este valor e transformar em um c¨®digo JSON:

{
           "data": [
               {
                   "{#HOST}": "Japan 1",
                   "{#COUNT}": "5"
               },
               {
                   "{#HOST}": "Japan 2",
                   "{#COUNT}": "12"
               },
               {
                   "{#HOST}": "Latvia",
                   "{#COUNT}": "3"
               }
           ]
       }

Os nomes das colunas da consulta foram automaticamente definidos como sendo os nomes de macro, seguidos de seus valores.

$ grep db.odbc.discovery /tmp/zabbix_server.log
        ...
        23876:20150114:153410.856 In db_odbc_discovery() query:'SELECT h1.host, COUNT(h2.host) FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;'
        23876:20150114:153410.860 db_odbc_discovery() column[1]:'host'
        23876:20150114:153410.860 db_odbc_discovery() column[2]:'COUNT(h2.host)'
        23876:20150114:153410.860 End of db_odbc_discovery():NOTSUPPORTED
        23876:20150114:153410.860 Item [Áú»¢¶Ä²© server:db.odbc.discovery[proxies,{$DSN}]] error: Cannot convert column #2 name to macro.

Agora conseguimos entender como uma consulta SQL ¨¦ transformada em um objeto JSON e podemos utilizar a macro {#HOST} para criar os prot¨®tipos de itens:

Uma vez que a descoberta seja executada, um item ser¨¢ criado para cada proxy:

3.6 Descobertas de servi?os no Windows

A descoberta de servi?os no Windows ¨¦ feita da mesma forma que a descoberta de sistemas de arquivos. A chave utilizada ¨¦ a "service.discovery" as seguintes macros estar?o dispon¨ªveis para uso nos filtros e prot¨®tipos de item/trigger/graph:

{#SERVICE.NAME}
       {#SERVICE.DISPLAYNAME}
       {#SERVICE.DESCRIPTION}
       {#SERVICE.STATE}
       {#SERVICE.STATENAME}
       {#SERVICE.PATH}
       {#SERVICE.USER}
       {#SERVICE.STARTUP}
       {#SERVICE.STARTUPNAME}

Atrav¨¦s da descoberta de servi?os do Windows voc¨º poder¨¢ criar prot¨®tipos de itens como "service.info[{#SERVICE.NAME},<param>]", onde param aceita os seguintes valores: state, displayname, path, user, startup ou description. Por exemplo, para obter o nome de exibi??o de um servi?o voc¨º pode criar um item com a chave "service.info[{#SERVICE.NAME},displayname]". Se o par?metro param n?o for definido ("service.info[{#SERVICE.NAME}]"), o valor padr?o state ser¨¢ utilizado.

As macros {#SERVICE.STATE} e {#SERVICE.STATENAME} retornar?o o mesmo conte¨²do, entretanto, {#SERVICE.STATE} retornar¨¢ a representa??o num¨¦rica (0-7), e {#SERVICE.STATENAME} a representa??o textual (running, paused, start pending, pause pending, continue pending, stop pending, stopped ou unknown). O mesmo se aplica ¨¤s macros {#SERVICE.STARTUP} e {#SERVICE.STARTUPNAME}, onde uma retorna a representa??o num¨¦rica (0-4) e a outra textual (automatic, automatic delayed, manual, disabled, unknown).

3.7 Criando LLD customizado

Al¨¦m de todos os tipos nativos de regra de descoberta, voc¨º tamb¨¦m poder¨¢ criar suas pr¨®prias regras de descoberta para retornar qualquer tipo de recurso - por exemplo, descobrir as bases de dados em um servidor de banco.

Para fazer isso precisamos de um item que retorne um JSON, definindo objetos e, opcionalmente, propriedades deles. A quantidade de macros por entidade n?o ¨¦ limitada. Nas descobertas nativas normalmente s?o retornadas uma ou duas macros mas ¨¦ poss¨ªvel retornar muito mais..

O formato JSON requerido ¨¦ ilustrado neste exemplo, suponhamos que voc¨º esteja usando um Áú»¢¶Ä²© Agent 1.8 (bem antigo), ele n?o ir¨¢ ter suporte nativo para a chave "vfs.fs.discovery", mas ainda assim ele ser¨¢ capaz de executar a descoberta de sistemas de arquivo. Um simples script em Perl no Linux poder¨¢ descobrir os sistemas de arquivo montados e apresentar o resultado no formato JSON, indexando tanto os nomes quanto os seus tipos. Poder¨ªamos criar, por exemplo, um UserParameter chamado "vfs.fs.discovery_perl":

#!/usr/bin/perl
       
       $first = 1;
       
       print "{\n";
       print "\t\"data\":[\n\n";
       
       for (`cat /proc/mounts`)
       {
           ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
           $fsname =~ s!/!\\/!g;
       
           print "\t,\n" if not $first;
           $first = 0;
       
           print "\t{\n";
           print "\t\t\"{#FSNAME}\":\"$fsname\",\n";
           print "\t\t\"{#FSTYPE}\":\"$fstype\"\n";
           print "\t}\n";
       }
       
       print "\n\t]\n";
       print "}\n";

Um exemplo de sa¨ªda deste script (reformatado para melhor legibilidade) poderia ser algo como isso:

{
         "data":[
         
         { "{#FSNAME}":"\/",                           "{#FSTYPE}":"rootfs"   },
         { "{#FSNAME}":"\/sys",                        "{#FSTYPE}":"sysfs"    },
         { "{#FSNAME}":"\/proc",                       "{#FSTYPE}":"proc"     },
         { "{#FSNAME}":"\/dev",                        "{#FSTYPE}":"devtmpfs" },
         { "{#FSNAME}":"\/dev\/pts",                   "{#FSTYPE}":"devpts"   },
         { "{#FSNAME}":"\/",                           "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"\/lib\/init\/rw",              "{#FSTYPE}":"tmpfs"    },
         { "{#FSNAME}":"\/dev\/shm",                   "{#FSTYPE}":"tmpfs"    },
         { "{#FSNAME}":"\/home",                       "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"\/tmp",                        "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"\/usr",                        "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"\/var",                        "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"\/sys\/fs\/fuse\/connections", "{#FSTYPE}":"fusectl"  }
         
         ]
       }

Assim, no Filtro da regra de descoberta voc¨º poder¨¢, por exemplo, validar o conte¨²do da macro "{#FSTYPE}" com uma express?o regular ( "rootfs|ext3").

Item prototypes

Once a rule is created, go to the items for that rule and press "Create prototype" to create an item prototype. Note how macro {#FSNAME} is used where a file system name is required. When the discovery rule is processed, this macro will be substituted with the discovered file system.

Low-level discovery macros and user macros may be used in item prototype configuration and item value preprocessing parameters. Note that when used in update intervals, a single macro has to fill the whole field. Multiple macros in one field or macros mixed with text are not supported.

Attributes that are specific for item prototypes:

We can create several item prototypes for each file system metric we are interested in:

Mass update option is available if you want to update properties of several item prototypes at once.

Trigger prototypes

We create trigger prototypes in a similar way as item prototypes:

Attributes that are specific for trigger prototypes:

When real triggers are created from the prototypes, there may be a need to be flexible as to what constant ('20' in our example) is used for comparison in the expression. See how user macros with context can be useful to accomplish such flexibility.

You can define dependencies between trigger prototypes as well (supported since Áú»¢¶Ä²© 3.0). To do that, go to the Dependencies tab. A trigger prototype may depend on another trigger prototype from the same low-level discovery (LLD) rule or on a regular trigger. A trigger prototype may not depend on a trigger prototype from a different LLD rule or on a trigger created from trigger prototype. Host trigger prototype cannot depend on a trigger from a template.

Graph prototypes

We can create graph prototypes, too:

Attributes that are specific for trigger prototypes:

Finally, we have created a discovery rule that looks as shown below. It has five item prototypes, two trigger prototypes, and one graph prototype.

Note: For configuring host prototypes, see the section about host prototype configuration in virtual machine monitoring.

Discovered entities

The screenshots below illustrate how discovered items, triggers, and graphs look like in the host's configuration. Discovered entities are prefixed with an orange link to a discovery rule they come from.

Note that discovered entities will not be created in case there are already existing entities with the same uniqueness criteria, for example, an item with the same key or graph with the same name. An error message is displayed in this case in the frontend that the low-level discovery rule could not create certain entities. The discovery rule itself, however, will not turn unsupported because some entity could not be created and had to be skipped. The discovery rule will go on creating/updating other entities.

Items (similarly, triggers and graphs) created by a low-level discovery rule will be deleted automatically if a discovered entity (file system, interface, etc) stops being discovered (or does not pass the filter anymore). In this case the items, triggers and graphs will be deleted after the days defined in the Keep lost resources period field pass.

When discovered entities become 'Not discovered anymore', a lifetime indicator is displayed in the item list. Move your mouse pointer over it and a message will be displayed indicating how many days are left until the item is deleted.

If entities were marked for deletion, but were not deleted at the expected time (disabled discovery rule or item host), they will be deleted the next time the discovery rule is processed.

Entities containing other entities, which are marked for deletion, will not update if changed on the discovery rule level. For example, LLD-based triggers will not update if they contain items that are marked for deletion.

Other types of discovery

More detail and how-tos on other types of out-of-the-box discovery is available in the following sections:

• discovery of network interfaces;
• discovery of CPUs and CPU cores;
• discovery of SNMP OIDs;
• discovery of JMX objects;
• discovery using ODBC SQL queries;
• discovery of Windows services;
• discovery of host interfaces in Áú»¢¶Ä²©.

For more detail on the JSON format for discovery items and an example of how to implement your own file system discoverer as a Perl script, see creating custom LLD rules.

Data limits for return values

There is no limit for low-level discovery rule JSON data if it is received directly by Áú»¢¶Ä²© server, because return values are processed without being stored in a database. There's also no limit for custom low-level discovery rules, however, if it is intended to acquire custom LLD data using a user parameter, then user parameter return value limit applies (512 KB).

If data has to go through Áú»¢¶Ä²© proxy it has to store this data in database so database limits apply.

Multiple LLD rules for same item

Since Áú»¢¶Ä²© agent version 3.2 it is possible to define several low-level discovery rules with the same discovery item.

To do that you need to define the Alias agent parameter, allowing to use altered discovery item keys in different discovery rules, for example vfs.fs.discovery[foo], vfs.fs.discovery[bar], etc.

Creating custom LLD rules

It is also possible to create a completely custom LLD rule, discovering any type of entities - for example, databases on a database server.

To do so, a custom item should be created that returns JSON, specifying found objects and optionally - some properties of them. The amount of macros per entity is not limited - while the built-in discovery rules return either one or two macros (for example, two for filesystem discovery), it is possible to return more.

The required JSON format is best illustrated with an example. Suppose we are running an old Áú»¢¶Ä²© 1.8 agent (one that does not support "vfs.fs.discovery"), but we still need to discover file systems. Here is a simple Perl script for Linux that discovers mounted file systems and outputs JSON, which includes both file system name and type. One way to use it would be as a UserParameter with key "vfs.fs.discovery_perl":

#!/usr/bin/perl
       
       $first = 1;
       
       print "[\n";
       
       for (`cat /proc/mounts`)
       {
           ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
       
           print "\t,\n" if not $first;
           $first = 0;
       
           print "\t{\n";
           print "\t\t\"{#FSNAME}\":\"$fsname\",\n";
           print "\t\t\"{#FSTYPE}\":\"$fstype\"\n";
           print "\t}\n";
       }
       
       print "]\n";

An example of its output (reformatted for clarity) is shown below. JSON for custom discovery checks has to follow the same format.

[
           { "{#FSNAME}":"/",                           "{#FSTYPE}":"rootfs"   },
           { "{#FSNAME}":"/sys",                        "{#FSTYPE}":"sysfs"    },
           { "{#FSNAME}":"/proc",                       "{#FSTYPE}":"proc"     },
           { "{#FSNAME}":"/dev",                        "{#FSTYPE}":"devtmpfs" },
           { "{#FSNAME}":"/dev/pts",                    "{#FSTYPE}":"devpts"   },
           { "{#FSNAME}":"/lib/init/rw",                "{#FSTYPE}":"tmpfs"    },
           { "{#FSNAME}":"/dev/shm",                    "{#FSTYPE}":"tmpfs"    },
           { "{#FSNAME}":"/home",                       "{#FSTYPE}":"ext3"     },
           { "{#FSNAME}":"/tmp",                        "{#FSTYPE}":"ext3"     },
           { "{#FSNAME}":"/usr",                        "{#FSTYPE}":"ext3"     },
           { "{#FSNAME}":"/var",                        "{#FSTYPE}":"ext3"     },
           { "{#FSNAME}":"/sys/fs/fuse/connections",    "{#FSTYPE}":"fusectl"  }
       ]

In previous example it is required that the keys match the LLD macro names used in prototypes, the alternative is to extract LLD macro values using JSONPath {#FSNAME} ¡ú $.fsname and {#FSTYPE} ¡ú $.fstype, thus making such script possible:

#!/usr/bin/perl
        
       $first = 1;
        
       print "[\n";
        
       for (`cat /proc/mounts`)
       {
           ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
        
           print "\t,\n" if not $first;
           $first = 0;
        
           print "\t{\n";
           print "\t\t\"fsname\":\"$fsname\",\n";
           print "\t\t\"fstype\":\"$fstype\"\n";
           print "\t}\n";
       }
        
       print "]\n";

An example of its output (reformatted for clarity) is shown below. JSON for custom discovery checks has to follow the same format.

[
           { "fsname":"/",                           "fstype":"rootfs"   },
           { "fsname":"/sys",                        "fstype":"sysfs"    },
           { "fsname":"/proc",                       "fstype":"proc"     },
           { "fsname":"/dev",                        "fstype":"devtmpfs" },
           { "fsname":"/dev/pts",                    "fstype":"devpts"   },
           { "fsname":"/lib/init/rw",                "fstype":"tmpfs"    },
           { "fsname":"/dev/shm",                    "fstype":"tmpfs"    },
           { "fsname":"/home",                       "fstype":"ext3"     },
           { "fsname":"/tmp",                        "fstype":"ext3"     },
           { "fsname":"/usr",                        "fstype":"ext3"     },
           { "fsname":"/var",                        "fstype":"ext3"     },
           { "fsname":"/sys/fs/fuse/connections",    "fstype":"fusectl"  }
       ]

Then, in the discovery rule's "Filter" field, we could specify "{#FSTYPE}" as a macro and "rootfs|ext3" as a regular expression.

Note that, if using a user parameter, the return value is limited to 512 KB. For more details, see data limits for LLD return values.

Using LLD macros in user macro contexts

LLD macros may be used inside user macro context, for example, in trigger prototypes.