Esta é a parte final do artigo,
aqui está o começo .
A última vez que escrevi sobre como implementei o monitoramento de dispositivos, agora vamos nos concentrar no gerenciamento. Em discussões com "técnicos" por parte do Cliente, geralmente encontro uma percepção limitada dos recursos de dispositivos tão pequenos (com pouco desempenho e recursos de memória), muitas pessoas pensam que "o máximo que precisamos é enviar uma reinicialização, para algo mais sério - enviaremos uma equipe" .
Mas a prática mostra que isso não é inteiramente verdade.
Aqui está uma pequena lista de tarefas comuns comuns:
- Diagnóstico e solução de problemas de rede. Por trás da porta Ethernet do seu roteador, outra peça de hardware geralmente possui seu próprio endereço IP interno. Às vezes, pode (precisa) "ping". Ou gerenciamento de túnel - se um roteador que não liga repentinamente em um roteador executando um modem 3G, mas vemos o próprio roteador.
- Serviço do sistema. Atualização de firmware, atualização de script de serviço.
- Ato de equilíbrio. Isso poderia ser chamado de "perversões", mas o conceito de "balanceador", como cito, "a capacidade de um artista circense de manter o equilíbrio em uma posição instável do corpo" é mais adequado. Situações semelhantes surgem devido ao orçamento limitado do cliente. Abaixo estão alguns exemplos, mas porque eles não têm relação direta com o assunto da narrativa, coloque-os em notas
Monitoramento WifiUm tópico da moda nos últimos cinco anos é principalmente entre as redes de varejo federais. Você percorre lentamente os pregões e seu telefone celular com o Wi-Fi ligado na tentativa de "aderir" a algum encadeamento da rede envia regularmente pacotes de solicitação de sonda que podem ser analisados para calcular com que frequência você chega a esta loja. percorrer as trajetórias e assim por diante. Em seguida, os dados são coletados, analisados, mapas de calor são desenhados e os gerentes de tais imagens “extraem” dinheiro da gerência ou dos investidores. Enquanto isso .... "não há dinheiro, mas você aguenta ...", e o resultado (real) já deve ser mostrado, a boa e velha música está incluída "Sim, sim, é claro que vamos colocar tsiska e o que você quiser, mas agora precisamos mostre ao cliente o resultado! A propósito, eles esqueceram de dizer que o Cliente permitia que nosso equipamento fosse conectado ao seu hotspot via Wi-Fi, mas, em geral, é como se fossemos clientes convidados. ” E agora você precisa fazer roteadores-balanceadores - várias subinterfaces de WiFi aumentam, uma das quais se apega a um ponto de acesso e a segunda monitora o ambiente, descarrega freneticamente o resultado do tcpdump em si mesmo, então o conteúdo do arquivo é compactado no arquivo morto e correndo o risco de "comer demais" tentando cuspir o conteúdo no servidor ftp. Não é de surpreender que o balanceador de roteador frequentemente "se quebre" e, de alguma forma, precise ser ressuscitado remotamente.
RaioAqui é mais fácil descrever a situação com algo como esta declaração do cliente: "Queremos uma rede descentralizada de pontos ativos que funcionem em equipamentos cujo modelo não é conhecido antecipadamente, por meio de canais, mas ainda não sabemos quais. Ah, eles esqueceram de dizer que não apenas queremos exibir anúncios para os clientes, mas também analisar tudo no site do ponto de acesso. Não, ainda não sabemos o porquê, mas surgiremos, não duvide, fomos capazes de ter essa ideia "
E não devemos esquecer que, devido à massa de circunstâncias incertas com antecedência, o controle deve ser realizado em condições fora do padrão, quando não podemos conectar-se ao roteador diretamente via ip: a porta e somos forçados a esperar apenas pela atividade. Se o ignorarmos, o diálogo entre o servidor e o roteador poderá ser representado assim:
- Roteador : oi. Eu sou um roteador, existem tarefas para mim?
- Servidor : como um roteador, registrei você que está vivo. Aqui está a tarefa: mostre-me o resultado do comando ifconfig?
- Roteador : oi. Eu sou um roteador, a última vez que você me pediu para mostrar o resultado do ifconfig, aqui está ele. Há alguma tarefa para mim?
- Servidor : como um roteador, registrei você que está vivo. Não há tarefas para você.
A pergunta mais interessante: como um roteador remoto pode enviar uma certa quantidade de informações? Na última parte, descrevi que no roteador, devido aos recursos limitados, existe apenas um wget "despojado" que funciona apenas por meio de GET e nada mais, não há cliente ftp ou curl. Mais precisamente, precisamos de uma maneira universal, independentemente das características da montagem da imagem. Eu decidi usar o wget. Mais precisamente, como eu "parei" - eu simplesmente não tinha escolha :)
Reserva imediataMinha solução de gerenciamento está funcionando, mas é muito limitada e tenho certeza de que está torta, mesmo que atenda à maioria dos meus clientes. Como seria possível fazê-lo com sabedoria - escrever um pequeno utilitário que envie dados binários pela 80ª porta. Inclua-o (utilitário) no firmware do roteador e use o bash para acessá-lo. Mas a realidade é que: a) você precisa rapidamente b) talvez precise fazer tudo no “zoológico de roteadores” existente c) “não faça mal!” - se o roteador funcionar e executar outras tarefas, tente fazer alterações que afetarão a funcionalidade existente.
Vamos para a implementação. Digamos que seu cliente queira que o zabbix reinicie o roteador de maneira fácil e natural, com um "clique do mouse". Hoje começaremos a descrição da implementação com o zabbiksa.
No menu "Administração" -> "Scripts", adicione um novo script. Nós o chamamos de "Reinicialização", como um comando que escrevemos "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Além disso: Menu "Monitoramento" -> "Dados recentes" -> "Clique com o botão direito do mouse no nó da rede". É assim que o menu fica depois de adicionar um script.
Assim, colocamos o script reboot.php no diretório / usr / share / zabbix (você pode ter outro, eu uso o diretório raiz do zabbixa).
Isenção de responsabilidade por segurançaPara maior clareza das explicações no script, eu uso apenas o ID do roteador, mas não a senha. Na versão de trabalho, isso não é recomendado! Por que fiz isso: porque a grande questão é onde armazenar senhas para roteadores? No próprio zabbixe no "inventário"? Prática contraditória. Como opção: restringir o acesso externo ao próprio arquivo reboot.php
Arquivo Reboot.php
<?php
Na verdade tudo. A pergunta "como obter o resultado da execução de um comando pelo lado do dispositivo" permanece em aberto. Considere o problema usando o comando ifconfig como exemplo. Este comando pode ser enviado ao dispositivo:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt
onde:
message = `ifconfig` - atribuímos o resultado da saída do comando ifconfig à variável $ message
wget " xn - 80abgfbdwanb2akugdrd3a2e5gsbj.xn - p1ai / a.php - nosso script a.php que registra roteadores e recebe mensagens deles
u = usuário & p = senha! & m = $ message - credenciais e o valor da variável de solicitação m - atribui o conteúdo da variável $ message
-O /tmp/out.txt - nesse caso, não precisamos de saída para o arquivo /tmp/out.txt, mas se você não especificar esse parâmetro, o wget não funcionará
Por que isso funciona tortoPorque é uma falha de segurança em potencial. o erro mais inofensivo que pode acontecer é se, por exemplo, houver um símbolo "&" na saída do seu comando. Portanto, é necessário filtrar tudo o que é enviado dos roteadores e tudo o que chega ao servidor. Sim, tenho vergonha, sério. Em minha defesa, só posso escrever - que todo o artigo é dedicado a como gerenciar roteadores com firmware indefinido antecipadamente, com canais de comunicação indefinidamente definidos.
Bem, toquei no futuro: ainda não descobri como refletir os resultados (por exemplo, o resultado do comando) que chegam ao servidor usando as ferramentas padrão do zabbix.
Lembro que
todas as fontes podem ser obtidas no repositório Git