更新：
实际问题与我所描述的不同。解决问题后，我将提供并更新/编辑此故障单。在该线程中可以找到更多详细信息-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帐户作为“ RESOURCE”，然后为“ CONDITION”选择“ Custom log search”信号名称。警报逻辑-“结果数大于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（例如Period = 30和Frequency = 5,，这意味着“每5分钟评估一次表达式，从当前时间获取最近30分钟的数据”），那么我们会收到多个重复的警报，因为{{ 1}}比Period大，因此日志搜索查询很有可能每Frequency分钟返回相同的日志条目-这是非常不希望的行为。
答案 0 :(得分：0)
问题恰好与ARM模板创建警报的错误行为有关。感谢Stanislav Zhelyazkov，它已被确定下来并解决了-我现在使用替代的ARM API，它似乎可以正常工作。可以在此处找到有关该主题的更多详细信息-https://techcommunity.microsoft.com/t5/Azure-Log-Analytics/Reliably-trigger-alerts-for-Log-Analytics-log-entries/m-p/309610。