7

With SNMP pollers, is it better to locate them closer to the DB to ensure the poller to DB traffic has a better chance of making it. Or put the poller closer to monitored device, so that traffic is more accurate in terms of latency and making it to the device?

e.g. I have 3 regions, and 3 pollers, and 1 DB. Do I put all four devices in one location, or distribute the pollers?

I have some opinions but wanted to get other side of the story.

Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
Ken
  • 149
  • 2
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer. – Ron Maupin Jan 04 '21 at 00:06

4 Answers4

5

This seems like useless micro-optimization in any case, which you shouldn't worry about until actual practical issue arises, which is likely never.

However purely academically you should put snmp poller near device it is polling as it is request/response protocol which is RTT bound. The poller can aggregate the polled data and use TCP with windows to send large amount of data fast to DB.

ytti
  • 9,776
  • 42
  • 53
3

FWIW this is a great question and I can't disagree with @ytti in that this has a lot of potential to go down a theory/academia rabbithole.

From a practical perspective, placing the pollers close to the objects being polled is what you want to do. I'm not a distributed systems expert/SDE, but I'd imagine that any NMS that's designed to be distributed should already have functions in it to separate out db insertion timestamps from actual polled SNMP data and its own timestamps. It's still not an easy problem to solve, but as ytti has already said (and I agree with), doing the db inserts shouldn't take priority over data gathered from polling. Those have the luxury of being wrapped up in TCP for better data integrity protection. With actual SNMP polls and traps, you have "best effort" times two to contend with - number one being UDP obviously, and number 2 being process management/"data integrity" (ie counters being accurate etc) on the box that you're polling. Sometimes a box just starts to choke and returning numbers via SNMP takes a backseat to other things.

John Jensen
  • 8,997
  • 4
  • 29
  • 47
  • snmp is over udp and the DB connection would most likely be TCP. So the polling closer to the source is better. Besides, what if the poller is placed in another site from the devices being polled and connectivity is lost. Collect locally (in realtime), roll up data remotely (in near realtime). – generalnetworkerror May 24 '13 at 00:02
1

The number of pollers used should be based on the number of nodes that is being polled and the frequency of polls. In addition, some vendors do not support the poller being distant from the DB. Solarwinds has this restriction.

henklu
  • 799
  • 1
  • 8
  • 18
1

Being closer to the polled devices also means you can have a higher polling frequency due to lower latency. I found that when I was trying to poll a device over our transatlantic circuits at say 5 or 10 second intervals it was taking too long to walk the tables.

Mark-K
  • 11
  • 3
  • Technically you can do polling asynchronously. You could have two process design where one process spews out UDP wire-rate another process stores replies. Then you have third process doing offline analysis if you're getting data at conforming intervals stores, if not, raise alarm and have ops investigate reason. – ytti May 24 '13 at 07:20