Configure um sensor de telemetria proxy NETCONF em Junos
Usando o streaming de telemetria Junos, você pode transformar qualquer informação de estado disponível em um sensor de telemetria por meio da funcionalidade Proxy XML. 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 por meio de chamadas de procedimento remoto (RPCs) da NETCONF.
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. A inclusão desses 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 bfde show ddos-protectionshow bgp.
Para verificar o nível de verbosidade de um comando, emita o command-name| display xml | count comando. Se a contagem de linha exceder um valor de 4000 linhas, o comando não será recomendado para streaming proxy XML. Esse valor é mais uma aproximação baseada em base interna. Pode ser menos dependente de vários fatores, como tipo de dispositivo, poder de processamento do dispositivo e a carga de CPU existente. Consequentemente, esse recurso precisa ser usado com base no desempenho do dispositivo.
Você pode emitir o comando command-name| display xml antes de usar um arquivo YANG que mapeia um comando de modo operacional Junos OS ou 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 habilitado, 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 de chamadas de procedimento remoto (RPC) do comando. -
Os dados do sensor xmlproxyd não completam o envoltório.
-
O xmlproxyd transmite dados parciais ou não 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 que são lentos ou atrasados.
-
O processo ou aplicativo que atende ao RPC do comando verbose pode mostrar altos números de CPU ou atrasos na execução das tarefas principais. Esse comportamento é causado quando o processo ou aplicativo está ocupado atendendo ao RPC que tem saída verbosa.
Essa 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 conectados atualmente, a show system users saída também oferece 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 taging 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 de amostra 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 com o nome user-table que contém uma lista de entradas de usuários.
Abaixo está um arquivo YANG de amostra 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 pares de valor chave retirados das tags XML correspondentes.
Os arquivos YANG personalizados para o Junos OS estão em conformidade com a sintaxe de 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 configuram o proxy XML.
Para usar o xmlproxyd processo (daemon) para traduzir dados de telemetria, crie um render.yang arquivo. Neste arquivo, a configuração dr:command-app é xmlproxyd.
O nome de arquivo e módulo XML proxy YANG deve começar com xmlproxyd_:
Para o nome de arquivo YANG de 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 em 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 PTX10008 roteadores que operam o Junos OS Evolved, não conectem mais de 10 coletores por roteador para RPCs de telemetria.
- Como o xmlproxyd realiza O XML e o processamento de texto, um dispositivo deve conter apenas sensores proxy XML que são executados dentro do intervalo de utilização da CPU.
As instruções a seguir usam o jtimon do 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á fechada 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 de sensores de telemetria definidos pelo usuário:
Execute um tcpdump para a interface de que suas solicitações de gRPC vieram (para esta tarefa, a interface
fxp0foi usada).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Habilite traceoptions usando o set services analytics traceoptions flag xmlproxy comando. Verifique o
xmlproxydarquivo de log para obter a confirmação de se o RPC do comando CLI foi enviado e se uma resposta foi recebida:
Emita 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