Zabbix Documentation 4.4

3.04.04.2 (current)In development:4.4 (devel)Unsupported:1.82.02.22.43.23.4

User Tools

Site Tools


pt:manual:discovery:low_level_discovery

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
pt:manual:discovery:low_level_discovery [2015/12/30 13:01]
spaww created
pt:manual:discovery:low_level_discovery [2019/04/02 06:04] (current)
Line 10: Line 10:
   * descoberta de interfaces de rede;   * descoberta de interfaces de rede;
   * descoberta de CPUs seus núcleos;   * descoberta de CPUs seus núcleos;
-  * descoberta de árvores de OID SNMP;+  * descoberta de árvores de OID SNMP;acesse
   * descoberta usando consultas SQL/ODBC;   * descoberta usando consultas SQL/ODBC;
   * descoberta de serviços Windows.   * descoberta de serviços Windows.
  
-O usuário pode extender ​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.+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: A arquitetura geral do processo de descoberto pode ser definido assim:
Line 20: Line 20:
   * 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:   * 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 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 ​dinâmicamente ​usando as informações descobertas.+    * 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 Zabbix solicita ao Zabbix 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 importanes ​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"​.+Um item que descobre os elementos necessários é como qualquer outro item: O Zabbix solicita ao Zabbix 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"​.
  
 <​note>​Os itens de LLD "​vfs.fs.discovery",​ "​net.if.discovery"​ e a descoberta de OIDs SNMP são suportados desde o Zabbix 2.0.\\ O item "​system.cpu.discovery"​ desde o Zabbix 2.4.\\ A descoberta através de "​querys SQL OBDC" desde o Zabbix 3.0.</​note>​ <​note>​Os itens de LLD "​vfs.fs.discovery",​ "​net.if.discovery"​ e a descoberta de OIDs SNMP são suportados desde o Zabbix 2.0.\\ O item "​system.cpu.discovery"​ desde o Zabbix 2.4.\\ A descoberta através de "​querys SQL OBDC" desde o Zabbix 3.0.</​note>​
Line 38: Line 38:
 Para descobrir um sistema de arquivos: Para descobrir um sistema de arquivos:
  
-  * Acesseo: ​//​Configuração//​ -> //​Templates// ​+  * Acesse ​//​Configuração//​ -> //​Templates// ​
   * Clique no link //​Descoberta//​ da linha apropriada   * Clique no link //​Descoberta//​ da linha apropriada
  
Line 54: Line 54:
 |//​Tipo// ​ |Tipo da verificação a ser executada; pode ser //Agente Zabbix (passivo)// ou //Agente Zabbix (ativo)// neste caso.  | |//​Tipo// ​ |Tipo da verificação a ser executada; pode ser //Agente Zabbix (passivo)// ou //Agente Zabbix (ativo)// neste caso.  |
 |//​Chave// ​ |Um item com a chave "​vfs.fs.discovery"​ foi desenvolvido no Zabbix Agent para permitir a descoberta de sistemas de arquivos em várias plataformas (consulte [[pt:​manual:​appendix:​items:​supported_by_platform|a lista de itens suportados]]),​ e retorna um JSON com a lista de sistemas de arquivos e seus tipos. ​ | |//​Chave// ​ |Um item com a chave "​vfs.fs.discovery"​ foi desenvolvido no Zabbix Agent para permitir a descoberta de sistemas de arquivos em várias plataformas (consulte [[pt:​manual:​appendix:​items:​supported_by_platform|a lista de itens suportados]]),​ e retorna um JSON com a lista de sistemas de arquivos e seus tipos. ​ |
