헬스모니터 폭주 해결 + 통합 모니터링 상태판(한선씨) 신규
1. API 에러 근본원인·해결 (exit 137 = OOM)
- CrownyTVM/server.js 62개 복제 → 6.3GB → 메모리고갈 → crownyc OOM-kill(무출력 exit137).
- 원인:
health-monitor.sh(org.crowny.health-monitor.plist)의 재기동 죽음의소용돌이 — :7730 헬스체크가 메모리압박으로 타임아웃→새 인스턴스 생성→바인드실패해도 종료안함→orphan 6일 누적. - 조치(되돌리기 가능): health-monitor
launchctl bootout+disable+plist→.disabled 백업, orphan 60개 수거(포트보유 2개만 보존). 62→2개, 3.4GB 회수, estEL API 정상복구. 크라우니관제.sh(자율관제v2, gateway.yaml 자가치유)는 정식 감독 → 보존. 재리필 안함 확인.
2. CrownyTVM/server.js 한선씨 대체 판단
15,754줄 모놀리스(체인:9729+TURN:3478+HTTP:7730, estEL/RTC 의존). 한선씨 대체 대상 아님 — 필요한 코어. 문제는 언어가 아니라 깨진 health-monitor였고 이미 제거. 신규·소형만 한선씨.3. 통합 모니터링 상태판 (신규, 순수 한선씨) — health-monitor 알림 대체
- 모니터판.한선(+.rpn, :9614): cowork 댓글/게시글 + 게이트웨이 헬스다운을 한 칸반보드에.
- 워크플로: 미확인→확인→진행중→완료 (GET /set?id&s, data/모니터상태.psv 영속) + 관리(/notify→msg릴레이 :9939).
- 소스: 모니터피드.sh(외부 JSON→얇은 PSV, 체계+jq — 64KB캡 회피). 병합·상태·렌더 로직은 전부 한선씨.
- 영속: launchd
org.crowny.monitor(KeepAlive 단일인스턴스, ThrottleInterval 30). 죽여도 정확히 1개만 재기동 — 폭주 health-monitor와 정반대 구조. - 검증: 13항목 표시, 상태전이 영속·반영, 관리알림 msg릴레이 200, health 200, KeepAlive 재기동 확인.
접속
http://127.0.0.1:9614/ (또는 gateway monitor.crowny.org→9614 배선)남은 것 (사용자 판단)
- gateway 헬스 소스 확대(현 5개 핵심포트 → gateway.yaml 전체), cowork 외 서비스 댓글 소스 추가
- 상태판을 gateway 도메인 승격, 티어 인증
- amti 알림 "스크립트 열기" 문제: 별도 소스(LaunchAgent 아님) — 추적 필요시 지시
4. 3대 확장 완료 (2026-07-04 후속)
① 헬스 소스 전체화: 모니터피드.sh가 gateway.yaml 전 서비스(name+upstream)를 단일 lsof 스냅샷으로 헬스체크 → 다운만 보드에(현 40건 감지). 5개 핵심포트 → 전체. ② monitor.crowny.org 승격: gateway.yaml 기존 crowny-monitor(→죽은 :9743) 발견 → :9614 재지정(aliases monitoring.crowny.org, healthCheck 추가). yaml 백업+파싱검증 OK. ⚠️게이트웨이 핫리로드 없음+수동재시작 wedge위험(메모리) → 다음 게이트웨이 리로드 시 활성. 구 :9743(PID24737)은 라우팅분리(무해, 잔존). ③ amti/ABTI 알림 해결: 소스 추적 = abti-watcher.sh osascript 알림("N건 대기중"인데 클릭→스크립트만 열림). 해결: ABTI requests.json pending을 보드 소스로 편입(확인/진행중/완료 처리 가능) + 알림 subtitle→"monitor.crowny.org 상태판에서 확인·처리". abti-watcher.sh 백업.검증: 보드 53항목(댓글12+헬스40+ABTI1), 상태전이 영속, 3소스 카드 렌더 확인.
활성화 남은 1스텝 (사용자/안전창)
monitor.crowny.org 라우트는 gateway.yaml에 세팅됨 — 게이트웨이 안전 리로드 시 활성(로컬 http://127.0.0.1:9614 즉시 사용가능). 전역 wedge 위험으로 자동 재시작 안 함.5. 게이트웨이 리로드·활성화 (2026-07-04)
monitor.crowny.org 활성화 위해 게이트웨이 리로드(launchctl kickstart -k org.crowny.gateway). ⚠️ 문서화된 wedge 재현: 초기 기동창 000→잠깐 200→runtime wedge(전도메인 000). 재기동 1회 더 + 15초 settle → 완전복구(docs·game·crowny·monitor 3회연속 200).- 성능 수정: 보드 /가 매요청 피드재생성(3.3s)로 게이트 타임아웃 → 피드생성을 org.crowny.monitor.feed(StartInterval 60s) 분리, 보드는 캐시만(0.09s).
- 결과: monitor.crowny.org 라이브(→:9614 통합 상태판), 게이트 안정.
- 교훈 학습: 게이트 리로드 후 20초+ 광역 안정성 3회연속 확인 필수(단일 200 신뢰금지).
- 별개 관찰: msg.crowny.org 게이트 000이나 :9939 서비스는 가동 — 선존 라우팅 이슈(추적 필요시 지시).