【问题标题】:Alert on error rate exceeding threshold using Azure Insights and/or Analytics使用 Azure Insights 和/或 Analytics 在错误率超过阈值时发出警报
【发布时间】:2017-06-28 08:58:19
【问题描述】:

我正在向 Azure Application Insights 发送 customEvents,如下所示:

timestamp                 |  name          |  customDimensions
----------------------------------------------------------------------------
2017-06-22T14:10:07.391Z  |  StatusChange  |  {"Status":"3000","Id":"49315"}
2017-06-22T14:10:14.699Z  |  StatusChange  |  {"Status":"3000","Id":"49315"}
2017-06-22T14:10:15.716Z  |  StatusChange  |  {"Status":"2000","Id":"49315"}
2017-06-22T14:10:21.164Z  |  StatusChange  |  {"Status":"1000","Id":"41986"}
2017-06-22T14:10:24.994Z  |  StatusChange  |  {"Status":"3000","Id":"41986"}
2017-06-22T14:10:25.604Z  |  StatusChange  |  {"Status":"2000","Id":"41986"}
2017-06-22T14:10:29.964Z  |  StatusChange  |  {"Status":"3000","Id":"54234"}
2017-06-22T14:10:35.192Z  |  StatusChange  |  {"Status":"2000","Id":"54234"}
2017-06-22T14:10:35.809Z  |  StatusChange  |  {"Status":"3000","Id":"54234"}
2017-06-22T14:10:39.22Z   |  StatusChange  |  {"Status":"1000","Id":"74458"}

假设状态3000 是错误状态,我想在过去一小时内一定百分比的Ids 最终处于错误状态时收到警报。

据我所知,Insights 默认无法执行此操作,因此我想尝试approach described here 编写一个可以触发警报的 Analytics 查询。这是我能想到的最好的:

customEvents
| where timestamp > ago(1h)
| extend isError = iff(toint(customDimensions.Status) == 3000, 1, 0)
| summarize failures = sum(isError), successes = sum(1 - isError) by timestamp bin = 1h
| extend ratio = todouble(failures) / todouble(failures+successes)
| extend failure_Percent = ratio * 100
| project iff(failure_Percent < 50, "PASSED", "FAILED")

但是,为了让我的警报正常工作,查询应该:

  1. 即使一小时内没有事件,也返回“PASSED”(另一个警报会处理没有事件的情况)
  2. 只考虑一个小时内每个 ID 的最终状态。

在写入请求时,如果没有事件,则查询既不返回“PASSED”也不返回“FAILED”。

它还考虑了带有Status == 3000任何条记录,这意味着上面的示例将返回“FAILED”(10 条记录中有 5 条状态为 3000),而实际上只有 1 条记录4 个 ID 最终处于错误状态。

谁能帮我找出正确的查询?

(以及可选的次要问题:是否有人使用 Insights 设置了类似的警报?这是正确的方法吗?)

【问题讨论】:

    标签: azure-application-insights ms-app-analytics aiql


    【解决方案1】:

    如前所述,由于您只在一个小时内进行查询,因此您不需要将 timestamp 分箱,或者根本不需要将其用作聚合的一部分。
    回答您的问题:

    1. 克服根本没有数据的方法是将合成行注入到您的表中,如果没有找到其他结果,它将转换为成功结果
    2. 如果您希望您的通过/失败标准基于每个 ID 的最终状态,那么您需要在您的 summarize 中使用 argmax - 它会返回对应于最大时间戳的状态。

    所以总结一下:

    customEvents
    | where timestamp > ago(1h)
    | extend isError = iff(toint(customDimensions.Status) == 3000, 1, 0)
    | summarize argmax(timestamp, isError) by tostring(customDimensions.Id) 
    | summarize failures = sum(max_timestamp_isError), successes = sum(1 - max_timestamp_isError)
    | extend ratio = todouble(failures) / todouble(failures+successes)
    | extend failure_Percent = ratio * 100
    | project Result = iff(failure_Percent < 50, "PASSED", "FAILED"), IsSynthetic = 0
    | union (datatable(Result:string, IsSynthetic:long) ["PASSED", 1])
    | top 1 by IsSynthetic asc 
    | project Result 
    

    关于附加问题 - 您可以使用 Flow 根据 Analytics 查询设置警报。有关相关问题/答案,请参阅 here

    【讨论】:

    • 为了将来参考,如果我不bin时间戳,查询总是返回一些东西(因为总和返回0),所以合成结果没有帮助。所以要么保留垃圾箱,要么就像我最终做的那样,返回“PASSED”if failed == success == 0。无论如何,感谢您的精彩解释
    【解决方案2】:

    如果您在一小时内没有数据,我假设查询不会返回任何行,因为timestamp bin = 1h(又名bin(timestamp,1h))不返回任何垃圾箱?

    但如果您只查询最后一小时,我认为您根本不需要时间戳上的 bin?

    如果没有您的数据,很难准确地重现,但是...您可以尝试类似的方法(注意语法错误):

    customEvents
    | where timestamp > ago(1h)
    | extend isError = iff(toint(customDimensions.Status) == 3000, 1, 0)
    | summarize totalCount = count(), failures = countif(isError == 1), successes = countif(isError ==0) 
    | extend ratio = iff(totalCount == 0, 0, todouble(failures) / todouble(failures+successes))
    | extend failure_Percent = ratio * 100
    | project iff(failure_Percent < 50, "PASSED", "FAILED")
    

    假设,摆脱小时分档应该只是让你回到这里的单行

    totalCount = 0, failures = 0, successes = 0,所以失败百分比的数学应该给你返回 0 失败率,这应该让你“通过”。

    如果没有尝试,我不确定这是否有效,或者如果没有数据,仍然不会返回任何行?

    对于你的第二个问题,你可以使用类似的东西

    let maxTimestamp = toscalar(customEvents where timestamp > ago(1h)
    | summarize max(timestamp));
    customEvents | where timestamp == maxTimestamp ...
    // ... more query here
    

    仅获取具有一小时内最后一个事件的时间戳的行?

    【讨论】:

      猜你喜欢
      • 2020-04-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-04-10
      • 2020-10-16
      • 1970-01-01
      • 2018-10-29
      相关资源
      最近更新 更多