-|//​Intervalo de atualização (em seg)// ​ |Este campo define de quanto em quanto tempo o Zabbix irá executar a descoberta. No ínicio, quando você está configurando a regra de descoberta, pode ser interessante definir um intervalo curto, mas uma vez que você tenha confiança que sua regra está buscando o que você precisa, modifique o tempo para, no mínimo, 30 minutos. Esta recomendaçao ​se deve ao fato que os sistemas de arquivo não mudam tanto assim.\\ //Nota//: Se você definir o intervalo de atualização com o valor '​0',​ a coleta do item não será agendada, entretanto, se você também definir um intervalo flexível, o item será coletado somente nos momentos definidos no intervalo flexível. ​ | +|//​Intervalo de atualização (em seg)// ​ |Este campo define de quanto em quanto tempo o Zabbix irá executar a descoberta. No início, quando você está configurando a regra de descoberta, pode ser interessante definir um intervalo curto, mas uma vez que você tenha confiança que sua regra está buscando o que você precisa, modifique o tempo para, no mínimo, 30 minutos. Esta recomendação ​se deve ao fato que os sistemas de arquivo não mudam tanto assim.\\ //Nota//: Se você definir o intervalo de atualização com o valor '​0',​ a coleta do item não será agendada, entretanto, se você também definir um intervalo flexível, o item será coletado somente nos momentos definidos no intervalo flexível. ​ | 
-|//​Intervalo customizado// ​ |Você pode criar regras customizadas de coleta para o item:\\ **Flexível** - cria uma excessão ​ao //Intervalo de atualização//​ (intervalo com frequência diferenciada)\\ **Agendamento** - cria um agendamento de coleta.\\ Para maiores detalhes consulte o manual de [[pt:​manual:​config:​items:​item:​custom_intervals|Intervalos customizados]]. Agendamento é suportado desde o Zabix 3.0.0. ​ |+|//​Intervalo customizado// ​ |Você pode criar regras customizadas de coleta para o item:\\ **Flexível** - cria uma exceção ​ao //Intervalo de atualização//​ (intervalo com frequência diferenciada)\\ **Agendamento** - cria um agendamento de coleta.\\ Para maiores detalhes consulte o manual de [[pt:​manual:​config:​items:​item:​custom_intervals|Intervalos customizados]]. Agendamento é suportado desde o Zabix 3.0.0. ​ |
 |//Manter dados de recursos perdidos por (em dias)// ​ |Este campo define por quantos dias serão mantidos os recursos que foram descobertos em algum momento e deixaram de ser percebidos (máximo 3650 dias). \\ //Nota:// Se for definido como "​0"​ as entidades criadas com base nestes recursos serão imediatamente excluídas. O uso do valor "​0"​ não é recomendado pois erros de edição em filtros poderão fazer com que todas as entidades criadas dinamicamente e os dados históricos coletados sejam apagados. ​  | |//Manter dados de recursos perdidos por (em dias)// ​ |Este campo define por quantos dias serão mantidos os recursos que foram descobertos em algum momento e deixaram de ser percebidos (máximo 3650 dias). \\ //Nota:// Se for definido como "​0"​ as entidades criadas com base nestes recursos serão imediatamente excluídas. O uso do valor "​0"​ não é recomendado pois erros de edição em filtros poderão fazer com que todas as entidades criadas dinamicamente e os dados históricos coletados sejam apagados. ​  |
 |//​Descrição// ​ |Descrição da regra. ​ | |//​Descrição// ​ |Descrição da regra. ​ |
Line 78: Line 78:
 <​note>​Se um protótipo de item for criado com o status //​Inativo//,​ os itens continuarão a ser criados a partir dele mas estarão com o status //Inativo// também.</​note>​ <​note>​Se um protótipo de item for criado com o status //​Inativo//,​ os itens continuarão a ser criados a partir dele mas estarão com o status //Inativo// também.</​note>​
  
-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 dinâmicamente ​as aplicações e as associe aos itens. Consulte mais nas   ​[[pt:​manual:​discovery:​low_level_discovery:​notes|notas sobre descoberta de aplicações]].+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   ​[[pt:​manual:​discovery:​low_level_discovery:​notes|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: Nós podemos criar vários protótipos de item para cada métrica de sistema de arquivo que nos interesse:
Line 110: Line 110:
 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). 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. ​Entreganto, 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)//.+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. 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.
Line 152: Line 152:
 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}//​. 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 endender ​o que isso significa, vamos executar alguns ''​snmpwalks''​ em nosso switch: ​+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   $ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB::​ifDescr
   IF-MIB::​ifDescr.1 = STRING: WAN   IF-MIB::​ifDescr.1 = STRING: WAN
Line 240: Line 240:
 {{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png|}}
  
