요약 규칙을 사용하여 Log Analytics 작업 영역의 데이터 집계(미리 보기)

요약 규칙을 사용하면 로그 데이터를 정기적으로 집계하고 집계된 결과를 Log Analytics 작업 영역의 사용자 지정 로그 테이블로 보낼 수 있습니다. 요약 규칙을 사용하여 다음 용도로 데이터를 최적화합니다.

• 분석 및 보고서: 특히 보안 및 인시던트 분석, 월별 또는 연간 비즈니스 보고서 등에 필요한 대규모 데이터 세트 및 시간 범위에 대해 사용합니다. 대용량 데이터 세트에 대한 복잡한 쿼리는 종종 시간이 초과됩니다. 정리 및 집계된 요약된 데이터를 분석하고 보고하는 것이 더 쉽고 효율적입니다.

• 자세한 로그에 대한 비용 절감: 많던 적던, 저렴한 기본 로그 테이블에서 필요한 만큼 데이터를 보존하고 분석 및 보고서를 위해 분석 테이블에 요약된 데이터를 보낼 수 있습니다.

• 보안 및 데이터 프라이버시: 공유 가능한 요약 데이터에서 개인 정보 세부 정보를 제거하거나 난독 처리하고 원시 데이터가 있는 테이블에 대한 액세스를 제한합니다.

이 문서에서는 요약 규칙의 작동 방식과 요약 규칙을 정의하고 보는 방법을 설명하고 요약 규칙의 사용 및 이점에 대한 몇 가지 예를 제공합니다.

요약 규칙의 몇 가지 이점에 대한 개요를 제공하는 비디오는 다음과 같습니다.

요약 규칙 작동 방식

요약 규칙은 Log Analytics 작업 영역에서 직접 일괄 처리를 수행합니다. 요약 규칙은 KQL 쿼리를 기준으로 bin 크기로 정의된 데이터 청크를 집계하고 요약된 결과를 Log Analytics 작업 영역에서 Analytics 로그 플랜을 사용하여 사용자 지정 테이블로 다시 수집합니다.

테이블에 Analytics 또는 기본 데이터 플랜있는지에 관계없이 모든 테이블의 데이터를 집계할 수 있습니다. Azure Monitor는 정의한 쿼리에 따라 대상 테이블 스키마를 만듭니다. 대상 테이블이 이미 있는 경우 Azure Monitor는 쿼리 결과를 지원하는 데 필요한 열을 추가합니다. 모든 대상 테이블에는 다음을 비롯한 요약 규칙 정보가 포함된 표준 필드 집합도 포함됩니다.

• _RuleName: 집계된 로그 항목을 생성한 요약 규칙
• _RuleLastModifiedTime: 파일이 마지막으로 수정된 시간
• _BinSize: 집계 간격
• _BinStartTime 집계 시작 시간

최대 30개의 활성 규칙을 구성하여 여러 테이블의 데이터를 집계하고, 집계된 데이터를 별도의 대상 테이블 또는 동일한 테이블로 보낼 수 있습니다.

데이터 내보내기 규칙을 정의하여 추가 통합을 위해 사용자 지정 로그 테이블에서 스토리지 계정 또는 Event Hubs로 요약된 데이터를 내보낼 수 있습니다.

예제: ContainerLogsV2 데이터 요약

컨테이너를 모니터링하는 경우 많은 양의 자세한 정보 로그를 ContainerLogsV2 테이블에 수집합니다.

요약 규칙에서 이 쿼리를 통해 60분 이내에 모든 고유 로그 항목을 집계하여 분석에 유용한 데이터를 유지하고 필요하지 않은 데이터를 삭제할 수 있습니다.

ContainerLogV2 | summarize Count = count() by  Computer, ContainerName, PodName, PodNamespace, LogSource, LogLevel, Message = tostring(LogMessage.Message)

ContainerLogsV2 테이블의 원시 데이터는 다음과 같습니다.

요약 규칙이 대상 테이블로 보내는 집계된 데이터는 다음과 같습니다.

대상 테이블은 한 시간 내에 수백 개의 유사한 항목을 로깅하는 대신, KQL 쿼리에 정의된 각 고유 항목의 수를 보여 줍니다. 원시 데이터의 저렴한 보존을 위해 ContainerLogsV2 테이블에서기본 데이터 플랜을 설정하고 분석 요구 사항에 맞게 대상 테이블의 요약된 데이터를 사용합니다.

