我想在 Check_MK 的库存插件中处理来自 TP-Link 交换机的 LLDP 数据。TP-Link 交换机不使用 LLDP 的标准 SNMP OID,并且他们的自定义 MIB 有一个奇怪的怪癖。他们没有将索引放在 OID 的末尾,而是将其放在 OID 的中间。
[[[u'1.1.99353.1', u'Te1/0/25'], [u'1.2.99353.1', u'1'], [u'1.3.99353.1', u'MAC地址'], [ u'1.4.99353.1', u'00:zzzzzzz'], [u'1.5.99353.1', u'MAC 地址'], [u'1.6.99353.1', u'00:zzzzzzzz'], [u'1.7 .99353.1', u'120'], [u'1.8.99353.1', u'Port 25'], [u'1.9.99353.1', u'THE_HOST_NAME'], [u'1.11.99353.1', u'Bridge Router'], [u'1.12.99353.1', u'Bridge Router'], [u'shortened', u'for 简洁']]
所以在正常的星球上,我会期待像 99353. 8和 99353. 9或者 99353.1 这样的东西。8和 99353.1。9 . 他们在这里所做的(1. X .99353.1)很奇怪。我不知道该怎么办。我所知道的是我必须使它正常化,而我太愚蠢了,不能这样做。
这就是我想从中得到的:
{
l_id : 99353.1 # from the "index"
l_ifname : u'Te1/0/25' # from 1.1
r_ifname : u'Port 25' # from 1.8
r_hostname : u'THE_HOST_NAME' # from 1.9.
}
映射这个(只是列表的一个子集,而拆分关键是完全超出我的技能水平。我想避免花半天时间用一堆 for 循环产生丑陋的东西。特别是因为这个应该去上游一个社区项目,我不希望任何人伤害他们的眼睛。
是否有一些聪明的方法可以让我将其分解为 2-3 个较小的问题?