-Protótipos de gráfic:+Protótipos de gráfico:
  
 {{manual:​discovery:​low_level_discovery:​graph_prototype_snmp.png|}} {{manual:​discovery:​low_level_discovery:​graph_prototype_snmp.png|}}
Line 284: Line 284:
 Internamente a chave "​db.odbc.discovery[]"​ irá receber este valor e transformar em um código JSON: Internamente a chave "​db.odbc.discovery[]"​ irá receber este valor e transformar em um código JSON:
  
-<​code ​js>+<​code ​java>
 { {
     "​data":​ [     "​data":​ [
Line 306: Line 306:
  
 <​note>​ <​note>​
-Se não estiver muito claro como um nome de coluna foi transformado em um nome de macro, sugerimos utilizar ​apelidso ​de colunas no exemplo acima (ex. "​COUNT(h2.host) AS count"​).+Se não estiver muito claro como um nome de coluna foi transformado em um nome de macro, sugerimos utilizar ​apelidos ​de colunas no exemplo acima (ex. "​COUNT(h2.host) AS count"​).
  
 Caso o nome de alguma coluna não possa ser transformado em um nome válido de macro, a regra irá para o estado 'Não suportado'​ com mensagem de erro detalhando o problema com a coluna de número X. Se informações adicionais forem necessárias,​ poderão ser obtidas ao ativar o modo de debug 4 (**DebugLevel=4**) e consultar o log do Zabbix Server: Caso o nome de alguma coluna não possa ser transformado em um nome válido de macro, a regra irá para o estado 'Não suportado'​ com mensagem de erro detalhando o problema com a coluna de número X. Se informações adicionais forem necessárias,​ poderão ser obtidas ao ativar o modo de debug 4 (**DebugLevel=4**) e consultar o log do Zabbix Server:
Line 353: Line 353:
 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. 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 +Para fazer isso precisamos de um item que retorne um JSON, definindo objetos eopcionalmente,​ propriedades delesA 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..
-To do soa custom item should be created that returns JSONspecifying found objects and optionally - some properties of themThe amount of macros ​per entity is not limited - while the built-in discovery rules return either one ou 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 Zabbix 1.8 agent (one that does not support ​"​vfs.fs.discovery"​)but we still need to discover file systems. Here is simple Perl script ​for Linux that discovers mounted file systems and outputs ​JSON, which includes both file system name and typeOne way to use it would be as a UserParameter ​with key "​vfs.fs.discovery_perl":​+O formato ​JSON requerido é ilustrado neste exemplo, suponhamos que você esteja usando um Zabbix ​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 ​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 tiposPoderíamos criar, por exemplo, um **UserParameter** chamado ​"​vfs.fs.discovery_perl":​
  
 <code perl> <code perl>
Line 384: Line 383:
 </​code>​ </​code>​
  
-<note important>​Allowed symbols for LLD macro names are **0-9** , **A-Z** , **_** , **.** \\ \\  ​Lowercase letters are not supported in the names.</​note>​+<note important>​Os caracteres permitidos em um nome de macro LLD são **0-9** , **A-Z** , **_** , **.** \\ \\  ​Não são suportadas letras minúsculas em seus nomes.</​note>​
  
-An example of its output ​(reformatted for clarityis shown below. JSON for custom discovery checks has to follow the same format.+Um exemplo de saída deste script ​(reformatado para melhor legibilidadepoderia ser algo como isso:
  
   {   {
Line 408: Line 407:
   }   }
  
-Thenin the discovery rule's "​Filter"​ fieldwe could specify ​"​{#​FSTYPE}" ​as a macro and "​rootfs|ext3" ​as a regular expression.+Assimno //Filtro// da regra de descoberta você poderá, por exemplovalidar o conteúdo da macro "​{#​FSTYPE}" ​com uma expressão regular ( "​rootfs|ext3"​).
  
-<​note>​You don't have to use macro names FSNAME/​FSTYPE ​with custom LLD rulesyou are free to use whatever names you like.</​note>​+<​note>​Você não precisa nomear as macros como FSNAME/​FSTYPE ​em regras customizadas, use o nome que quiser contando que se adeque aos caracteres permitidos.</​note>​