HTTP API에서 이벤트 수집하기
목표: 제품의 HTTP API Polling Connector로 이벤트를 수집해 일반 Stream/Route를 통해 Destination으로 전송합니다.화면 버전: 표시된 이미지는 과거 Control UI 테스트 캡처입니다. 현재 제품의 기본 5단계 순서(Connect → Sample & Record Selection → Destinations → Route Processing → Deploy)를 우선하세요. 번호별 화면 가이드에서 차이를 설명합니다.
실행 순서와 완료 기준
- 필수 정보 준비: Vendor 공식 API/연동 가이드에서 Endpoint, 인증 방식, 최소 권한, Pagination/Checkpoint, 응답 샘플을 확인합니다. 테스트용 비식별 이벤트와 실제 Destination 접속 정보를 준비합니다.
- 모르는 항목은 ChatGPT로 정리: 공개 API 문서와 비식별 샘플을 제공하고 Connector 필수 필드, 요청 예시, Event Root, Timestamp/ID, Cursor, 미확인 사항을 표로 요청합니다. Token·비밀번호는 입력하지 않습니다. ChatGPT 답변은 Vendor 문서와 Run Test로 검증합니다.
- Connector 생성: Connectors → Create Connector에서 이 페이지의 해당 Source Type을 선택하고 실제 접속·인증 정보를 입력합니다. 저장하고 연결 테스트를 확인합니다.
- Destination 생성: Destinations → Create에서 실제 수신기 유형(SYSLOG_UDP/TCP/TLS 또는 WEBHOOK_POST)을 선택하고 Host/Port/URL, TLS/인증을 입력합니다.
- Stream 생성: Streams → Create → Connect에서 Connector를 선택하고 Source 요청/수집 조건을 지정합니다.
- 샘플과 스키마: Sample & Record Selection → Run Test에서 실제 레코드가 추출되는지 확인합니다. Record Root, Union Schema, Pagination 및 Checkpoint를 확정합니다.
- 데이터 처리: Destinations에서 Route를 연결하고 Route Processing에서 Mapping, Timestamp, Enrichment, Masking/Drop/Quarantine을 설정합니다. Tokenization은 실제 제품에서 지원되는 경우에만 사용합니다. Route Effective Status와 최종 출력값을 확인합니다.
- 배포와 검증: Deploy의 경고를 해결하고 Stream을 실행합니다. Run ID, Route Logs와 실제 Destination 수신 기록을 비교합니다. 이 세 가지가 일치해야 완료입니다.
- 장애 대응: 연결/인증 오류는 API 권한·TLS·Network·429를, 레코드 0건은 Record Root·Pagination을, 전송 실패는 Delivery Incident를, 필드 변경은 Schema Drift를 확인합니다.
ChatGPT 질문 예시
DataRelay Control에서 이 제품의 로그를 수집하려고 합니다. 아래 공개 API 가이드와 비식별 JSON 샘플을 기준으로 Connector 연결·인증 필수값, API Request/Pagination, Event Root, Timestamp/ID/Checkpoint, Mapping·민감 필드 보호, 장애 시 확인 항목을 표로 작성해 주세요. 문서에 없는 정보는 임의로 생성하지 말고 ‘확인 필요’로 표시하세요.
API 소유자에게 먼저 확보할 정보
실제로 접근 가능한 Base URL, 요청 경로/Method, 인증 방식, 개인정보가 제거된 응답 샘플, Pagination, 이벤트 순서 및 Cursor/Checkpoint 정의가 필요합니다. 아래 주소는 실제로 동작하는 API가 아닌 설명용입니다.1. Connector 만들기
- Connectors → Create Connector로 이동하여 HTTP API Polling을 선택합니다.
- Connector Name, 실제 Host / Base URL을 입력합니다.
- Vendor가 지원하는 인증 방식을 선택하고 Credential을 구성합니다. Secret을 공개 YAML이나 샘플 JSON에 넣지 않습니다.
- Connector를 저장한 뒤 연결 테스트 기능이 제공되면 실제 응답/TLS/권한을 검증합니다.
2. 수집 방법 지정
/streams/new를 열고 Connect에서 앞의 Connector를 선택합니다.- 실제 Endpoint, HTTP Method, Query Parameter를 설정합니다.
- Vendor 문서에 따라 Page/Offset/Cursor 방식의 Pagination을 설정합니다. 제품마다 방식이 다르므로 임의로 추정하지 않습니다.
- Sample & Record Selection → Run Test에서 API 호출을 수행하고 HTTP Status와 응답 JSON을 확인합니다.
- Record Selection에서 실제 이벤트 배열을 지정합니다.
{"events":[...]}구조가 확인될 때만$.events를 선택하고 추출 건수를 검증합니다. - Union Schema에서 필수/드문 필드와 민감 필드 제안을 검토합니다. 자동 제안한 Record Path와 Checkpoint는 사용자 확인 후 사용합니다.
- 이벤트 진행 상태에 사용할 Checkpoint Mode와 Field를 구성합니다. 안정적인 Cursor가 없는 API라면 잘못된 증분 수집을 강행하지 않습니다.



3. Destination 연결 및 배포
- Destinations에서 기존 목적지를 선택합니다. 독립 검증이 필요하면 테스트 수신기를 사용합니다.
- Route Processing에서 Transform, 필요한 Data Protection, Preview를 확인합니다.
- Deploy의 차단 경고를 해결한 후 배포하고, 필요 시 Stream을 시작합니다.
- 실제 수집 Run을 수행하여 Logs의 Route 결과와 Destination 수신 기록을 모두 확인합니다.


4. 증분 수집의 정확도 확인
- Run ID, 수집 이벤트 ID/시간 범위, 실행 전 Checkpoint를 기록합니다.
- 새 이벤트가 없는 상태에서 다음 주기를 실행하고 예상치 못한 중복이 없는지 확인합니다.
- 테스트 가능한 Vendor API라면 새 가상 이벤트를 추가하고 수집·전송·Checkpoint 갱신을 검증합니다.
- 필요한 Destination 전달이 성공하기 전에는 Checkpoint가 전진하지 않아야 합니다.
- Timestamp 중복/순서 변경이 있는 API라면 커서 전략을 수정해야 합니다.
문제 해결
완료 조건: 신규 이벤트가 독립 Destination에 저장되고, 그 이벤트의 Route 전송 로그와 Checkpoint 동작이 일치합니다.
관련: Schema 변경, 전송 장애.
