Telemetry가 SQL 알림을 평가하는 방법

유용한 알림은 차트에 첨부된 임계값 이상의 것입니다. 평가자는 쿼리가 만료되는 시기, 실행할 SQL, 개수를 계산하는 행, 해당 행을 하나의 값으로 줄이는 방법, 상태 변경 여부 및 알림 시기를 결정해야 합니다.

이 가이드에서는 Telemetry가 구현한 평가 경로를 문서화합니다. 이는 가동 시간, 대기 시간 또는 배달 보장이 아닌 검사 가능한 동작 설명입니다.

알림 입력 모델: 시계열 신호 1개

Telemetry의 알림 생성 워크플로는 의도적으로 한 줄, 즉 정렬된 시간 축, 하나의 숫자 값 축, 그룹화 또는 분할 차원 없이 시작됩니다. 탐색에는 분할 기준이 없는 꺾은선형 차트가 필요합니다. SQL 결과에는 명시적인 시간 x축, 숫자 y축 및 그룹화 기준이 없음으로 설정된 선형 차트가 필요합니다.

이 제약은 평가자의 입력을 이해할 수 있게 유지합니다. 각 결과 행은 특정 시점이고, 선택한 메트릭에는 하나의 의미와 단위가 있으며, 구성된 임계값은 하나의 알림 상태를 생성합니다. 다중 시리즈 결과에는 일부 또는 모든 시리즈가 상태를 제어하는지 여부, 각 시리즈가 독립적인 기록을 소유하는지 여부, 알림을 그룹화하는 방법, 누락되거나 새로 나타나는 시리즈의 의미 등 추가 정책이 필요합니다. Telemetry는 이러한 의미 체계를 암시적으로 발명하는 것을 방지합니다.

신호를 계산하는 SQL는 여전히 복잡할 수 있습니다. 테이블을 조인하고, 특정 서비스 또는 경로로 필터링하고, 비율을 계산하거나, 최소 샘플 크기를 적용할 수 있습니다. 알림에 노출되는 최종 결과는 간단해야 합니다. 즉, 행당 하나의 시간 버킷과 하나의 숫자 신호입니다. 대시보드에서 그룹화된 비교를 유지하거나 각 그룹에 고유한 임계값, 소유자 및 응답이 있는 경우 별도의 알림을 생성하세요.

평가 순서

평가자는 연결된 1분 일정 루프를 사용합니다. 각 패스는 활성화된 알림을 로드하고, 격리된 오류 처리를 통해 이를 동시에 평가하고, 패스 결과를 기록하고, 현재 패스가 완료된 후 다음 패스를 예약합니다. 1분 루프는 폴링 흐름입니다. 각 알림에는 여전히 자체적으로 구성된 간격이 있습니다.

활성화된 모든 알림에 대해 다음을 수행합니다.

1. 마지막 평가 시간과 구성된 간격으로 알림이 만료되는지 확인하세요.
2. 다른 평가자가 동일한 버전을 동시에 요청할 수 없도록 현재 버전을 사용하여 알림을 요청하세요.
3. 쿼리 해결: 쿼리 지원 알림에 대해 정확히 저장된 SQL을 사용하거나 저장된 탐색 구성에서 SQL을 다시 생성합니다.
4. write 문이 포함된 쿼리 지원 SQL을 거부합니다.
5. 쿼리를 실행하고 결과 열과 행을 검사합니다.
6. 선택적으로 불완전한 시간 버킷을 나타내는 경우 최신 행을 삭제합니다.
7. 구성된 최근 포인트 수를 가져와 하나의 관찰 값으로 집계합니다.
8. 해당 값을 임계값 및 연산자와 비교합니다.
9. 새로운 상태, 관찰된 값, 평가 시간 및 제어된 오류를 저장합니다.
10. 상태가 전환될 때만 기록을 추가하고 이메일 전송을 시도합니다.

문제를 해결할 때 이 순서가 중요합니다. 유효한 쿼리는 여전히 사용 가능한 값을 생성하지 않을 수 있고, 사용 가능한 값은 임계값 미만으로 유지될 수 있으며, 알림이 이미 실행 중일 때 위반된 임계값은 자동으로 유지될 수 있습니다.

저장된 쿼리 및 소스 탐색

쿼리 지원 알림은 알림와 함께 저장된 SQL을 실행합니다. 평가자는 이를 최신 쿼리 개정으로 자동으로 바꾸지 않습니다. 대시보드와 알림이 일치하지 않는 것으로 나타나면 알림에 첨부된 SQL을 검토하세요.

Explore 지원 알림은 Explore 구성을 저장하고 Explore에서 사용하는 것과 동일한 쿼리 작성 경계를 통해 SQL을 재생성합니다. 따라서 스키마, 필터, 그룹화 또는 집계를 변경하면 저장된 구성이 계속 확인되는지 여부에 영향을 미칠 수 있습니다.

쿼리 지원 알림에 대해서는 쓰기 지향 문이 거부됩니다. 알림은 테이블이나 관리 상태를 변경하는 것이 아니라 결과를 관찰하기 위한 것입니다. SQL이 읽기 전용인 경우에도 시간 및 결과 크기에 따라 알림 SQL을 유지합니다.

최신 포인트 제외

시간 버킷 쿼리는 일반적으로 현재 불완전한 버킷을 먼저 반환합니다. 부분적인 분 또는 시간을 전체 기록 버킷과 비교하면 잘못된 복구 또는 잘못된 위반 신호가 생성될 수 있습니다.

exclude latest incomplete point가 활성화되면 평가자는 구성된 포인트 수를 선택하기 전에 최신 행을 먼저 정렬하고 최신 결과 행을 제거합니다. 해당 설정은 각 행이 실제로 시간 버킷을 나타내고 최신 행이 불완전한 경우에만 정확합니다.