필수 사용 권한

제한 사항

• 요약 규칙은 현재 퍼블릭 클라우드에서만 사용할 수 있습니다.

• 요약 규칙은 들어오는 데이터를 처리하며 기록 시간 범위에서 구성할 수 없습니다.

• bin 실행 재시도 횟수가 제한에 도달하면 bin을 건너뛰고 다시 실행할 수 없습니다.

• Lighthouse를 사용하여 다른 테넌트의 Log Analytics 작업 영역을 쿼리하는 것은 지원되지 않습니다.

• KQL 제한은 원본 테이블의 테이블 계획에 따라 달라집니다.

  • Analytics: 다음을 제외한 모든 KQL 명령을 지원합니다.

    • workspaces(), app() 및 resource() 식을 사용하는 리소스 간 쿼리, ADX() 및 ARG() 식을 사용하는 서비스 간 쿼리
    • bag unpack, narrow 및 pivot을 비롯하여 데이터 스키마의 모양을 바꾸는 플러그 인

  • 기본: 단일 테이블에서 모든 KQL 명령을 지원합니다. lookup 연산자를 사용하여 최대 5개의 Analytics 테이블을 조인할 수 있습니다.

  • 함수: 사용자 정의 함수는 지원되지 않습니다. Microsoft에서 제공하는 시스템 함수는 지원됩니다.

가격 책정 모델

요약 규칙에는 추가 비용이 없습니다. 쿼리를 실행하는 원본 테이블의 테이블 계획에 따라 쿼리 및 대상 테이블에 대한 결과 수집에 대해서만 비용을 지불합니다.

예를 들어 bin당 100개의 레코드를 반환하는 시간별 규칙에 대한 비용 계산은 다음과 같습니다.

자세한 내용은 Azure Monitor 가격을 참조하세요.

요약 규칙 만들기 또는 업데이트

규칙을 만들기 전에 Log Analytics에서 쿼리로 실험해봅니다. 쿼리가 쿼리 제한에 도달하지 않았는지 또는 쿼리 제한에 근접하지 않았는지 확인합니다. 쿼리가 의도한 스키마 및 예상 결과를 생성하는지 확인합니다. 쿼리가 쿼리 제한에 근접한 경우 더 작은 binSize를 사용하여 bin당 더 적은 데이터를 처리하는 것이 좋습니다. 더 적은 레코드를 반환하거나 볼륨이 높은 필드를 제거하도록 쿼리를 수정할 수도 있습니다.

쿼리를 업데이트하고 결과 집합에서 출력 필드를 제거하면 Azure Monitor는 대상 테이블에서 열을 자동으로 제거하지 않습니다. 수동으로 테이블의 열을 삭제해야 합니다.

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2023-01-01-preview
Authorization: {credential}

