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

규칙 평가 문제 해결

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

주제

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

알림 실행 상태 확인

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

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

참고

알림이 firing 또는 pending 상태인 동안 샘플 값은 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"
}

규칙 관리자 또는 Alertmanager의 더 많은 예시를 보려면 규칙 관리자 문제 해결 및 알림 관리자를 사용하여 Amazon Managed Service for Prometheus에서 알림 관리 및 전달 섹션을 참조하세요.

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

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

작은 정보

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

규칙이 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가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

규칙 파일 편집

규칙 관리자 문제 해결