다음과 같은 단일 행 집계에는 활성화하지 마십시오.

SELECT
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '15 minutes';

유일한 행을 삭제하면 평가할 값이 남지 않습니다. 시계열의 경우 명시적 버킷 열과 하나의 숫자 값 열을 반환합니다.

SELECT
  date_bin(INTERVAL '5 minutes', completed_at, TIMESTAMP '1970-01-01') AS bucket,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '35 minutes'
GROUP BY bucket
ORDER BY bucket DESC;

포인트 선택 및 집계

최신 포인트 처리 후 평가자는 구성된 최근 행 수를 가져옵니다. 선택한 숫자 값을 추출하고 알림 집계 설정을 사용하여 해당 점수를 줄입니다.

SQL이 이미 전체 결정 창을 계산한 경우 단일 지점을 사용합니다. 알림이 의도적으로 여러 버킷에 걸쳐 지속성을 요구하는 경우 여러 지점을 사용합니다. 집계는 운영 질문과 일치해야 합니다.

• maximum는 선택한 지점이 위반되었는지 묻습니다.
• minimum는 선택한 모든 점이 바닥 위에 있는지 묻습니다.
• average는 짧은 변화를 완화하지만 심각한 지점 하나를 숨길 수 있습니다.
• sum는 겹치지 않는 버킷에 걸쳐 누적된 개수를 맞춥니다.
• latest는 가장 최근에 남은 완전점을 사용합니다.

응답 절차에 이 선택 사항을 문서화하십시오. "5 이상의 실패율"은 그것이 최근 5분 버킷을 의미하는지, 3개 버킷의 평균 또는 해당 버킷의 최대값을 의미하는지 팀이 알지 않는 한 모호합니다.

상태 전환 및 알림

Telemetry는 단일 평가와 별도로 알림 상태를 저장합니다. 성공적인 평가를 통해 ok 또는 firing가 생성될 수 있습니다. 실행, 추출 또는 구성 문제로 인해 오류 결과가 발생합니다.

기록과 알림은 전환 지향적입니다. ok에서 firing로 이동하면 트리거 전환이 생성됩니다. firing에서 ok로 이동하면 해상도 전환이 생성됩니다. 동일한 상태에서 반복된 평가는 모든 폴링 패스에서 동일한 전환 이메일을 보내지 않고 평가 기록을 업데이트합니다.

이 평가자에 대한 현재 알림 전달은 이메일입니다. 상태 전환이 저장된 후 전달이 시도됩니다. 전달 실패로 인해 알림이 전환되었다는 사실이 지워져서는 안 됩니다. 따라서 알림 기록과 이메일 전달을 별도로 조사해야 합니다.

동시성 및 클레임 동작

각 알림은 현재 버전을 사용하여 낙관적 동시성을 통해 요청됩니다. 버전이 변경되었거나 다른 평가자가 이미 해당 버전을 주장한 경우 해당 주장이 성공하지 못합니다. 이렇게 하면 두 평가자가 고의로 동일한 알림 버전을 동시에 처리하는 것을 방지할 수 있습니다.

스케줄러는 확정된 약속으로 활성화된 알림 세트를 평가하므로 하나의 거부된 알림로 인해 해당 패스의 나머지 알림이 완료되는 것을 방해하지 않습니다. 루프는 현재 패스가 확정된 후에만 다음 패스를 예약하여 한 프로세스 내에서 패스가 겹치는 것을 방지합니다.

이러한 컨트롤은 평가자의 동작을 설명합니다. 이는 분산 서비스 가용성 주장이 아닙니다. 배포 토폴로지, 프로세스 다시 시작, 이메일 공급자 동작 및 향후 구현 변경 사항은 여전히 ​​운영 검토에 속합니다.

문제 해결 체크리스트

알림이 예상대로 작동하지 않는 경우:

1. 정확히 연결된 SQL을 실행하고 읽기 전용인지 확인합니다.
2. 선택한 값 열이 숫자이고 모든 관련 행에 존재하는지 확인하세요.
3. 결과 순서를 검사합니다. 최신 포인트 논리는 어떤 행이 최신인지 파악하는 데 달려 있습니다.
4. 쿼리가 하나의 집계 행을 반환하는지 아니면 여러 시간 버킷을 반환하는지 확인합니다.
5. exclude latest incomplete point, 포인트 수, 집계를 함께 검토하세요.
6. 연산자와 임계값이 선택한 값과 동일한 단위를 사용하는지 확인하십시오.
7. 가장 최근의 상태 전환 및 제어된 오류에 대한 알림 기록을 확인하세요.
8. 쿼리/평가 실패를 이메일 전달 실패와 분리하세요.
9. 알림이 활성화되어 있고 구성된 간격에 대해 충분한 시간이 경과했는지 확인합니다.
10. 임계값 양쪽에 합성 이벤트 고정 장치를 사용하여 테스트합니다.

배달 관련 조사를 위해서는 알림 배달 문제 해결을 계속 진행하세요. 이벤트 및 쿼리 디자인에는 알림 및 첫 번째 대시보드 및 알림 만들기를 사용하세요.

해석의 경계

평가자는 구성된 결정을 일관되게 실행할 수 있지만 비즈니스 정의가 올바른지 여부를 결정할 수는 없습니다. 이벤트 그레인, 분모, 기간, 임계값, 누락 데이터 정책 및 응답 소유자는 알림 계약의 일부로 유지됩니다.

스키마 변경, 쿼리 편집, 릴리스 변경, 트래픽 이동 및 사고 회고 후 알림을 다시 검토합니다. 더 이상 사용되지 않는 임계값이나 분모가 있는 기술적으로 작동하는 알림은 여전히 신뢰할 수 없는 알림입니다.