대시보드가 아닌 증거에 대하여

sigiro가 모든 행마다 차트가 아니라 순위가 매겨진 목록과 실행 가능한 쿼리로 응답하는 이유. 베이스라인이란 무엇이며, 이 설계가 하지 않기로 한 것은 무엇인지 설명합니다.

sigiro에 서비스가 왜 정상이 아닌지 물으면, 하나의 구조화된 증거 블록을 반환합니다. 이 블록은 주의를 기울일 만한 항목의 순위 목록으로 시작합니다. 각 항목에는 수치가 포함된 한 줄 요약과, 그 주장을 검증하기 위해 실행할 수 있는 SQL 쿼리가 함께 담겨 있습니다.

차트는 반환하지 않으며, 앞으로도 결코 반환하지 않습니다. 이 페이지에서는 그 선택을 설명합니다. sigiro가 무엇을 비정상으로 판단하는지, 발견한 것에 어떻게 순위를 매기는지, 왜 쿼리가 응답과 함께 전달되는지, 그리고 이 설계가 하지 않기로 한 것은 무엇인지 다룹니다.

읽는 주체는 볼 수 없습니다

차트는 사람에게 좋은 답입니다. 사람은 형태를 한눈에 파악하고, 14:10의 급변을 알아채고, 다음으로 넘어갑니다. 수십 년간의 옵저버빌리티 도구는 그 순간을 중심으로 만들어졌으며, 잘 만들어져 있습니다.

이제 프로덕션을 복구하는 주체는 에이전트이며, 에이전트는 차트를 볼 수 없습니다. 읽을 수 있는 것은 텍스트입니다. 그래서 루프는 수정 단계보다 앞에서 끊어집니다. 에이전트는 패치를 작성할 수는 있지만, 무엇이 고장났는지 알아낼 수 없고, 자신의 패치가 효과가 있었는지도 알 수 없습니다.

sigiro는 그 간극을 메우는 부분입니다. 대시보드 아래에 놓이는 계층이며, 대시보드를 대체하지 않습니다. 패널이 필요하다면 직접 준비해서 동일한 테이블을 가리키게 하십시오.

각 시계열은 자기 자신의 최근 이력과 비교됩니다. sigiro는 7일 윈도우에 걸쳐 모든 신호를 5분 단위 버킷으로 집계하고, 버킷 단위 시계열에 대해 베이지안 온라인 변화점 탐지를 실행합니다. 변화점이란 시계열의 통계적 체제가 바뀌는 지점입니다. 전체 탐지기에서 유일한 구조적 선택은 방향입니다. sigiro는 변화점 이후의 평균이 이전의 평균보다 더 나쁠 때만 그 이동을 유지합니다. 오류가 더 많거나, 더 느리거나, 더 시끄럽거나, 더 비싸진 경우입니다. 이는 누군가가 고른 숫자가 아니라 비교입니다.

다섯 가지 신호가 탐지됩니다:

신호	키 기준	측정 대상
`error_rate`	서비스 및 오퍼레이션	각 버킷에서 오류 스팬의 비율
`latency_p95`	서비스 및 오퍼레이션	각 버킷에서 p95 스팬 지속 시간
`log_volume`	서비스	각 버킷에서 로그 개수
`error_log_rate`	서비스	각 버킷에서 ERROR 등급 로그의 비율
`profile_cost`	서비스	각 버킷에서 프로파일링된 총 비용

여기서 두 가지 결과가 따라오며, 둘 다 사람들을 놀라게 합니다.

항상 느린 서비스는 이상 징후가 아닙니다. p95가 한 주 내내 2초였다면 2초는 그 서비스에 정상이며, sigiro는 아무 말도 하지 않습니다. 이는 올바른 동작이면서 동시에 실제 한계이기도 합니다. sigiro는 무엇이 변했는지 알려주며, 만성적인 결함은 변하지 않습니다. 만성적인 결함에는 쿼리를 사용하십시오.

