[ZBX-3192] The caching of indexes SNMP doesn't work? Created: 2010 Nov 06  Updated: 2017 May 30  Resolved: 2011 May 31

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 1.9.4 (alpha)
Fix Version/s: 1.8.6, 1.9.5 (alpha)

Type: Incident report Priority: Blocker
Reporter: Vladimir Kravchenko Assignee: Unassigned
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

zabbix revision 15316



 Description   

It can be connected with use of macroes in "index value"?

jimson[root]:~ # cat /var/log/zabbix/server.log | g snmp_get_index
60357:20101107:002323.533 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.1' value:'FastEthernet0/1'
60355:20101107:002324.543 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.2' value:'FastEthernet0/2'
60357:20101107:002325.553 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.3' value:'FastEthernet0/3'
60357:20101107:002326.569 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.1' value:'FastEthernet0/1'
60355:20101107:002327.584 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.2' value:'FastEthernet0/2'
60359:20101107:002328.594 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.3' value:'FastEthernet0/3'
60357:20101107:002329.603 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.1' value:'FastEthernet0/1'
60358:20101107:002330.614 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60358:20101107:002330.624 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.2' value:'FastEthernet0/2'
60355:20101107:002331.624 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60355:20101107:002331.630 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.3' value:'FastEthernet0/3'
60359:20101107:002332.638 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002333.644 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002334.654 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002335.664 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002336.674 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002337.684 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002339.693 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002340.705 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002342.714 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002343.724 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002344.734 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.10024' value:'FastEthernet0/24'
60357:20101107:002348.744 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.9' value:'FastEthernet0/9'
60358:20101107:002353.774 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.1' value:'FastEthernet0/1'
60357:20101107:002354.786 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.2' value:'FastEthernet0/2'
60359:20101107:002355.794 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.3' value:'FastEthernet0/3'
60355:20101107:002356.808 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.1' value:'FastEthernet0/1'
60358:20101107:002357.814 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.2' value:'FastEthernet0/2'
60357:20101107:002358.824 In snmp_get_index() oid:'1.3.6.1.2.1.2.2.1.2.3' value:'FastEthernet0/3'



 Comments   
Comment by Vladimir Kravchenko [ 2010 Nov 07 ]

Я немного погорячился с этим тикетом, мои извенения, но багу я все равно нашел:

В структуре кэша нету идентификации SNMP агента, а так как один и тот же "value" для одного и того же "oid" будет иметь разный индекс для каждого агента (железки), то кэш фактически работать не будет, а так как индекс каждый раз перепроверяется, получается на каждый каждый запрос получаем полный набор: перепроверка + сканирование индекса.
Собственно у меня в сети (как видно из дебага выше) есть свичи где индексация портов начинается с 10000, а есть и такие где нумерация с 1.

И что бы не флудить, да еще и на русском, лишний раз, мои скромные предложения
1) таймаут на кэш запись, до истечения таймаута индекс не перепроверяется, а сразу идет запрос значения, если запрос значения вернул ошибку, то сбрасываем кэш (значение можно и не перезапрашивать и заново индекс в этой итерации не искать)
2) таймаут конфигурируемый как поле элемента данных, так как в 90% случаев (agent, value, index_oid) => index будет вечным, это и интерфейсы свичей и маршрутизаторы с включенным snmp ifindex persist
3) кэш общий для всех пулеров, если это возможно

P.S. типичная конфигурация для SNMP опросов это банальный 48-ми(48+2uplink) портовый эзернет свич, минимум 16 элементов данных на каждый интерфейс, получается 800 элементов опрашиваемых в лучшем случае раз в 5 минут, при текущей реализации кэша это 1600 опросов через 1 пулер, если же пулеров несколько или есть устройства с несовпадающими индексами, то

Comment by Ghozlane TOUMI [ 2011 Feb 24 ]

Hi.
Seems the problem is also present in 1.8.4
from the logs, the cache won't get a hit, and every index is retrieved every time and saved in the cache again...
at 6 items per port, that adds up quickly...
Obviously this floods the switch snmp agent, and it seems my switch can't keep up ...

