서비스와 사용자의 동작 관찰하기

질문에서 시작하세요

모니터링은 알려진 조건을 확인합니다. 관찰 가능성은 예상하지 못한 실패를 포함해 시스템 동작을 조사하는 데 도움이 됩니다. 대시보드가 늘어난다고 답이 자동으로 좋아지지는 않습니다.

가상의 내보내기 서비스에서는 사용자 질문으로 시작하세요. 권한 있는 사용자가 합의한 시간 안에 올바른 내보내기 결과를 받을 수 있나요? 그런 다음 이 질문에 답하고 실패를 설명하는 데 도움이 되는 신호를 선택하세요.

OpenTelemetry는 텔레메트리를 위한 계측 도구와 표준을 제공합니다. 호환되는 백엔드로 신호를 보낼 수 있습니다. 저장소, 쿼리, 접근 통제, 보존 정책, 증거에 따라 행동할 사람은 여전히 필요합니다. 관찰 가능성 입문.

메트릭은 시간에 따른 수량을 측정합니다. 로그는 사건을 기록합니다. 트레이스는 요청이 시스템을 통과할 때 관련 작업을 연결합니다. 스팬은 트레이스 안의 작업 하나를 나타냅니다.

비동기 작업에서는 제출된 작업과 워커 실행 사이에 안전한 상관관계를 유지하세요. HTTP 202 응답은 작업이 접수되었다는 뜻일 수 있습니다. 내보내기가 완료되었다는 증거는 아닙니다.

SLO를 정하기 전에 SLI와 분모를 정의하세요. 이 예에서는 합의한 시간 안에 올바르게 완료된 처리 대상 내보내기를 집계합니다. 오래 실행되거나 포기된 작업을 측정에 어떻게 포함할지 정하세요.

오류 예산은 SLO 기간 안에서 허용되는 실패를 설명합니다. 소진율은 실패가 그 예산을 얼마나 빠르게 소비하는지 설명합니다. Google의 지침은 적시 탐지와 과도한 알림 사이의 균형을 위해 여러 시간 구간을 사용합니다. SLO 기반 알림.

적시에 조치해야 하는 조건이면 담당자를 호출하세요. 덜 긴급한 작업은 대기열로 보내세요. 모든 알림에는 담당자, 영향 설명, 조사 링크, 대응 지침이 필요합니다. 반복해서 아무 조치로도 이어지지 않는 알림은 검토하세요.

모든 서비스에 하나의 일반적인 임계값을 쓰지 마세요. 사용자 영향, 트래픽, 업무 시간, 대응 역량이 결정에 영향을 줍니다.

텔레메트리에는 개인정보, 토큰, 요청 매개변수, 기밀 문서가 들어 있을 수 있습니다. 수집 전에 허용 필드를 정하세요. 접근과 보존을 제한하세요. 외부 백엔드로 내보내기 전에 비밀 정보를 제거하세요. 민감한 텔레메트리.

고객 이메일이나 고유 작업 ID를 메트릭 라벨로 사용하지 마세요. 제한 없는 라벨은 시계열 수를 늘리고 식별자를 노출할 수 있습니다. 메트릭에는 통제된 차원을 사용하세요. 승인된 상관관계 식별자는 접근이 통제된 로그나 트레이스에 넣으세요.

파이프라인 자체도 측정하세요. 수집 실패, 버려진 데이터, 최신 관찰 이후 경과 시간을 확인하세요. 평평한 오류 차트는 오류가 없거나 텔레메트리가 들어오지 않는다는 뜻일 수 있습니다. 그 차이를 표시하세요.

가상의 서비스가 모든 요청에 HTTP 202를 반환합니다. 큐의 대기 시간이 몇 초에서 15분으로 늘어납니다. 워커 로그에는 데이터베이스 시간 초과가 반복됩니다. 표본 트레이스는 워커 시간의 대부분이 데이터베이스 호출에 쓰인다고 보여 줍니다.

이 증거는 범위를 좁힌 조사를 뒷받침합니다. 하지만 원인이 쿼리 변경, 연결 고갈, 데이터베이스 용량 중 무엇인지는 입증하지 않습니다. 디버깅 방법으로 가설을 비교하세요.

Taiga Monitoring은 가용성과 브라우저 경험 신호를 포함한 제품 상태 화면을 제공합니다. 인프라와 애플리케이션의 관찰 가능성을 보완하며 해당 시스템을 대체하지는 않습니다. Monitoring.