기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 규칙 평가 문제 해결
이 안내서에서는 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에서 규칙 평가와 관련된 일반적인 문제를 식별하고 해결할 수 있습니다.