IncidentRelay v2.3.1에 대한 작업 예시(에 확인됨) 아래의 이름, 식별자 및 타이밍은 예시입니다. 프로덕션 자격 증명을 사용하기 전에 테스트 배포에서 이를 검증하세요.
비즈니스 예 · 설정 · 실제 예 · 승인 확인 · 한계 및 실패 모드
비즈니스 예: 세 개의 클라이언트 시스템, 하나의 시끄러운 지원 채팅
고객 사례 연구가 아닌 예시 시나리오입니다. 아래 지표는 측정된 절감액이나 IR에 모든 보고 대시보드가 포함되어 있다는 주장이 아니라 파일럿을 위한 제안 사항입니다.
상황 및 위험. 서비스 제공업체는 각각 애플리케이션 및 인프라 알림이 포함된 3개의 클라이언트를 지원합니다. 모든 것이 한 번의 채팅으로 이루어집니다. 반복되는 경고로 인해 원본 보고서가 묻혀지는 동안 엔지니어는 메시지를 다른 팀에 전달합니다. 모니터링을 통해 장애가 즉시 감지된 경우에도 소유권이 지연되고 지원 노력을 피할 수 있다는 것이 비즈니스 위험입니다.
IR을 사용한 워크플로. 각 클라이언트 서비스를 담당 팀에 매핑하고 각 발신자에 대해 의도한 경로 토큰을 사용합니다. 환경과 서비스 라벨을 일치시키고, 의도한 소유권 경계 내에서만 통화 중 대상과 그룹 반복을 선택합니다. 패턴을 확장하기 전에 아래 일치자를 사용하여 한 클라이언트의 프로덕션 청구 서비스를 시험해 보십시오.
검증을 통한 운영상의 이점. 일상적인 메시지 전달을 명시적 라우팅으로 대체합니다. 여러 호스트가 동일한 문제를 보고하는 경우 별도의 하위 경고를 유지하면서 조치를 취할 수 있는 팀의 첫 번째 응답을 유지하세요.
측정 대상. 첫 번째 라우팅 결정 후 재할당된 경고, 소유자가 없는 그룹 및 각 클라이언트의 기본 오류별 알림을 계산합니다. 거부되거나 일치하지 않는 테스트 이벤트도 검토합니다. 클라이언트의 중단이 눈에 띄지 않으면 페이지 수를 줄이는 것은 성공이 아닙니다.
경계. 라벨 일치는 고객 데이터 격리가 아닙니다. 액세스 권한, 자격 증명 및 배포 경계를 별도로 검토하세요. 일관되지 않은 레이블이나 지나치게 광범위한 그룹화는 여전히 잘못된 팀에 작업을 보내거나 관련 없는 증상을 결합할 수 있습니다. 다른 클라이언트를 온보딩하기 전에 해당 사례를 검증하십시오.
별도의 섭취, 소유 및 배송
프로덕션 청구 서비스와 스테이징 사본이 실수로 같은 사람을 깨워서는 안 됩니다. 첫 번째 파일럿에서는 프로덕션 청구 팀을 위한 웹후크 경로를 생성하고 기본 서비스와 순환 또는 정책을 선택하고 채널을 연결합니다. 수입 토큰이 경로를 선택합니다. 일치하는 레이블만으로는 발신자를 인증하거나 임의의 경로를 선택하지 않습니다.
좁은 경로 일치자와 명시적인 그룹화 키
이것을 경로의 일치 편집기에 붙여넣습니다. 들어오는 웹훅 본문이 아닌 일치자 개체입니다. 모든 조건은 AND 의미 체계를 사용합니다. 프로덕션 및 서비스 레이블을 요구하면 스테이징 및 레이블이 없는 이벤트가 이 경로에서 제외됩니다.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}이 예에서는 경로의 group_by 필드를 다음과 같이 설정합니다.
["alertname", "severity", "labels.cluster"]동일한 클러스터에서 동일한 경고를 보고하는 두 호스트는 별도의 하위 ID를 유지하면서 AlertGroup을 공유할 수 있습니다. 일반 웹훅의 경우 billing:node-1:health 및 billing:node-2:health와 같은 안정적인 지문을 사용하세요. 실패 및 복구에 예상되는 레이블을 포함하고 모든 재시도의 ID로 새 타임스탬프를 사용하지 마십시오.
중복 제거와 그룹화는 다릅니다. 동일한 지문이 하위 항목을 업데이트합니다. 동일한 그룹 키를 가진 다른 지문은 한 그룹에 별도의 하위 항목을 만듭니다. 경로, 팀, 소스 및 서비스도 범위 그룹화입니다. 각 호스트가 별도의 그룹이어야 하는 경우에만 그룹화 필드에 instance를 추가하세요.
한 명의 발신자가 실제로 여러 팀에 서비스를 제공하는 경우
이벤트 콘텐츠에서 소유권을 선택해야 하는 경우 글로벌 조정을 사용하세요. 빌더에서 labels.environment equals production 및 labels.service equals billing-api 조건으로 시작한 다음 동일한 그룹에서 유효한 팀, 경로 및 서비스 개체를 선택합니다. 설치 간에 숫자 개체 ID를 복사하지 마십시오.
일치 및 비일치 모두 검증 및 시뮬레이션하고 게시한 다음 hybrid 호환성이 있는 shadow를 사용합니다. active로 전환하기 전에 실제 실행을 검토하세요. 프로덕션 동작을 변경하지 않고 결정 사항을 섀도우 기록합니다. 시뮬레이터는 엔드 투 엔드 전달을 증명하지 않습니다.
작은 라우팅 테스트 매트릭스 사용
| 입력 | 이 예의 예상 결과 |
|---|---|
| 생산과금 이벤트 | Matcher가 패스합니다. 선택한 서비스, 담당자 및 채널이 계획된 소유권과 일치합니다. |
| 서비스 라벨 준비 또는 누락 | Matcher가 통과하지 못했습니다. 보낸 사람이 의도한 대체 경로를 확인합니다. 이 예에서는 포괄 경로를 생성하지 않습니다. |
| 중복된 지문 | 동일한 하위 항목이 업데이트됩니다. 그룹화 레이블이 일치하면 다른 호스트 지문이 동일한 그룹에 두 번째 하위 항목을 생성합니다. |
| 두 자녀 중 한 명만 회복 | 그 아이는 결심합니다. 그룹은 모든 해고 어린이가 회복될 때까지 계속 해고합니다. 고아 복구에서는 새 그룹이 생성되지 않습니다. |
증거를 조용히 지우는 규칙을 피하세요
빈 매처는 모든 항목과 일치합니다. severity이라는 라벨은 정규화된 이벤트 심각도와 자동으로 동일한 필드가 아닙니다. 문서화된 필드 경로를 사용하고 실제 정규화된 이벤트를 검사합니다. 복구도 허용해야 하는 흡입 경로에는 status=firing이 필요하지 않습니다.
active + legacy는 조정 결정을 적용하지 않습니다. hybrid에서는 잘못된 엔터티 조합이 기존 경로로 대체될 수 있습니다. 대신 신뢰할 수 있는 orchestration 모드는 평가 또는 엔터티 유효성 검사 실패 시 처리를 차단합니다. 의도적으로 실패 동작을 선택합니다.
광범위한 drop 또는 suppress 규칙 없이 시작하세요. 억제 및 그룹화는 알림을 줄일 수 있지만 잘못된 모니터링 신호를 유용하게 만들지는 못합니다. 테스트를 거친 이전 버전을 유지하고 출시를 확장하기 전에 예상치 못한 불일치를 검토하세요.