Sidekiq job telemetry로 이벤트 전송 및 확인
제어된 애플리케이션 경계에서 Sidekiq job telemetry를 사용하고, 이벤트 계약을 작게 유지하고, 집계 뷰를 구축하기 전에 알려진 결과를 확인하세요.
- 1
결과를 선택하세요
Sidekiq 재시도 모니터링
- 2
계약 정의
job_id, job_name, queue_name, attempt, status, duration_ms, release
- 3
결과에서 방출
초기화 파일에서 서버 미들웨어를 등록합니다. 같은 논리적 jid는 Sidekiq 재시도에서도 유지됩니다. 첫 시도는 1이고 retry_count가 0이면 두 번째 시도입니다. 잘못된 재시도 메타데이터는 알 수 없는 값으로 남깁니다.
- 4
증거를 확인하세요
Exercise a known fixture, then inspect job_attempt_completed for one correctly typed terminal row.
시작하기 전에
시작하기 전에
- 쓰기 권한이 있는 서버 측 TELEMETRY_API_KEY
- 이 예제를 config/initializers/telemetry_sidekiq.rb에 넣고 각 워커 프로세스에서 한 번 로드합니다
- Sidekiq::ServerMiddleware를 제공하는 Sidekiq 7 이상
배송 설정
서버 측 설치 및 초기화
서버 측 키와 명시적인 열기 및 읽기 시간 제한이 있는 작은 Net::HTTP 래퍼를 사용합니다. 브라우저 번들, 클라이언트에 표시되는 환경 변수, 소스 제어, 로그 및 예외 메시지에서 수집 자격 증명을 유지하세요.
- 1제한된 네트워크 동작을 갖춘 재사용 가능한 서버 측 전달 클라이언트 하나를 준비합니다.
- 2성공, 실패, 재시도 또는 시간 초과 경계에 결과 이벤트를 추가합니다.
- 3알림을 활성화하기 전에 제어된 고정 장치를 보내고 저장된 행을 검사하십시오.
스니펫
하나의 체계적인 이벤트로 시작하세요
워크플로가 완료, 실패 또는 재시도되는 위치에 이 셰이프를 추가합니다. 그런 다음 실제 필드에서 대시보드를 구축합니다.
Sidekiq job telemetry 이벤트
# config/initializers/telemetry_sidekiq.rb
require "sidekiq"
require "json"
require "net/http"
require "uri"
module TelemetrySidekiqAttempts
def self.delivery_failed
warn "Telemetry job event delivery failed."
rescue StandardError
# A broken diagnostic sink must not change the job outcome.
end
def self.log(fields)
key = ENV["TELEMETRY_API_KEY"]
return if key.nil? || key.empty?
uri = URI("https://api.telemetry.sh/log")
request = Net::HTTP::Post.new(uri)
request["Authorization"] = key
request["Content-Type"] = "application/json"
request.body = { table: "job_attempt_completed", data: fields }.to_json
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.open_timeout = 1
http.read_timeout = 1
http.write_timeout = 1
http.max_retries = 0
response = http.start { |client| client.request(request) }
delivery_failed unless response.is_a?(Net::HTTPSuccess)
rescue StandardError
delivery_failed
end
end
class TelemetryOutcomeMiddleware
include Sidekiq::ServerMiddleware
def call(_job_instance, job, queue)
started = Process.clock_gettime(Process::CLOCK_MONOTONIC)
status = "not_returned"
begin
result = yield
status = "returned"
result
rescue StandardError
status = "raised"
raise
ensure
begin
retry_count = job["retry_count"]
attempt = if !job.key?("retry_count")
1
elsif retry_count.is_a?(Integer) && retry_count >= 0
retry_count + 2
end
TelemetrySidekiqAttempts.log({
job_id: job["jid"],
job_name: job["class"],
queue_name: queue,
attempt: attempt,
status: status,
duration_ms: ((Process.clock_gettime(
Process::CLOCK_MONOTONIC
) - started) * 1000).round(2),
release: ENV["APP_RELEASE"]
})
rescue StandardError
TelemetrySidekiqAttempts.delivery_failed
end
end
end
end
Sidekiq.configure_server do |config|
config.server_middleware do |chain|
chain.add TelemetryOutcomeMiddleware
end
end이벤트 스키마
job_id, job_name, queue_name, attempt, status, duration_ms, release
작업 인수, 결과 본문, 예외 메시지, 애플리케이션 계정 데이터는 포함하지 않습니다
설정 확인하기
체크포인트 1
초기화 파일에서 서버 미들웨어를 등록합니다. 같은 논리적 jid는 Sidekiq 재시도에서도 유지됩니다. 첫 시도는 1이고 retry_count가 0이면 두 번째 시도입니다. 잘못된 재시도 메타데이터는 알 수 없는 값으로 남깁니다.
체크포인트 2
작업 블록이 반환되었다고 후속 전달이 완료된 것은 아닙니다. StandardError는 raised로 기록하고 원래대로 다시 발생시킵니다. 그 밖의 반환되지 않는 종료는 not_returned로 남깁니다.
체크포인트 3
이 예제는 큐 대기, 재시도 소진, Active Job의 별도 재시도 정책을 측정하지 않습니다. 각각 검증된 수명 주기 훅에서 기록하세요.
체크포인트 4
소요 시간은 단조 시계를 사용하며 동기 내보내기 시간을 제외합니다. 내보내기는 여전히 워커를 점유하고 처리 지연을 늘립니다.
체크포인트 5
전송, 2xx가 아닌 응답, 인코딩, 메타데이터, 진단 실패를 격리합니다. 키가 없으면 내보내기를 건너뛰며 작업 결과나 원래 예외를 바꾸지 않습니다.
체크포인트 6
연결, 읽기, 쓰기 시간 제한은 각각 1초이며 엄격한 전체 시간 제한은 아닙니다. 내보내기 재시도, 영속 큐, 종료 시 비우기는 없습니다. 손실을 허용할 수 없다면 애플리케이션이 관리하는 아웃박스를 사용하세요.
검증
이벤트가 도착했음을 증명하세요.
알려진 성공 및 실패 사례를 연습한 후 이를 실행하십시오. 최종 이벤트 계약이 스니펫과 다른 경우 대체 테이블 이름을 바꾸세요.
Sidekiq job telemetry 확인 쿼리
SELECT *
FROM job_attempt_completed
ORDER BY timestamp_utc DESC
LIMIT 20;구현 참조
새로운 프로덕션 경로를 활성화하기 전에 이벤트 계약, 데이터 안전 지침, 업스트림 기본 문서를 검토하세요.
이벤트를 기록할 위치
결과 이벤트를 작고 복구 가능하게 유지
이 패턴은 다음을 제공합니다.
- 업스트림 워크플로우 옆에 제한된 SQL 지원 결과가 있습니다.
- 대시보드, 알림 및 교차 이벤트 상관 관계를 위한 안정적인 필드입니다.
- 성공, 실패, 재시도 및 시간 초과 동작을 검증하기 위한 고정 장치 기반 경로입니다.
이 패턴은 제공하지 않습니다
- OTLP 내보내기, 자동 수집 파이프라인 또는 자세한 추적 및 진단 로그를 대체합니다.
- 페이로드에 이벤트 ID가 포함되어 있기 때문에 정확히 한 번만 전달됩니다.
- 원시 공급자 페이로드, 사용자 콘텐츠, 자격 증명 또는 규제 데이터를 수집할 수 있는 권한입니다.
이벤트 스키마 예제
이 워크플로의 이벤트 스키마
쿼리 또는 스니펫을 프로덕션에 적용하기 전에 행 그레인, 방출 경계, 필수 유형, 개인 정보 보호 클래스, 예제 페이로드 및 유효성 검사 체크리스트를 검토하세요.
관련 제품 기능
이 워크플로를 다음에서 계속하세요. 알림
검토된 신뢰성 쿼리를 소유한 임계값 및 응답 워크플로로 승격합니다.
관련 SQL 레시피
더 많은 SQL 예제
이 워크플로의 구조화된 필드에 대해 쿼리를 실행하고, 예제 결과를 검사하고, 유용한 답변을 대시보드 또는 알림으로 전환하세요.
백그라운드 작업 재시도 및 실패율 측정
가장 많은 재시도를 소비하거나 여전히 실패하는 백그라운드 작업은 무엇입니까?
레시피 열기작업별 대기열 대기 시간 측정
작업자가 작업을 시작하기 전에 가장 오래 기다리는 작업은 무엇입니까?
레시피 열기SQL을 사용하여 중단된 백그라운드 작업 찾기
어떤 작업이 시작되었지만 종료 이벤트를 생성하지 않았습니까?
레시피 열기배달 못한 편지 대기열 증가 측정
배달 못한 편지 작업을 해결하는 것보다 더 빨리 추가하는 대기열은 무엇입니까?
레시피 열기백그라운드 작업 재시도 폭풍 감지
현재 재시도에 가장 많은 노력을 기울이고 있는 작업 유형은 무엇입니까?
레시피 열기구현 제품군별로 찾아보기
관련 통합 패턴 비교
이 통합과 페어링할 템플릿
더 많은 통합