제한됨: 리소스 사용량이 비정상적으로 높은 경우 실시간 규칙이 이 상태로 설정될 수 있습니다. 제한됨 규칙은 Google SecOps의 안정성이 유지되도록 시스템의 다른 실시간 규칙과 격리됩니다.
제한됨 라이브 규칙의 경우 성공적인 규칙 실행이 항상 가능한 것은 아닙니다.
그러나 규칙 실행이 성공하면 감지 항목이 보관되고 이를 검토할 수 있습니다. 제한됨 라이브 규칙은 항상 오류 메시지를 생성합니다. 여기에는 규칙의 성능을 향상시키는 방법에 대한 추천이 포함됩니다.
제한됨 규칙의 성능이 3일 이내에 개선되지 않으면 상태가 일시중지됨으로 변경됩니다.
참고: 최근에 이 규칙을 변경하지 않았다면 오류가 간헐적으로 발생할 수 있으며 자동으로 해결될 수 있습니다.
일시중지됨: 실시간 규칙이 3일 동안 제한됨 상태로 유지되고 성능 향상이 나타나지 않으면 이 상태로 전환됩니다. 이 규칙의 실행이 일시중지되고 규칙 성능 향상에 관한 제안이 포함된 오류 메시지가 반환됩니다.
실시간 규칙을 사용 설정됨 상태로 되돌리려면 YARA-L 권장사항에 따라 규칙 성능을 최적화하고 변경사항을 저장합니다. 규칙이 저장된 후 사용 설정됨 상태로 재설정되고 제한됨 상태에 다시 도달하기 전까지 최소 한 시간 이상 걸립니다.
실행 빈도를 낮게 구성하면 잠재적으로 규칙의 성능 문제를 해결할 가능성이 있습니다. 예를 들어 10분마다 실행되는 규칙을 1시간 또는 24시간에 한 번만 실행되도록 재구성할 수 있습니다. 그러나 규칙의 실행 빈도를 변경해도 해당 상태가 다시 사용 설정됨으로 변경되지는 않습니다. 규칙을 일부 수정하고 저장하면 해당 상태가 자동으로 사용 설정됨으로 재설정됩니다.
규칙 상태는 규칙 대시보드에 표시되고 Detection Engine API를 통해서도 액세스할 수 있습니다. 제한됨 또는 일시중지됨 상태의 규칙으로 생성된 오류는 ListErrors API 메서드를 사용해서 제공됩니다.
이 오류는 해당 규칙이 제한됨 또는 일시중지됨 상태임을 나타내고 문제 해결 방법에 대한 문서 링크를 제공합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eLive rules in Google Security Operations prioritize real-time data for immediate threat detection, and can be enabled by toggling the "Live Rule" option in the Rules Dashboard.\u003c/p\u003e\n"],["\u003cp\u003eGoogle SecOps enforces limits on live rules, with quotas for both multiple event rules and total live rules, indicated in the "Rules Capacity" section.\u003c/p\u003e\n"],["\u003cp\u003eDetection delays in live rules can be influenced by several factors, including rule type, run frequency, data ingestion delay, contextual joins, data enrichment, timezone discrepancies, and the use of reference lists.\u003c/p\u003e\n"],["\u003cp\u003eLive rules can have statuses such as Enabled, Disabled, Limited, or Paused, with Limited and Paused statuses indicating performance issues and potential service interruptions, requiring optimization or modifications.\u003c/p\u003e\n"],["\u003cp\u003eThe engine automatically removes duplicate detections from rules that rely on time-based windows and match variables.\u003c/p\u003e\n"]]],[],null,["# Learn how to apply a rule to live data\n======================================\n\nSupported in: \nGoogle secops [SIEM](/chronicle/docs/secops/google-secops-siem-toc)\n\nWhen you create a rule, it does not initially search for detections based on\nevents received in your Google Security Operations account in real time. However, you set the\nrule to search for detections in real time by setting the **Live Rule** toggle\nto enabled.\n\nWhen a rule is configured to search for detections in real time, it prioritizes\nlive data for immediate threat detection.\n\nTo set a rule to live, complete the following steps:\n\n1. Click **Detection** \\\u003e **Rules \\& Detections**.\n\n2. Click the **Rules Dashboard** tab.\n\n3. Click the more_vert **Rules** option icon for a rule and toggle the **Live Rule** to enabled.\n\n **Live Rule**\n4. Select **View Rule Detections** to view detections from a live rule.\n\nDisplay Rules quota\n-------------------\n\nAt the top right of the Rules dashboard, click **Rules capacity** to display the limits to the number of rules that can be enabled as live.\n\nGoogle SecOps imposes the following rule limits:\n\n- **Multiple Events Rules Quota** : Displays the current count of live-enabled Multiple Event rules and the maximum allowed. Learn more about the difference between [Single Event](/chronicle/docs/detection/yara-l-2-0-overview#single-event-rule) and [Multiple Event](/chronicle/docs/detection/yara-l-2-0-overview#multiple_event_rule) rules.\n- **Total Rules Quota** : Displays the current total count of rules enabled as live across all [rule types](#rule-types) and the maximum number of rules that can be enabled as live.\n\n| **Note:** Google SecOps indicates if you're over your rule quota in the **Rules Capacity** dialog. You won't be able to enable additional live rules until you reduce the number of enabled live rules.\n\nRules executions\n----------------\n\nLive rules executions for a given event time bucket are triggered with decreasing frequency. A final cleanup run occurs, after which no further executions start.\n\nEach execution runs over the latest versions of [reference lists](/chronicle/docs/reference/reference-lists) used in the rules, and against the latest [event and entity data enrichment](/chronicle/docs/event-processing/data-enrichment).\n\nSome detections can be retrospectively generated if they're detected only by later executions. For example, the last execution might use the latest version of the reference list, which now detects more events, and events and entity data can be reprocessed due to new enrichments.\n| **Note:** Rules trigger detections based on UDM events available when the rule runs. The system creates new detections when additional events arrive, but does not update existing detections.\n\n### Deduplication\n\nGoogle SecOps automatically identifies and removes duplicate detections from rules. This process applies only to rules with match variables, as they rely on time-based windows. Detections with identical match variable values, within overlapping time windows, are suppressed as duplicates.\n\nGoogle SecOps treats each rule version as distinct, new logic. As a result, when a rule is updated, it can trigger repeated detections based on past events. These detections are not removed, even if they appear to be duplicates.\n\nDetection latencies\n-------------------\n\nVarious factors determine how long it takes for a detection to be generated from a live rule. The following list includes the different factors that contribute to detection delays:\n\n- [Rule types](#rule-types)\n- [Run frequency](#run-frequency)\n- [Ingestion delay](#ingestion-delay)\n- [Contextual joins](#contextual-joins)\n- [Enriched UDM data](#enriched-udm-data)\n- [Timezone issues](#timezone-issues)\n- [Reference lists](#reference-lists)\n\n### Rule types\n\n- [Single-event rules](/chronicle/docs/detection/yara-l-2-0-overview#single-event-rule) are executed near-real time in a streaming approach. Use these rules, when possible, to minimize latency.\n- [Multi-event rules](/chronicle/docs/detection/yara-l-2-0-overview#multi-event-rule) execute on a scheduled basis, which results in higher latency due to the time between scheduled runs.\n\n### Run frequency\n\nTo achieve faster detections, use a shorter run frequency and smaller match window. Using shorter match windows (under one hour) enables more frequent runs.\n\n### Ingestion delay\n\nVerify that data is sent to Google Security Operations as soon as the event occurs. When reviewing a detection, carefully check the UDM event and ingestion timestamps.\n\n### Contextual joins\n\nMulti-event rules that use contextual data, such as UEBA or Entity Graph, might experience higher delays. The contextual data must first be generated by Google SecOps.\n\n### Enriched UDM data\n\nGoogle SecOps enriches events with data from other events. To identify if a rule is evaluating an enriched field, review the [Event Viewer](/chronicle/docs/investigation/udm-search#event-viewer). If the rule is evaluating an enriched field, the detection might be delayed.\n\n### Timezone issues\n\nRules execute more frequently for real-time data. Data might arrive in real-time, but Google SecOps might still treat it as late-arriving if the event time is incorrect due to timezone discrepancies.\n\nThe Google SecOps SIEM default timezone is UTC. If the original data has an event timestamp set to another timezone besides UTC, update the data timezone. If updating the timezone at the log source is not possible, then contact [Support](/chronicle/docs/getting-support), to override the timezone.\n\n### Non-existence rules\n\nRules that check for [non-existence](/chronicle/docs/detection/yara-l-2-0-syntax#bounded_and_unbounded_conditions) (for example, rules that contain `!$e` or `#e=0`) are executed with a minimum delay of one hour to verify that data has time to arrive.\n\n### Reference lists\n\nRule executions always use the most up-to-date version of a reference list. If the reference list was recently updated, a new detection might appear late. This happens because the detection might only be included in new contents of the updated list during later executions of the scheduled rule.\n\nTo achieve lower detection latencies, we recommend doing the following:\n\n- Send log data to Google SecOps as soon as the event occurs.\n- Review the audit rules to determine if it is necessary to use non-existence or context-enriched data.\n- Configure a smaller [run frequency](/chronicle/docs/detection/run-frequency).\n\nRule status\n-----------\n\nLive rules can have one of the following statuses:\n\n- **Enabled:** Rule is active and working normally as a live rule.\n\n- **Disabled:** Rule is disabled.\n\n- **Limited:** Live rules can be set to this status when they show\n unusually high resource usage. **Limited** rules are isolated from the other live\n rules in the system to maintain the stability of Google SecOps.\n\n For **Limited** live rules, successful rule executions aren't always possible.\n However, if the rule execution succeeds, detections are retained and available\n for you to review. **Limited** live rules always generate an error message,\n which includes recommendations about how to improve the performance of the rule.\n\n If the performance of a **Limited** rule doesn't improve within 3 days, its\n status is changed to **Paused**.\n\n **Note**: If there've been no recent changes to this rule, the errors might be intermittent\n and could resolve automatically.\n- **Paused:** Live rules enter this status when they've been in **Limited**\n status for 3 days and haven't shown any performance improvement. Executions for\n this rule have been paused and error messages with suggestions on how to\n improve the rule's performance are returned.\n\nTo return any live rule to the **Enabled** status, follow\n[YARA-L best practices](/chronicle/docs/detection/yara-l-best-practices) to\noptimize its performance of your rule and save the changes. After the rule has been saved,\nthe rule is reset to the **Enabled** state, and it will take at least an hour\nbefore it reaches the **Limited** status again.\n\nYou can potentially resolve performance issues with a rule by configuring it\nto run less frequently. For example, you could reconfigure a rule from running\nevery 10 minutes to running once an hour or once every 24 hours. However,\nchanging the execution frequency of a rule won't change its status back to\n**Enabled** . If you make a small modification to the rule and save it, you can\nautomatically reset its status to **Enabled**.\n\nRule statuses are displayed in the **Rules Dashboard** and are also accessible\nthrough the Detection Engine API. Errors generated by rules in the **Limited**\nor **Paused** status are available using the\n[`ListErrors`](/chronicle/docs/reference/detection-engine-api#listerrors) API method.\nThe error indicates that the rule is either in the **Limited** or **Paused** status,\nand provides a link to documentation on how to resolve the issue.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]
