简介博科光纤交换机官方MIB参考手册PDF覆盖Fabric OS v3.1.x、v3.2.x、v4.x、v5.x、v6.0及v6.1.0等多个版本面向管理存储区域网络的运维工程师和网络管理员用于通过SNMP远程监控光交状态、开展日常故障排查。手册系统说明博科专用MIB的层次结构与对象定义可据此查看端口状态、带宽利用率、错误统计、温度告警等关键性能指标也可对照监控数据定位异常为理解光交内部对象模型与优化SAN网络性能提供官方依据。资源为单个PDF文件大小4.36MB支持全文检索与离线查阅已有1255人下载学习。相比零散在线页面完整单文件更便于按章节跳转与保存留档适合需要深入掌握博科MIB字段含义、梳理监控告警项的中高级运维人员。文档还附版本历史与版权声明便于核对适用固件范围。1. 这份MIB PDF到底解决什么问题别让交换机变成监控黑匣子SAN存储网络里最怕的一件事是光纤交换机端口报错而监控平台只能看到“端口down”一个光秃秃的状态。值班同事满屏告警里找不到根因登录交换机敲命令又看不出来趋势。Brocade光纤交换机MIB说明53-1000602-02-MIB-v610.pdf就是Brocade官方对Fabric OS 6.1.0时代SNMP管理对象的完整字典。它把端口状态、温度、光模块收发功率、登录会话、错误日志这些硬件与协议对象全部映射成SNMP能读的OID树。做存储监控的人拿到这份PDF才能在Zabbix、Prometheus或自研监控里把一台交换机拆成几十个可观测指标。适合谁负责SAN网络监控的运维、给监控平台写采集器的开发以及需要对接交换机和NetView这类大型网管平台的人。2. 先读懂MIB文档结构从PDF里的OID到snmpwalk的第一条命令2.1 文档里那棵OID树是怎么长出来的这份PDF的编排逻辑和你翻开一本新华字典一样。前面是目录后面是一张张表每张表定义一个MIB模块。我拿到手的第一件事不看那些英文废话先翻到模块清单确认里面用了哪几个基础MIB模块。Brocade设备通常会带标准MIB模块和私有MIB模块常见的私有模块集中在1.3.6.1.4.1.1588这棵子树下1588是Brocade在IANA注册的企业号。所有sw开头的对象名基本都在这一带。PDF里每个对象的描述是给人看的真正落地之前需要把“对象名、OID、对象类型、访问权限”这一行抄出来。访问权限有三个值值得注意read-only表示只能读read-write表示用snmpset能改not-accessible表示这是表索引用的不需要采集。很多新手把not-accessible的对象当成故障其实那是索引列没业务意义。常见的做法是这样先找到设备实际编译的MIB源文件通常是一堆.mib或.txt用net-snmp的snmptranslate验证这些文件能被正确加载再去翻阅PDF加深理解。千万别直接拿PDF里的数字乱配监控平台监控平台要的是编译后的MIB文件不是PDF文档。2.2 用snmpwalk验证PDF里的对象到底存不存在拿到交换机IP和SNMP读社区串先敲一条最保守的命令确认SNMP agent活着。假设交换机地址是192.168.1.10社区串是publicsnmpwalk -v 2c -c public 192.168.1.10 1.3.6.1.2.1.1这条命令走的是标准MIB的system组读取设备描述、系统对象ID、开机时间这些基本盘。返回结果里如果sysObjectID以.1.3.6.1.4.1.1588结尾就能确定为Brocade设备。这一步不需要加载任何私有MIB文件属于裸访问用来判断网络通路和社区串是否正确。确认通路后再访问Brocade私有节点把整棵私有树拉一遍。注意第一次不要拉太大范围控制在1.3.6.1.4.1.1588下一层或两层避免交换机在业务高峰期响应过慢。我一般会先拉snmpwalk -v 2c -c public 192.168.1.10 1.3.6.1.4.1.1588.2看Fabric OS家族的私有MIB是否可达。能看到一堆sw开头或fibreChannel开头的对象说明PDF描述的对象树上设备真实存在。下面这条是加载MIB文件后用对象名查询的典型姿势很多监控脚本里都会用到snmpget -v 2c -c public -M /opt/brocade_mibs -m BROCADE-MIB 192.168.1.10 swSwitchName.0-M指定MIB文件所在目录-m指定模块名称最后一个参数是对象名加.0后缀。如果加对了MIB文件返回的是一串可读的交换机名称如果提示找不到对象多半是MIB文件和固件版本对不上这在后面避坑章节会展开。3. 照着PDF摘对象落地一组可复用的SNMP采集命令3.1 从文档里摘监控对象哪些值得抄进采集脚本PDF翻久了会发现能抄的对象分三类。第一类是无脑必拍的温度、风扇、电源、端口操作状态。这类对象在文档里都有明确的状态值定义温度对象往往返回整数单位是摄氏度电源对象返回statusOn或其他枚举值。第二类是故障定位时才拉的对象比如错误包计数、CRC错误计数、链路超时计数。第三类是trap事件定义这不在采集范围但要配置告警接收。抄对象的时候我习惯先做一张小表格式是“功能描述、对象名、OID、返回值类型、正常范围”。这张表直接决定后面监控模板怎么写。端口状态在文档里通常有两种表达标准ifTable里的ifOperStatus以及私有MIB里带sw前缀的端口状态对象。前者用于通用拓扑管理后者用于Brocade特有的端口类型和连线状态。建议两者都拉便于后续排障对照。3.2 用Python拼一个SNMP采集器从PDF到监控数据的完整链路有了OID就可以写采集器了。下面这个脚本基于pysnmp把交换机名称、温度和端口流量读出来。这是从PDF到监控数据的最小闭环。from pysnmp.hlapi import * def snmp_get_value(oid, host192.168.1.10, communitypublic): error_indication, error_status, error_index, var_binds next( getCmd(SnmpEngine(), CommunityData(community), UdpTransportTarget((host, 161), timeout3, retries1), ContextData(), ObjectType(ObjectIdentity(oid))) ) if error_indication: print(f查询失败: {error_indication}) return None return var_binds[0][1] # 交换机名称对应标准MIB sysName.0 sys_name snmp_get_value(1.3.6.1.2.1.1.5.0) print(f交换机名称: {sys_name}) # 端口1的入口流量ifHCInOctets对应存储流量趋势 if_in snmp_get_value(1.3.6.1.2.1.31.1.1.1.6.1) print(f端口1入方向字节数: {if_in})这个脚本里getCmd是pysnmp的同步查询接口每次调用返回一个迭代器用next取第一条结果。UdpTransportTarget里的timeout3和retries1很关键光纤交换机在转发压力大的时候SNMP响应可能延迟超过默认超时时间收窄超时会导致误报。端口流量的OID用的是ifHCInOctets这是64位高容量计数器避免32位计数器在10G以上速率翻转太快。如果PDF里写的是老式的ifInOctets且对象类型是32位Counter生产环境务必换成HC版本。你不需要自己动手拼大段代码因为Zabbix这类工具自带SNMP采集器。但我建议先跑通上面这段脚本原因是用脚本验证单条OID的返回值远比在Zabbix里配置好模板再调试要快。脚本验证通过再把这个OID填进监控平台的监控项里时间成本最低。4. 把博科光纤交换机常用命令和MIB结合起来做排障4.1 switchshow与snmpwalk的端口状态对照命令行和MIB不是两套割裂的东西。实际排障中我习惯先用命令行确认硬件层事实再用MIB数据确认监控平台的数据是否正确。比如交换机端口显示Online但监控平台报端口down首先怀疑的就是OID映射错了。在交换机上用switchshow看端口状态可以看到端口编号、速率、类型和连接状态。这段输出里的“Online/Offline”是Fabric OS自己维护的端口状态。对应到MIB需要去PDF里找端口操作状态对象。标准ifOperStatus是1到7的整数1表示up2表示down这在所有MIB监控工具里一致。Brocade私有MIB里的端口状态对象会增加更多层级比如端口是否被禁用、是否在测试模式取值含义要回PDF里核对。下面是常用的几条博科光纤交换机常用命令以及它们和MIB对象的对应关系。命令行适合当前状态精确定位MIB适合历史趋势持续记录。排障场景命令行工具建议MIB对象端口状态与速率switchshowifOperStatus、ifHighSpeed端口错误计数porterrshow私有MIB的错误包计数对象温度与风扇状态sensorshow私有MIB的传感器表流量的长期趋势portperfshow -t 10ifHCInOctets、ifHCOutOctets已登录服务器列表fabricshow私有MIB的交换机名称表表格里的MIB对象都需要按PDF里的实际名称核对一遍。我的经验是命令行给出的信息永远比MIB快但MIB的历史曲线能把“从什么时候开始错”这件事讲清楚。比如porterrshow显示CRC错误累计数量很大可以立刻确认链路质量问题但要画一张“每晚几点错误增长”的图还得靠MIB持续采集。4.2 利用PDF里的trap定义让Brocade交换机主动报警除了被动轮询这份PDF后半部分通常会给出trap定义。trap是交换机主动发出来的SNMP消息在Brocade的设备上配置好SNMP trap主机后端口状态变化、温度越界、登录失败都会直接推给监控平台。配置trap主机常见做法是登录交换机后用snmpConfig命令进入交互界面设置trap接收方的IP和社区串。这一步不需要改MIB但要保证监控平台已经导入PDF对应的trap定义文件。否则平台收到trap后会显示一串无人能看懂的OID数字。验证trap是否生效最直接的方法是搬动一条跳线让端口状态翻转观察监控平台是否在几秒内弹出告警。如果没有弹先检查交换机的snmpTrapConfig是否指定了正确的接收IP再检查平台侧是否加载了Brocade的trap MIB文件。trap这块是排障里最“玄学”的环节很多问题实际出在平台的trap端口没开或者交换机发的v2c trap被防火墙拦了。5. Brocade MIB使用避坑5个我踩过的坑5.1 snmpwalk走到一半卡住不动平台监控数据大面积缺失现象对Brocade私有MIB做全量snmpwalk到了光纤端口状态表附近就长时间无响应命令不报错也不返回。 原因交换机的SNMP agent在处理某些表的索引映射时开销极高尤其当端口数量多、VC逻辑链路复杂时。这属于Fabric OS在SNMP实现上的固有行为不是网络问题。 解决不要全表walk。针对具体业务改用snmpget按OID精准查询或者用snmpbulkwalk降低请求次数。监控平台里也能设置“不采集not-accessible对象”减少无意义请求。5.2 MIB文件版本与固件小版本不匹配导致很多对象查不到现象加载了PDF同名的MIB文件但snmpwalk返回“No Such Object”。 原因MIB版本对应的是Fabric OS的某个大版本序列交换机固件如果做了小版本升级某些私有对象会被大幅调整。 解决从交换机上直接下载当前固件配套的MIB文件。常见做法是通过FTP或USB到设备文件系统里取。取出来后用snmptranslate -Td -m BROCADE-MIB手动测试对象是否存在确认没问题再替换监控平台的旧MIB。5.3 温度、功率这类返回值解析成乱码或负数现象平台把温度和光功率显示成8192、-40这类异常值。 原因Brocade私有MIB里不少对象是Integer32或Gauge32但部分传感器对象在文档里被定义为带符号数或需要换算偏移量。直接用原始值画图就会出现负数和离谱数值。 解决翻PDF的对象描述找到“单位和换算”那段说明。温度通常直接以摄氏度返回但光模块电压的返回值可能以微伏为单位需要除以某个系数。还有的对象返回值是编码后的十六进制字符串需要解开再取子串。5.4 端口重启后MIB索引对不上平台最近一条数据现象拔插一根光纤之后同一端口的流量历史曲线开始对到了另一个端口上。 原因Brocade某些端口表的索引不是固定不变的物理端口号而是逻辑索引。监控平台如果只按“索引名称”关联端口逻辑索引变化后就会映射错位。 解决采集端口类数据时除了OID索引额外把端口的ifName或物理端口描述也采样下来。每次抓取后做一次端口名到索引的映射校验发现不对就重刷映射关系。5.5 Trap能收到但内容看不懂平台一直显示未知OID现象监控平台确实弹了告警但标题是一长串数字比如.1.3.6.1.4.1.1588.2.1.1.1.1.7.1。 原因平台只启用了trap接收端口没有导入Brocade的trap MIB定义文件。SNMP trap里携带的是OID数字必须靠MIB翻译成可读的对象名。 解决在监控平台的MIB导入页面把PDF配套的MIB文件全部导入并重启SNMP trap接收器。导入后用snmptranslate -Td验证trap中出现的OID能被正确解析。6. 把一个OID变成一条监控告警的完整流程与验证方法假设现在要把交换机温度做成告警项完整流程分四步。第一步先回PDF里找到温度传感器的对象名和OID确认这个对象是Gauge32类型同时确定正常温度范围Brocade交换机一般建议告警阈值设在环境温度加30℃上下。第二步用snmptranslate -Td -m BROCADE-MIB 对象名看MIB文件能否正确翻译该对象。第三步在监控平台新建一个监控项走SNMP直接采集OID轮询频率设300秒超时设5秒重试1次。拿温度这项举例监控项的预处理脚本要把原始整数值直接转换成摄氏度并映射成数值类型。第四步设置告警阈值比如60℃为Warning80℃为Critical连续采集两次越阈值才产生告警。这里有个值得养成的习惯每一次阈值变更都回到PDF核对传感器对象的取值范围别凭感觉设一个肯定报不出来的数。验证整个链路是否可用比配置过程更重要。对只读对象可以等对象自然变化后再对比平台曲线对温度这类不能随便触发变化的对象我采用的办法是把阈值临时调到当前值以下人为触发一次越限告警确认告警通道打通后再把阈值改回正常值。不建议直接用snmpset去模拟交换机事件虽然MIB里部分对象可写但生产交换机上修改非标准参数存在风险。最后说一个我个人坚持的备份习惯每台Brocade交换机在完成固件升级后我会花十分钟把设备上当前生效的MIB文件全部导出一份按固件版本号归档同时用snmpwalk把私有MIB的顶层结构拉一遍存成文本。这样无论监控平台还是后续排障都有一份和实际固件严格对应的字典可查。能少踩一半版本的坑。希望帮到你。本文还有配套的精品资源点击获取 Brocade光纤交换机MIB解析：从OID到SNMP监控排障实战
简介博科光纤交换机官方MIB参考手册PDF覆盖Fabric OS v3.1.x、v3.2.x、v4.x、v5.x、v6.0及v6.1.0等多个版本面向管理存储区域网络的运维工程师和网络管理员用于通过SNMP远程监控光交状态、开展日常故障排查。手册系统说明博科专用MIB的层次结构与对象定义可据此查看端口状态、带宽利用率、错误统计、温度告警等关键性能指标也可对照监控数据定位异常为理解光交内部对象模型与优化SAN网络性能提供官方依据。资源为单个PDF文件大小4.36MB支持全文检索与离线查阅已有1255人下载学习。相比零散在线页面完整单文件更便于按章节跳转与保存留档适合需要深入掌握博科MIB字段含义、梳理监控告警项的中高级运维人员。文档还附版本历史与版权声明便于核对适用固件范围。1. 这份MIB PDF到底解决什么问题别让交换机变成监控黑匣子SAN存储网络里最怕的一件事是光纤交换机端口报错而监控平台只能看到“端口down”一个光秃秃的状态。值班同事满屏告警里找不到根因登录交换机敲命令又看不出来趋势。Brocade光纤交换机MIB说明53-1000602-02-MIB-v610.pdf就是Brocade官方对Fabric OS 6.1.0时代SNMP管理对象的完整字典。它把端口状态、温度、光模块收发功率、登录会话、错误日志这些硬件与协议对象全部映射成SNMP能读的OID树。做存储监控的人拿到这份PDF才能在Zabbix、Prometheus或自研监控里把一台交换机拆成几十个可观测指标。适合谁负责SAN网络监控的运维、给监控平台写采集器的开发以及需要对接交换机和NetView这类大型网管平台的人。2. 先读懂MIB文档结构从PDF里的OID到snmpwalk的第一条命令2.1 文档里那棵OID树是怎么长出来的这份PDF的编排逻辑和你翻开一本新华字典一样。前面是目录后面是一张张表每张表定义一个MIB模块。我拿到手的第一件事不看那些英文废话先翻到模块清单确认里面用了哪几个基础MIB模块。Brocade设备通常会带标准MIB模块和私有MIB模块常见的私有模块集中在1.3.6.1.4.1.1588这棵子树下1588是Brocade在IANA注册的企业号。所有sw开头的对象名基本都在这一带。PDF里每个对象的描述是给人看的真正落地之前需要把“对象名、OID、对象类型、访问权限”这一行抄出来。访问权限有三个值值得注意read-only表示只能读read-write表示用snmpset能改not-accessible表示这是表索引用的不需要采集。很多新手把not-accessible的对象当成故障其实那是索引列没业务意义。常见的做法是这样先找到设备实际编译的MIB源文件通常是一堆.mib或.txt用net-snmp的snmptranslate验证这些文件能被正确加载再去翻阅PDF加深理解。千万别直接拿PDF里的数字乱配监控平台监控平台要的是编译后的MIB文件不是PDF文档。2.2 用snmpwalk验证PDF里的对象到底存不存在拿到交换机IP和SNMP读社区串先敲一条最保守的命令确认SNMP agent活着。假设交换机地址是192.168.1.10社区串是publicsnmpwalk -v 2c -c public 192.168.1.10 1.3.6.1.2.1.1这条命令走的是标准MIB的system组读取设备描述、系统对象ID、开机时间这些基本盘。返回结果里如果sysObjectID以.1.3.6.1.4.1.1588结尾就能确定为Brocade设备。这一步不需要加载任何私有MIB文件属于裸访问用来判断网络通路和社区串是否正确。确认通路后再访问Brocade私有节点把整棵私有树拉一遍。注意第一次不要拉太大范围控制在1.3.6.1.4.1.1588下一层或两层避免交换机在业务高峰期响应过慢。我一般会先拉snmpwalk -v 2c -c public 192.168.1.10 1.3.6.1.4.1.1588.2看Fabric OS家族的私有MIB是否可达。能看到一堆sw开头或fibreChannel开头的对象说明PDF描述的对象树上设备真实存在。下面这条是加载MIB文件后用对象名查询的典型姿势很多监控脚本里都会用到snmpget -v 2c -c public -M /opt/brocade_mibs -m BROCADE-MIB 192.168.1.10 swSwitchName.0-M指定MIB文件所在目录-m指定模块名称最后一个参数是对象名加.0后缀。如果加对了MIB文件返回的是一串可读的交换机名称如果提示找不到对象多半是MIB文件和固件版本对不上这在后面避坑章节会展开。3. 照着PDF摘对象落地一组可复用的SNMP采集命令3.1 从文档里摘监控对象哪些值得抄进采集脚本PDF翻久了会发现能抄的对象分三类。第一类是无脑必拍的温度、风扇、电源、端口操作状态。这类对象在文档里都有明确的状态值定义温度对象往往返回整数单位是摄氏度电源对象返回statusOn或其他枚举值。第二类是故障定位时才拉的对象比如错误包计数、CRC错误计数、链路超时计数。第三类是trap事件定义这不在采集范围但要配置告警接收。抄对象的时候我习惯先做一张小表格式是“功能描述、对象名、OID、返回值类型、正常范围”。这张表直接决定后面监控模板怎么写。端口状态在文档里通常有两种表达标准ifTable里的ifOperStatus以及私有MIB里带sw前缀的端口状态对象。前者用于通用拓扑管理后者用于Brocade特有的端口类型和连线状态。建议两者都拉便于后续排障对照。3.2 用Python拼一个SNMP采集器从PDF到监控数据的完整链路有了OID就可以写采集器了。下面这个脚本基于pysnmp把交换机名称、温度和端口流量读出来。这是从PDF到监控数据的最小闭环。from pysnmp.hlapi import * def snmp_get_value(oid, host192.168.1.10, communitypublic): error_indication, error_status, error_index, var_binds next( getCmd(SnmpEngine(), CommunityData(community), UdpTransportTarget((host, 161), timeout3, retries1), ContextData(), ObjectType(ObjectIdentity(oid))) ) if error_indication: print(f查询失败: {error_indication}) return None return var_binds[0][1] # 交换机名称对应标准MIB sysName.0 sys_name snmp_get_value(1.3.6.1.2.1.1.5.0) print(f交换机名称: {sys_name}) # 端口1的入口流量ifHCInOctets对应存储流量趋势 if_in snmp_get_value(1.3.6.1.2.1.31.1.1.1.6.1) print(f端口1入方向字节数: {if_in})这个脚本里getCmd是pysnmp的同步查询接口每次调用返回一个迭代器用next取第一条结果。UdpTransportTarget里的timeout3和retries1很关键光纤交换机在转发压力大的时候SNMP响应可能延迟超过默认超时时间收窄超时会导致误报。端口流量的OID用的是ifHCInOctets这是64位高容量计数器避免32位计数器在10G以上速率翻转太快。如果PDF里写的是老式的ifInOctets且对象类型是32位Counter生产环境务必换成HC版本。你不需要自己动手拼大段代码因为Zabbix这类工具自带SNMP采集器。但我建议先跑通上面这段脚本原因是用脚本验证单条OID的返回值远比在Zabbix里配置好模板再调试要快。脚本验证通过再把这个OID填进监控平台的监控项里时间成本最低。4. 把博科光纤交换机常用命令和MIB结合起来做排障4.1 switchshow与snmpwalk的端口状态对照命令行和MIB不是两套割裂的东西。实际排障中我习惯先用命令行确认硬件层事实再用MIB数据确认监控平台的数据是否正确。比如交换机端口显示Online但监控平台报端口down首先怀疑的就是OID映射错了。在交换机上用switchshow看端口状态可以看到端口编号、速率、类型和连接状态。这段输出里的“Online/Offline”是Fabric OS自己维护的端口状态。对应到MIB需要去PDF里找端口操作状态对象。标准ifOperStatus是1到7的整数1表示up2表示down这在所有MIB监控工具里一致。Brocade私有MIB里的端口状态对象会增加更多层级比如端口是否被禁用、是否在测试模式取值含义要回PDF里核对。下面是常用的几条博科光纤交换机常用命令以及它们和MIB对象的对应关系。命令行适合当前状态精确定位MIB适合历史趋势持续记录。排障场景命令行工具建议MIB对象端口状态与速率switchshowifOperStatus、ifHighSpeed端口错误计数porterrshow私有MIB的错误包计数对象温度与风扇状态sensorshow私有MIB的传感器表流量的长期趋势portperfshow -t 10ifHCInOctets、ifHCOutOctets已登录服务器列表fabricshow私有MIB的交换机名称表表格里的MIB对象都需要按PDF里的实际名称核对一遍。我的经验是命令行给出的信息永远比MIB快但MIB的历史曲线能把“从什么时候开始错”这件事讲清楚。比如porterrshow显示CRC错误累计数量很大可以立刻确认链路质量问题但要画一张“每晚几点错误增长”的图还得靠MIB持续采集。4.2 利用PDF里的trap定义让Brocade交换机主动报警除了被动轮询这份PDF后半部分通常会给出trap定义。trap是交换机主动发出来的SNMP消息在Brocade的设备上配置好SNMP trap主机后端口状态变化、温度越界、登录失败都会直接推给监控平台。配置trap主机常见做法是登录交换机后用snmpConfig命令进入交互界面设置trap接收方的IP和社区串。这一步不需要改MIB但要保证监控平台已经导入PDF对应的trap定义文件。否则平台收到trap后会显示一串无人能看懂的OID数字。验证trap是否生效最直接的方法是搬动一条跳线让端口状态翻转观察监控平台是否在几秒内弹出告警。如果没有弹先检查交换机的snmpTrapConfig是否指定了正确的接收IP再检查平台侧是否加载了Brocade的trap MIB文件。trap这块是排障里最“玄学”的环节很多问题实际出在平台的trap端口没开或者交换机发的v2c trap被防火墙拦了。5. Brocade MIB使用避坑5个我踩过的坑5.1 snmpwalk走到一半卡住不动平台监控数据大面积缺失现象对Brocade私有MIB做全量snmpwalk到了光纤端口状态表附近就长时间无响应命令不报错也不返回。 原因交换机的SNMP agent在处理某些表的索引映射时开销极高尤其当端口数量多、VC逻辑链路复杂时。这属于Fabric OS在SNMP实现上的固有行为不是网络问题。 解决不要全表walk。针对具体业务改用snmpget按OID精准查询或者用snmpbulkwalk降低请求次数。监控平台里也能设置“不采集not-accessible对象”减少无意义请求。5.2 MIB文件版本与固件小版本不匹配导致很多对象查不到现象加载了PDF同名的MIB文件但snmpwalk返回“No Such Object”。 原因MIB版本对应的是Fabric OS的某个大版本序列交换机固件如果做了小版本升级某些私有对象会被大幅调整。 解决从交换机上直接下载当前固件配套的MIB文件。常见做法是通过FTP或USB到设备文件系统里取。取出来后用snmptranslate -Td -m BROCADE-MIB手动测试对象是否存在确认没问题再替换监控平台的旧MIB。5.3 温度、功率这类返回值解析成乱码或负数现象平台把温度和光功率显示成8192、-40这类异常值。 原因Brocade私有MIB里不少对象是Integer32或Gauge32但部分传感器对象在文档里被定义为带符号数或需要换算偏移量。直接用原始值画图就会出现负数和离谱数值。 解决翻PDF的对象描述找到“单位和换算”那段说明。温度通常直接以摄氏度返回但光模块电压的返回值可能以微伏为单位需要除以某个系数。还有的对象返回值是编码后的十六进制字符串需要解开再取子串。5.4 端口重启后MIB索引对不上平台最近一条数据现象拔插一根光纤之后同一端口的流量历史曲线开始对到了另一个端口上。 原因Brocade某些端口表的索引不是固定不变的物理端口号而是逻辑索引。监控平台如果只按“索引名称”关联端口逻辑索引变化后就会映射错位。 解决采集端口类数据时除了OID索引额外把端口的ifName或物理端口描述也采样下来。每次抓取后做一次端口名到索引的映射校验发现不对就重刷映射关系。5.5 Trap能收到但内容看不懂平台一直显示未知OID现象监控平台确实弹了告警但标题是一长串数字比如.1.3.6.1.4.1.1588.2.1.1.1.1.7.1。 原因平台只启用了trap接收端口没有导入Brocade的trap MIB定义文件。SNMP trap里携带的是OID数字必须靠MIB翻译成可读的对象名。 解决在监控平台的MIB导入页面把PDF配套的MIB文件全部导入并重启SNMP trap接收器。导入后用snmptranslate -Td验证trap中出现的OID能被正确解析。6. 把一个OID变成一条监控告警的完整流程与验证方法假设现在要把交换机温度做成告警项完整流程分四步。第一步先回PDF里找到温度传感器的对象名和OID确认这个对象是Gauge32类型同时确定正常温度范围Brocade交换机一般建议告警阈值设在环境温度加30℃上下。第二步用snmptranslate -Td -m BROCADE-MIB 对象名看MIB文件能否正确翻译该对象。第三步在监控平台新建一个监控项走SNMP直接采集OID轮询频率设300秒超时设5秒重试1次。拿温度这项举例监控项的预处理脚本要把原始整数值直接转换成摄氏度并映射成数值类型。第四步设置告警阈值比如60℃为Warning80℃为Critical连续采集两次越阈值才产生告警。这里有个值得养成的习惯每一次阈值变更都回到PDF核对传感器对象的取值范围别凭感觉设一个肯定报不出来的数。验证整个链路是否可用比配置过程更重要。对只读对象可以等对象自然变化后再对比平台曲线对温度这类不能随便触发变化的对象我采用的办法是把阈值临时调到当前值以下人为触发一次越限告警确认告警通道打通后再把阈值改回正常值。不建议直接用snmpset去模拟交换机事件虽然MIB里部分对象可写但生产交换机上修改非标准参数存在风险。最后说一个我个人坚持的备份习惯每台Brocade交换机在完成固件升级后我会花十分钟把设备上当前生效的MIB文件全部导出一份按固件版本号归档同时用snmpwalk把私有MIB的顶层结构拉一遍存成文本。这样无论监控平台还是后续排障都有一份和实际固件严格对应的字典可查。能少踩一半版本的坑。希望帮到你。本文还有配套的精品资源点击获取