기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 규칙을 사용하여 지표가 수신될 때 지표 수정 또는 모니터링
Amazon Managed Service for Prometheus에서 지표를 수신할 때 지표에 따라 작업하도록 규칙을 설정할 수 있습니다. 이러한 규칙은 지표를 모니터링하거나 수신된 지표를 기반으로 계산된 새 지표를 생성할 수도 있습니다.
Amazon Managed Service for Prometheus는 정기적으로 평가하는 두 가지 유형의 **규칙을 지원합니다.
+ **기록 규칙을 사용하면 자주 필요하거나 계산 비용이 많이 드는 식을 미리 계산하고, 해당 결과를 새로운 시계열 세트로 저장할 수 있습니다. 미리 계산된 결과를 쿼리하는 것이 필요할 때마다 원래 식을 실행하는 것보다 훨씬 빠른 경우가 많습니다.
+ **알림 규칙을 사용하면 PromQL 및 임곗값을 기준으로 알림 조건을 정의할 수 있습니다. 규칙이 임곗값을 트리거하면 [알림 관리자](AMP-alert-manager.md)에게 알림이 전송되고 알림 관리자는 규칙을 관리하도록 구성하거나 이 알림을 다운스트림으로 Amazon Simple Notification Service 등의 수신기에 전달할 수 있습니다.
Amazon Managed Service for Prometheus에서 규칙을 사용하려면 규칙을 정의하는 하나 이상의 YAML 규칙 파일을 생성합니다. Amazon Managed Service for Prometheus 규칙 파일은 독립형 Prometheus의 규칙 파일과 형식이 동일합니다. 자세한 내용은 Prometheus 설명서의 [기록 규칙 정의](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) 및 [알림 규칙](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)을 참조하세요.
하나의 워크스페이스에 여러 규칙 파일을 둘 수 있습니다. 각각의 개별 규칙 파일은 별도의 **네임스페이스 내에 포함됩니다. 규칙 파일이 여러 개 있으면 기존 Prometheus 규칙 파일을 변경하거나 결합하지 않고도 워크스페이스로 가져올 수 있습니다. 규칙 그룹 네임스페이스마다 태그가 다를 수도 있습니다.
**규칙 시퀀싱**
규칙 파일 내에서 규칙은 **규칙 그룹 내에 포함됩니다. 규칙 파일의 단일 규칙 그룹 내 규칙은 항상 위에서 아래로 평가됩니다. 따라서 기록 규칙에서 하나의 기록 규칙 결과를 이후 기록 규칙을 계산할 때 사용하거나 동일한 규칙 그룹의 알림 규칙에 사용할 수 있습니다. 하지만 별도의 규칙 파일을 실행하는 순서는 지정할 수 없으므로 한 기록 규칙의 결과를 사용하여 다른 규칙 그룹이나 다른 규칙 파일의 규칙을 계산할 수는 없습니다.
**Topics**
+ [규칙 사용에 필요한 IAM 권한 이해](AMP-ruler-IAM-permissions.md)
+ [규칙 파일 생성](AMP-ruler-rulesfile.md)
+ [Amazon Managed Service for Prometheus에 규칙 구성 파일 업로드](AMP-rules-upload.md)
+ [규칙 구성 파일 편집 또는 교체](AMP-rules-edit.md)
+ [규칙 평가 문제 해결](troubleshoot-rule-evaluations.md)
+ [규칙 관리자 문제 해결](Troubleshooting-rule-fail-error.md)
# 규칙 사용에 필요한 IAM 권한 이해
Amazon Managed Service for Prometheus에서 사용자에게 규칙을 사용할 수 있는 권한을 부여해야 합니다. 다음 권한으로 AWS Identity and Access Management (IAM) 정책을 생성하고 사용자, 그룹 또는 역할에 정책을 할당합니다.
**참고**
IAM에 대한 자세한 내용은 [Amazon Managed Service for Prometheus용 Identity and Access Management](security-iam.md) 섹션을 참조하세요.
**규칙 사용에 대한 액세스 권한을 부여하는 정책**
다음 정책은 계정의 모든 리소스에 대한 규칙을 사용하기 위한 액세스 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aps:CreateRuleGroupsNamespace",
"aps:ListRuleGroupsNamespaces",
"aps:DescribeRuleGroupsNamespace",
"aps:PutRuleGroupsNamespace",
"aps:DeleteRuleGroupsNamespace"
],
"Resource": "*"
}
]
}
```
------
**한 네임스페이스에만 액세스 권한을 부여하는 정책**
특정 정책에 대해서만 액세스 권한을 부여하는 정책을 생성할 수도 있습니다. 다음 샘플 정책은 지정된 `RuleGroupNamespace`에 대해서만 액세스 권한을 부여합니다. 이 정책을 사용하려면 **, **, ** 및 **을 계정에 적합한 값으로 바꿉니다.
# 규칙 파일 생성
Amazon Managed Service for Prometheus에서 규칙을 사용하려면 규칙을 정의하는 규칙 파일을 생성합니다. Amazon Managed Service for Prometheus 규칙 파일은 독립형 Prometheus의 규칙 파일과 형식이 동일한 YAML 텍스트 파일입니다. 자세한 내용은 *Prometheus* 설명서의 [기록 규칙 정의](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) 및 [알림 규칙](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)을 참조하세요.
다음은 규칙 파일의 기본 예제입니다.
```
groups:
- name: cpu_metrics
interval: 60s
rules:
- record: avg_cpu_usage
expr: avg(rate(node_cpu_seconds_total[5m])) by (instance)
- alert: HighAverageCPU
expr: avg_cpu_usage > 0.8
for: 10m
keep_firing_for: 20m
labels:
severity: critical
annotations:
summary: "Average CPU usage across cluster is too high"
```
이 예제에서는 60초마다 평가되는 규칙 그룹 `cpu_metrics`를 생성합니다. 이 규칙 그룹은 `avg_cpu_usage`라는 기록 규칙을 사용하여 새 지표를 생성한 다음 이를 알림에 사용합니다. 다음 목록에서는 사용된 속성의 일부를 설명합니다. 포함할 수 있는 알림 규칙 및 기타 속성에 대한 자세한 내용은 *Prometheus 설명서*의 [알림 규칙](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)을 참조하세요.
+ `record: avg_cpu_usage` - 이 기록 규칙은 `avg_cpu_usage`라는 새 지표를 생성합니다.
+ `interval` 속성이 지정되지 않은 경우 규칙 그룹의 기본 평가 간격은 60초입니다.
+ `expr: avg(rate(node_cpu_seconds_total[5m])) by (instance)` - 기록 규칙에 대한 이 표현식은 `instance` 레이블별로 그룹화하여 각 노드의 지난 5분 동안의 평균 CPU 사용량을 계산합니다.
+ `alert: HighAverageCPU` - 이 알림 규칙은 `HighAverageCPU`라는 새 알림을 생성합니다.
+ `expr: avg_cpu_usage > 0.8 ` - 이 표현식은 평균 CPU 사용량이 80%를 초과하는 샘플을 알림에 표시합니다.
+ `for: 10m` - 평균 CPU 사용량이 최소 10분 동안 80%를 초과하는 경우에만 알림이 실행됩니다.
이 경우 지표는 최근 5분 동안의 평균으로 계산됩니다. 따라서 연속된 최소 두 개의 5분 샘플(총 10분)에서 평균 CPU 사용률이 80%를 초과할 경우에만 알림이 실행됩니다.
+ `keep_firing_for: 20m` – 이 알림은 샘플이 최소 20분 동안 임곗값 미만이 될 때까지 계속 실행됩니다. 이는 알림이 연속해서 반복적으로 오르내리는 것을 방지하는 데 유용할 수 있습니다.
**참고**
규칙 정의 파일을 로컬에서 생성한 다음 Amazon Managed Service for Prometheus에 업로드하거나 Amazon Managed Service for Prometheus 콘솔 내에서 직접 정의를 생성, 편집 및 업로드할 수 있습니다. 어느 쪽이든 동일한 형식 규칙이 적용됩니다. 파일 업로드 및 편집에 대한 자세한 내용은 [Amazon Managed Service for Prometheus에 규칙 구성 파일 업로드](AMP-rules-upload.md) 섹션을 참조하세요.
# Amazon Managed Service for Prometheus에 규칙 구성 파일 업로드
규칙 구성 파일에서 원하는 규칙이 무엇인지 알면 콘솔 내에서 해당 규칙을 생성 및 편집하거나 콘솔 또는 AWS CLI를 사용하여 파일을 업로드할 수 있습니다.
**참고**
Amazon EKS 클러스터를 실행하는 경우 [Kubernetes용AWS 컨트롤러](integrating-ack.md)를 사용하여 규칙 구성 파일을 업로드할 수도 있습니다.
**Amazon Managed Service for Prometheus 콘솔을 사용하여 규칙 구성을 편집하거나 바꾸고 네임스페이스를 생성하려면**
1. [https://console.aws.amazon.com/prometheus/](https://console.aws.amazon.com/prometheus/home)에서 Amazon Managed Service for Prometheus 콘솔을 엽니다.
1. 페이지 왼쪽 상단에서 메뉴 아이콘을 선택한 다음, **모든 워크스페이스**를 선택합니다.
1. 워크스페이스의 워크스페이스 ID를 선택한 다음, **규칙 관리** 탭을 선택합니다.
1. **네임스페이스 추가**를 선택합니다.
1. **파일 선택**을 선택하고 규칙 정의 파일을 선택합니다.
또는 **구성 정의**를 선택하여 Amazon Managed Service for Prometheus 콘솔에서 직접 규칙 정의 파일을 생성하고 편집할 수 있습니다. 이렇게 하면 업로드하기 전에 편집하는 샘플 기본 정의 파일이 생성됩니다.
1. (선택 사항) 네임스페이스에 태그를 추가하려면 **새 태그 추가**를 선택합니다.
그런 다음, **키**에서 태그 이름을 입력합니다. **값(Value)**에 태그의 선택적 값을 추가할 수 있습니다.
다른 태그를 추가하려면 **새 태그 추가**를 선택합니다.
1. **계속**을 선택합니다. Amazon Managed Service for Prometheus는 선택한 규칙 파일과 동일한 이름을 가진 새 네임스페이스를 생성합니다.
**AWS CLI 를 사용하여 알림 관리자 구성을 새 네임스페이스의 워크스페이스에 업로드하려면**
1. Base64는 알림 관리자 파일의 내용을 인코딩합니다. Linux에서 다음 명령을 사용할 수 있습니다.
```
base64 input-file output-file
```
macOS에서 다음 명령을 사용할 수 있습니다.
```
openssl base64 input-file output-file
```
1. 다음 명령 중 하나를 입력하여 네임스페이스를 생성하고 파일을 업로드합니다.
AWS CLI 버전 2에서 다음을 입력합니다.
```
aws amp create-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region
```
AWS CLI 버전 1에서 다음을 입력합니다.
```
aws amp create-rule-groups-namespace --data fileb://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region
```
1. 알림 관리자 구성이 활성화되는 데 몇 초 정도 걸립니다. 상태를 확인하려면 다음 명령을 입력합니다.
```
aws amp describe-rule-groups-namespace --workspace-id workspace_id --name namespace-name --region region
```
`status`가 `ACTIVE`이면 규칙 파일이 적용된 것입니다.
# 규칙 구성 파일 편집 또는 교체
Amazon Managed Service for Prometheus에 이미 업로드한 규칙 파일의 규칙을 변경하려면 새 규칙 파일을 업로드하여 기존 구성을 교체하거나 콘솔에서 직접 현재 구성을 편집할 수 있습니다. 선택적으로 현재 파일을 다운로드하고 텍스트 편집기에서 편집한 다음, 새 버전을 업로드할 수 있습니다.
**Amazon Managed Service for Prometheus 콘솔을 사용하여 규칙 구성을 편집하려면**
1. [https://console.aws.amazon.com/prometheus/](https://console.aws.amazon.com/prometheus/home)에서 Amazon Managed Service for Prometheus 콘솔을 엽니다.
1. 페이지 왼쪽 상단에서 메뉴 아이콘을 선택한 다음, **모든 워크스페이스**를 선택합니다.
1. 워크스페이스의 워크스페이스 ID를 선택한 다음, **규칙 관리** 탭을 선택합니다.
1. 편집하려는 규칙 구성 파일의 이름을 선택합니다.
1. (선택 사항) 현재 규칙 구성 파일을 다운로드하려면 **다운로드** 또는 **복사**를 선택합니다.
1. 콘솔 내에서 구성을 직접 편집하려면 **수정**을 선택합니다. 완료되면 **저장**을 선택합니다.
또는 **구성 교체**를 선택하여 새 구성 파일을 업로드할 수 있습니다. 이 경우 새 규칙 정의 파일을 선택하고 **계속**을 선택하여 파일을 업로드합니다.
**AWS CLI 를 사용하여 규칙 구성 파일을 편집하려면**
1. Base64는 규칙 파일의 내용을 인코딩합니다. Linux에서 다음 명령을 사용할 수 있습니다.
```
base64 input-file output-file
```
macOS에서 다음 명령을 사용할 수 있습니다.
```
openssl base64 input-file output-file
```
1. 다음 명령 중 하나를 입력하여 새 파일을 업로드합니다.
AWS CLI 버전 2에서 다음을 입력합니다.
```
aws amp put-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region
```
AWS CLI 버전 1에서 다음을 입력합니다.
```
aws amp put-rule-groups-namespace --data fileb://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region
```
1. 규칙 파일이 활성화되는 데 몇 초 정도 걸립니다. 상태를 확인하려면 다음 명령을 입력합니다.
```
aws amp describe-rule-groups-namespace --workspace-id workspace_id --name namespace-name --region region
```
`status`가 `ACTIVE`이면 규칙 파일이 적용된 것입니다. 그때까지는 이 규칙 파일의 이전 버전이 계속 활성 상태입니다.
# 규칙 평가 문제 해결
이 안내서에서는 Amazon Managed Service for Prometheus(AMP)의 규칙 평가와 관련된 일반적인 문제에 대한 단계별 문제 해결 절차를 제공합니다. 다음 절차에 따라 알림 및 기록 규칙 문제를 진단하고 해결합니다.
**Topics**
+ [알림 실행 상태 확인](#troubleshoot-rule-validate-firing-status)
+ [누락된 알림 해결](#troubleshoot-rule-missing-alert-notifications)
+ [규칙 상태 확인](#troubleshoot-rule-check-health-status)
+ [쿼리에서 오프셋을 사용하여 수집 지연 처리](#troubleshoot-rule-offset-queries)
+ [일반적인 문제 및 해결 방법](#troubleshoot-rule-common-issues)
+ [규칙 평가 모범 사례](#troubleshoot-rule-best-practices)
## 알림 실행 상태 확인
규칙 평가 문제를 해결할 때 먼저 합성 시계열 `ALERTS`를 쿼리하여 알림이 실행되었는지 확인합니다. `ALERTS` 시계열에는 다음 레이블이 포함됩니다.
+ **alertname** - 알림의 이름입니다.
+ **alertstate** - **pending** 또는 **firing**입니다.
+ **pending** - 알림이 `for` 절에 지정된 기간 동안 대기 중입니다.
+ **firing** - 알림이 지정된 기간 동안 조건을 충족했습니다. 추가 레이블은 알림 규칙에 정의되어 있습니다.
**참고**
알림이 **firing** 또는 **pending** 상태인 동안 샘플 값은 **1**입니다. 알림이 유휴 상태이면 샘플이 생성되지 않습니다.
## 누락된 알림 해결
알림이 실행 중이지만 알림이 도착하지 않은 경우 다음 Alertmanager 설정을 확인합니다.
1. **Alertmanager 구성 확인** - 라우팅 수신기 및 설정이 올바르게 구성되었는지 확인합니다. 대기 시간, 시간 간격 및 필수 레이블을 포함하여 알림 실행에 영향을 미칠 수 있는 라우팅 블록 설정을 검토합니다. 알림 규칙을 해당 라우팅 및 수신기와 비교하여 적절한 매칭을 확인합니다. `time_interval`이 지정된 경로의 경우 타임스탬프가 지정된 간격 내에 있는지 확인합니다.
1. **알림 수신기 권한 확인** - Amazon SNS 주제를 사용할 때 AMP에 알림을 게시하는 데 필요한 권한이 있는지 확인합니다. 자세한 내용은 [Amazon Managed Service for Prometheus에 Amazon SNS 주제로 알림 메시지를 전송할 수 있는 권한 부여](AMP-alertmanager-receiver-AMPpermission.md) 단원을 참조하십시오.
1. **수신자 페이로드 호환성 검증** - 알림 수신자가 Alertmanager의 페이로드 형식을 수락하는지 확인합니다. Amazon SNS 요구 사항은 [Amazon SNS 메시지 검증 규칙 이해](AMP-alertmanager-receiver-validation-truncation.md) 섹션을 참조하세요.
1. **Alertmanager 로그 검토** - AMP는 알림 문제를 디버깅하는 데 도움이 되도록 Alertmanager의 제공형 로그를 제공합니다. 자세한 내용은 [CloudWatch Logs를 사용하여 Amazon Managed Service for Prometheus 이벤트 모니터링](CW-logs.md) 단원을 참조하십시오.
Alertmanager에 대한 자세한 내용은 [알림 관리자를 사용하여 Amazon Managed Service for Prometheus에서 알림 관리 및 전달](AMP-alert-manager.md) 섹션을 참조하세요.
## 규칙 상태 확인
잘못된 형식의 규칙으로 인해 평가 오류가 발생할 수 있습니다. 다음 방법을 사용하면 규칙 평가 실패 원인을 확인할 수 있습니다.
**Example**
**ListRules API 사용**
[ListRules](AMP-APIReference-ListRules.md) API는 규칙 상태에 대한 정보를 제공합니다. `health` 및 `lastError` 필드에서 문제를 진단할 수 있습니다.
**응답 예제:**
```
{
"status": "success",
"data": {
"groups": [
{
"name": "my_rule_group",
"file": "my_namespace",
"rules": [
{
"state": "firing",
"name": "broken_alerting_rule",
"query": "...",
"duration": 0,
"keepFiringFor": 0,
"labels": {},
"annotations": {},
"alerts": [],
"health": "err",
"lastError": "vector contains metrics with the same labelset after applying alert labels",
"type": "alerting",
"lastEvaluation": "1970-01-01T00:00:00.00000000Z",
"evaluationTime": 0.08
}
]
}
]
}
}
```
**Example**
**제공형 로그 사용**
ListRules API에는 최신 정보만 표시됩니다. 자세한 기록을 보려면 워크스페이스에서 [제공형 로그](CW-logs.md)를 활성화하여 다음 항목에 액세스하세요.
+ 평가 실패의 타임스탬프
+ 상세 오류 메시지
+ 과거 평가 데이터
**제공형 로그 메시지의 예:**
```
{
"workspaceId": "ws-a2c55905-e0b4-4065-a310-d83ce597a391",
"message": {
"log": "Evaluating rule failed, name=broken_alerting_rule, group=my_rule_group, namespace=my_namespace, err=vector contains metrics with the same labelset after applying alert labels",
"level": "ERROR",
"name": "broken_alerting_rule",
"group": "my_rule_group",
"namespace": "my_namespace"
},
"component": "ruler"
}
```
규칙 관리자 또는 Alertmanager의 더 많은 예시를 보려면 [규칙 관리자 문제 해결](Troubleshooting-rule-fail-error.md) 및 [알림 관리자를 사용하여 Amazon Managed Service for Prometheus에서 알림 관리 및 전달](AMP-alert-manager.md) 섹션을 참조하세요.
## 쿼리에서 오프셋을 사용하여 수집 지연 처리
기본적으로 표현식은 평가 시점의 값을 사용하여 오프셋 없이(즉시 쿼리) 평가됩니다. 지표 수집이 지연되는 경우 기록 규칙이 모든 지표를 수집한 후 표현식을 수동으로 평가할 때와 동일한 값을 나타내지 못할 수 있습니다.
**작은 정보**
오프셋 한정자를 사용하면 수집 지연으로 인한 문제를 줄일 수 있습니다. 자세한 내용은 Prometheus 설명서에서 [Offset modifier](https://prometheus.io/docs/prometheus/latest/querying/basics/#offset-modifier)를 참조하세요**.
### 예: 지연된 지표 처리
규칙이 12:00에 평가되지만 수집 지연으로 지표의 최신 샘플이 11:45인 경우 규칙은 12:00 타임스탬프에 해당하는 샘플을 찾지 못합니다. 이를 완화하려면 **my\$1metric\$1name offset 15m **과 같은 오프셋을 추가합니다.
### 예: 여러 소스의 지표 처리
지표가 서로 다른 소스(예: 두 서버)에서 생성된 경우 서로 다른 시간에 수집될 수 있습니다. 이를 완화하려면 **metric\$1from\$1server\$1A / metric\$1from\$1server\$1B **와 같은 표현식을 구성합니다.
규칙이 서버 A와 서버 B의 수집 시간 사이에 평가되면 예상치 못한 결과가 발생할 수 있습니다. 오프셋을 사용하면 평가 시간을 맞추는 데 도움이 될 수 있습니다.
## 일반적인 문제 및 해결 방법
**기록 규칙 데이터의 차이**
수동 평가(쿼리 API 또는 UI를 통해 기록 규칙의 원래 PromQL 표현식을 직접 실행하는 경우)와 비교하여 기록 규칙 데이터에 차이가 발견된다면 다음 중 하나가 원인일 수 있습니다.
1. **긴 평가 시간** - 하나의 규칙 그룹에서 여러 평가를 동시에 수행할 수 없습니다. 평가 시간이 구성된 간격을 초과하면 이후 평가가 누락될 수 있습니다. 구성된 간격을 초과하여 평가가 여러 번 연속으로 누락되면 기록 규칙이 무효 상태가 될 수 있습니다. 자세한 내용은 Prometheus 설명서에서 [Staleness](https://prometheus.io/docs/prometheus/latest/querying/basics/#staleness)를 참조하세요**. CloudWatch 지표 `RuleGroupLastEvaluationDuration`으로 평가 기간을 모니터링하면 평가하는 데 너무 오래 걸리는 규칙 그룹을 식별할 수 있습니다.
1. **평가 누락 모니터링** - AMP는 평가 누락 시점을 추적하기 위해 `RuleGroupIterationsMissed` CloudWatch 지표를 제공합니다. ListRules API는 각 규칙/그룹의 평가 시간과 마지막 평가 시간을 표시하므로 누락된 평가 패턴을 식별하는 데 도움이 될 수 있습니다. 자세한 내용은 [ListRules](AMP-APIReference-ListRules.md) 단원을 참조하십시오.
**권장 사항: 규칙을 별도의 그룹으로 분할**
평가 기간을 줄이려면 규칙을 별도의 규칙 그룹으로 분할합니다. 그룹 내 규칙은 순차적으로 실행되지만, 규칙 그룹은 병렬로 실행될 수 있습니다. 서로 의존하는 관련 규칙들은 같은 그룹에 포함시킵니다. 일반적으로 규칙 그룹이 작을수록 평가 일관성이 향상되고 차이가 줄어듭니다.
## 규칙 평가 모범 사례
1. **규칙 그룹 크기 최적화** - 일관된 평가가 가능하도록 규칙 그룹을 작게 유지합니다. 관련 규칙을 그룹화하되 큰 규칙 그룹은 사용하지 마세요.
1. **적절한 평가 간격 설정** - 시기 적절한 알림과 시스템 로드 간의 균형을 맞춥니다. 모니터링되는 지표의 안정성 패턴을 검토하여 정상 변동 범위를 파악합니다.
1. **지연된 지표에 오프셋 한정자 사용** - 수집 지연을 보정할 오프셋을 추가합니다. 관찰된 수집 패턴에 따라 오프셋 기간을 조정합니다.
1. **평가 성능 모니터링** - `RuleGroupIterationsMissed` 지표를 추적합니다. ListRules API에서 평가 시간을 검토합니다.
1. **규칙 표현식 검증** - 표현식이 규칙 정의와 수동 쿼리 간에 정확히 일치하는지 확인합니다. 다양한 시간 범위의 표현식을 테스트하여 동작을 이해합니다.
1. **정기적으로 규칙 상태 검토** - 규칙 평가에서 오류가 있는지 확인합니다. 제공형 로그에서 반복되는 문제를 모니터링합니다.
이러한 문제 해결 단계와 모범 사례를 따르면 Amazon Managed Service for Prometheus에서 규칙 평가와 관련된 일반적인 문제를 식별하고 해결할 수 있습니다.
# 규칙 관리자 문제 해결
[CloudWatch Logs를 사용하여 Amazon Managed Service for Prometheus 이벤트 모니터링](CW-logs.md)을 사용하여 알림 관리자 및 규칙 관리자 관련 문제를 해결할 수 있습니다. 이 섹션에는 규칙 관리자 관련 문제 해결 항목이 포함되어 있습니다.
**
**로그에 다음과 같은 규칙 관리자 실패 오류가 포함된 경우**
```
{
"workspaceId": "ws-12345c67-89c0-4d12-345b-f14db70f7a99",
"message": {
"log": "Evaluating rule failed, name=failure, group=canary_long_running_vl_namespace, namespace=canary_long_running_vl_namespace, err=found duplicate series for the match group {dimension1=\\\"1\\\"} on the right hand-side of the operation: [{__name__=\\\"fake_metric2\\\", dimension1=\\\"1\\\", dimension2=\\\"b\\\"}, {__name__=\\\"fake_metric2\\\", dimension1=\\\"1\\\", dimension2=\\\"a\\\"}];many-to-many matching not allowed: matching labels must be unique on one side",
"level": "ERROR",
"name": "failure",
"group": "canary_long_running_vl_namespace",
"namespace": "canary_long_running_vl_namespace"
},
"component": "ruler"
}
```
규칙을 실행하는 동안 오류가 발생했음을 의미합니다.
**취할 조치**
오류 메시지를 사용하여 규칙 실행 문제를 해결합니다.