microsoft / microsoft/AzureMonitorCommunity
Issue with a Log Analytics Data Cap Breach Alert
まだ誰も着手していません。
- 主要言語
- PowerShell
- スター
- 1.2k
- フォーク
- 493
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
I am trying to setup a scheduled query alert from the AKS-Construction repo, and have run into some odd behavior. Apparently, the alert can be setup from the AKS-Construction templates, but not from a standalone deployment. I am trying to move the alert into my logging templates as it isn't really AKS related.
https://github.com/Azure/AKS-Construction/issues/559
resource Daily_data_cap_breached_for_workspace_logworkspacename_CIQ_1 'microsoft.insights/scheduledqueryrules@2022-06-15' = {
name: 'Daily data cap breached for workspace ${resLogAnalyticsWorkspace.name} CIQ-1'
location: parAutomationAccountLocation
properties: {
displayName: 'Daily data cap breached for workspace ${resLogAnalyticsWorkspace.name} CIQ-1'
description: 'This alert monitors daily data cap defined on a workspace and fires when the daily data cap is breached.'
severity: 1
enabled: metricAlertsEnabled
evaluationFrequency: evalFrequency
scopes: [
resLogAnalyticsWorkspace.id
]
windowSize: windowSize
autoMitigate: false
criteria: {
allOf: [
{
query: '_LogOperation | where Operation == "Data collection Status" | where Detail contains "OverQuota"'
timeAggregation: 'Count'
operator: 'GreaterThan'
threshold: 0
failingPeriods: {
numberOfEvaluationPeriods: 1
minFailingPeriodsToAlert: 1
}
}
]
}
muteActionsDuration: 'P1D'
}
}
throws the following exception from a standalone bicep deployment
{
"status": "Failed",
"error": {
"code": "BadRequest",
"message": "Couldn't optimize the query because it doesn't contain the table Operation explicitly. Please add the table to the query explicitly and try again"
}
}
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
AKS-Construction のテンプレートにある scheduledqueryrules リソースを、スタンドアロンの logging-template デプロイメントにある同じリソースと比較します。まず、提供されたクエリとエラーを使ってスタンドアロンの Bicep デプロイメントを再現し、その後、それぞれのコンテキストでアラートのクエリがどのように処理されるかを追跡します。アラートを query-optimization の BadRequest なしでスタンドアロンでデプロイできれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- azure
- 領域
- cloud, observability-sre
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100