已发出严重\警告的告警，但未触发操作
1.) 确保操作已与生成告警的属性相关联。例如，如果服务器的CPU利用率超过了允许水平并生成告警，请导航到监控页面->配置告警并确保操作与此属性相关联。
2.) 如果这是一个电子邮件的操作，从操作下拉列表->查看操作->手动执行操作并检查邮件操作是否有效。
如果它失败了并指向与SMTP相关的错误，则由于SMTP问题而无法触发该操作。如果需要测试SMTP服务器，请参阅此知识库文章。
注：如果这是服务台售票措施，请参见日是KB。
3.) 如果SMTP有效，请导航到管理->操作\告警设置选项卡，之后检查是否选中了“生成告警时启用操作”的字段。
4.) 如果上述字段被选中并且监视器存在于任何组中，请验证组级别中是否启用了操作。这可以从监视器组视图中验证，如下面的屏幕截图所示。
Related Articles
属性违反了阈值，但没有生成告警
1.) 确保已为该属性关联了阈值，并且没有为其配置业务时间限制。例如，如果服务器的CPU利用率超过了允许的水平，请导航至监视器→配置告警来检查是否已为CPU 利用率 (%)设置了阈值。 导航到阈值配置文件 → 查看阈值配置文件页面。点击要检查的阈值配置文件。点击“显示高级选项”并检查“要尝试的轮询”字段的值以了解严重和警告的严重性。 如果设置为使用全局默认值，请参见步骤 2。 如果将其设置为3/3或不同的值，则只有在满足该条件时才会触发告警。 ...【opm】接口删除告警方法
可能场景： 1，客户使用的企业版，探针被删除，但中心中仍然存在此探针的告警无法删除。 2，脚本监视器：脚本已经删除，残留的告警无法删除 方法： 使用接口删除 https://localhost:8060/api/json/alarm/deleteAlarm?apiKey=***************&entity=sample_entity 改变以上链接的API Key 和 Entity （故障对象） 故障对象ID如何获取： API Key: 使用postman工具删除：注post方法OpManager中的告警严重性级别
OpManager具有四个不同的告警严重性级别。设备故障告警的严重性级别（可用性监视）已经预先定义好了。 以下是具有严重性和将触发具有这些严重性的告警时间的列表： 1) 服务关闭：当服务关闭且URL监视器关闭 2) 注意：当设备因可用性中的第一个轮询而关闭时 3) 故障：当设备在可用性中连续3次轮询关闭时 4) 严重：当设备在可用性中连续5次轮询关闭时。这是OpManager中最高等级的严重性。 5) 正常：在任何没有告警的时候。 如您所见，设备停机告警的严重性将根据未命中轮询的数量自动更改。 ...即使超过阈值，我也没有收到告警。需要做什么？
解决方法： 在管理 -> 操作/告警设置 -> 连续轮询次数中查看值。该值决定了它应该等待多少轮询间隔来确定是否可以生成告警。OP删除告警失败处理方法---没有[XXXXXX]的告警详细信息
删除设备告警时遇到以下问题，提示： 没有[XXXXXX]的告警详细信息。 此告警是远程ping脚本监视器生成。 处理办法： 在告警中找到此告警，按照以下找出“故障对象”列。复制故障对象ID 登录到数据库执行删除操作： 命令：Delete from alert where entity='‘’ ID ';