更新:
实际问题与我所描述的不同。我将在解决问题后提供并更新/编辑此票证。有关详细信息,请访问此主题-https://techcommunity.microsoft.com/t5/Azure-Log-Analytics/Reliably-trigger-alerts-for-Log-Analytics-log-entries/m-p/319315/highlight/false#M1224
原问题:
我们使用Azure Monitor
创建基于Log Analytics
中日志的警报。为此,我们选择Log Analytics帐户作为“资源”,然后选择“自定义日志搜索”信号名称作为“条件”。警报逻辑-“结果数大于0”。
查询示例:
search *
| where ResourceProvider == "MICROSOFT.DATAFACTORY" and status_s == "Failed"
对于Period
和Frequency
,让我们设置15
分钟。所有看起来很简单,但是...
问题:上面描述的设置不起作用(它工作 * 有时 *),因为警报只是偶尔触发,很多都错过了,这是完全不可接受的行为。
如果我们设置Period = Frequency = 5
分钟,我们基本上错过了几乎所有的事件。Period = Frequency = 15
分钟工作得更好,但仍然有很多事件丢失。Period = Frequency = 30
工作得更好,但所有这一切看起来很奇怪。
重要通知-日志是从Data Factory V2
收集到Log Analytics
的。我怀疑警报遗漏是由于日志在传送到Log Analytics
时有一些延迟(最多几分钟)。因此,当Azure Monitor
评估最后15
分钟的警报查询时(Period=15
)可能是大多数重新发送的日志条目仍不在Log Analytics
中。在15
分钟内执行下一次查询评估时,将错过延迟前一个15
分钟间隔进入的日志。这个假设是正确的吗?如果是的话,这就很奇怪了--那么我们应该如何配置Period
和Frequency
的值呢?如果我设置Period > Frequency
(例如X1 M20 N1 X和X1 M21 N1 X表示“每5分钟评估表达式,take data for last 30 minutes from current time”),则我们会收到多个重复的警报,因为Period
大于Frequency
,因此日志搜索查询很可能每隔5
分钟返回相同的日志条目-这是非常不希望的行为。
2条答案
按热度按时间qlckcl4x1#
问题发生在ARM模板创建警报的错误行为上。多亏了Stanislav Zhelyazkov,这个问题已经被解决了--我现在使用替代的ARM API,它看起来工作得很好。关于这个主题的更多细节可以在这里找到--https://techcommunity.microsoft.com/t5/Azure-Log-Analytics/Reliably-trigger-alerts-for-Log-Analytics-log-entries/m-p/309610。
edqdpe6u2#
我们遇到了类似的问题,这篇文章帮助我们解决了这个问题:https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/handling-ingestion-delay-in-azure-sentinel-scheduled-alert-rules/ba-p/2052851
简而言之,我们现在设置了一个日志警报,每15分钟运行一次,并使用过去30分钟的数据(二头肌/手臂:frequencyInMinutes=15,timeWindowInMinutes=30)。此外,我还在查询中添加了一个where语句,其中
ago(15m)
应等于警报的频率:这应该可以解决由于接收延迟而无法触发警报的问题,而且还可以防止重复。