알림 실행 상태 확인 누락된 알림 해결 규칙 상태 확인 쿼리에서 오프셋을 사용하여 수집 지연 처리 일반적인 문제 및 해결 방법 규칙 평가 모범 사례

규칙 평가 문제 해결

이 가이드는 Amazon Managed Service for Prometheus(AMP)의 규칙 평가와 관련된 일반적인 문제에 대한 step-by-step 문제 해결 절차를 제공합니다. 다음 절차에 따라 알림 및 기록 규칙 문제를 진단하고 해결합니다.

주제

알림 실행 상태 확인
누락된 알림 해결
규칙 상태 확인
쿼리에서 오프셋을 사용하여 수집 지연 처리
일반적인 문제 및 해결 방법
규칙 평가 모범 사례

알림 실행 상태 확인

규칙 평가 문제를 해결할 때 먼저 합성 시계열를 쿼리하여 알림이 실행되었는지 확인합니다ALERTS. ALERTS 시계열에는 다음 레이블이 포함됩니다.

alertname - 알림의 이름입니다.
alertstate - 보류 중이거나 실행 중입니다.
- pending - 알림이 for절에 지정된 기간 동안 대기 중입니다.
- 실행 - 알림이 지정된 기간 동안 조건을 충족했습니다. 추가 레이블은 알림 규칙에 정의되어 있습니다.

참고

알림이 실행 중이거나 보류 중인 동안 샘플 값은 1입니다. 알림이 유휴 상태이면 샘플이 생성되지 않습니다.

누락된 알림 해결

알림이 실행 중이지만 알림이 도착하지 않는 경우 다음 Alertmanager 설정을 확인합니다.

Alertmanager 구성 확인 - 라우팅 수신기 및 설정이 올바르게 구성되었는지 확인합니다. 알림 실행에 영향을 미칠 수 있는 대기 시간, 시간 간격 및 필수 레이블을 포함한 라우팅 블록 설정을 검토합니다. 알림 규칙을 해당 경로 및 수신기와 비교하여 적절한 일치를 확인합니다. 가 있는 경로의 경우 타임스탬프가 지정된 간격 내에 있는지 time_interval확인합니다.
알림 수신기 권한 확인 - Amazon SNS 주제를 사용할 때 AMP에 알림을 게시하는 데 필요한 권한이 있는지 확인합니다. 자세한 내용은 Amazon Managed Service for Prometheus에 Amazon SNS 주제로 알림 메시지를 전송할 수 있는 권한 부여 단원을 참조하십시오.
수신자 페이로드 호환성 검증 - 알림 수신자가 Alertmanager의 페이로드 형식을 수락하는지 확인합니다. Amazon SNS 요구 사항은 섹션을 참조하세요Amazon SNS 메시지 검증 규칙 이해.
Alertmanager 로그 검토 - AMP는 알림 문제를 디버깅하는 데 도움이 되도록 Alertmanager의 판매 로그를 제공합니다. 자세한 내용은 CloudWatch Logs를 사용하여 Amazon Managed Service for Prometheus 이벤트 모니터링 단원을 참조하십시오.

Alertmanager에 대한 자세한 내용은 섹션을 참조하세요알림 관리자를 사용하여 Amazon Managed Service for Prometheus에서 알림 관리 및 전달.

규칙 상태 확인

규칙이 잘못되면 평가 실패가 발생할 수 있습니다. 다음 방법을 사용하여 규칙이 평가되지 않은 이유를 식별합니다.

ListRules API 사용

ListRules 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
          }
        ]
      }
    ]
  }
}

벤딩된 로그 사용

ListRules API에는 최신 정보만 표시됩니다. 자세한 기록을 보려면 워크스페이스에서 판매 로그를 활성화하여 다음에 액세스하세요.

평가 실패의 타임스탬프
자세한 오류 메시지
과거 평가 데이터

벤딩된 로그 메시지의 예:


{
  "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"
}

Ruler 또는 Alertmanager의 로그에 대한 자세한 예는 규칙 관리자 문제 해결 및 섹션을 참조하세요알림 관리자를 사용하여 Amazon Managed Service for Prometheus에서 알림 관리 및 전달.

쿼리에서 오프셋을 사용하여 수집 지연 처리

기본적으로 표현식은 평가 시점의 값을 사용하여 오프셋(인스턴트 쿼리) 없이 평가됩니다. 지표 수집이 지연되는 경우 기록 규칙은 모든 지표를 수집한 후 표현식을 수동으로 평가할 때와 동일한 값을 나타내지 않을 수 있습니다.