{
  "properties": {
      "ruleType": "User",
      "description": "My test rule",
      "ruleDefinition": {
          "query": "StorageBlobLogs | summarize count() by AccountName",
          "binSize": 30,
          "destinationTable": "MySummaryLogs_CL"
      }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "type": "String",
      "metadata": {
        "description": "The workspace name where summary rule is deployed."
      }
    },
    "summaryRuleName": {
      "type": "String",
      "metadata": {
        "description": "The summary rule name."
      }
    },
    "description": {
      "type": "String",
      "metadata": {
        "description": "A description of the rule."
      }
    },
    "location": {
      "defaultValue": "[resourceGroup().location]",
      "type": "String",
      "metadata": {
        "description": "The Location of the workspace summary rule is deployed."
      }
    },
    "ruleType": {
      "defaultValue": "User",
      "allowedValues": [
        "User"
      ],
      "type": "String",
      "metadata": {
        "description": "The summary rule type (User,System). Should be 'User' for and rule with query that you define."
      }
    },
    "query": {
      "type": "String",
      "metadata": {
      "description": "The query used in summary rules."
      }
    },
    "binSize": {
      "defaultValue": 60,
      "allowedValues": [
        20,
        30,
        60,
        120,
        180,
        360,
        720,
        1440
      ],
      "type": "Int",
      "metadata": {
        "description": "The execution interval in minutes, and the lookback time range."
      }
    },
    "destinationTable": {
      "type": "String",
      "metadata": {
        "description": "The name of the custom log table that the summary results are sent to. Name must end with '_CL'."
      }
    }
    // ----- optional -----
    // "binDelay": {
    //   "type": "Int",
    //   "metadata": {
    //     "description": "Optional - The minimum wait time in minutes before bin execution. For example, value of '10' cause bin (01:00-02:00) to be executed after 02:10."
    //   }
    // },
    // "timeSelector": {
    //   "defaultValue": "TimeGenerated",
    //   "allowedValues": [
    //     "TimeGenerated"
    //   ],
    //   "type": "String",  
    //   "metadata": {
    //     "description": "Optional - The time field to be used by the summary rule. Must be 'TimeGenerated'."
    //   }
    // },
    // "binStartTime": {
    //   "type": "String",
    //   "metadata": {
    //     "description": "Optional - The Time of initial bin. Can start at current time minus binSize, or future, and in whole hours. For example: '2024-01-01T08:00'."
    //   }
    // }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/workspaces/summaryLogs",
      "apiVersion": "2023-01-01-preview",
      //"name": "[format('{0}/{1}', parameters('workspaceName'), parameters('summaryRuleName'))]",
      "name": "[concat(parameters('workspaceName'), '/', parameters('summaryRuleName'))]",
      "properties": {
        "ruleType": "[parameters('ruleType')]",
        "description": "[parameters('description')]",
        "ruleDefinition": {
          "query": "[parameters('query')]",
          "binSize": "[parameters('binSize')]",
          "destinationTable": "[parameters('destinationTable')]"
          // ----- optional -----
          //"binDelay": "[parameters('binDelay')]",
          //"timeSelector": "[parameters('timeSelector')]",
          //"binStartTime": "[parameters('binStartTime')]"
        }
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "value": "myworkspace"
    },
    "summaryRuleName": {
      "value": "myrulename"
    },
    "description": {
      "value": "My rule description."
    },
    "location": {
      "value": "eastus" //Log Analytics workspace region
    },
    "ruleType": {
      "value": "User"
    },
    "query": {
      "value": "StorageBlobLogs | summarize Count = count(), DurationMs98 = percentile(DurationMs, 90) by StatusCode, CallerIpAddress, OperationName"
    },
    "binSize": {
      "value": 20
    },
    "destinationTable": {
      "value": "MySummaryLogs_CL"
    }
  }
}

이 표에서는 요약 규칙 매개 변수에 대해 설명합니다.

집계 타이밍 구성

기본적으로 요약 규칙은 그 다음 정각 시간에 첫 번째 집계를 만듭니다.

Azure Monitor가 추가하는 짧은 지연 시간에는 수집 대기 시간(또는 모니터링되는 시스템에서 데이터를 만든 시간과 Azure Monitor에서 데이터를 분석할 수 있는 시간 사이의 시간)이 고려됩니다. 기본적으로 이 지연은 3분 30초에서 각 데이터 청크를 집계하기 전 binSize 값의 10% 사이입니다. 대부분의 경우 이 지연 시간이 있으므로 Azure Monitor가 각 bin 기간 내에 기록된 모든 데이터를 집계할 수 있습니다.

예시:

• 14:44에 bin 크기가 30분인 요약 규칙을 만듭니다.

  규칙은 14:30에서 15:00 사이에 기록된 데이터에 대해 15:00 직후(예: 15:04)에 첫 번째 집계를 만듭니다.

• 14:44에 bin 크기가 720분(12시간)인 요약 규칙을 만듭니다.

  규칙은 03:00에서 15:00 사이에 기록된 데이터에 대해 13:00 이후 16:12-72분(720 bin 크기의 10%)에 첫 번째 집계를 만듭니다.

binStartTime 및 binDelay 매개 변수를 사용하여 첫 번째 집계의 타이밍과 각 집계 전에 Azure Monitor가 추가하는 지연 시간을 변경합니다.

다음 섹션에서는 기본 집계 타이밍 및 고급 집계 타이밍 옵션의 예를 제공합니다.

기본 집계 타이밍 사용

이 예제에서 요약 규칙은 2023-06-07 14:44에 만들어지고 Azure Monitor는 4분의 기본 지연 시간을 추가합니다.

선택적 집계 타이밍 매개 변수 설정

