Ad Widget

Collapse

SNMP traps are not supported by proxies in proxy group

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • hunter86_bg
    Junior Member
    • Jan 2026
    • 3

    #1

    SNMP traps are not supported by proxies in proxy group

    Hello community,

    I’m trying to monitor some legacy devices that support SNMP traps only (no agent, and polling is not available/viable). I’m on Zabbix 7.0 and looking at proxy groups for HA/load balancing.

    In the official docs for proxy groups / proxy HA, under Important Notes, it says:
    “SNMP traps are not supported by proxies in proxy group.”
    I also saw this Zabbix blog post describing a workaround where traps are copied/synchronized between proxies in a proxy group.
    I’m struggling to understand what “not supported” means in practice and what the recommended architecture is.

    Questions:
    1. Does this limitation mean:
      • A) traps cannot be used at all if the host is monitored via a proxy group, or
      • B) traps can be received, but failover/load balancing won’t work correctly (e.g., traps may land on the “wrong” proxy after host redistribution)?
    2. If the blog’s “copy traps between proxies” approach is used (like using NFS mounted on all proxies in the group):
      • Is this considered a supported configuration or just a community workaround?
      • How do you avoid issues like duplicate processing (same trap seen by multiple proxies) or unmatched traps?
    3. What is the officially recommended way to achieve redundancy for trap-only devices with proxy groups?
      • Should we avoid proxy groups and instead use something like a VIP/keepalived for UDP/162 + a shared trap file (or similar)?
      • Or is the recommendation to receive traps on the server side only (we host ours in K8S)?

    Any guidance from people running this in production would be appreciated.

    Thanks!
  • cyber
    Senior Member
    Zabbix Certified SpecialistZabbix Certified Professional
    • Dec 2006
    • 4832

    #2
    If you are monitoring pure SNMP nodes, just forget all the proxy group stuff. Your device is sending that trap to one (most probably) destination, it has no idea, if the end point has been reorganized and it should sent it to some other place... So yes... it may land on wrong proxy. As there are other processes involved like snmptrapd etc... then all this proxy redirecting etc does not work either, as long as I understand.
    I have not read blog post you mention (and you dd not link it also). So I dont know the deatails there.
    Do not sed anything to server, just have a dedicated proxy(ies) for those devices.

    Comment

    • hunter86_bg
      Junior Member
      • Jan 2026
      • 3

      #3
      Hi cyber,
      Based on what you said, I see these options:
      1. Setup 2 or more proxies with High Availability (for example corocync + pacemaker) controlling the virtual IP, the database and the proxy process
      2. Setup something similar to this blog post

      I want to avoid the first option as it's far too complex for a few SNMP legacy devices.
      Option 2 sounds plausible but I need to test it.

      I'm not sure that we can use dedicated proxies and still have High Availability , as the device must be set to be monitored by a Proxy Group or a Proxy itself. If we put a LoadBalancer, it can forward the request to a proxy that doesn't match the proxy configuration for the host in the Zabbix server.

      Comment

      • cyber
        Senior Member
        Zabbix Certified SpecialistZabbix Certified Professional
        • Dec 2006
        • 4832

        #4
        I have proxy clusters with corosync/pacemaker... not too complicated to set up. VIP, proxy process and snmptrapd all move together, if needed... I use sqlite3 for proxies, so there is no need to move that around..:P Network devices still have just one place where they send it. Once bound to a proxy it is rarely changed. One reason I did not bother with native groups...

        that blog post describes a trap copier.. keepalived holds a VIP on one host and background process copies incoming traps between hosts (logifles). So whichever proxy is monitoring that node, it will receive that trap, even if trap VIP is pointing to another node at the moment... keepalived switches over pretty fast, what they say there about snmptrapd being down... quite small chance... you shoudl bea ble to starrt it an bind it that VIP process even if it is not currently in that host... so downtime is minimal, just nothing is coming in via "normal" way.. but with more proxies you need to copy from all to all..

        If you put a loadbalancer there (as VIP) then you need make sure that all those hosts behind it copy incoming traps to other hosts, as that blogpost describes... trap comes in through LB, which points to proxy X at the moment, snmptrapd receives it, your background process copies it to proxies Y and Z. Your host is set to be monitored by Y, for example. trap is received... X and Z ignore it as they dont know anything about that host... with LB you need copying from all nodes to all nodes... you never know which one is chosen by LB... in that sense keepalived is better, it keeps that VIP pretty much in one place...

        Comment

        • hunter86_bg
          Junior Member
          • Jan 2026
          • 3

          #5
          I do support you for pacemaker/corosync but most of the colleagues doesn't know it and I want to simplify it for them.

          I was thinking to test writing the trap file on NFS which should avoid the whole copying of the traps back and forth while ensuring the correct proxy got the trap for processing.

          Comment

          Working...