갓 시작한 서버에서는 아무것도 발견되지 않습니다. 탐지기는 시계열이 벗어날 체제를 갖추기까지 여러 개의 버킷을 필요로 합니다. 일정한 시계열과 매우 짧은 시계열은 구조적으로 모두 변화점을 만들어내지 않으며, 그래서 최소 데이터 포인트 수 옵션도 없습니다.

5분 버킷 역시 의도적으로 둔감하게 잡은 경계입니다. 이는 탐지기가 지속적인 이동을 표시하고 1분짜리 순간적 변동은 무시하게 만듭니다. 1분 장애는 이 탐지기에 보이지 않으며, 그런 경우에는 페이징 시스템이 적합한 도구입니다.

이동에서 인시던트로, 그리고 순위 목록으로

실제 결함은 여러 신호를 동시에 움직입니다. 오류가 증가하고, 지연이 증가하고, 로그 볼륨이 증가하며, 이 셋은 세 개의 사건이 아니라 하나의 사건입니다.

그래서 이동은 순위가 매겨지기 전에 상관 분석됩니다. 동일한 5분 탐지 버킷 또는 인접한 버킷에 있는 두 이동은 하나의 인시던트 항목으로 병합되며, 이 항목은 구성 이동들과, 시간적으로 가까운 배포가 있다면 그 의심 배포를 함께 담습니다. 짝이 없는 이동은 단일 신호 항목으로 남습니다.

그다음 목록의 순서가 정해집니다. 첫 번째 정렬 키는 심각도입니다. 그 안에서 이상 항목은 상관된 신호의 개수, 다음으로 이동의 크기, 다음으로 원시 차이 순으로 순위가 매겨지며, 각 키는 큰 값에서 작은 값 순으로 정렬됩니다. 그래서 세 신호 인시던트가 단독 지연 이동보다 상위에 오며, 이는 하나의 질문과 제한된 주의력을 가진 독자에게 올바른 순서입니다.

크기 항목은 한 문장 정도 설명할 가치가 있습니다. 순진한 방식은 잘못되기 때문입니다. sigiro는 원시 차이 대신 대칭 상대 변화량 (after − before) / (after + before)를 사용합니다. 원시 차이로는 마이크로초로 측정된 지연 이동과 퍼센트로 측정된 오류율 이동을 비교할 수 없습니다. 의미가 무엇이든 마이크로초가 항상 이깁니다. 상대적 형태는 단위가 없으므로, 서로 다른 신호의 이동이 정직하게 서로 비교 정렬됩니다.

이상 징후가 아닌 항목은 맨 뒤에 옵니다. 로그가 없는 오류 같은 불일치, 대응할 수 있는 커버리지 공백, 그리고 중복 스팬이나 고아 스팬처럼 텔레메트리 파이프라인 자체의 결함이 여기에 해당합니다. 마지막 그룹은 독자가 다른 무엇보다 먼저 물어야 할 질문에 답합니다. 이 데이터를 애초에 신뢰할 수 있는가?

쿼리는 응답과 함께 전달됩니다

주장을 담은 모든 행에는 drill_down_sql이 포함됩니다. 그 주장을 만들어낸 쿼리로, /v1/query에 바로 전송할 수 있습니다.

이는 우리가 가장 강력하게 옹호할 설계 요소이며, 그 이유는 편의성이 아닙니다. 검증할 수 있는 주장은 종류가 다른 주장이기 때문입니다. 자동화된 진단을 신뢰해야 할 필요가 없으며, 여러분의 에이전트도 그럴 필요가 없습니다. 쿼리를 실행하십시오. 윈도우를 넓혀 보십시오. 필터를 바꿔서 주장이 살아남는지 확인하십시오.

또한 대안으로는 고칠 수 없는 실패를 고쳐줍니다. 검증할 수 없는 요약은 믿거나 버려야 하며, 반증 불가능한 요약을 받은 에이전트는 그것을 믿게 됩니다. 쿼리는 반증 가능합니다. sigiro가 틀렸을 때 — 그리고 때때로 틀립니다 — 쿼리는 그것을 저렴하게 알아내는 방법입니다.