이 예제에서 요약 규칙은 2023-06-07 14:44에 만들어지고 규칙에는 다음과 같은 고급 구성 설정이 포함됩니다.

• binStartTime: 2023-06-08 07:00
• binDelay: 8분

요약 규칙 보기

이 GET API 호출을 사용하여 특정 요약 규칙에 대한 구성을 확인합니다.

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName1}?api-version=2023-01-01-preview
Authorization: {credential}

이 GET API 호출을 통해 구성을 확인하여 Log Analytics 작업 영역에서 모든 요약 규칙의 구성을 확인합니다.

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs?api-version=2023-01-01-preview
Authorization: {credential}

요약 규칙 중지 및 다시 시작

예를 들어 데이터가 테이블에 수집되었는지 확인하려고 하며 요약된 테이블 및 보고서에 영향을 주지 않으려면 규칙을 일정 기간 동안 중지할 수 있습니다. 규칙을 다시 시작하면 Azure Monitor는 다음 1시간 이후부터 또는 정의된 binStartTime(선택 사항) 매개 변수에 따라 데이터 처리를 시작합니다.

규칙을 중지하려면 다음 POST API 호출을 사용합니다.

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/stop?api-version=2023-01-01-preview
Authorization: {credential}

규칙을 다시 시작하려면 다음 POST API 호출을 사용합니다.

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/start?api-version=2023-01-01-preview
Authorization: {credential}

요약 규칙 삭제

Log Analytics 작업 영역에는 최대 30개의 활성 요약 규칙이 있을 수 있습니다. 새 규칙을 만들려고 하지만 이미 30개의 활성 규칙이 있는 경우 기존 활성 요약 규칙을 중지하거나 삭제해야 합니다.

규칙을 중지하려면 다음 DELETE API 호출을 사용합니다.

DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2023-01-01-preview
Authorization: {credential}

요약 규칙 모니터링

요약 규칙을 모니터링하려면 Log Analytics 작업 영역의 진단 설정에서 요약 로그 범주를 사용하도록 설정합니다. Azure Monitor는 요약 규칙 실행 시작, 성공 및 실패 정보를 포함한 요약 규칙 실행 세부 정보를 작업 영역의 LASummaryLogs 테이블에 보냅니다.

아래와 같이 bin 오류가 있을 때 bin 실행이 시간 제한에 가까워질 때 알림을 받도록 로그 경고 규칙을 설정하는 것이 좋습니다. 실패 원인에 따라 각 실행에서 더 적은 데이터를 처리하도록 bin 크기를 줄이거나 쿼리를 수정하여 볼륨이 높은 레코드 또는 필드를 더 적게 반환할 수 있습니다.

이 쿼리는 다음과 같이 실패한 실행을 반환합니다.

LASummaryLogs | where Status == "Failed"

이 쿼리는 QueryDurationMs 값이 0.9 x 600,000밀리초보다 큰 bin 실행을 반환합니다.

LASummaryLogs | where QueryDurationMs > 0.9 * 600000

데이터 완성도 확인

요약 규칙은 스케일링이 가능하도록 설계되었으며, 예를 들어 쿼리 제한과 관련된 일시적인 서비스 또는 쿼리 오류를 극복하기 위한 다시 시도 메커니즘을 포함합니다. 다시 시도 메커니즘은 8시간 내에 실패한 bin을 집계하기 위해 10번 시도하며, 이 횟수가 되면 bin을 건너뜁니다. 규칙은 isActive: false로 설정되고 8회 연속 bin 다시 시도 후 보류됩니다. 모니터 요약 규칙을 사용하도록 설정하면 Azure Monitor는 작업 영역의 LASummaryLogs 테이블에 이벤트를 기록합니다.

실패한 bin 실행을 다시 실행할 수는 없지만 다음 쿼리를 사용하여 실패한 실행을 볼 수 있습니다.

let startTime = datetime("2024-02-16");
let endtTime = datetime("2024-03-03");
let ruleName = "myRuleName";
let stepSize = 20m; // The stepSize value is equal to the bin size defined in the rule
LASummaryLogs
| where RuleName == ruleName
| where Status == 'Succeeded'
| make-series dcount(BinStartTime) default=0 on BinStartTime from startTime to endtTime step stepSize
| render timechart