512:20110224:083915.472 In substitute_simple_macros() data:'ifInOctets01'
512:20110224:083915.472 In substitute_simple_macros() data:'xxxxx'
512:20110224:083915.472 In substitute_simple_macros() data:'ifInOctets"index","ifDescr","Port #1"'
512:20110224:083915.472 In get_value() key:'ifInOctets01'
512:20110224:083915.472 In get_value_snmp() key:'ifInOctets01' oid:'ifInOctets"index","ifDescr","Port #1"'
512:20110224:083915.472 In snmp_open_session()
512:20110224:083915.473 SNMP [[email protected]:161]
512:20110224:083915.473 End of snmp_open_session()
512:20110224:083915.473 Special processing
512:20110224:083915.473 method:index
512:20110224:083915.473 oid_index:ifDescr
512:20110224:083915.473 index_value:Port #1
512:20110224:083915.473 In snmp_normalize(oid:ifDescr)
512:20110224:083915.474 End of snmp_normalize():1.3.6.1.2.1.2.2.1.2
512:20110224:083915.474 In cache_get_snmp_index(oid:1.3.6.1.2.1.2.2.1.2,value:Port #1)
512:20110224:083915.474 In get_snmpidx_nearestindex(oid:1.3.6.1.2.1.2.2.1.2,value:Port #1)
512:20110224:083915.474 End of get_snmpidx_nearestindex():1
512:20110224:083915.474 End of cache_get_snmp_index(index:101):SUCCEED
512:20110224:083915.474 In snmp_get_index(oid:1.3.6.1.2.1.2.2.1.2.101,value:Port #1)
512:20110224:083915.474 snmp_get_index: snmp_pdu_create()
512:20110224:083915.506 VAR: IF-MIB::ifDescr.101 = Port #1 (type=4)(length = 7)
512:20110224:083915.506 FOUND: Index is 101
512:20110224:083915.506 End of snmp_get_index():SUCCEED
512:20110224:083915.506 In cache_put_snmp_index(oid:1.3.6.1.2.1.2.2.1.2,value:Port #1,index:101)
512:20110224:083915.507 In get_snmpidx_nearestindex(oid:1.3.6.1.2.1.2.2.1.2,value:Port #1)
512:20110224:083915.507 End of get_snmpidx_nearestindex():1
512:20110224:083915.507 End of cache_put_snmp_index()
512:20110224:083915.507 Found index:101
512:20110224:083915.507 In snmp_normalize(oid:ifInOctets)
512:20110224:083915.507 End of snmp_normalize():1.3.6.1.2.1.2.2.1.10
512:20110224:083915.507 Full OID:1.3.6.1.2.1.2.2.1.10.101
512:20110224:083915.507 In get_snmp(oid:1.3.6.1.2.1.2.2.1.10.101)
512:20110224:083915.571 Status send [0]
512:20110224:083915.571 AV loop OID [1.3.6.1.2.1.2.2.1.10.101] Type [0x41] 'Counter32: 664431371'
512:20110224:083915.571 End of get_snmp():SUCCEED
512:20110224:083915.572 In snmp_close_session()
512:20110224:083915.572 End of snmp_close_session()
512:20110224:083915.572 End of get_value_snmp():SUCCEED
512:20110224:083915.572 End of get_value():SUCCEED
512:20110224:083915.572 In zbx_hashset_search()
512:20110224:083915.572 End of zbx_hashset_search()
512:20110224:083915.572 In zbx_hashset_search()
512:20110224:083915.572 End of zbx_hashset_search()
512:20110224:083915.572 In calculate_item_nextcheck (23475,120,"",1298536755)
512:20110224:083915.573 End calculate_item_nextcheck (nextcheck:1298536875 delay:120)
512:20110224:083915.573 In zbx_binary_heap_insert() key:23475
512:20110224:083915.573 In zbx_hashmap_get() key:23475
512:20110224:083915.573 End of zbx_hashmap_get() key:23475 value:-1
512:20110224:083915.573 In zbx_hashmap_set() key:23475 value:88
512:20110224:083915.573 End of zbx_hashmap_set()
512:20110224:083915.573 End of zbx_binary_heap_insert()
512:20110224:083915.573 In DCflush_nextchecks()
512:20110224:083915.573 End of get_values()

Comment by Ilia Sotnikov [ 2011 Apr 20 ]

The request I've submitted, ZBXNEXT-760, contains the patch which implements separate cache entries for separate hosts, along with sharing SNMP index cache between pollers.

Comment by dimir [ 2011 May 30 ]

At this point we decided to just fix the bug by adding destination point id (host + port). No IPC so each poller will have it's own cache.

Comment by dimir [ 2011 May 31 ]

Set Fix versions.

Comment by dimir [ 2011 May 31 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-3192

Comment by dimir [ 2011 Jun 02 ]

Fixed in trunk r19995, 1.8 r19977.

Generated at Fri Mar 29 04:13:06 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.