Django and Celery structured event monitoring로 이벤트 전송 및 확인
Celery 작업의 한 시도를 관측하고 원래 결과를 유지하며 차트를 만들기 전에 기록된 상태를 확인하세요.
- 1
시도 선택
Celery 워커 결과
- 2
계약 정의
job_name, job_id, queue_name, observed_state, status
- 3
시도 상태 기록
이 예제는 task_postrun의 SUCCESS, FAILURE, RETRY를 시도 상태로 기록합니다. 재시도는 최종 실패가 아닙니다.
- 4
증거를 확인하세요
알려진 작업을 실행하고 celery_task_attempt_finished에서 관측된 시도 상태를 확인하세요. 재시도 행은 최종 결과가 아닙니다.
시작하기 전에
시작하기 전에
- 서버측 TELEMETRY_API_KEY
- 워커 프로세스에 설치된 Celery
- Celery 워커가 시작될 때 이 모듈을 가져오세요
배송 설정
서버 측 설치 및 초기화
이 Celery 워커 모듈은 Python 표준 라이브러리 HTTP로 이벤트를 보냅니다. Telemetry SDK를 설치하거나 초기화할 필요가 없습니다. 브라우저 번들, 클라이언트에 표시되는 환경 변수, 소스 제어, 로그 및 예외 메시지에서 수집 자격 증명을 유지하세요.
- 1워커마다 시그널 모듈을 한 번 로드하고 내보내기 오류를 작업 결과와 분리하세요.
- 2성공, 실패, 재시도 또는 시간 초과 경계에 결과 이벤트를 추가합니다.
- 3알림을 활성화하기 전에 제어된 고정 장치를 보내고 저장된 행을 검사하십시오.
스니펫
하나의 체계적인 이벤트로 시작하세요
워크플로가 완료, 실패 또는 재시도되는 위치에 이 셰이프를 추가합니다. 그런 다음 실제 필드에서 대시보드를 구축합니다.
Django and Celery structured event monitoring 이벤트
import json
import logging
import os
from urllib.request import Request, urlopen
from celery.signals import task_postrun
def report_export_failure():
try:
logging.getLogger(__name__).warning("Telemetry export unavailable")
except Exception:
pass
@task_postrun.connect(weak=False)
def record_task(sender=None, task_id=None, state=None, **kwargs):
try:
status = {"SUCCESS": "success", "FAILURE": "failed",
"RETRY": "retry_scheduled"}.get(state)
if status is None:
return # Other states need their own observed lifecycle handlers.
key = os.getenv("TELEMETRY_API_KEY")
if not key:
report_export_failure()
return
delivery = sender.request.delivery_info or {}
payload = {
"table": "celery_task_attempt_finished",
"data": {
"job_name": sender.name,
"job_id": task_id,
"queue_name": delivery.get("routing_key"),
"observed_state": state,
"status": status,
"attempt": sender.request.retries + 1,
},
}
request = Request("https://api.telemetry.sh/log",
data=json.dumps(payload).encode("utf-8"),
headers={"Authorization": key,
"Content-Type": "application/json",
"User-Agent": "telemetry-agent/1.0"},
method="POST")
# Socket timeout, not a hard end-to-end deadline. Export can be lost.
with urlopen(request, timeout=1.0) as response:
if not 200 <= response.status < 300:
report_export_failure()
except Exception:
# Do not let export or metadata errors replace the task outcome.
report_export_failure()이벤트 스키마
job_name, job_id, queue_name, observed_state, status
관측된 실행의 attempt는 retries + 1입니다
워커 메타데이터만 사용하며 내보내기 전에 작업 및 큐 식별자를 검토하세요
설정 확인하기
체크포인트 1
이 예제는 task_postrun의 SUCCESS, FAILURE, RETRY를 시도 상태로 기록합니다. 재시도는 최종 실패가 아닙니다.
체크포인트 2
재시도 시 논리 작업 ID를 유지하고 retries + 1을 시도 번호로 기록하세요.
체크포인트 3
각 워커 프로세스에서 이 모듈을 한 번 가져오세요. Django 요청을 계측하거나 작업 소요 시간을 측정하지 않습니다.
체크포인트 4
내보내기는 최선형이며 소켓 타임아웃은 1초입니다. 워커 지연이 늘어나며 엄격한 전체 시간 제한, 영속적 전달 또는 내보내기 재시도를 구현하지 않습니다.
체크포인트 5
작업 인수, 결과, 예외 텍스트, URL, 자격 증명을 이벤트에 포함하지 마세요. 워커 손실이나 종료로 task_postrun이 발생하지 않을 수 있으므로 누락된 이벤트의 상태는 알 수 없습니다.
검증
이벤트가 도착했음을 증명하세요.
알려진 성공 및 실패 사례를 연습한 후 이를 실행하십시오. 최종 이벤트 계약이 스니펫과 다른 경우 대체 테이블 이름을 바꾸세요.
Django and Celery structured event monitoring 확인 쿼리
SELECT *
FROM celery_task_attempt_finished
ORDER BY timestamp_utc DESC
LIMIT 20;구현 참조
새로운 프로덕션 경로를 활성화하기 전에 이벤트 계약, 데이터 안전 지침, 업스트림 기본 문서를 검토하세요.
이벤트를 기록할 위치
결과 이벤트를 작고 복구 가능하게 유지
이 패턴은 다음을 제공합니다.
- 업스트림 워크플로우 옆에 제한된 SQL 지원 결과가 있습니다.
- 대시보드, 알림 및 교차 이벤트 상관 관계를 위한 안정적인 필드입니다.
- 성공, 실패, 재시도 및 시간 초과 동작을 검증하기 위한 고정 장치 기반 경로입니다.
이 패턴은 제공하지 않습니다
- OTLP 내보내기, 자동 수집 파이프라인 또는 자세한 추적 및 진단 로그를 대체합니다.
- 페이로드에 이벤트 ID가 포함되어 있기 때문에 정확히 한 번만 전달됩니다.
- 원시 공급자 페이로드, 사용자 콘텐츠, 자격 증명 또는 규제 데이터를 수집할 수 있는 권한입니다.
이벤트 스키마 예제
이 워크플로의 이벤트 스키마
쿼리 또는 스니펫을 프로덕션에 적용하기 전에 행 그레인, 방출 경계, 필수 유형, 개인 정보 보호 클래스, 예제 페이로드 및 유효성 검사 체크리스트를 검토하세요.
관련 제품 기능
이 워크플로를 다음에서 계속하세요. 알림
검토된 신뢰성 쿼리를 소유한 임계값 및 응답 워크플로로 승격합니다.
관련 SQL 레시피
더 많은 SQL 예제
이 워크플로의 구조화된 필드에 대해 쿼리를 실행하고, 예제 결과를 검사하고, 유용한 답변을 대시보드 또는 알림으로 전환하세요.
백그라운드 작업 재시도 및 실패율 측정
가장 많은 재시도를 소비하거나 여전히 실패하는 백그라운드 작업은 무엇입니까?
레시피 열기작업별 대기열 대기 시간 측정
작업자가 작업을 시작하기 전에 가장 오래 기다리는 작업은 무엇입니까?
레시피 열기배달 못한 편지 대기열 증가 측정
배달 못한 편지 작업을 해결하는 것보다 더 빨리 추가하는 대기열은 무엇입니까?
레시피 열기경로별 API 오류율 계산
요청이 20건 이상인 API 경로 중 5xx 오류율이 가장 높은 경로는 무엇인가요?
레시피 열기백그라운드 작업 재시도 폭풍 감지
현재 재시도에 가장 많은 노력을 기울이고 있는 작업 유형은 무엇입니까?
레시피 열기구현 제품군별로 찾아보기
관련 통합 패턴 비교
이 통합과 페어링할 템플릿
더 많은 통합
BullMQ 대기열 모니터링
SQL 지원 수명 주기 이벤트를 통해 BullMQ 대기열 대기, 실행 기간, 재시도, 실패 및 배달 못한 편지 증가를 측정합니다.
가이드 열기RabbitMQ 대기열 Telemetry
구조화된 이벤트를 통해 RabbitMQ 게시 확인, 전달, 승인, 재전송, 대기열 대기, 재시도 및 배달 못한 편지 결과를 추적합니다.
가이드 열기Azure 서비스 버스 Telemetry
메시지 본문을 수집하지 않고도 Azure Service Bus 전송, 수신, 잠금 갱신, 결제, 재전송, 지연 및 배달 못한 편지 결과를 추적합니다.
가이드 열기