Redis에 태그를 주입하고 → edge-processor가 집어가는지 → InfluxDB에 기대대로 저장되는지까지 한 번에 확인합니다.
json_v1 해시에 주입 → ② edge-processor의 Cleaner가 해당 field를 지우면 수집된 것 → ③ InfluxDB에서 그 시각의 필드를 조회 → ④ 기대결과와 대조. 스케줄러가 20ms 주기라 보통 수십 ms 안에 끝납니다.| 코드 | 분류 | 시나리오 | |
|---|---|---|---|
| SC-01 | 정상 | 정상 — 숫자 태그 1개 수집·저장 가장 기본 경로. 주입 → Cleaner가 field 삭제(수집 증거) → InfluxDB에 double로 저장되는지 확인한다. | |
| SC-02 | 정상 | 정상 — 문자열 태그 저장 JsonV1Collector.parseValueFromJson은 텍스트를 String으로 그대로 넘기고, InfluxSaver가 string field로 저장한다. | |
| SC-03 | 정상 | 정상 — 다중 태그 그룹 동시 수집 data 배열에 그룹이 여러 개일 때 전부 Tag로 펼쳐져 한 번의 writePoints로 저장되는지 확인한다. | |
| SC-04 | 경계 | 경계 — 임계 직전(-1500ms)은 실시간 수집된다 RedisService.getLatestTimestampKey는 |ts - now| <= time-threshold-ms 인 키만 실시간 대상으로 본다. 기본 2000ms 기준 안쪽. | |
| SC-05 | 경계 | 경계 — 임계 초과(-5000ms)는 실시간 경로에서 빠진다 임계 밖 키는 getMissedTimestampKey로 분류되어 실시간 파이프라인이 건너뛴다. ⚠️ 다만 MissedDataRecoveryService가 10분 주기로 결국 수거하므로, 이 시나리오는 "대기 시간 안에 실시간 수집되지 않음"만 검증한다. | |
| SC-06 | 예외 | 예외 — 미지원 타입(boolean)만 있으면 수집 자체가 실패한다 ⚠️ 위험지점 재현. parseValueFromJson이 boolean을 null로 스킵 → tags가 비어 collect()가 실패 반환 → DataPipelineService가 조기 return → **Cleaner가 호출되지 않아 Redis에 데이터가 그대로 남는다.** missed 복구도 tags가 비면 cleanup 없이 skip하므로 이 키는 계속 쌓인다. | |
| SC-07 | 예외 | 예외 — 숫자와 미지원 타입이 섞이면 숫자만 저장된다 한 field 안에 지원/미지원 타입이 섞이면 지원 타입만 Tag가 되어 저장되고, 미지원 값은 WARN 로그만 남기고 조용히 사라진다. | |
| SC-08 | 예외 | 예외 — 미지원 타입 필드는 InfluxDB에 저장되지 않는다 SC-07과 같은 페이로드로, 이번엔 미지원 필드가 실제로 저장되지 않았는지를 반대편에서 확인한다. | |
| SC-09 | 예외 | 예외 — null 값은 스킵된다 parseValueFromJson은 JSON null을 명시적으로 허용하되 값 없음(null)으로 반환해 태그를 만들지 않는다. 함께 넣은 숫자만 저장되어야 한다. | |
| SC-10 | 정상 | 정상 — 정수 값도 double로 저장된다 valueNode.isNumber()면 asDouble()로 변환하므로 정수를 넣어도 InfluxDB에는 실수로 들어간다. 타입 기대가 어긋나지 않는지 확인한다. |