本文介绍日志服务告警监控规则的常见问题。
使用RAM用户操作告警时，如何为RAM用户授权？
当您使用RAM用户操作告警时，需要先授予RAM用户告警操作权限。具体操作，请参见授予RAM用户告警操作权限。
创建告警监控规则时，遇到Alert count exceeds the maximum limit错误，如何处理？
如果您在创建告警监控规则时，系统出现Alert count exceeds the maximum limit错误，表示该Project下的告警监控规则超过了最大限制（默认100个）。您可以提工单申请扩容至200个。
- 删除该Project下无用的告警监控规则。
- 将日志采集到不同的Project中，减少单个Project下的告警监控规则数量。
例如将服务A的日志采集到Project1中，将服务B的日志采集到Project2中，则您可以在不同的Project中创建告警监控规则。
- 合并相似的告警监控规则。
例如监控同一个Logstore中的数据时，您可以只创建一个告警监控规则，通过分组评估实现使用一条告警监控规则同时监控多个目标。更多信息，请参见分组评估。
- 通过数据加工或定时SQL将数据存储到一个Logstore后再创建告警监控规则。
例如您要监控多个Logstore中的错误日志，则可以将所有的错误日志存储到一个Logstore中，然后基于该Logstore创建一个告警监控规则。
如何基于关键字设置告警？
将日志采集到日志服务后，您可以通过日志服务告警系统实现基于日志关键字的告警。具体操作，请参见基于日志关键字设置告警。
如何监控不同的对象？
在某些情况下，您无法提前知道目标字段的所有取值，但需要监控该字段在任意取值时是否满足告警触发条件，那么就可以使用分组评估功能，选择该字段作为标签进行分组，每个分组单独评估告警的触发条件。更多信息，请参见分组评估。
例如，您将多个服务器的指标数据存储在一个时序库中，但希望每个服务器的CPU使用率（cpu_util）超过95%时，日志服务可以分开发送每个服务器的告警信息，则可以使用分组评估。
为什么设置了多个触发条件，只有一个生效？
查询统计结果按照触发条件的顺序逐条匹配，当查询统计结果符合第一个触发条件后，不再匹配后面的触发条件。因此当您设置触发条件中的严重度时，需从较高级别的严重度开始配置。具体操作，请参见设置告警严重度。
为什么出现漏告警或者误告警？
- 漏告警：例如告警触发条件是错误日志数大于10就触发告警，而在Logstore查询分析页面查询时某个时间段内错误日志数实际大于10 ，却没有触发告警。
- 误告警：例如告警触发条件是QPS低于100就触发告警，而在Logstore查询分析页面查询时某个时间段内QPS实际大于100，却触发了告警。
出现漏告警或者误告警，一般是由于数据写入到Logstore到可查询存在一定的延迟，当告警监控规则中的查询时间范围设置为相对时间时，会导致告警的查询不完全准确。为了避免这两种情况，建议扩大告警监控规则中的查询时间范围或者将查询时间范围设置为整点时间。更多信息，请参见监控时效性说明。
在告警历史图表中，当是否触发告警为true，原因为Notify threshold not reached时，如何处理？
如果告警历史统计仪表盘的告警历史图表中，是否触发告警显示为true，而原因显示为Notify threshold not reached，表示您在告警监控规则中设置了连续触发阈值，而此次触发还未达到连续触发阈值。例如设置连续触发阈值为3次，那么连续3次都满足触发条件，才会真正触发告警。
