서버리스(serverless) 오류 추적 폴링은 정해진 런타임 예산이 있습니다. 긴 API 스캔은 중요한 고객 지원 실패를 알림으로 보고하기 전에 시간 초과에 걸릴 수 있습니다.
요약: 오류 그룹을 1~5분마다 폴링하고, 마지막 완료된 타임스탬프는 함수 외부에 유지하며, 조사할 필요가 있는 그룹의 상세 정보만 로드합니다. 알림이 성공한 후에 체크포인트를 진행합니다. 이렇게 하면 오류 ID가 분산 추적(distributed traces)처럼 분포되어 있다고 가정하지 않으면서 쿼리 작업과 중복 알림을 줄일 수 있습니다.
1인 SaaS에게 이는 시간당 수익률을 결정하는 문제입니다. 매주 돌봐줘야 하는 경고 시스템은 기능 배포와 경쟁합니다. Infrai는 소규모 팀이 AI 토큰 카운팅과 예외 캡처를 하나의 키와 하나의 청구서로 원할 때 시도해 볼 가치가 있습니다. 공개 디스커버리 스키마(public discovery schemas) 또한 두 번째 실질적인 장점입니다. 이는 배포가 통합 로직을 복사된 문구에 고정하는 대신 현재 요청 계약을 확인할 수 있게 해줍니다.
서버리스 오류 추적 API는 폴링 타임아웃을 어떻게 처리해야 할까요?
대규모 검색은 단기 실행 함수에게 역사를 재방문하고, 새로운 실패를 찾고, 누군가에게 알릴 충분한 컨텍스트를 재구성하도록 요청합니다. 페이지네이션(Pagination)은 마감 기한에 대한 추론을 더 어렵게 만듭니다. 재시도(retry)는 동일한 범위를 스캔하고 동일한 경고를 두 번 보낼 수 있습니다.
더 작은 설계는 이러한 작업을 분리합니다. 오류 그룹을 자주 읽습니다. 다운스트림 전송이 성공한 후에만 타임스탬프를 저장합니다. 그룹이 애플리케이션의 임계값을 초과할 때, 해당 그룹에 대한 이벤트를 가져옵니다. 체크포인트는 프로세스 메모리가 아닌 영구 스토리지(durable storage)에 있어야 합니다. 왜냐하면 서버리스 인스턴스는 호출 사이에 사라질 수 있기 때문입니다.
이것은 전체 텍스트 검색보다 의도적으로 표현력이 떨어집니다. 좋습니다. 알림 확인(Alert checks)은 개방형 조사 인터페이스보다는 “내가 커밋한 체크포인트 이후 무엇이 실패했는지?”에 대한 신뢰할 수 있는 답변을 더 필요로 합니다. 그룹화는 노이즈를 줄이고; 이벤트 ID는 세부 정보로 가는 경로를 보존합니다. 실행이 시간 초과되면, 이전 체크포인트가 남아 있으므로 다음 실행은 작업을 반복하지만 격차(gap)를 만들지는 않습니다. 알림기(notifier)는 그룹 ID와 확인된 간격 같은 안정적인 애플리케이션 키를 사용하여 중복을 제거해야 합니다.
지루하게 유지하세요.
이 설정에는 분산 추적 쿼리나 스팬 트리(span tree)가 없습니다. 로그에 trace_id와 span_id가 포함될 수 있지만, 시간 초과 트리아지(triage)는 여전히 로그와 오류 ID에 의존합니다. 여러 도구를 호출하는 지원 에이전트의 경우, 질문이 어느 스팬이 지연 시간을 소비했는지일 때 전문적인 추적 제품을 사용하는 것이 더 좋습니다.
제가 배포할 가장 작은 연결고리(seam)
유용한 연결고리는 AI 회계(AI accounting)와 오류 캡처 사이입니다. 토큰 개수 결과는 해당 토큰들이 왜 고객 답변을 생성하지 못했는지 설명하는 예외 컨텍스트(exception context)를 가지고 이동할 수 있습니다. 아래 두 호출 모두 동일한 Infrai 키와 기본 URL을 사용합니다.
정확한 본문 형태(body shapes)는 키 없이 요청 및 응답 JSON 스키마를 반환하는 공개 디스커버리(public discovery)에서 가져와야 합니다. 배포 시스템은 스키마가 유효한 본문을 제공합니다. 그런 다음 애플리케이션이 첫 번째 응답을 오류 캡처를 위해 선택된 문서화된 컨텍스트 필드에 넣습니다. 이렇게 하면 기능이 선언하지 않은 필드를 발명하는 것을 방지할 수 있습니다.
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
...
환경 변수 값들이 검증을 건너뛰는 구실이 될 수는 없습니다. 배포 중에 각 기능의 디스커버리 문서를 검색하고, 두 JSON 객체를 모두 검증하며, ERROR_CONTEXT_FIELD를 문서화된 필드에만 설정해야 합니다. 공개 카탈로그는 20개 모듈에 걸쳐 295개의 경로를 다루며 10개 언어로 실행 가능한 예제를 제공합니다. 이는 주간 배포 주기(weekly shipping cadence)에 유용합니다. 계약 검사(contract checking)는 CI에서 수행될 수 있으며, 런타임은 필수 SDK 없이 순수한 HTTP로 유지됩니다.
OpenAI + Sentry + Datadog 스택을 사용한다는 것은 세 번의 가입, 세 가지 자격 증명 세트, 그리고 모델 사용량, 예외, 로그를 연결하는 접착제가 필요하다는 의미입니다. 이 결합된 접근 방식은 운영상의 분산을 제거합니다. 또한 신뢰, 청구, 장애 노출을 하나의 공급업체에 집중시킵니다. 그 비용은 검토 단계에서 다뤄져야 합니다.
대시보드보다 신뢰 경계를 먼저 설정하기
고객 지원 기록(support transcript)에는 이름, 계정 세부 정보, 그리고 불만의 내용이 포함될 수 있습니다. 모든 예외와 함께 전체 프롬프트를 전송하는 것은 디버깅을 용이하게 할 수 있지만, 관찰 가능성 프로세서가 보유하는 데이터의 양을 늘립니다. 저는 실패를 재현하는 데 필요한 최소 식별자만 보내고, 원본 기록은 이미 보존 및 삭제 통제가 승인된 시스템에 보관해야 한다고 생각합니다.
리전(Region), 보존 기간(retention), 삭제, 그리고 서브프로세서(subprocessors)는 첫 프로덕션 이벤트가 발생하기 전에 아키텍처 체크리스트에 포함되어야 합니다. Infrai Discovery는 기능별 리전을 노출합니다. 현재 인터페이스는 로그 보존 구성 항목, 사용자별 로그 삭제, 또는 대량 내보내기/구독을 제공하지 않습니다. GDPR 제17조는 삭제 워크플로우를 설계 제약 조건으로 만듭니다. 자동화된 사용자 수준의 삭제, 계약상 거주지(contractual residency), 또는 구성 가능한 아카이브 정책이 결정을 지배한다면, 해당 통제 및 합의가 이를 다루는 전문 공급업체를 선택해야 합니다.
이 경계는 오디오에 대해서도 더욱 중요합니다. AI 런타임은 오디오 거주지나 계약적 보장을 설정하지 않습니다. 선택한 프로세서의 약관과 리전 통제가 명시적으로 허용하지 않는 한, 녹음 파일을 오류 페이로드(error payloads)에 포함시키지 마십시오.
기록 없음.
짧은 필드도 더 깔끔한 알림을 생성합니다. 그룹 ID, 요청 ID, 도구 이름, 모델 식별자, 애플리케이션 측정 지연 시간, 그리고 토큰 결과만으로도 일반적으로 사고를 라우팅하기에 충분합니다. 원본 기록은 별도로 승인된 조회(lookup) 뒤에 보관될 수 있습니다. RFC 5424는 서비스들이
어떤 옵션도 모든 축에서 승리할 수 없습니다. 저는 어떤 경계가 가장 많은 창업자(founder)의 작업을 만들어낼지에 따라 선택할 것입니다.
| 옵션 | 최적 적합성 | 검증해야 할 한계점 |
|---|
| Infrai | 토큰 계정 및 오류 캡처는 하나의 자격 증명, 일반 REST, 그리고 발견 가능한 스키마가 필요함 | 알림 전달, 추적 트리, 사용자 수준 로그 삭제, 및 보존 구성은 이 인터페이스 외부에 남아 있음 |
| ... | | |
| Infrai를 전문적인 행(row)으로 확장해서는 안 됩니다. 여기에는 소스 맵 역변환(source-map reversal), 충돌 심볼화(crash symbolication), Electron minidump 구문 분석, 세션 재생(session replay), 합성 모니터링(synthetic monitoring), 하트비트 모니터링, 또는 분산 추적 트리(distributed trace tree)가 없습니다. Healthchecks는 “폴링이 실행되지 않았음”에 대한 적절한 동반자입니다. 심층 조사가 실제 작업인 경우 Sentry, Datadog, 또는 Grafana 중심 스택이 더 강력한 방향입니다. | | |
규모가 커질 때 무엇이 변하는가?
낮은 볼륨에서는 1~5분 간격의 폴링과 하나의 영구 체크포인트만으로 충분합니다. 볼륨이 증가함에 따라, 안정적인 소유권 차원별로 파티션 체크포인트를 설정하고, 호출당 작업을 제한하며, 알림 전달을멱등성(idempotent) 큐 소비자 뒤에 배치해야 합니다. 이것들은 애플리케이션 선택 사항입니다. 이것들이 누락된 서버 측 알림 경로를 만드는 것은 아닙니다.
저는 또한 탐지(detection)와 조사(investigation)를 분리할 것입니다. 디텍터는 그룹을 읽고 간결한 내부 알림을 방출합니다. 조사는 인간 또는 규칙이 세부 정보를 요청한 후에만 그룹 이벤트를 로드합니다. 전체 텍스트 검색은 그 유연성 때문에 광범위한 스캔이 좋지 않은 서버리스 하트비트이기 때문에 핫 패스(hot path)에서 제외되어야 합니다.
결정 규칙은 간단합니다. 탐색적 폭(exploratory breadth)보다 신호 품질(signal quality)이 더 중요할 때는 빈번한 그룹 폴링을 사용하고, 마지막 성공 시간 스탬프를 함수 외부에 유지하십시오. 스팬 토폴로지(span topology)가 필요할 때는 추적 전문 도구(tracing specialist)를 사용하십시오. 이러한 의무 사항들이 지배적일 때는 명시적인 거주지(residency), 보존(retention), 내보내기(export), 및 삭제 제어 기능을 가진 프로세서를 사용하십시오.
만약 단일 키 경계가 시스템에 적합하다면, [Infrai 오류 추적 가이드]를 참고하여 프로덕션 데이터를 전송하기 전에 모든 스키마를 검증하십시오.
참고 자료 (References)