Deep Agent Builder 모니터링과 실행 상태 확인
모니터링은 실행이 느린지, 실패했는지, 아직 처리 중인지, 운영자 조치가 필요한지를 구분하는 작업입니다. 이 페이지는 Agent 실행과 평가 실행을 확인할 때 사용할 상태, 관리자 조회 범위, Redis 관측 결과의 해석 순서를 설명합니다. 화면에 표시된 색이나 카드만으로 상태를 확정하지 않고, API가 반환한 상태와 처리 시각을 함께 확인합니다.
먼저 확인할 범위
모니터링 대상은 세 범위로 나뉩니다.
| 대상 | 확인할 내용 | 주로 사용하는 범위 |
|---|---|---|
| Agent 실행 | 실행 상태, 오류, 실행 시간, trace_id, 생성 로그 | 관리자 Agent 모니터링 |
| 평가 실행 | run 상태, 처리된 Case 수, Case별 결과, evaluator와 Dataset | 평가 결과와 실행 조회 |
| Redis 인프라 | Stream, ARQ queue, connection, pool과 수집 상태 | 관리자 Redis 관측 |
관리자 Agent 조회는 관리자 앱 접근과 해당 workspace 권한이 필요합니다. Redis 관측은 관리자 앱 접근과 인프라 읽기 권한이 필요합니다. SSE 연결 해제나 counter 조정은 읽기 권한만으로 수행하지 않으며 별도 설정 변경 권한과 확인 문자열이 필요합니다.
SSE 연결 해제에는 ADMIN_SETTING_UPDATE 권한과 RELEASE_SSE_CONNECTIONS 확인 문자열이 필요합니다. Counter reconciliation에는 같은 권한과 RECONCILE_SSE_COUNTERS 확인 문자열이 필요합니다. 확인 문자열이 맞지 않으면 요청을 실행하지 않고 422 응답으로 거부됩니다.
Agent 실행 상태 확인
관리자 모니터링에서 다음 정보를 함께 조회합니다.
- 실행 대상 Agent와 workspace
- trigger type, executor, 시작·종료 시각과 duration_ms
- 현재 상태와 error_message
- trace_id
- 필요할 때 오류 목록과 Agent 생성 로그
Agent 실행 상태에는 pending, running, interrupted, success, error, cancelled, drained, timeout이 있습니다. 상태 이름만으로 원인을 확정하지 말고 종료 시각, 오류 메시지와 trace_id를 함께 기록합니다. drained는 배포, autoscale, manual, sigterm 중 하나의 사유를 가질 수 있습니다.
오류를 확인할 때는 오류 목록에서 error 상태만 분리하고, stack trace가 공개 화면에 표시되는지와 비밀값이 마스킹됐는지는 별도로 확인합니다. 이 매뉴얼의 근거에서는 stack trace의 비밀값 마스킹을 보장하지 않으므로 원문 로그를 그대로 공유하지 않습니다.
평가 실행 상태 확인
평가 실행은 먼저 Service DB에 pending 행을 기록한 뒤 ARQ의 agent_jobs queue에 작업을 넣습니다. 따라서 생성 요청이 성공해도 worker가 실제로 처리를 시작했다는 뜻은 아닙니다. 다음 순서로 확인합니다.
- run이 pending에서 running으로 이동했는지 확인합니다.
- terminal 상태인 success, error, cancelled, timeout 중 하나인지 확인합니다. API enum에는 drained도 포함되므로 화면 상태와 서버 응답을 대조합니다.
- 처리된 Case 수와 결과 목록을 조회합니다.
- score, judge_reasoning, error를 Case별로 확인합니다.
- 일부 Case만 처리됐거나 timeout으로 끝났다면 성공한 결과만으로 전체 품질을 판단하지 않습니다.
평가 실행의 사용자별 동시 실행 기본 한도는 2이며 EVALUATION_MAX_CONCURRENT_RUNS로 바꿀 수 있습니다. 한도 초과로 429 RATE_LIMITED가 반환되면 같은 요청을 반복하지 말고 해당 사용자의 pending 또는 running run을 먼저 확인합니다.
평가 취소가 성공해도 모든 Case 처리가 즉시 멈춘다고 단정하지 않습니다. DB에 취소 상태가 기록된 뒤 Redis 취소 신호 전달이 실패하면 worker가 남은 Case를 처리할 수 있습니다. 취소 뒤에는 최종 상태, 처리된 Case 수와 결과 목록을 다시 조회합니다.
Redis와 queue 관측 결과 해석
관리자 Redis 관측은 다음 Stream과 ARQ queue를 프로토콜별로 구분해 보여줍니다.
- runs:queue
- fix_runs:queue
- skill_chat:queue
- agent_create:queue
- arq:queue:agent_jobs
- 호환용 arq:queue:eval_jobs
- mail:outbound
관리자 Redis API 계약의 관측 목록은 위와 같습니다. 다른 운영 시나리오 문서에는 assistants:queue가 함께 언급되므로, 실제 응답의 목록을 기준으로 기록하고 문서의 목록만으로 모든 환경의 queue가 같다고 단정하지 않습니다.
collector가 없거나 live snapshot을 읽지 못하면 빈 시계열, degraded_states 또는 fallback이 반환될 수 있습니다. 이 응답만으로 Redis 장애를 확정하지 않습니다. connections 조회는 CLIENT LIST 실패를 degraded 상태의 200 응답으로 돌려줄 수 있고, 다른 live snapshot을 읽지 못하면 503 SERVICE_UNAVAILABLE이 될 수 있습니다.
queue 통계를 볼 때는 프로토콜별 구분과 queue 이름, pending 또는 lag 정보, 수집 시각을 함께 기록합니다. Redis 관측 계약에는 consumer group별 통계, rich worker grid, 실패 job 상위 목록이 없으므로, 해당 화면이나 지표가 있다고 가정해 운영 판단을 확장하지 않습니다.
운영 조치와 경계
SSE 연결을 정리할 때는 release 요청이 즉시 Redis client나 Stream을 삭제하지 않습니다. 연결 row에 release marker를 남기고 relay가 다음 XREAD 또는 heartbeat 경계에서 종료합니다. 따라서 요청 성공을 즉시 연결 종료나 즉시 복구로 해석하지 않습니다. 목록에 없는 연결 ID가 섞여 있어도 요청 전체가 실패하지 않고, 성공 응답의 실패 항목으로 분리돼 돌아옵니다.
Counter reconciliation은 release 대기 row를 active 집계에서 제외하고 global 및 type counter를 다시 씁니다. 이 조치는 run이나 session의 durable state, XACK, Stream 삭제를 변경하지 않습니다. Redis 오류가 중간에 발생하면 앞선 marker 또는 counter 변경이 남을 수 있으므로, 503 이후 상태를 다시 조회합니다.
두 조치 모두 감사 기록을 남깁니다. release는 admin_sse_stream_release_requested, counter reconciliation은 admin_sse_stream_counters_reconciled 이벤트 식별자로 기록되므로, 감사 로그에서 식별자로 검색하면 조치 내역을 추적할 수 있습니다.
완료 판단과 다음 조치
다음 조건을 모두 확인하면 현재 실행의 상태를 기록할 수 있습니다.
- 대상 workspace, Agent 또는 evaluation run을 식별했습니다.
- 서버가 반환한 상태와 화면 표시를 대조했습니다.
- 종료 상태라면 종료 시각과 오류를 확인했습니다.
- 평가라면 처리된 Case 수와 Case별 결과를 확인했습니다.
- queue 또는 Redis 관측이 degraded인지 정상인지 구분했습니다.
- 취소나 운영 조치 뒤에 상태를 다시 조회했습니다.
- 운영 조치를 했다면 감사 로그에 조치 기록이 남는지 확인했습니다.
상태가 pending 또는 running에 오래 머물면 queue와 worker 상태를 확인합니다. 결과가 비어 있으면 실행 상태와 export 가능 시점을 먼저 확인합니다. 409 CONFLICT, 429 RATE_LIMITED 또는 503 SERVICE_UNAVAILABLE이 반복되면 요청을 재시도하기 전에 대상 상태, 동시 실행 수, 권한과 Redis 수집 상태를 나눠 확인합니다. 원인이 확인되지 않은 상태에서 threshold를 낮추거나 실패 Case를 제거하지 않습니다.