我使用Kusto查询在Azure AppInsights中创建时间图,使用Google's examples of measuring if a webservice is within its error budget之一可视化我们的when服务何时在其SLO内(以及何时不在
SLI = The proportion of sufficiently fast requests, as measured from the load balancer metrics. “Sufficiently fast” is defined as < 400 ms.
SLO = 90% of requests < 400 ms
Measured as:
count of http_requests with a duration less than or equal to "0.4" seconds
divided by count of all http_requests
假设在7天的窗口中有10分钟的检查间隔,下面是我的代码:
let fastResponseTimeMaxMs = 400.0;
let errorBudgetThresholdForFastResponseTime = 90.0;
//
let startTime = ago(7days);
let endTime = now();
let timeStep = 10m;
//
let timeRange = range InspectionTime from startTime to endTime step timeStep;
timeRange
| extend RespTimeMax_ms = fastResponseTimeMaxMs
| extend ActualCount = toscalar
(
requests
| where timestamp > InspectionTime - timeStep
| where timestamp <= InspectionTime
| where success == "True"
| where duration <= fastResponseTimeMaxMs
| count
)
| extend TotalCount = toscalar
(
requests
| where timestamp > InspectionTime - timeStep
| where timestamp <= InspectionTime
| where success == "True"
| count
)
| extend Percentage = round(todecimal(ActualCount * 100) / todecimal(TotalCount), 2)
| extend ErrorBudgetMinPercent = errorBudgetThresholdForFastResponseTime
| extend InBudget = case(Percentage >= ErrorBudgetMinPercent, 1, 0)
我希望实现的查询输出示例:
InspectionTime [UTC] RespTimeMax_ms ActualCount TotalCount Percentage ErrorBudgetMinPercent InBudget
2019-05-23T21:53:17.894 400 8,098 8,138 99.51 90 1
2019-05-23T22:03:17.894 400 8,197 9,184 89.14 90 0
2019-05-23T22:13:17.894 400 8,002 8,555 93.54 90 1
我得到的错误是:
'where' operator: Failed to resolve scalar expression named 'InspectionTime'
我尝试过todatetime(InspectionTime)
,但失败了,出现了同样的错误。
用datetime
类型的其他对象替换InspectionTime
可以使这段代码执行正常,但不是我想要的日期时间值。例如,当在上面的代码示例中使用时,使用此代码段可以正常执行:
| extend ActualCount = toscalar
(
requests
| where timestamp > startTime // instead of 'InspectionTime - timeStep'
| where timestamp <= endTime // instead of 'InspectionTime'
| where duration <= fastResponseTimeMaxMs
| count
)
对我来说,在toscalar(...)
中使用InspectionTime
似乎是这个问题的症结所在,因为我能够使用range(...)
在类似的查询中使用InspectionTime
,而不是将它嵌套在toscalar(...)
中。
注意:我不想要request.duration
的时间图,因为根据上面定义的公式,它不会告诉我超过阈值(400ms)的请求计数是否超过了我们的错误预算。
https://stackoverflow.com/questions/56386504
复制相似问题