关于 SNMP MIB 陷阱组织的建议答案

【问题标题】：Advice on SNMP MIB trap organization关于 SNMP MIB 陷阱组织的建议
【发布时间】：2013-01-25 22:53:19
【问题描述】：

我正在寻找有关 SNMP MIB 陷阱组织或最佳实践的建议。我没有找到任何描述真实世界使用情况和期望的材料。

我过去只使用过 SNMP，大部分时间只是获取/设置，我以前从未处理过陷阱。

让我解释一下……

我最近加入了一家公司，需要查看他们的 MIB，但其中的陷阱不是我所期望的。

对于每个引发警报条件的陷阱（例如，“超过 X 阈值”- 严重性严重，ID 100）都有一个完全独立的陷阱用于清除（“超过 X 阈值清除”- 严重性清除，ID 134）。每个陷阱都有一个任意的“trap-id”分配给它，其中没有编码任何意义或关系信息。知道陷阱 134 清除陷阱 100 的唯一方法是查看陷阱的文本名称。这似乎不对。

例如，风扇故障陷阱如下（为简洁而编辑）：

    fooTrapFanFailure NOTIFICATION-TYPE
        OBJECTS {StampID, SerialNumber, Name, TrapID, Severity}
        DESCRIPTION   "Fan failure, trap-id 105, severity major"
        ::= { fooTraps 8 }

    fooTrapFanFailureClear NOTIFICATION-TYPE
        OBJECTS {StampID, SerialNumber, Name, TrapID, Severity}
        DESCRIPTION  "Fan failure clear, trap-id 132, severity informational"
        ::= { fooTraps 11 }

我知道 132 清除 105 的唯一方法是手动读取 MIB 或以编程方式扫描 MIB 并根据陷阱名称构建表。这个案例更加愚蠢，因为清除陷阱显示为“信息”严重性。

我预计当“超过 X 阈值”trap-id 100 被提高时，它会被发送，其严重性设置为“严重”，当它清除时，会发送相同的 trap-id 100 严重性'清除'。

或者，如果只有一个包含陷阱 ID 和严重性的通用警报陷阱，而不是我的 65 个左右的独特陷阱，那就更好了。

所以，简而言之，问题是：

这种“两陷阱，一举一解”正常吗？

【问题讨论】：

标签： snmp mib

【解决方案1】：

这不正常，但没关系。我明白他们为什么会这样做，很容易根据 OID 在 HP OV NNM 中分配颜色（不知道确切的版本，但它在 2000 年有效）。否则您可能必须解析数据包才能在 Manager/Management 站上显示颜色。

通常最好将陷阱状态用作陷阱绑定的一部分。

【讨论】：

【解决方案2】：

我将我的 Mib 文件与 SNMPc 一起使用。我的文件只有一个陷阱 EventOccured 和由 SNMPc 过滤器生成的所有其他逻辑（相关性）。我使用 Severity='CL' 来清除陷阱。所以不明白“fooTrapFanFailureClear”陷阱中的 Severity 变量对您有什么要求？

【讨论】：