microsoft / microsoft/AzureMonitorCommunity

Issue with a Log Analytics Data Cap Breach Alert

オープン
#167 コメント 1 件 リアクション 3 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
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"
    }
}

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

AKS-Construction のテンプレートにある scheduledqueryrules リソースを、スタンドアロンの logging-template デプロイメントにある同じリソースと比較します。まず、提供されたクエリとエラーを使ってスタンドアロンの Bicep デプロイメントを再現し、その後、それぞれのコンテキストでアラートのクエリがどのように処理されるかを追跡します。アラートを query-optimization の BadRequest なしでスタンドアロンでデプロイできれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
azure
領域
cloud, observability-sre
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。