Devo localizar o poller SNMP perto de DB ou de dispositivos monitorados?


7

Com os pesquisadores de SNMP, é melhor localizá-los mais perto do banco de dados para garantir que o pesquisador no tráfego de banco de dados tenha uma chance maior de fazê-lo. Ou aproxime o pesquisador do dispositivo monitorado, para que o tráfego seja mais preciso em termos de latência e para o dispositivo?

por exemplo, tenho 3 regiões, 3 pesquisadores e 1 banco de dados. Coloco todos os quatro dispositivos em um local ou distribuo os pesquisadores?

Tenho algumas opiniões, mas queria entender o outro lado da história.


Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:


5

De qualquer forma, isso parece uma micro-otimização inútil, com a qual você não deve se preocupar até que surja um problema prático real, o que provavelmente nunca será.

No entanto, puramente academicamente, você deve colocar o snmp poller próximo ao dispositivo que está pesquisando, pois é o protocolo de solicitação / resposta que está vinculado ao RTT. O pesquisador pode agregar os dados pesquisados ​​e usar o TCP com o Windows para enviar grande quantidade de dados rapidamente ao DB.


3

FWIW, essa é uma ótima pergunta e não posso discordar de @ytti, pois isso tem muito potencial para diminuir o rabino de teoria / academia.

De uma perspectiva prática, colocar os pesquisadores perto dos objetos pesquisados ​​é o que você deseja fazer. Não sou especialista em sistemas distribuídos / SDE, mas imagino que qualquer NMS projetado para ser distribuído já deve ter funções nele para separar os carimbos de data / hora de inserção de banco de dados dos dados SNMP reais pesquisados ​​e seus próprios carimbos de data / hora. Ainda não é um problema fácil de resolver, mas como o ytti já disse (e eu concordo), fazer as inserções de banco de dados não deve ter prioridade sobre os dados coletados nas pesquisas. Eles têm o luxo de serem envolvidos no TCP para melhorar a proteção da integridade dos dados. Com pesquisas e traps SNMP reais, você tem o "melhor esforço" duas vezes para enfrentar - o número um é o UDP, obviamente, e o número 2 é o gerenciamento de processos / "integridade dos dados" (ou seja, os contadores são precisos, etc.) na caixa que você está pesquisando. Às vezes, uma caixa começa a engasgar e os números retornados via SNMP ficam no banco de trás de outras coisas.


o snmp está sobre o udp e a conexão com o banco de dados provavelmente seria TCP. Portanto, a pesquisa mais próxima da fonte é melhor. Além disso, e se o pesquisador for colocado em outro site a partir dos dispositivos pesquisados ​​e a conectividade for perdida. Colete localmente (em tempo real), acumule dados remotamente (quase em tempo real).
generalnetworkerror

1

O número de pesquisadores usados ​​deve basear-se no número de nós que estão sendo pesquisados ​​e na frequência das pesquisas. Além disso, alguns fornecedores não suportam que o pesquisador esteja distante do banco de dados. Solarwinds tem essa restrição.


1

Estar mais próximo dos dispositivos pesquisados ​​também significa que você pode ter uma frequência de pesquisa mais alta devido à menor latência. Descobri que quando estava tentando pesquisar um dispositivo sobre nossos circuitos transatlânticos em intervalos de 5 ou 10 segundos, demorava muito tempo para andar nas mesas.


Tecnicamente, você pode fazer pesquisas de forma assíncrona. Você pode ter um design de dois processos em que um processo libere a taxa de transmissão UDP, enquanto outro processo armazena respostas. Em seguida, você tem o terceiro processo de análise offline, se estiver obtendo dados em intervalos de armazenamento adequados; caso contrário, dê um alarme e as operações investigam o motivo.
Ytti 24/05
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.