이 쿼리는 결과를 시간 차트로 렌더링합니다.

규칙 수정 옵션 및 자동 관리 경고에 대해서는 요약 규칙 모니터링 섹션을 참조하세요.

고객 관리형 키를 사용하여 요약 규칙 쿼리 암호화

KQL 쿼리는 주석 또는 쿼리 구문에 중요한 정보를 포함할 수 있습니다. 요약 규칙 쿼리를 암호화하려면 스토리지 계정을 Log Analytics 작업 영역에 연결하고 고객 관리형 키를 사용합니다.

암호화된 쿼리를 사용하는 경우의 고려 사항:

• 스토리지 계정을 연결하여 쿼리를 암호화해도 기존 규칙이 중단되지 않습니다.
• 기본적으로 Azure Monitor는 Log Analytics 스토리지에 요약 규칙 쿼리를 저장합니다. 스토리지 계정을 Log Analytics 작업 영역에 연결하기 전에 기존 요약 규칙이 있는 경우 쿼리가 스토리지 계정에 기존 쿼리를 저장하도록 요약 규칙을 업데이트합니다.
• 스토리지 계정에 저장한 쿼리는 CustomerConfigurationStoreTable 테이블에 있습니다. 이러한 쿼리는 서비스 아티팩트로 간주되며 해당 형식이 변경될 수 있습니다.
• 요약 규칙 쿼리, Log Analytics의 저장된 쿼리, 로그 경고에 대해 동일한 스토리지 계정을 사용할 수 있습니다.

요약 규칙 문제 해결

이 섹션에서는 요약 규칙 문제를 해결하기 위한 팁을 제공합니다.

실수로 삭제된 요약 규칙 대상 테이블

요약 규칙이 활성 상태인 동안 대상 테이블을 삭제하면 규칙이 일시 중단되고 Azure Monitor가 규칙이 일시 중단되었음을 나타내는 메시지와 함께 이벤트를 LASummaryLogs 테이블에 보냅니다.

대상 테이블에 요약 결과가 필요하지 않은 경우 규칙과 테이블을 삭제합니다. 요약 결과를 복구해야 하는 경우 요약 규칙 만들기 또는 업데이트 섹션의 단계에 따라 테이블을 다시 만듭니다. 테이블의 보존 정책에 따라 삭제 전에 수집된 데이터를 포함하는 대상 테이블이 복원됩니다.

대상 테이블에 요약 결과가 필요하지 않은 경우 규칙과 테이블을 삭제합니다. 요약 결과가 필요한 경우 요약 규칙 만들기 또는 업데이트 섹션의 단계에 따라 대상 테이블을 다시 만들고, 테이블의 보존 정책에 따라 삭제 전에 수집된 데이터를 비롯한 모든 데이터를 복원합니다.

쿼리는 대상 테이블에서 새 열을 만드는 연산자를 사용합니다.

대상 테이블 스키마는 요약 규칙을 만들거나 업데이트할 때 정의됩니다. 요약 규칙의 쿼리에 들어오는 데이터에 따라 출력 스키마 확장을 허용하는 연산자가 포함된 경우(예: 쿼리에서 arg_max(expression, *) 함수를 사용하는 경우) 요약 규칙을 만들거나 업데이트한 후 Azure Monitor는 대상 테이블에 새 열을 추가하지 않으며 이러한 열이 필요한 출력 데이터는 삭제됩니다. 대상 테이블에 새 필드를 추가하려면 요약 규칙을 업데이트하거나 수동으로 테이블에 열을 추가합니다.

제거된 열의 데이터는 테이블의 보존 설정에 따라 작업 영역에 남아 있습니다.

쿼리에서 열을 제거하면 열과 데이터는 테이블이나 작업 영역에 정의된 보존 기간을 기준으로 대상에 남아 있습니다. 대상 테이블에서 제거할 필요가 없으면 테이블 스키마에서 열을 삭제합니다. 그런 다음 동일한 이름의 열을 추가하면 보존 기간보다 오래되지 않은 모든 데이터가 다시 나타납니다.

관련 콘텐츠

• Azure Monitor 로그 데이터 플랜에 대해 자세히 알아봅니다.
• Log Analytics에서 KQL 모드 사용에 대한 자습서를 살펴봅니다.
• KQL에 대한 전체 참조 설명서에 액세스합니다.