Ad Widget

Collapse

Legacy SNMP discovery vs walk

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Martynas
    Junior Member
    • Aug 2024
    • 3

    #1

    Legacy SNMP discovery vs walk

    I have been testing Zabbix 7 before upgrading my production machine to it and while playing with new walk SNMP discovery method and my network switches, I thought: is it really more efficient than legacy SNMP method in all scenarios?

    For example image this scenario: I have a switch with 48 ports, and I want to monitor only port with word "IMPORTANT" in the interface description.

    With the old SNMP discovery method, zabbix would run SNMP discovery on all ports, filter the response and create items for ports that have word "IMPORTANT" and only monitor those ports and once in a while would run discovery again through all ports just to check if new items have to be created. This means zabbix would monitor not all ports, and only query all ports once in a while.

    With the new SNMP walk method, zabbix would run SNMP queries for all ports, get response, filter the port description with word "IMPORTANT", create items for these ports, but still would constantly run SNMP queries on all ports, ignoring the fact that I want to monitor only ports with certain description.

    So have I been thinking correct? Maybe I should still stick to legacy SNMP method, because in my enviroment we have network switches with 90+ ports, but we only monitor like 5 ports.
  • cyber
    Senior Member
    Zabbix Certified SpecialistZabbix Certified Professional
    • Dec 2006
    • 4806

    #2
    it is the question of doing one walk (one query) vs doing multiple get-s (multiple queries), towards each of your items... with walk, it is not doing, as you said "constantly run SNMP queries on all ports".. it is doing one walk...
    I think from devices perspective it can be easier to answer once with a bit more data, than, lets say... to 25 queries with less data... if we take for example snmpv3, where that device has to authenticate each of those get-s instead of one walk...

    Comment

    • Martynas
      Junior Member
      • Aug 2024
      • 3

      #3
      Originally posted by cyber
      it is the question of doing one walk (one query) vs doing multiple get-s (multiple queries), towards each of your items... with walk, it is not doing, as you said "constantly run SNMP queries on all ports".. it is doing one walk...
      I think from devices perspective it can be easier to answer once with a bit more data, than, lets say... to 25 queries with less data... if we take for example snmpv3, where that device has to authenticate each of those get-s instead of one walk...
      I completely forgot about SNMP V3, since we still use V2, but still from network load perspective, the legacy method is more efficient since it queries for information about port it need, not all of them.

      So for example if I want to monitor a network switch with new snmp walk method, but only certain ports, it will query the switch for information about all port, when discard the unwanted information and only leave the data I want, so why not use the legacy SNMP method and only query the switch for the ports I want?

      Comment

      • Markku
        Senior Member
        Zabbix Certified SpecialistZabbix Certified ProfessionalZabbix Certified Expert
        • Sep 2018
        • 1781

        #4
        Originally posted by Martynas
        Maybe I should still stick to legacy SNMP method, because in my enviroment we have network switches with 90+ ports, but we only monitor like 5 ports.
        Yes, maybe.

        That said, maybe the walk method also works just fine nowadays?

        Markku

        Comment

        • Martynas
          Junior Member
          • Aug 2024
          • 3

          #5
          Just in case anyone else wonder about this:

          Did some tests on same 8 port switches, but filtering out data and only keeping information about 1 port. One switch was monitored by template with legacy method, the other with template with SNMP walk method

          The SNMP Engine process in switch with legacy SNMP discovery was reached only about 0.01% load, with the new method the load was 0.2%, with 2.5% peaks happening everytime queries are run. Also just to note the peaks will be the same on legacy SNMP method, but they will only happen when item discoveries are run, that's about every hour in default template.

          I also measured network load for 10 mins:

          Template with legacy SNMP method:

          Legacy SNMP method generated 50KB traffic in 10 minute period

          SNMP walk method generated 237KB traffic in 10 method period.


          So I would say if you are filtering out a lot of discovered items, legacy SNMP method can be more efficient. In other cases just use the new walk method.



          Originally posted by Markku

          Yes, maybe.

          That said, maybe the walk method also works just fine nowadays?

          Markku
          I'm not saying it's not working properly, but in my case, where I want to get data about couple of ports, not all of them, then querying only those said ports will be more efficient.

          Comment

          • greenApples
            Junior Member
            • Nov 2021
            • 5

            #6
            I'm still fairly new to Zabbix, so I might be misunderstanding something. However, as far as I know, you can still replicate the old behavior even when using the SNMP walk approach. One option is to build your LLD by walking only the index OID, and then use regular SNMP agent items in the item prototypes. That way, each discovered item performs its own SNMP query.

            Personally, I prefer the inherited approach that uses a single SNMP walk item, where I walk the set of OIDs I’m actually interested in. I then use that item as the source for both the LLD rule and the item prototypes. In my setup, I also configure the original “walk” item to not store any historical data, since the actual metrics are collected and stored by the item prototypes.

            Comment

            Working...