DefStream 0.1.7__tar.gz → 0.1.9__tar.gz

{defstream-0.1.7 → defstream-0.1.9}/DefStream.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: DefStream
-Version: 0.1.7
+Version: 0.1.9
 Summary: Synchronous message processing with pluggable broker adapters
 Home-page: https://github.com/yong5eon/DefStream
 Author: Heo Yongseon
@@ -59,9 +59,60 @@ DefStream은 메시지 브로커에서 받은 작업을 일반 Python 함수처
 - [생명주기 훅](#생명주기-훅)
 - [요청·응답 계약과 검증](#요청응답-계약과-검증)
 - [상태 확인과 작업 콘솔](#상태-확인과-작업-콘솔)
+- [로깅](#로깅)
 - [브로커 선택과 운영 주의사항](#브로커-선택과-운영-주의사항)
 - [예제와 라이선스](#예제와-라이선스)
 
+## 로깅
+
+DefStream은 표준 `logging`으로 기록하며 핸들러·포매터·레벨을 설정하지 않습니다.
+애플리케이션에서 필요한 출처만 선택해 출력하세요. 샘플은 `Sample`과 `DefStream`
+이름 및 그 하위 로거만 출력하며, 샘플의 `print()`는 로그로 대체했습니다.
+Worker의 기존 시작 배너는 로깅 설정과 무관하게 그대로 출력됩니다.
+
+```python
+from logging import DEBUG, Filter, Formatter, StreamHandler, getLogger
+
+sources = (Filter('Sample'), Filter('DefStream'))
+handler = StreamHandler()
+handler.setFormatter(Formatter(
+  '%(asctime)s %(processName)s %(name)s %(levelname)s %(message)s'
+))
+handler.addFilter(lambda record: any(source.filter(record) for source in sources))
+root = getLogger()
+root.setLevel(DEBUG)
+root.addHandler(handler)
+
+logger = getLogger('Sample')
+logger.info('Application started')
+```
+
+필터는 루트 로거가 아닌 **핸들러**에 적용합니다. `Filter('DefStream')`은
+`DefStream`과 `DefStream.` 하위 이름을 포함하지만 `DefStreamExtra`는 포함하지 않습니다.
+위 설정은 독립 실행 애플리케이션을 위한 예제이며, 이미 있는 다른 핸들러의 출력은 바꾸지 않습니다.
+브로커만 보고 싶으면 `DefStream` 대신 `DefStream.Broker.Implements.RabbitMQ` 또는
+`DefStream.Broker.Implements.Redis`를 선택할 수 있습니다.
+
+- 클래스 멤버 `logger`에 `DefStream.Worker`, `DefStream.Run`, `DefStream.Executor`,
+  `DefStream.Pool`, `DefStream.ThreadPool`, `DefStream.ProcessPool`을 사용합니다.
+- Pool 공통 메서드도 실제 풀의 로거 멤버를 사용합니다. 사용자 하위 클래스는 기본 이름을
+  상속하며 원하면 `logger`를 명시적으로 재정의할 수 있습니다.
+- Inspector·Server·RequestHandler는 `DefStream.Inspector`를 공유합니다.
+  HTTP 요청 수신은 DEBUG, 응답 상태와 전송 결과는 INFO입니다.
+  확장 고유 로그는 `DefStream.Inspector.Extensions.<확장 이름>`을 사용합니다.
+- 정상 메시지별 처리 흐름은 DEBUG, 생명주기는 INFO, 주의할 사건은 WARNING,
+  처리 실패는 ERROR로 기록합니다. 본문·결과·인증정보는 기본 로그에 포함하지 않습니다.
+- 핸들러가 전혀 없으면 Python의 `lastResort`에 의해 WARNING 이상이 stderr에 나올 수 있습니다.
+  사용자 예외 메시지에는 민감한 값을 넣지 마세요. 실패 traceback에 예외 메시지가 포함됩니다.
+
+ProcessPool은 `spawn` 자식 프로세스를 사용하므로 부모의 핸들러가 자동으로 전달되지 않습니다.
+자식도 로그를 출력하려면 import 가능한 `PoolSetup` 구현에서 같은 설정을 적용하고
+`ProcessPool(..., setups=...)`로 전달하세요. 자식 초기화 훅이 실행되기 전의 DEBUG·INFO는
+그 설정으로 수신할 수 없습니다.
+[RabbitMQ 작업 예제의 LoggingSetup](./sample/Worker/RabbitMQ/Tasks.py)과
+[부모·자식 설정 예제](./sample/Worker/RabbitMQ/Worker.py)를 참고하세요.
+기존 애플리케이션에서는 이미 설정한 핸들러를 반복 추가하지 않도록 초기화 위치를 관리해야 합니다.
+
 ## 설치
 
 Python **3.9 이상**이 필요합니다. 실제 메시지 처리를 위해 사용할 브로커 서버도 준비하세요.

{defstream-0.1.7 → defstream-0.1.9}/DefStream.egg-info/SOURCES.txt

@@ -14,10 +14,17 @@ issues/feature/1/README.md
 issues/feature/1/REQUIREMENTS.md
 issues/feature/1/TASK.md
 issues/feature/1/ci.refs.json
+issues/feature/8/IMPLEMENTS.md
+issues/feature/8/README.md
+issues/feature/8/REQUIREMENTS.md
+issues/feature/8/ci.refs.json
 issues/fix/3/IMPLEMENTS.md
 issues/fix/3/README.md
 issues/fix/3/REQUIREMENTS.md
 issues/fix/3/ci.refs.json
+issues/fix/6/IMPLEMENTS.md
+issues/fix/6/README.md
+issues/fix/6/REQUIREMENTS.md
 sample/Broker/Sample.py
 sample/Worker/Sample.py
 sample/Worker/RabbitMQ/Client.py
@@ -77,9 +84,12 @@ src/Worker/Worker.py
 src/Worker/__init__.py
 test/test_dashboard.py
 test/test_dashboard_ui.cjs
+test/test_descriptor.py
 test/test_inspector.py
 test/test_inspector_console.py
+test/test_inspector_logging.py
 test/test_lifecycle_hooks.py
+test/test_logging.py
 test/test_pool_callbacks.py
 test/test_process_signals.py
 test/test_protocol_contracts.py

{defstream-0.1.7 → defstream-0.1.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: DefStream
-Version: 0.1.7
+Version: 0.1.9
 Summary: Synchronous message processing with pluggable broker adapters
 Home-page: https://github.com/yong5eon/DefStream
 Author: Heo Yongseon
@@ -59,9 +59,60 @@ DefStream은 메시지 브로커에서 받은 작업을 일반 Python 함수처
 - [생명주기 훅](#생명주기-훅)
 - [요청·응답 계약과 검증](#요청응답-계약과-검증)
 - [상태 확인과 작업 콘솔](#상태-확인과-작업-콘솔)
+- [로깅](#로깅)
 - [브로커 선택과 운영 주의사항](#브로커-선택과-운영-주의사항)
 - [예제와 라이선스](#예제와-라이선스)
 
+## 로깅
+
+DefStream은 표준 `logging`으로 기록하며 핸들러·포매터·레벨을 설정하지 않습니다.
+애플리케이션에서 필요한 출처만 선택해 출력하세요. 샘플은 `Sample`과 `DefStream`
+이름 및 그 하위 로거만 출력하며, 샘플의 `print()`는 로그로 대체했습니다.
+Worker의 기존 시작 배너는 로깅 설정과 무관하게 그대로 출력됩니다.
+
+```python
+from logging import DEBUG, Filter, Formatter, StreamHandler, getLogger
+
+sources = (Filter('Sample'), Filter('DefStream'))
+handler = StreamHandler()
+handler.setFormatter(Formatter(
+  '%(asctime)s %(processName)s %(name)s %(levelname)s %(message)s'
+))
+handler.addFilter(lambda record: any(source.filter(record) for source in sources))
+root = getLogger()
+root.setLevel(DEBUG)
+root.addHandler(handler)
+
+logger = getLogger('Sample')
+logger.info('Application started')
+```
+
+필터는 루트 로거가 아닌 **핸들러**에 적용합니다. `Filter('DefStream')`은
+`DefStream`과 `DefStream.` 하위 이름을 포함하지만 `DefStreamExtra`는 포함하지 않습니다.
+위 설정은 독립 실행 애플리케이션을 위한 예제이며, 이미 있는 다른 핸들러의 출력은 바꾸지 않습니다.
+브로커만 보고 싶으면 `DefStream` 대신 `DefStream.Broker.Implements.RabbitMQ` 또는
+`DefStream.Broker.Implements.Redis`를 선택할 수 있습니다.
+
+- 클래스 멤버 `logger`에 `DefStream.Worker`, `DefStream.Run`, `DefStream.Executor`,
+  `DefStream.Pool`, `DefStream.ThreadPool`, `DefStream.ProcessPool`을 사용합니다.
+- Pool 공통 메서드도 실제 풀의 로거 멤버를 사용합니다. 사용자 하위 클래스는 기본 이름을
+  상속하며 원하면 `logger`를 명시적으로 재정의할 수 있습니다.
+- Inspector·Server·RequestHandler는 `DefStream.Inspector`를 공유합니다.
+  HTTP 요청 수신은 DEBUG, 응답 상태와 전송 결과는 INFO입니다.
+  확장 고유 로그는 `DefStream.Inspector.Extensions.<확장 이름>`을 사용합니다.
+- 정상 메시지별 처리 흐름은 DEBUG, 생명주기는 INFO, 주의할 사건은 WARNING,
+  처리 실패는 ERROR로 기록합니다. 본문·결과·인증정보는 기본 로그에 포함하지 않습니다.
+- 핸들러가 전혀 없으면 Python의 `lastResort`에 의해 WARNING 이상이 stderr에 나올 수 있습니다.
+  사용자 예외 메시지에는 민감한 값을 넣지 마세요. 실패 traceback에 예외 메시지가 포함됩니다.
+
+ProcessPool은 `spawn` 자식 프로세스를 사용하므로 부모의 핸들러가 자동으로 전달되지 않습니다.
+자식도 로그를 출력하려면 import 가능한 `PoolSetup` 구현에서 같은 설정을 적용하고
+`ProcessPool(..., setups=...)`로 전달하세요. 자식 초기화 훅이 실행되기 전의 DEBUG·INFO는
+그 설정으로 수신할 수 없습니다.
+[RabbitMQ 작업 예제의 LoggingSetup](./sample/Worker/RabbitMQ/Tasks.py)과
+[부모·자식 설정 예제](./sample/Worker/RabbitMQ/Worker.py)를 참고하세요.
+기존 애플리케이션에서는 이미 설정한 핸들러를 반복 추가하지 않도록 초기화 위치를 관리해야 합니다.
+
 ## 설치
 
 Python **3.9 이상**이 필요합니다. 실제 메시지 처리를 위해 사용할 브로커 서버도 준비하세요.

{defstream-0.1.7 → defstream-0.1.9}/README.en.md

@@ -30,6 +30,13 @@ Configure execution, acknowledgements, failure policies, and monitoring without
 - [Broker selection and operational considerations](#broker-selection-and-operational-considerations)
 - [Examples and license](#examples-and-license)
 
+## 로깅 지원
+
+클래스별 표준 로거와 사용자 주도 핸들러 설정을 지원합니다.
+샘플은 `Sample` 및 `DefStream` 계층만 출력하며, ProcessPool 자식은 별도 setup 훅으로
+출력을 설정합니다. Worker의 시작 배너는 유지됩니다.
+로거 이름, 선택 수신, 예외 메시지 주의사항과 프로세스 설정은 [로깅 안내](./README.md#로깅)를 참고하세요.
+
 ## Installation
 
 Requires Python **3.9 or newer**. Prepare the broker server you intend to use.

{defstream-0.1.7 → defstream-0.1.9}/README.md

@@ -26,9 +26,60 @@ DefStream은 메시지 브로커에서 받은 작업을 일반 Python 함수처
 - [생명주기 훅](#생명주기-훅)
 - [요청·응답 계약과 검증](#요청응답-계약과-검증)
 - [상태 확인과 작업 콘솔](#상태-확인과-작업-콘솔)
+- [로깅](#로깅)
 - [브로커 선택과 운영 주의사항](#브로커-선택과-운영-주의사항)
 - [예제와 라이선스](#예제와-라이선스)
 
+## 로깅
+
+DefStream은 표준 `logging`으로 기록하며 핸들러·포매터·레벨을 설정하지 않습니다.
+애플리케이션에서 필요한 출처만 선택해 출력하세요. 샘플은 `Sample`과 `DefStream`
+이름 및 그 하위 로거만 출력하며, 샘플의 `print()`는 로그로 대체했습니다.
+Worker의 기존 시작 배너는 로깅 설정과 무관하게 그대로 출력됩니다.
+
+```python
+from logging import DEBUG, Filter, Formatter, StreamHandler, getLogger
+
+sources = (Filter('Sample'), Filter('DefStream'))
+handler = StreamHandler()
+handler.setFormatter(Formatter(
+  '%(asctime)s %(processName)s %(name)s %(levelname)s %(message)s'
+))
+handler.addFilter(lambda record: any(source.filter(record) for source in sources))
+root = getLogger()
+root.setLevel(DEBUG)
+root.addHandler(handler)
+
+logger = getLogger('Sample')
+logger.info('Application started')
+```
+
+필터는 루트 로거가 아닌 **핸들러**에 적용합니다. `Filter('DefStream')`은
+`DefStream`과 `DefStream.` 하위 이름을 포함하지만 `DefStreamExtra`는 포함하지 않습니다.
+위 설정은 독립 실행 애플리케이션을 위한 예제이며, 이미 있는 다른 핸들러의 출력은 바꾸지 않습니다.
+브로커만 보고 싶으면 `DefStream` 대신 `DefStream.Broker.Implements.RabbitMQ` 또는
+`DefStream.Broker.Implements.Redis`를 선택할 수 있습니다.
+
+- 클래스 멤버 `logger`에 `DefStream.Worker`, `DefStream.Run`, `DefStream.Executor`,
+  `DefStream.Pool`, `DefStream.ThreadPool`, `DefStream.ProcessPool`을 사용합니다.
+- Pool 공통 메서드도 실제 풀의 로거 멤버를 사용합니다. 사용자 하위 클래스는 기본 이름을
+  상속하며 원하면 `logger`를 명시적으로 재정의할 수 있습니다.
+- Inspector·Server·RequestHandler는 `DefStream.Inspector`를 공유합니다.
+  HTTP 요청 수신은 DEBUG, 응답 상태와 전송 결과는 INFO입니다.
+  확장 고유 로그는 `DefStream.Inspector.Extensions.<확장 이름>`을 사용합니다.
+- 정상 메시지별 처리 흐름은 DEBUG, 생명주기는 INFO, 주의할 사건은 WARNING,
+  처리 실패는 ERROR로 기록합니다. 본문·결과·인증정보는 기본 로그에 포함하지 않습니다.
+- 핸들러가 전혀 없으면 Python의 `lastResort`에 의해 WARNING 이상이 stderr에 나올 수 있습니다.
+  사용자 예외 메시지에는 민감한 값을 넣지 마세요. 실패 traceback에 예외 메시지가 포함됩니다.
+
+ProcessPool은 `spawn` 자식 프로세스를 사용하므로 부모의 핸들러가 자동으로 전달되지 않습니다.
+자식도 로그를 출력하려면 import 가능한 `PoolSetup` 구현에서 같은 설정을 적용하고
+`ProcessPool(..., setups=...)`로 전달하세요. 자식 초기화 훅이 실행되기 전의 DEBUG·INFO는
+그 설정으로 수신할 수 없습니다.
+[RabbitMQ 작업 예제의 LoggingSetup](./sample/Worker/RabbitMQ/Tasks.py)과
+[부모·자식 설정 예제](./sample/Worker/RabbitMQ/Worker.py)를 참고하세요.
+기존 애플리케이션에서는 이미 설정한 핸들러를 반복 추가하지 않도록 초기화 위치를 관리해야 합니다.
+
 ## 설치
 
 Python **3.9 이상**이 필요합니다. 실제 메시지 처리를 위해 사용할 브로커 서버도 준비하세요.

defstream-0.1.9/issues/feature/8/IMPLEMENTS.md

@@ -0,0 +1,106 @@
+# 로깅 지원 구현 기록
+
+## 1. 구현 개요
+
+[요구사항](./REQUIREMENTS.md)에 따라 Worker 실행 흐름과 Inspector에 Python 표준
+`logging`을 적용했다. 출력 정책은 애플리케이션에 맡기고 클래스별 명시적 로거로
+관찰 지점을 제공한다.
+
+- 구현·검증일: 2026-10-20
+- 사용자용 안내: [변경 로그](./README.md)
+- 연계 구현: [RabbitMQ](../../../../DefStream-RabbitMQ/issues/feature/5/IMPLEMENTS.md),
+  [Redis](../../../../DefStream-Redis/issues/feature/5/IMPLEMENTS.md)
+
+## 2. 클래스별 로거와 기록 책임
+
+로거는 클래스 멤버 `logger`로 정의하고 공통 메서드는 `self.logger`를 사용한다.
+사용자 하위 클래스의 이름을 자동으로 사용하지 않으며, 명시적으로 재정의할 수 있다.
+
+| 대상 | 로거 이름 | 구현한 관찰 지점 |
+| --- | --- | --- |
+| [Worker](../../../src/Worker/Worker.py) | `DefStream.Worker` | 작업 등록, 연결·구독·훅, 수신·제출, 성공·실패 정책, 종료·미확인 메시지 |
+| [Pool](../../../src/Worker/Pool.py) | `DefStream.Pool` | 제출, 포화, 슬롯 반환, 완료 대기와 종료 |
+| ThreadPool·ProcessPool | `DefStream.ThreadPool`·`DefStream.ProcessPool` | 구체 풀 구성과 상속받은 공통 동작 |
+| [Executor](../../../src/Worker/Executor.py) | `DefStream.Executor` | 실행 환경 시작·종료, 작업·결과 전달과 실행 환경 장애 |
+| [Run](../../../src/Worker/Run.py) | `DefStream.Run` | 작업 전체 이름, 훅·입출력 검증·실행 단계와 소요 시간 |
+| [Inspector·Server·RequestHandler](../../../src/Inspector/Inspector.py) | `DefStream.Inspector` | 확장 등록·시작, 서버 생명주기, HTTP 수신·응답과 내부 오류 |
+| [Inspector 확장](../../../src/Inspector/Extensions) | `DefStream.Inspector.Extensions.<클래스 이름>` | HealthCheck·Console·Metrics·Dashboard·Specifications의 고유 처리 |
+
+ThreadPool·ProcessPool의 공통 처리는 구체 클래스의 로거로 기록한다.
+`Specification`에는 독립 로거를 추가하지 않았다.
+
+## 3. 레벨과 실패 처리
+
+- INFO: Worker·풀·실행 환경·서버의 생명주기와 HTTP 응답 전송 결과.
+- DEBUG: 메시지별 정상 처리, 작업 실행·검증·훅, 풀 포화와 확장 고유 진단.
+- WARNING: 잘못된 메시지, 명시적 완료 대기의 시간 초과와 Console 요청 거부 등.
+- ERROR: 작업·실행 환경·서버·확장 내부 실패와 종료 후 확인 처리 불가.
+
+Worker로 전달되는 작업 실패의 최종 ERROR와 traceback은 Worker가 담당한다.
+Run·Pool·Executor의 일반 작업 실패 추적은 DEBUG로 기록해 중복을 줄였다.
+Mapping이 아닌 메시지의 거부는 WARNING으로 구분하고 기존 실패 정책 호출은 유지했다.
+Run을 직접 호출했을 때의 예외 전파도 유지한다.
+
+## 4. Inspector의 HTTP 기록
+
+기본 WSGI 요청 처리 경계를 확장하여 다음을 기록한다.
+
+- 파싱한 요청 수신: DEBUG, HTTP 메서드와 쿼리를 제외한 경로.
+- 응답 전송 결과: INFO, 메서드·경로·상태 코드·응답 크기·소요 시간.
+- WSGI·연결 처리 실패: ERROR, 예외 타입과 프레임의 파일·줄·함수 위치.
+
+확장에서는 공통 HTTP 접근 로그를 반복하지 않는다. 전송 중단을 정상 전송으로
+기록하지 않으며, 오류 기록에는 예외 문자열과 소스 코드 줄을 포함하지 않는다.
+HealthCheck는 probe 예약·응답·판정과 응답 생성을 DEBUG로 기록하고,
+예약 실패를 ERROR로 기록한다. 상태 변화 전용 INFO·WARNING은 추가하지 않았다.
+
+## 5. 출력 설정과 샘플
+
+- 라이브러리는 핸들러·NullHandler·포매터·필터·레벨을 설정하지 않는다.
+- 루트 로거까지 기본 전파를 유지하며, 미설정 시 표준 `logging.lastResort`가
+  WARNING 이상을 stderr에 출력할 수 있다.
+- 런타임 로그 메시지는 영어로 작성하고 한국어 문서·주석은 유지한다.
+- 본문·결과·인증정보를 기본 문맥에 넣지 않는다. 단, Worker의 작업 실패
+  traceback에는 사용자 예외 메시지가 포함될 수 있으므로 사용자가 주의해야 한다.
+- [Worker 샘플](../../../sample/Worker)과 [Broker 샘플](../../../sample/Broker)은
+  `Sample`과 `DefStream` 계층만 핸들러 필터로 선택한다.
+- 샘플의 `print()`는 로그로 전환하고 라이브러리 시작 배너는 유지했다.
+- [RabbitMQ Worker 샘플](../../../sample/Worker/RabbitMQ/Worker.py)은 부모 진입점과
+  ProcessPool의 `setups`에 [LoggingSetup](../../../sample/Worker/RabbitMQ/Tasks.py)을
+  적용한다. `spawn` 자식이 부모의 핸들러를 자동 상속한다고 가정하지 않는다.
+
+## 6. 검증 결과
+
+Python 3.13.16에서 실제 RabbitMQ·Redis가 실행 중인 환경으로 검증했다.
+
+| 검증 범위 | 결과 |
+| --- | --- |
+| 코어 로깅·Inspector·Worker·풀·훅·프로세스·메시지 관련 테스트 | 151개 통과 |
+| RabbitMQ 연계 테스트 | 52개 통과 |
+| Redis 연계 테스트 | 25개 통과 |
+| 세 프로젝트 소스·샘플의 로그 및 observe 호출 문자열 | 376곳 점검, 한국어 문자열 없음 |
+| 세 프로젝트 소스·샘플 `compileall` 및 `git diff --check` | 통과 |
+
+[로깅 테스트](../../../test/test_logging.py)는 클래스 멤버·상속·사용자 재정의,
+레벨·본문 제외·작업 실패 traceback 중복 방지·배너 유지·샘플 필터·spawn 설정을
+검증한다. [Inspector 로깅 테스트](../../../test/test_inspector_logging.py)는 실제 HTTP
+요청에서 수신·응답 각 1회 기록, 쿼리·본문 제외, WSGI 500과 전송 중단을 검증한다.
+기존 테스트의 이전 모듈 로거 기대값도 새 이름과 레벨에 맞췄다.
+
+위 228개는 선택해 실행한 관련 테스트의 합계이며 코어 전체 테스트 실행을 뜻하지 않는다.
+모든 Python 버전·모든 파일의 정적 타입 검사나 배포 검증을 완료한 것은 아니다.
+
+### 재검증
+
+개발 가상환경과 로컬 브로커가 준비된 작업공간 루트에서 실행한다.
+통합 테스트는 브로커에 테스트 자원을 생성·정리하므로 운영 환경을 사용하지 않는다.
+
+```powershell
+$env:PYTHONIOENCODING = 'utf-8'
+$env:DEFSTREAM_RABBITMQ_TESTS = '1'
+$env:DEFSTREAM_REDIS_TESTS = '1'
+Set-Location .\DefStream\test
+& ..\..\.venv\Scripts\python.exe -m unittest test_logging test_inspector_logging test_worker test_worker_startup test_pool_callbacks test_runner_hooks test_lifecycle_hooks test_process_signals test_inspector test_inspector_console test_dashboard test_specifications test_protocol_contracts test_task_messages
+```
+
+브로커별 재검증 명령은 각 구현 기록을 참고한다.

defstream-0.1.9/issues/feature/8/README.md

@@ -0,0 +1,40 @@
+# 로깅 지원
+
+## 변경 요약
+
+Worker와 Inspector의 동작을 클래스별 표준 로거로 관찰할 수 있습니다.
+라이브러리는 로그를 기록하며, 출력 대상·형식·레벨·필터는 애플리케이션이 정합니다.
+런타임 로그 메시지는 영어입니다.
+
+## 추가한 기록
+
+- `DefStream.Worker`: 등록·시작·수신·완료·실패·종료.
+- `DefStream.Run`: 작업별 훅·입출력 검증·실행 단계.
+- `DefStream.Pool`, `DefStream.ThreadPool`, `DefStream.ProcessPool`,
+  `DefStream.Executor`: 실행 환경·제출·결과 회수·대기·종료.
+- `DefStream.Inspector`: 서버 생명주기, 요청 수신(DEBUG), 응답 상태·크기·시간(INFO).
+- `DefStream.Inspector.Extensions.<클래스 이름>`: 각 확장 고유 진단.
+
+정상 메시지별 상세 흐름은 DEBUG, 주요 생명주기는 INFO로 확인할 수 있습니다.
+잘못된 메시지와 대기 시간 초과는 WARNING, 작업·내부 처리 실패는 ERROR로 구분합니다.
+Pool 공통 동작도 실제 ThreadPool·ProcessPool의 로거 이름으로 기록됩니다.
+
+## 사용자 설정과 호환성
+
+- 기존 `DefStream.Worker.Worker` 등 모듈 경로 기반 이름으로 필터링했다면
+  새 클래스별 이름으로 바꾸세요. `DefStream` 계층 전체 수신도 가능합니다.
+- 클래스 멤버 `logger`를 상속하며 사용자 하위 클래스에서 재정의할 수 있습니다.
+  사용자 작업이 직접 생성한 로거 이름은 프레임워크가 바꾸지 않습니다.
+- 핸들러·NullHandler·레벨을 자동 설정하지 않습니다.
+  핸들러가 없으면 Python의 `lastResort`로 WARNING 이상이 출력될 수 있습니다.
+- 본문·결과·인증정보는 기본 로그 문맥에서 제외합니다. 사용자 예외 메시지는
+  Worker의 실패 traceback에 포함될 수 있으므로 민감정보를 넣지 마세요.
+- 작업 처리·정산·종료 계약과 기존 시작 배너는 유지합니다.
+
+## 샘플 변경
+
+샘플은 `print()` 대신 `Sample` 로거를 사용하며 `Sample`과 `DefStream` 계층만
+출력합니다. [RabbitMQ Worker 샘플](../../../sample/Worker/RabbitMQ/Worker.py)은
+부모와 spawn 자식에 [LoggingSetup](../../../sample/Worker/RabbitMQ/Tasks.py)을 적용합니다.
+실제 애플리케이션도 ProcessPool 자식의 로깅을 별도로 설정해야 합니다.
+설정 예제는 [사용 설명서](../../../README.md#로깅)를 참고하세요.

defstream-0.1.9/issues/feature/8/REQUIREMENTS.md

@@ -0,0 +1,168 @@
+# 로깅 지원
+
+## 1. 목적과 범위
+
+- 개발자가 Worker의 시작부터 작업 실행, 메시지 완료 처리, 종료까지 추적할 수 있도록 풍부한 진단 로그를 제공한다.
+- Inspector 및 확장의 시작, HTTP 요청 처리, 상태 확인과 내부 실패를 관찰할 수 있게 한다.
+- Python 표준 `logging`을 사용하며, 출력 대상·형식·레벨·필터는 사용자 애플리케이션이 결정한다.
+- 이 문서는 현재 소스 조사와 사용자 검토를 반영한 요구사항이다. 클래스별 로거 이름과 HTTP 기록 책임은 아래와 같이 확정한다.
+- 이 요구사항에 따라 소스와 샘플의 로깅을 구현한다. 라이브러리용 로깅 초기화 API와 사용자용 `LOG_*` 함수는 범위에 포함하지 않는다.
+- 브로커 구현체는 별도 명세를 따른다.
+  - [DefStream-RabbitMQ 로깅 지원](../../../../DefStream-RabbitMQ/issues/feature/5/REQUIREMENTS.md)
+  - [DefStream-Redis 로깅 지원](../../../../DefStream-Redis/issues/feature/5/REQUIREMENTS.md)
+
+## 2. 로거 이름과 사용자 설정
+
+- 모듈 경로를 그대로 사용하는 `getLogger(__name__)` 대신, 클래스마다 명시적으로 정한 고정 이름을 사용한다.
+- 로거는 클래스 멤버로 보관한다. 기반 클래스의 공통 메서드는 해당 멤버를 사용하고, 구체 클래스는 필요한 경우 자신의 명시적 로거 멤버를 정의한다.
+- Worker 계열 이름은 `DefStream.ClassName` 형식이다.
+- Inspector·Server·RequestHandler는 `DefStream.Inspector` 이름을 공유한다.
+- 내장 확장은 `DefStream.Inspector.Extensions.ExtensionName` 형식이다.
+- 프레임워크 로그의 이름을 사용자 정의 하위 클래스의 모듈·클래스 이름으로 자동 변경하지 않는다.
+  - 사용자 `SendEmail`이 `Run`을 상속해도 기반 실행 흐름 로그는 `DefStream.Run`으로 기록한다.
+  - 실제 작업의 `모듈명.클래스명`은 별도 문맥으로 남겨 작업들을 구분한다.
+- 사용자 정의 작업에서 직접 호출한 로깅의 이름·동작은 변경하지 않는다.
+- 샘플은 `Sample` 로거를 사용하고, 샘플에서 설정한 출력 핸들러는 `Sample`과 `DefStream` 계층만 수신한다. 샘플의 `print()`는 DEBUG·INFO 로그로 대체하되 라이브러리의 시작 배너는 유지한다.
+- 클래스별 이름과 상위 `DefStream`, `DefStream.Inspector`에서 선택적으로 수신할 수 있어야 한다.
+- 루트 로거로의 기본 전파를 막지 않으며, 라이브러리가 `basicConfig()`, 출력 핸들러, 포매터, 필터, 로그 레벨을 임의로 설정하지 않는다.
+- DefStream은 로그 기록만 수행하며 출력 핸들러뿐 아니라 `NullHandler`도 추가하지 않는다. 로그 수신·출력 설정은 사용자 애플리케이션의 책임이다.
+- 사용자가 핸들러를 설정하지 않으면 Python 표준 동작인 `logging.lastResort`에 의해 WARNING 이상이 stderr에 출력될 수 있다. 이번 요구사항은 미설정 상태의 완전한 무출력을 보장하지 않는다.
+
+## 3. 현재 상태
+
+- [Worker](../../../src/Worker/Worker.py)의 모듈 로거가 작업 실패, 미확인 메시지를 남긴 종료, 종료 후 메시지 확인 처리 불가를 ERROR로 기록한다.
+- [Inspector](../../../src/Inspector/Inspector.py)의 모듈 로거가 HTTP 접근 기록을 INFO로, 서버 실행 실패를 예외 로그로 기록한다.
+- [Console](../../../src/Inspector/Extensions/Console.py)은 인증·출처·입력 거부, RPC 실패, 내부 요청 처리 실패를 기록한다.
+- [HealthCheck](../../../src/Inspector/Extensions/HealthCheck.py)는 상태 확인 작업 예약 실패를 예외 로그로 기록한다.
+- 다른 Worker 모듈과 나머지 Inspector 확장에는 현재 직접적인 로깅 호출이 없다.
+- [Startup](../../../src/Worker/Startup.py)은 로거 대신 `print()`로 시작 배너와 구성을 출력한다.
+
+## 4. 클래스별 로거 이름
+
+아래 이름을 사용한다. 확장은 고유한 내부 처리와 진단에 필요한 로그만 기록하며, 공통 HTTP 접근 기록을 반복하지 않는다.
+
+| 구분 | 클래스와 소스 | 로거 이름 | 필요한 관찰 범위 |
+| --- | --- | --- | --- |
+| 우선 대상 | [Worker](../../../src/Worker/Worker.py) | `DefStream.Worker` | 등록·시작·수신·완료·실패·종료의 전체 조정 |
+| 공통 구현 | [Pool](../../../src/Worker/Pool.py) | `DefStream.Pool` (직접 생성 시) | 제출 수락·포화·슬롯 반환·완료 대기를 기록하며, 내장 구체 풀에서는 구체 클래스의 로거 멤버를 사용 |
+| 우선 대상 | [ThreadPool](../../../src/Worker/Pool.py) | `DefStream.ThreadPool` | 스레드 풀 구성 및 상속받은 Pool 공통 동작 |
+| 우선 대상 | [ProcessPool](../../../src/Worker/Pool.py) | `DefStream.ProcessPool` | 프로세스 풀 구성 및 상속받은 Pool 공통 동작 |
+| 우선 대상 | [Executor](../../../src/Worker/Executor.py) | `DefStream.Executor` | 실행 환경 시작·종료, 작업 전달·결과 회수, 실행 환경 장애 |
+| 우선 대상 | [Run](../../../src/Worker/Run.py) | `DefStream.Run` | 사용자 작업을 감싸는 훅·검증·실행 단계 |
+| 우선 대상 | [Inspector](../../../src/Inspector/Inspector.py) | `DefStream.Inspector` | 확장 등록·시작, HTTP 서버 생명주기와 요청 처리 |
+| 보조 대상 | [Server](../../../src/Inspector/Inspector.py) | `DefStream.Inspector` (공유) | HTTP 서버의 연결 처리 문맥. Inspector와 중복되는 생명주기 로그는 제외 |
+| 보조 대상 | [RequestHandler](../../../src/Inspector/Inspector.py) | `DefStream.Inspector` (공유) | 공통 HTTP 요청 수신(DEBUG)과 응답 상태를 포함한 전송 결과(INFO) |
+| 우선 대상 | [HealthCheck](../../../src/Inspector/Extensions/HealthCheck.py) | `DefStream.Inspector.Extensions.HealthCheck` | 상태 확인 작업 예약·응답·시간 초과·상태 변화 |
+| 우선 대상 | [Console](../../../src/Inspector/Extensions/Console.py) | `DefStream.Inspector.Extensions.Console` | 요청 검증·발행·RPC·접근 거부·내부 오류 |
+| 우선 대상 | [Metrics](../../../src/Inspector/Extensions/Metrics.py) | `DefStream.Inspector.Extensions.Metrics` | 수집 초기화, 작업 관측 시작·종료, 스냅샷·응답 생성 |
+| 우선 대상 | [Dashboard](../../../src/Inspector/Extensions/Dashboard.py) | `DefStream.Inspector.Extensions.Dashboard` | Metrics 연결, HTML·JSON 응답 생성 |
+| 우선 대상 | [Specifications](../../../src/Inspector/Extensions/Specifications.py) | `DefStream.Inspector.Extensions.Specifications` | 작업 목록의 AsyncAPI 문서 생성과 응답 |
+
+### 4.1. 독립 로거를 우선 추가하지 않을 대상
+
+| 대상 | 판단 근거와 기록 책임 |
+| --- | --- |
+| [Specification](../../../src/Worker/Specification.py) | 독립 로깅 대상에서 제외한다. 입력·출력 검증 단계와 실패는 Run·Worker에서 관찰한다. Inspector의 Specifications 확장과는 별개이다. |
+| [Handler](../../../src/Worker/Worker.py) | Worker의 `receive()`로 전달하는 어댑터이다. 수신 로그는 Worker에서 기록한다. |
+| [WorkerSetup·WorkerCleanup](../../../src/Worker/Worker.py), [PoolSetup·PoolCleanup](../../../src/Worker/Pool.py), [RunSetup·RunComplete·RunError](../../../src/Worker/Run.py) | 사용자 구현용 추상 계약이다. 호출 전후를 프레임워크의 호출 지점에서 기록하며 구현체 내부 로그는 사용자가 정한다. |
+| [Context](../../../src/Worker/Run.py), [PoolFull](../../../src/Worker/Pool.py) | 문맥 보관 객체와 예외 타입이다. 생성 자체를 별도 로깅하지 않는다. |
+| [Extension](../../../src/Inspector/Extension.py) | 기본 훅은 동작이 없거나 구체 확장으로 위임한다. 등록·호출은 Inspector, 구체 동작은 해당 확장에서 기록한다. |
+| [Response](../../../src/Inspector/Response.py), [TaskMetrics·스냅샷 타입](../../../src/Inspector/Extensions/Metrics.py) | 응답·집계·데이터 표현 객체이다. 생성이나 필드별 갱신을 별도 로거로 기록하지 않는다. |
+| [Broker 계약](../../../src/Broker/Connection.py)과 [기본 Consumer](../../../src/Broker/Consumer.py) | 인터페이스 및 공통 위임이다. 실제 I/O 로그는 구현체에서 기록한다. |
+| [Requeue·Reject](../../../src/Broker/Policies.py) | Event의 `nack()`·`reject()`로 위임한다. Worker/Consumer에서 정책 선택, 구현체 Event에서 실제 처리 결과를 기록한다. |
+| [Descriptor](../../../src/Descriptor)·[Validator](../../../src/Validator) 계열 | 값 변환·검증의 세부 재귀 호출마다 로그를 추가하지 않는다. 작업 경계의 Run에서 단계와 실패를 추적한다. |
+
+### 4.2. 클래스가 아닌 처리의 귀속
+
+- [Startup.startup()](../../../src/Worker/Startup.py): 기존 `print()` 시작 배너와 구성 출력을 유지한다. 로그로 대체하거나 동일한 배너를 중복 로깅하지 않는다. Worker의 생명주기 로그는 별도로 기록한다.
+- [Executor의 execute_loop()·initialize_process()](../../../src/Worker/Executor.py): 스레드·프로세스 내부 실행 로그는 `DefStream.Executor`에 귀속하는 후보로 둔다.
+- [Executor의 run_cleanups()](../../../src/Worker/Executor.py): Worker 종료와 실행 환경 종료에서 함께 사용한다. 훅 호출 주체의 로거에서 기록하여 중복을 피한다.
+- [Message의 declare()·emit()·request()](../../../src/Worker/Message.py): 클래스가 없는 공통 API이므로 새 클래스나 임의의 로거 이름을 만들지 않는다. 이번 초안에서는 실제 브로커 구현체와 Console 호출 지점에서 기록한다.
+- Pool 공통 메서드의 `self`는 실제 ThreadPool·ProcessPool 인스턴스이므로 구체 풀에 명시적으로 지정한 로거를 사용한다. 두 내장 풀의 공통 동작이 `DefStream.Pool`로 기록되지 않도록 한다.
+- 사용자 하위 클래스는 기반 ThreadPool·ProcessPool의 명시적 이름을 유지한다. 단순히 `type(self).__name__`으로 로거 이름을 자동 생성하지 않는다.
+- Pool은 추상 클래스가 아니며 외부 executor를 받아 직접 생성할 수 있는 기존 공개 API이다. 클래스 멤버의 이름은 `DefStream.Pool`로 두고, ThreadPool·ProcessPool은 각각 자신의 명시적 로거 멤버를 정의한다. 별도 이름 판별·주입 API를 추가하지 않는다.
+
+## 5. 레벨별 기록 요구사항
+
+### 5.1. Worker
+
+- INFO: 시작 시도, 구독을 마치고 수신 가능한 상태, 최초 종료 요청, 실행 중 작업 정리 대기, 실제 자원 정리를 마친 종료.
+- DEBUG: 작업 등록, broker 연결·Consumer 생성 단계, setup·cleanup 호출 전후, 구독 적용, 메시지 수신, Pool 제출, 결과 콜백 예약, 성공·실패 정책 적용, 미완료 작업 수 변화.
+- DEBUG: 종료 중 수신 메시지의 `nack()`, Pool 포화에 따른 `nack()` 등 정상 흐름 제어.
+- WARNING: Mapping이 아닌 메시지 본문처럼 실행 전에 거부하는 잘못된 메시지. 해당 사건을 기존 ERROR 경로와 이중 기록하지 않는다.
+- ERROR: 사용자 작업·훅·검증 실패, Consumer 종료 시 남은 미확인 메시지, Consumer 종료 후 결과 도착으로 확인 처리 불가.
+- 완료 로그는 작업 실행 성공과 Consumer 완료 처리의 성공을 구분한다. 브로커 재전달·영속화까지 보장한 것처럼 표현하지 않는다.
+
+### 5.2. Pool·ThreadPool·ProcessPool·Executor
+
+- INFO: 구체 풀의 동시 실행 수와 실행 방식, Executor 실행 환경 시작·종료, Pool 종료 시작·완료.
+- DEBUG: 작업 제출·회수, 내부 작업 키, 사용 슬롯·대기 작업 수, Future 완료, 결과·예외 전달 단계, 실행 단위별 setup·cleanup.
+- DEBUG: 정상적인 풀 포화, 취소·미제출 등 기존 흐름상 발생 가능한 상태. 포화가 발생할 때마다 WARNING을 출력하지 않는다.
+- WARNING: 명시적으로 요청한 완료 대기의 시간 초과. 정상적인 내부 큐 조회의 `Empty`는 경고가 아니다.
+- ERROR: 실행 환경 시작 실패, 실행 단위 비정상 종료, 결과 수집 루프 장애, 작업 결과 직렬화 실패.
+- 사용자 작업 예외를 Pool과 Executor에서도 반복 ERROR로 출력하지 않는다. Worker로 전달되는 경로에서는 최종 작업 실패 로그를 Worker가 담당한다.
+- 프로세스 실행의 로그에는 프로세스 구분이 가능해야 한다. 부모의 핸들러 설정이 `spawn` 자식에게 자동으로 전달된다고 가정하지 않으며 기존 setup 훅을 이용한 자식 로깅 설정 방법을 문서화한다.
+
+### 5.3. Run
+
+- DEBUG: 작업의 전체 이름, setup·입력 검증·실행·출력 검증·complete/error 훅의 시작·완료·실패 단계.
+- DEBUG: 실행 소요 시간은 시작과 종료의 대응이 가능한 범위에서 기록한다. Run 실행 시간과 Worker 전체 처리 시간은 구분한다.
+- INFO: 메시지마다 반복되는 정상 실행 로그를 기본적으로 올리지 않는다.
+- 작업 실패의 최종 ERROR와 traceback은 Worker에서 기록한다. Run 단계 로그는 실패가 발생한 위치를 식별하는 역할을 한다.
+- Run을 Worker 밖에서 직접 실행했을 때는 예외가 기존대로 호출자에게 전파된다. 로깅을 위해 예외를 삼키지 않는다.
+- 검증 대상 값, 스키마 전체, 예제 값은 출력하지 않는다.
+
+### 5.4. Inspector·Server·RequestHandler
+
+- INFO: 실제 바인딩된 주소·포트와 서버 시작·종료. 포트 `0`을 요청한 경우 실제 할당 포트를 기록한다.
+- DEBUG: 확장 클래스·경로 등록, 확장 시작, 라우팅 대상 및 HTTP 요청 수신 시 메서드·안전한 경로.
+- INFO: HTTP 응답 전송 결과를 상태 코드와 함께 기록한다. 가능한 경우 응답 크기·처리 시간도 포함한다. 모든 확장의 공통 접근 기록은 이 경계에서 담당한다.
+- 응답 생성과 실제 전송 완료를 구분한다. 전송 도중 실패한 응답을 정상 전송 완료로 기록하지 않으며, 기본 WSGI 접근 기록과 추가 로그가 중복되지 않도록 한다.
+- WARNING: 비정상 요청 거부는 HTTP 상태와 사유를 구분하되, 정상적인 404·405를 일괄 경고로 취급하지 않는다.
+- ERROR: 서버 바인딩·실행 실패, 확장 시작·요청 처리 중 내부 오류. 이미 전파되는 예외의 의미와 Worker 중지 동작을 보존한다.
+
+### 5.5. Inspector 확장
+
+| 클래스 | INFO | DEBUG | WARNING / ERROR |
+| --- | --- | --- | --- |
+| HealthCheck | 관측 상태 변화와 복구만 기록하는 후보 | probe 예약·응답·시간 초과, 판정 상태 | 정상 실행 중 응답 불가 전환은 WARNING 후보, 예약 중 예외는 ERROR. 정상 시작·종료 상태의 503은 장애와 구분 |
+| Console | 초기화 및 관리용 작업 발행·RPC 요청의 접수·성공 요약 | 카탈로그 생성, producer 생성·연결·정리, 작업·모드·소요 시간 | 인증·출처·입력 거부, 동시 요청 제한, RPC 시간 초과·원격 오류는 WARNING. 내부 요청 처리 실패는 ERROR |
+| Metrics | 수집 초기화와 관측 대상 작업 수 | 작업 관측 시작·종료, 스냅샷·렌더링 요약 | 집계·렌더링 내부 오류. 측정 대상 작업 실패를 Metrics에서 다시 ERROR로 출력하지 않음 |
+| Dashboard | Metrics 확장 연결 | HTML·JSON 응답 생성·소요 시간 | 필수 Metrics 연결 실패, 리소스 읽기·응답 생성 실패 |
+| Specifications | 확장 시작 시 경로 등 등록 요약은 Inspector가 담당 | 문서 생성 시작·완료, 작업·채널 수 | 중복 식별자·주소 오류·스키마 문서 생성 실패 |
+
+- 매번 같은 실패 상태를 반복하는 probe나 HTTP 조회로 WARNING·ERROR가 무제한 반복되지 않도록 기록 지점과 빈도를 검토한다.
+- 표의 오류는 각 클래스의 관찰 대상이다. 공통 Inspector 경계에서 기록한다면 동일 예외를 확장에서도 다시 ERROR로 기록하지 않는다.
+- 공통 HTTP 수신·응답 기록은 확장에서 반복하지 않는다. 단순 응답 생성이라는 이유만으로 독립 로그를 의무화하지 않고 확장 고유의 처리 단계가 있을 때 DEBUG를 기록한다.
+
+## 6. 기록 품질과 호환성
+
+- 공개 라이브러리와 샘플의 런타임 로그 메시지는 영어로 작성한다. 한국어 문서·주석은 유지하고 API·클래스·작업 식별자는 원문을 유지한다.
+- 최소 문맥은 사건명, 처리 단계, 작업의 전체 이름이며 해당 시점에 실제로 알 수 있는 값만 기록한다.
+- 메시지 식별자가 필요한 경우 브로커별 속성을 임의로 가정하지 않는다. 공통 Event 계약을 확장할지는 별도 결정하며, 현 단계에서는 가짜 식별자를 만들지 않는다.
+- 비밀번호, 인증 토큰·다이제스트, 전체 연결 설정, 메시지 본문, 결과 값, HTTP 요청 본문·헤더 전체, 쿼리 문자열을 기록하지 않는다.
+- 객체의 `repr()`나 예외 문자열에 본문·인증정보가 포함될 수 있으므로 무조건 출력하지 않는다. traceback 기록도 예외 메시지에 민감정보가 포함될 가능성을 검토한다.
+- 같은 예외의 traceback은 한 처리 경계에서 기록한다. 예외를 로깅하기 위해 추가한 포착 구문은 기존 전파·정리·재시도 동작을 바꾸지 않는다.
+- DEBUG 비활성 상태에서 로그만을 위한 직렬화·전체 순회·추가 I/O를 하지 않는다. 메시지 치환은 지연 평가를 활용한다.
+- 로그 추가를 이유로 제출 순서, 슬롯 반환, ack/nack/reject, 종료 대기, 훅 실행 횟수, 스레드·프로세스 소유권을 바꾸지 않는다.
+
+## 7. 확정 사항과 구현 원칙
+
+1. `print()` 시작 배너와 구성 출력을 유지한다.
+2. 로거는 클래스 멤버로 보관하고, Pool 공통 동작은 구체 클래스의 로거 멤버로 기록한다. 직접 생성한 Pool은 `DefStream.Pool`을 사용한다.
+3. 상태 확인 반복 실패의 빈도 제어는 중복·과도한 출력 방지 원칙에 따라 구현 시 구체화한다. 별도 설정 API를 미리 추가하지 않는다.
+4. 핸들러 주입·로거 교체 API를 추가하지 않으며, 명시적 이름과 상속 시 이름 유지 계약을 지킨다.
+
+## 8. 구현 후 수용 기준
+
+- 확정된 각 클래스 이름으로 LogRecord가 생성되고, 사용자 Run 하위 클래스 때문에 프레임워크 로거 이름이 달라지지 않는다.
+- ThreadPool·ProcessPool의 상속받은 공통 메서드도 각각 `DefStream.ThreadPool`·`DefStream.ProcessPool`로 기록하며 사용자 하위 클래스에서도 명시적 이름을 유지한다.
+- Inspector·Server·RequestHandler가 `DefStream.Inspector`를 공유하고, 요청 수신은 DEBUG, 응답 전송 결과와 상태 코드는 INFO로 한 번씩 기록한다.
+- Specification에 독립 로거를 추가하지 않는다.
+- 기존 `print()` 시작 배너·구성 출력의 내용과 동작을 유지하고, 로그 설정 여부로 이를 비활성화하지 않는다.
+- Worker 정상 처리·실패·풀 포화·종료, Executor 실행 환경 장애, Inspector 및 확장 정상·실패 경로의 레벨과 문맥을 검사한다.
+- `DefStream` 상위 로거 및 루트 핸들러에서 전파를 수신하고, 클래스·확장별 설정으로 선택 수신할 수 있다.
+- 사용자 핸들러·레벨·필터·포매터를 임의로 변경하지 않고, DefStream이 출력 핸들러 또는 NullHandler를 추가하지 않는다.
+- INFO에서 메시지별 DEBUG 로그가 나오지 않으며, 정상 포화·폴링·시작 및 종료 상태가 경고로 반복 출력되지 않는다.
+- 동일 실패의 중복 traceback과 민감정보 누출이 없고, 기존 Worker·Pool·Run·Inspector 테스트가 보장하는 동작을 유지한다.
+- ProcessPool의 부모·자식 로그 수집 조건과 설정 예제를 문서화하고, 프로세스별 로깅 설정을 적용한 경우를 검증한다.

defstream-0.1.9/issues/feature/8/ci.refs.json

@@ -0,0 +1,4 @@
+{
+  "DefStream-RabbitMQ": "feature/5",
+  "DefStream-Redis": "feature/5"
+}