Configure um sensor de telemetria proxy NETCONF em Junos
Usando o streaming de telemetria Junos, você pode transformar todas as informações de estado disponíveis em um sensor de telemetria por meio da funcionalidade XML Proxy. O protocolo de gerenciamento NETCONF XML e a API Junos XML documentam totalmente todas as opções para cada solicitação operacional do Junos OS suportada. Depois de configurar sensores proxy XML, você pode acessar dados pelo NETCONF para "obter" chamadas de procedimentos remotos (RPCs).
Esta tarefa mostra como transmitir a saída de um comando de modo operacional Junos OS.
Recomendamos não usar arquivos YANG que mapeiem um comando operacional Junos OS com saída extensa ou verbosa ou que seja lenta na produção de saída. Comandos com um atraso perceptível devem ser evitados em arquivos YANG. Incluir tais comandos pode afetar outros sensores xmlproxyd, bem como o desempenho do xmlproxyd.
A saída de alguns comandos de modo operacional é dinâmica e o nível de sua verbosidade depende de fatores como a configuração e o hardware. Exemplos desses comandos incluem qualquer variação deshow interfaces, show route, show arp, , show bfdshow bgpe show ddos-protection.
Para verificar o nível de verbosidade de um comando, emitiu o command-namedisplay xml | | count comando. Se a contagem de linha exceder um valor de 4000 linhas, o comando não é recomendado para streaming de proxy XML. Esse valor é mais uma aproximação baseada no forro de base interno. Pode ser menos dependendo de vários fatores, como o tipo de dispositivo, o poder de processamento do dispositivo e a carga de CPU existente. Consequentemente, esse recurso precisa ser usado de maneira cuidadosa com base no desempenho do dispositivo.
Você pode emitir o comando command-name| display xml antes de usar um arquivo YANG que mapeia um junos OS ou o comando de modo operacional Junos OS Evolved para verificar se o comando produz saída XML válida e não contém tags, dados ou formatação inválidos.
Usar um arquivo YANG que mapeia para um comando verboso resulta em um ou mais dos seguintes:
-
A utilização da CPU do processo xmlproxyd permanece alta. Se o xmlproxyd tiver o rastreamento ativado, a utilização da CPU será ainda maior.
-
Um aumento na utilização da memória do processo xmlproxyd.
-
O estado do processo xmlproxyd pode mostrar
sbwait, indicando que a saída de comando é verbosa e que o xmlproxyd está gastando um tempo significativo lendo a saída da chamada de procedimento remoto (RPC) do comando. -
Os dados do sensor xmlproxyd não completam o envoltório.
-
O xmlproxyd transmite dados parciais ou sem dados para os sensores.
-
O xmlproxyd perde ciclos de intervalo de relatórios. Os intervalos começam a se sobrepor por causa da saída verbosa de um comando, resultando em dados de streaming de sensores do xmlproxyd lentos ou atrasados.
-
O processo ou a aplicação que atende ao RPC do comando verbose pode mostrar altos números de CPU ou atrasos na execução de tarefas principais. Esse comportamento é causado quando o processo ou a aplicação está ocupado atendendo ao RPC que tem saída verbosa.
Esta tarefa requer o seguinte:
-
Uma Série MX, série vMX ou roteador da Série PTX operando o Junos OS Release 17.3R2 ou posterior.
-
Instalação do pacote de agente de rede necessário ( agente de rede-x86-32-17.4R1.16-C1.tgz ou posterior).
-
Um receptor de dados de telemetria, como o OpenNTI, para verificar a operação adequada do seu sensor de telemetria.
Nesta tarefa, você transmitirá o conteúdo do comando show system usersJunos OS.
mostrar usuários do sistema (Série vMX)
user@switch> show system users USER TTY FROM LOGIN@ IDLE WHAT user1 pts/0 172.31.12.36 12:40PM 39 -cli (cli) user2 pts/1 172,16.03.25 3:01AM - -cli (cli)
Além da lista esperada de usuários logados atualmente, a show system users saída também fornece a carga média do sistema como 1, 5 e 15 minutos. Você pode encontrar as médias de carga usando o show system users | display xml comando para visualizar a marcação XML para os campos de saída. Veja <load-average-1>, <load-average-5>e <load-average-15> na saída de marcação XML abaixo.
user@switch> show system users | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
<system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos">
<uptime-information>
<date-time junos:seconds="1520170982">1:43PM</date-time>
<up-time junos:seconds="86460">1 day, 40 mins</up-time>
<active-user-count junos:format="2 users">2</active-user-count>
<load-average-1>0.70</load-average-1>
<load-average-5>0.58</load-average-5>
<load-average-15>0.55</load-average-15>
<user-table>
<user-entry>
<user>root</user>
<tty>pts/0</tty>
<from>172.21.0.1</from>
<login-time junos:seconds="1520167202">12:40PM</login-time>
<idle-time junos:seconds="0">-</idle-time>
<command>cli</command>
</user-entry>
<user-entry>
<user>mwiget</user>
<tty>pts/1</tty>
<from>66.129.241.10</from>
<login-time junos:seconds="1520170862">1:41PM</login-time>
<idle-time junos:seconds="60">1</idle-time>
<command>cli</command>
</user-entry>
</user-table>
</uptime-information>
</system-users-information>
<cli>
<banner></banner>
</cli>
</rpc-reply>
A uptime-information tag mostrada na saída anterior é um contêiner que contém folhas, como date-time, up-timee active-user-count. . load-average-1 Abaixo está um arquivo YANG amostral para este contêiner:
container uptime-information {
dr:source "uptime-information"; // Exact name of the XML tag
leaf date-time { // YANG model leaf
type string; // Type of value
dr:source date-time; // Exact name of the XML tag
}
leaf up-time { // YANG model leaf
type string; // Type of value
dr:source up-time; // Exact name of the XML tag
}
leaf active-user-count { // YANG model leaf
type int32; // Type of value
dr:source active-user-count; // Exact name of the XML tag
}
leaf load-average-1 { // YANG model leaf
type string; // Type of value
dr:source load-average-1; // Exact name of the XML tag
}
...
A uptime-information tag também tem outro contêiner nomeado user-table que contém uma lista de entradas de usuários.
Abaixo está um arquivo YANG amostral para este contêiner:
container user-table { // "user-table" container which contains list of user-entry
dr:source "user-table"; // Exact name of the XML tag
list user-entry { // "user-entry" list which contains the users' details in form of leafs
key "user"; // Key for the list "user-entry" which is a leaf in the list "user-entry"
dr:source "user-entry"; // Source of the list "user-entry" which is the exact name of the XML tag
leaf user { // YANG model leaf
dr:source user; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf tty { // YANG model leaf
dr:source tty; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf from { // YANG model leaf
dr:source from; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf login-time { // YANG model leaf
dr:source login-time; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf idle-time { // YANG model leaf
dr:source idle-time; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf command { // YANG model leaf
dr:source command; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
}
}
Crie um arquivo YANG definido pelo usuário
O arquivo YANG define o comando Junos CLI a ser executado, o caminho de recursos em que os sensores são colocados e os principais pares de valor retirados das tags XML correspondentes.
Os arquivos YANG personalizados para o Junos OS estão em conformidade com a sintaxe da linguagem YANG definida no RFC 6020 YANG 1.0 YANG - Uma linguagem de modelagem de dados para o protocolo de configuração de rede (NETCONF) e RFC 7950 A linguagem de modelagem de dados YANG 1.1. Determinadas diretivas precisam estar presentes no arquivo que configure o proxy XML.
Para usar o xmlproxyd processo (daemon) para traduzir dados de telemetria, crie um render.yang arquivo. Neste arquivo, o dr:command-app está definido para xmlproxyd.
O nome de arquivo e módulo XML proxy YANG deve começar com xmlproxyd_:
Para o nome de arquivo YANG proxy XML, adicione a extensão
.yang, por exemplo,xmlproxyd_sysusers.yangPara o nome do módulo, use o nome do arquivo sem a extensão
.yang, por exemplo,xmlproxyd_sysusers
Para simplificar a criação de um arquivo YANG, é mais fácil começar modificando um exemplo de trabalho.
Carregue o arquivo Yang no Junos
Após a conclusão do arquivo YANG, faça o upload do arquivo YANG e verifique se o módulo foi criado.
Coletar dados do sensor
Use seu coletor favorito para retirar os dados do sensor de telemetria recém-criado do dispositivo.
Considere as restrições de recursos antes de iniciar sensores:
- Evite especificar o mesmo intervalo de relatórios para vários sensores proxy XML.
- Para os roteadores PTX10008 que operam o Junos OS Evolved, não conecte mais de 10 coletores por roteador para RPCs de telemetria.
- Como o xmlproxyd executa O XML e o processamento de texto, um dispositivo deve conter apenas sensores proxy XML que são executados dentro da faixa de utilização da CPU.
As instruções a seguir usam o jtimon coletor. Para obter informações sobre a configuração do jtimon, consulte o cliente da Interface de Telemetria Junos.
Se uma assinatura já existir para um sensor e uma assinatura duplicada estiver configurada, a conexão entre o coletor e o dispositivo será encerrada com a mensagem AlreadyExistsde erro.
Instalação de um arquivo YANG definido pelo usuário
Para adicionar, validar, modificar ou excluir um arquivo YANG definido pelo usuário para proxy XML para a interface de telemetria Junos, use o request system yang conjunto de comandos do modo operacional:
Veja também
Solucionar problemas de sensores de telemetria
Problema
Descrição
Use os seguintes métodos para solucionar problemas dos sensores de telemetria definidos pelo usuário:
Execute um tcpdump para a interface de onde vieram as solicitações de gRPC (para essa tarefa, a interface
fxp0foi usada).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Habilite rastreamentos usando o set services analytics traceoptions flag xmlproxy comando. Verifique o
xmlproxydarquivo de registro para confirmar se o RPC do comando CLI foi enviado e se uma resposta foi recebida:
Emite o show log xmlproxyd comando para mostrar o log xmlproxyd. O valor para o campo
xmlproxy_execute_cli_command:indica se o RPC foi enviado ou não. O valor para o campoxmlproxy_build_contextindica o comando.
user@switch>show log xmlproxyd Mar 4 18:52:46 vmxdockerlight_vmx1_1 clear-log[52495]: logfile cleared Mar 4 18:52:51 xmlproxy_telemetry_start_streaming: sensor /junos/system-users-information/ Mar 4 18:52:51 xmlproxy_build_context: command show system users merge-tag: Mar 4 18:52:51 <command format="xml">show system users</command> Mar 4 18:52:51 xmlproxy_execute_cli_command: Sent RPC.. Mar 4 18:52:51 <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos" xmlns:junos="http://xml.juniper.net/junos/*/junos"> <uptime-information> <date-time junos:seconds="1520189571"> 6:52PM </date-time> <up-time junos:seconds="107400"> 1 day, 5:50 </up-time> <active-user-count junos:format="1 users"> 1 </active-user-count> <load-average-1> 0.94 </load-average-1> <load-average-5> 0.73 </load-average-5> <load-average-15> 0.65