두 번째, 좀 더 조용한 이점이 있습니다. 쿼리는 다음 질문이 시작되는 지점이기도 합니다. 복사해서 조건 하나를 바꾸면, sigiro가 전혀 생각하지 못한 것을 물어본 셈입니다. 드릴 쿼리가 저장된 뷰로의 링크가 아니라 실제 테이블에 대한 원시 SQL인 이유가 바로 이것입니다.

다섯 번이 아니라 한 번 호출하는 이유

기존 방식의 조사는 다섯 번의 왕복입니다. 메트릭 저장소에 쿼리하고, 추론하고, 트레이스 저장소에 쿼리하고, 추론하고, 로그 저장소에 쿼리하고, 추론하고, 이벤트 저장소에 쿼리하고, 추론합니다. 각 왕복은 저렴하지만 각 모델 호출은 그렇지 않으므로, 모델이 전체 소요 시간을 지배하고 총합은 수십 초에 이릅니다. 또한 에이전트는 컨텍스트 윈도우가 조각들로 채워지면서 이전 컨텍스트를 잃습니다.

/v1/diagnose는 sigiro 내부에서 쿼리들을 병렬로 실행하고 하나의 상관된 블록을 반환합니다. 순위 목록은 동일한 쿼리들이 이미 반환한 데이터로부터 Rust에서 조립되므로, 추가 쿼리도 추가 메모리도 들지 않습니다. 한 번의 왕복, 한 번의 모델 호출, 하나의 일관된 그림입니다. 전체 블록은 원시 스팬 덤프가 아닌 수십 킬로바이트 분량의 구조화된 증거이며, 이는 현대적인 컨텍스트 윈도우의 아주 작은 일부입니다.

이 설계는 그 대가로 응답이 커지고 단일 호출이 느려집니다. 독자가 호출 사이에 몇 초씩 추론하는 경우에는 옳은 트레이드오프이고, 10초마다 50개 패널을 새로 고치는 대시보드에는 잘못된 트레이드오프입니다. sigiro는 전자의 독자를 위해 만들어졌습니다.

이 설계가 하지 않기로 한 것

정직한 목록입니다. 이 각각은 원할 만한 합리적인 것이기 때문입니다.

알림을 보내지 않습니다. 알림 경로도, 사람에게 이르는 에스컬레이션도 없습니다. GET /v1/anomalies는 폴링하는 테이블입니다. 예약된 에이전트나 cron 작업이 의도된 호출자입니다.

비즈니스 영향으로 순위를 매기지 않습니다. 순위는 통계적입니다. sigiro는 여러분의 서비스 중 어느 것이 결제를 처리하는지 알지 못하므로, 백그라운드 워커의 큰 이동이 체크아웃의 작은 이동보다 상위에 올 수 있습니다. 어떤 서비스가 중요한지는 여러분이 알고, 어떤 시계열이 움직였는지는 sigiro가 압니다.

원인을 설명하지 않습니다. 순위 목록은 무엇이 얼마나 변했는지, 어떤 신호들이 함께 움직였는지 말해주며, 시간적으로 가까운 배포가 있으면 그것을 의심 대상으로 지목합니다. 시간적 상관관계는 인과관계가 아닙니다. 증거와 드릴 쿼리는 여러분 혹은 여러분 에이전트의 판단을 위한 것이며, 진단은 그것을 만들어낸 쿼리가 딸린 가설입니다.

아무것도 그리지 않습니다. 만들어야 할 패널도 없고, 썩어갈 패널도 없습니다. 그것이 요점이며, 동시에 일부 독자가 가장 아쉬워할 부분이기도 합니다.

다음으로 읽을 내용

테이블에 대하여, 그리고 각 테이블이 설명하는 머신
배포 탐지에 대하여, 그리고 스팬이 담아야 하는 것 — 의심 배포가 어디에서 오는지
API 참조 — Finding 및 DiagnosisBlock 필드 전체