작은 정보

오프셋 한정자를 사용하면 수집 지연으로 인한 문제를 줄일 수 있습니다. 자세한 내용은 Prometheus 설명서의 오프셋 한정자를 참조하세요.

규칙이 12:00에 평가되지만 수집 지연으로 인해 지표의 최신 샘플이 11:45부터인 경우 규칙은 12:00 타임스탬프에서 샘플을 찾지 못합니다. 이를 완화하려면와 같은 오프셋을 추가합니다my_metric_name offset 15m .

지표가 두 서버와 같은 서로 다른 소스에서 시작된 경우 서로 다른 시간에 수집될 수 있습니다. 이를 완화하려면 다음과 같은 표현식을 형성합니다. metric_from_server_A / metric_from_server_B

규칙이 서버 A와 서버 B의 수집 시간 간에 평가되면 예상치 못한 결과가 발생합니다. 오프셋을 사용하면 평가 시간을 정렬하는 데 도움이 될 수 있습니다.

일반적인 문제 및 해결 방법

규칙 데이터 기록의 차이

수동 평가와 비교하여 기록 규칙 데이터에 차이가 있는 경우(쿼리 API 또는 UI를 통해 기록 규칙의 원래 PromQL 표현식을 직접 실행하는 경우) 다음 중 하나 때문일 수 있습니다.

긴 평가 시간 - 규칙 그룹에는 여러 개의 동시 평가가 있을 수 없습니다. 평가 시간이 구성된 간격을 초과하면 후속 평가가 누락될 수 있습니다. 구성된 간격을 초과하여 연속으로 누락된 평가가 여러 번 있으면 기록 규칙이 오래될 수 있습니다. 자세한 내용은 Prometheus 설명서의 Staleness를 참조하세요. CloudWatch 지표를 사용하여 평가 기간을 모니터링RuleGroupLastEvaluationDuration하여 평가하는 데 너무 오래 걸리는 규칙 그룹을 식별할 수 있습니다.
누락된 평가 모니터링 - AMP는 평가를 건너뛸 때 추적할 RuleGroupIterationsMissed CloudWatch 지표를 제공합니다. ListRules API는 각 규칙/그룹의 평가 시간과 마지막 평가 시간을 표시하므로 누락된 평가 패턴을 식별하는 데 도움이 될 수 있습니다. 자세한 내용은 ListRules 단원을 참조하십시오.

권장 사항: 규칙을 별도의 그룹으로 분할

평가 기간을 줄이려면 규칙을 별도의 규칙 그룹으로 분할합니다. 그룹 내 규칙은 순차적으로 실행되는 반면, 규칙 그룹은 병렬로 실행할 수 있습니다. 동일한 그룹에서 서로 의존하는 관련 규칙을 유지합니다. 일반적으로 규칙 그룹이 작을수록 평가 일관성이 향상되고 격차가 줄어듭니다.

규칙 평가 모범 사례

규칙 그룹 크기 최적화 - 일관된 평가를 위해 규칙 그룹을 작게 유지합니다. 관련 규칙을 그룹화하되 큰 규칙 그룹은 사용하지 마세요.
적절한 평가 간격 설정 - 시기 적절한 알림과 시스템 로드 간의 균형을 맞춥니다. 모니터링되는 지표의 안정성 패턴을 검토하여 정상 변동 범위를 파악합니다.
지연 지표에 오프셋 한정자 사용 - 수집 지연을 보정하기 위해 오프셋을 추가합니다. 관찰된 수집 패턴을 기반으로 오프셋 기간을 조정합니다.
평가 성능 모니터링 - RuleGroupIterationsMissed 지표를 추적합니다. ListRules API에서 평가 시간을 검토합니다.
규칙 표현식 검증 - 표현식이 규칙 정의와 수동 쿼리 간에 정확히 일치하는지 확인합니다. 시간 범위가 다른 표현식을 테스트하여 동작을 이해합니다.
규칙 상태를 정기적으로 검토 - 규칙 평가에서 오류가 있는지 확인합니다. 벤딩된 로그에서 반복되는 문제를 모니터링합니다.

이러한 문제 해결 단계와 모범 사례를 따르면 Amazon Managed Service for Prometheus에서 규칙 평가와 관련된 일반적인 문제를 식별하고 해결할 수 있습니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

규칙 파일 편집

규칙 관리자 문제 해결