Question

我正在寻找有关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并根据陷阱名称构建表。这个案例更加愚蠢，因为Clear陷阱显示出“信息”严重性。

我预计当一个'超过X阈值'trap-id 100被引发时，它将被发送，其严重性设置为'critical'，当它被清除时，同一个trap-id 100将以严重性发送'清楚'。

如果只有一个包含trap-id和severity的通用警报陷阱，而不是我65个左右的独特陷阱，那就更好了。

因此，简而言之，问题是：

这是'两个陷阱，一个加注，一个清除'正常吗？

Answer 1

这不正常，但没关系。我可以看出为什么他们可能这样做，很容易根据OID在HP OV NNM中分配颜色（不知道确切的版本，但它在2000年工作）。否则，您可能需要解析数据包以在Manager / Management Station上显示颜色。

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

Answer 2

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

有关SNMP MIB陷阱组织的建议

2 个答案: