| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[feature]增加告警清除逻辑 Co-authored-by: hxy<huxinyi9@huawei.com> # message auto-generated for no-merge-commit merge: !598 merge feat/hybrid-precision-detection into master [feature]增加告警清除逻辑 Created-by: hu-xinyi_555 Commit-by: hxy Merged-by: towncharlie Description: ## **1. 合入背景** 可见https://gitcode.com/Ascend/MindIE-Motor/issues/359 精度检测特性（前序合入 61b0475 [feature]支持混布场景的精度异常检测）已具备 **告警产生** 与 **auto-recovery 实例终止** 能力，但缺少完整的 **告警清除（CLEAR）闭环**： - auto-recovery 终止 P/D 实例后，OM 侧精度告警仍可能残留； - CCAE 手动下发 precision control 终止实例后，未同步清除对应 PD Group 告警； - 未开启 auto-recovery 时，实例恢复后无法通过连续正常检测自动清除活动告警； - Coordinator Scheduler 侧 alarm_active 状态无统一清理入口，影响后续同 PD Group 重复告警。 ## **2. 修改内容** 详细设计见：[docs/zh/design/fault_tolerance/precision_detection.md](../../pymotor/MindIE-PyMotor_8989/docs/zh/design/fault_tolerance/precision_detection.md)（告警清除章节） ### 2.1 三条清除路径 | 路径 | 触发方 | 行为 | |------|--------|------| | **auto-recovery 清除** | Controller | 精度 ALARM 触发终止 P/D 全部成功后，上报 CLEAR 至 OM，并通知 Coordinator 清理 Scheduler 活动状态 | | **CCAE 手动清除** | CCAE Reporter → Controller | 终止 P/D 时携带 precision_alarm_clear=true，复用统一恢复入口清除 OM 告警 + 通知 Coordinator | | **连续正常清除** | Coordinator | 活动告警下连续 precision_clear_threshold（默认 10）次有效正常检测后，上报 CLEAR | ### 2.2 组件交互（实现要点） 1. **Controller recovery_service.py（新增统一入口）** - complete_precision_pd_group_recovery()：可选终止 P/D → 从 AlarmStore 查找活动精度告警 → 深拷贝原 Alarm 并 clear() 上报 OM → 调用 CoordinatorApiClient.notify_precision_alarm_cleared() 清理 Scheduler 状态 - terminate_pd_group() / is_precision_raise_alarm() 等辅助函数供 API 层复用 2. **Controller alarm_store.py** - 新增 _active_precision_alarms 索引与 find_active_precision_alarm(p_id, d_id)，按 PD Group 追踪活动精度告警及其 moi 3. **Controller controller_api.py** - 精度 auto-recovery 成功后走 complete_precision_pd_group_recovery，响应携带 precision_alarm_cleared / precision_alarm_cleared_by_auto_recovery - POST /controller/terminate_instance 支持 precision_alarm_clear=true，CCAE 手动清除走同一恢复入口 4. **Coordinator Scheduler（scheduler.py + runtime）** - 新增 alarm_active、clear_probing、clear_tokens 等 per-PD-Group 状态 - record_precision_result() 在活动告警下累计连续正常样本，达 clear_threshold 触发 clear action - finish_precision_action(action_type=clear|raise) 提交 action 结果；auto-recovery 已清除时直接删除整组状态 - 新增 ZMQ 协议与 client/server 透传 finish_precision_action / record_precision_result(clear_threshold=...) 5. **Coordinator PrecisionReporter + PrecisionAlarm** - Reporter 支持 raise / clear 双 action 编排，clear_threshold_hit 时异步触发 CLEAR 上报 - PrecisionAlarm.execute(action=clear) 构造 build_precision_issue_clear_alarm() 并上报 Controller；CLEAR 必须使用与产生告警相同的 moi 6. **Coordinator Management API（新增）** - POST /precision/alarm_cleared：Controller 通知 Coordinator 删除 Scheduler 活动告警状态（Mgmt 进程 → Scheduler） 7. **CCAE Reporter + MotorBackend** - precision control 终止成功后调用带 precision_alarm_clear=true 的 group terminate - 新增 precision task 上报窗口与 controlCode 抑制逻辑 8. **公共层** - 新增 motor/common/alarm/deserialize.py：告警反序列化 - precision_issue_alarm.py：新增 build_precision_issue_clear_alarm() - coordinator.py：新增 precision_clear_threshold 配置项 ### 2.3 时序（auto-recovery 清除） mermaid sequenceDiagram participant CR as Coordinator PrecisionAlarm participant CT as Controller participant OM as OM/CCAE participant SCH as Coordinator Scheduler CR->>CT: POST report_alarms (ALARM) CT->>CT: terminate P/D instances CT->>OM: report ALARM + CLEAR (same moi) CT->>SCH: POST /precision/alarm_cleared SCH->>SCH: clear alarm_active state CT-->>CR: precision_alarm_cleared_by_auto_recovery=true --- ## **3. 资料变更** **涉及**，修改如下： | 文件 | 变更说明 | |------|----------| | docs/zh/design/fault_tolerance/precision_detection.md | 补充告警清除设计：三条清除路径、moi 一致性约束、Scheduler 状态清理、CCAE 手动清除时序 | | docs/zh/user_guide/features/precision_detection.md | 补充 precision_clear_threshold 配置说明 | | docs/zh/user_guide/api/observability_interface.md | 补充 CCAE precision control 调用 /controller/terminate_instance 时 precision_alarm_clear 字段说明 | --- ## **4. 接口变更** **涉及**，均为客户面/跨组件可见接口： | 接口 | 变更类型 | 说明 | |------|----------|------| | POST /controller/terminate_instance | **请求体扩展** | 新增可选字段 precision_alarm_clear: bool（默认 false）。为 true 时按 PD Group 终止 P/D 并清除精度告警；响应 data 新增 precision_alarm_cleared、scheduler_state_cleared、moi | | POST /controller/report_alarms（精度 ALARM 响应） | **响应扩展** | auto-recovery 成功后 data 新增 precision_alarm_cleared、precision_alarm_cleared_by_auto_recovery、scheduler_state_cleared | | POST /precision/alarm_cleared（Coordinator Mgmt） | **新增** | Controller → Coordinator，请求体 {p_instance_id, d_instance_id}，清除 Scheduler 侧活动精度告警状态 | | Coordinator 配置 | **新增字段** | precision_detection_config.precision_clear_threshold（默认 10） | | CCAE precision control → MotorBackend | **行为变更** | 终止实例时携带 precision_alarm_clear=true | --- ## **5. 测试结果**  --- ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!598 | 11 天前 | |
解决日志重复问题 Co-authored-by: wenkea<tianmengx12@163.com> Co-authored-by: 吴铭泾<wumingjing@huawei.com> # message auto-generated for no-merge-commit merge: !446 merge fix/request-cancel-and-logger into master 解决日志重复问题 Created-by: wenkea Commit-by: wenkea;吴铭泾 Merged-by: towncharlie Description: ## **1. 合入背景** Unified PD 路由在客户端断开、dispatch 取消等预期取消场景下，原先会将 asyncio.CancelledError 包装成 RuntimeError，在 dispatch.handle_request 中落入通用 Exception 分支，以 ERROR 级别打印完整堆栈，容易被误判为系统故障，干扰问题定位。 同时，日志模块在处理多行 message 和 exc_info 堆栈时，NewLineFormatter / MaxLengthFormatter 存在格式异常（堆栈 header 重复、换行截断不当），影响维测日志可读性。 #ISSUE ID: https://gitcode.com/Ascend/MindIE-PyMotor/issues/342 ## **2. 修改内容** 1.新增 RequestCancelledError 异常类型（motor/common/utils/error.py） 用于标识客户端断开、dispatch 取消等预期取消场景 携带 reason 字段，便于日志与 trace 记录 Unified PD 路由取消路径改造（motor/coordinator/router/strategies/unified_pd.py） 2.在 _process_response_error 中，将 asyncio.CancelledError 包装为 RequestCancelledError，替代原 RuntimeError 取消原因仍通过 check_cancel_error 解析，重试逻辑不变 Dispatch 层单独处理取消异常（motor/coordinator/router/dispatch.py） 3.新增 RequestCancelledError 捕获分支 以 debug 级别记录 api / req_id / reason，不再走通用 error 堆栈日志 仍返回 HTTP 500，并通过 sanitize_error_message 做安全处理 日志格式化修复（motor/common/logger/formatter.py、motor/common/logger/logger.py） 4.NewLineFormatter：仅对 message 内换行做 header 前缀扩展，避免 exc_info 堆栈 header 重复 MaxLengthFormatter：新增 _escape_for_single_line，将换行转义为 \n，保证单行日志长度截断正确 ## **3. 资料变更** 不涉及 ## **4. 接口变更** 不涉及。 ## **5. 测试结果** 1.取消异常类型与 reason 传递 pytest tests/coordinator/router/test_cancel_error.py PASSED 2.Dispatch 取消时不打 ERROR 堆栈 test_dispatch_request_cancelled_does_not_log_error PASSED 3.非预期异常仍打 ERROR 堆栈 test_dispatch_unexpected_exception_still_logs_error PASSED 4.Unified PD 取消包装为 RequestCancelledError test_unified_pd_process_response_error_wraps_cancelled_as_request_cancelled_error PASSED 5.多行日志 / exc_info / MaxLength 转义 pytest tests/common/logger/test_logger.py PASSED 7.构造真实推理场景测试日志打印效果 问题已解决 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!446 | 18 天前 | |
[bugfix] 非Layerwise D实例虚推请求适配 Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !384 merge fix/decode-layerwise-virtual-warmup into master [bugfix] 非Layerwise D实例虚推请求适配 Created-by: Jechin Commit-by: Jechin Merged-by: towncharlie Description: ## **1. 合入背景** > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 请通过#ISSUE ID关联issue。\ > 注意： Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. Fixes [#229](https://gitcode.com/Ascend/MindIE-PyMotor/issues/229) ## **2. 修改内容** > 请<ins>**描述修改内容的具体实现**</ins>，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。 > 如果是需求或者重构类的PR，需要<ins>**补充详细设计文档**</ins>（说明上下游组件关系、时序图、类图、DFX能力等内容）。 在非layerwise的connector场景下，decode实例虚推请求不需要特殊处理，和prefill一样 ## **3. 资料变更** > 请确认<ins>**是否涉及资料变更**</ins>。\ > 如涉及，需要在PR中体现，并简要说明修改内容。\ > 如不涉及，需填写“不涉及”。 不涉及 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 不涉及 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 使用MooncakeConnectorV1  使用MooncakeLayerwiseConnector  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!384 | 1 个月前 | |
[refractor] NodeManager代码微重构，提升代码可维护性 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !620 merge refractor/node_manager into master [refractor] NodeManager代码微重构，提升代码可维护性 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ## 1. 合入背景 ISSUE：https://gitcode.com/Ascend/MindIE-Motor/issues/368 ## 2. 修改内容 ### 2.1 Service Registry 重构 **文件**: motor/node_manager/core/services/registry.py 1. 用 typing.cast 消除 get_preparable() 中的 # type: ignore[arg-type,return-value]。 2. _MODULE_MAP 从模块级静态 dict 迁移到 _ServiceRegistry 实例属性，新增 add_discovery_path() API 支持动态注册后端模块路径。 3. 新增 get_active_sorted() 方法，将排序逻辑从 daemon.py 内联哨兵模式收归 registry。 4. _ServiceRegistration.is_active 改为 _is_active(active_backends) 方法，接受解析后的后端列表参数。 5. discover() 支持逗号分隔的多后端服务列表（如 "engine,memcache"），替代原来的单值匹配。 6. 删除 __slots__ 限制，2-3 个实例的内存节省可忽略。 7. 新增 tests/node_manager/core/services/test_registry.py，20 个单元测试覆盖 register、get_active 过滤、get_preparable 排序、discover 模块导入、重复注册、add_discovery_path、线程安全。 ### 2.2 服务协议提取 **文件**: motor/node_manager/core/services/protocols.py（新增） 1. DaemonService 和 PreparableService 从 registry.py 提取到 services/protocols.py。 2. daemon.py 直接从 protocols.py 导入，Protocol 定义与注册中心解耦。 ### 2.3 memcache LocalService 重构 **文件**: motor/node_manager/core/services/memcache/（新增目录） 1. **目录拆分**： services/memcache/ __init__.py worker.py ← LocalService 子进程入口（DistributedObjectStore().init(0)） lifecycle.py ← daemon 侧生命周期管理（@register_service、pull/stop/health_check） 2. **拉起方式改进**：pull() 使用 sys.executable -m motor.node_manager.core.services.memcache.worker 替代内联 -c 字符串，取消 PYTHON_EXEC_PATH 依赖。保持 subprocess.Popen(env=...) 确保与 Engine 子进程的 MMC_LOCAL_CONFIG_PATH 隔离。 3. **消除重复检查**：提取 _can_launch property，统一 should_launch() / pull() / prepare() 中的 enable、backend、mode 条件判断。 4. **简化 mark_dead()**：用 poll() 替代 wait(timeout=0) + 三重异常捕获。 5. **移除未使用的 _endpoints_count**：仅在日志中使用，改为局部变量。 ### 2.4 Engine 解耦 —— 服务配置化 **文件**: motor/node_manager/core/services/engine.py, motor/node_manager/core/daemon.py, motor/node_manager/main.py, motor/config/node_manager.py 1. @register_service(SERVICE_ENGINE) 新增 backend="engine"，从 backend=None（始终激活）改为按配置激活。 2. KVCacheStoreConfig 新增 mode 字段（"combined" / "separated"），通过 user_config.json 控制： json // Engine + KV 合体 Pod（默认） { "kv_cache_store_config": { "backend": "memcache", "mode": "combined" } } // KV 分离 Pod（只起 LocalService，不拉 Engine，不注册/心跳） { "kv_cache_store_config": { "backend": "memcache", "mode": "separated" } } // Engine only Pod {} 3. Daemon 新增 has_engine 属性，main.py 据此条件初始化 EngineManager / HeartbeatManager。 ### 2.5 main.py 重构 —— Application 基类 **文件**: motor/common/app/application.py（新增）, motor/node_manager/node_manager.py（新增）, motor/node_manager/main.py 1. **Application 基类** — 封装四个组件共享的 boilerplate： - 模块管理（add_module / get_module / stop_all_modules） - 配置热更新传播（on_config_updated → 先刷新自身间隔 _refresh_check_interval，再传播给所有带 update_config 的模块） - 可配置的 daemon loop 间隔（check_interval 参数，默认 1s，子类从 config 读取） - 信号处理（SIGINT / SIGTERM → threading.Event） - select-based daemon loop（stdin 读取 + stop_event.wait） - run() 模板方法：banner → init_modules → start_modules → config_watcher → daemon_loop → shutdown 2. **NodeManager(Application)**： - __init__ 传入 check_interval=config.basic_config.daemon_loop_interval（默认 5s，可在 user_config.json 中配置） - _refresh_check_interval()：配置热更新时同步刷新间隔 - init_modules()：根据 daemon.has_engine 动态注册模块 - _on_daemon_tick()：每 tick 检查 HeartbeatManager 自杀标志 - exit_code：自杀时返回 -1（pod rescheduling） 3. **main.py 瘦身**：从 186 行 → 37 行 thin wrapper： python def main() -> int: config = NodeManagerConfig.from_json() reconfigure_logging(config.logging_config) run_port_setup_or_exit(apply_node_manager_ports, config) nm = NodeManager(config) return nm.run() 删除所有模块级全局变量（modules、_should_exit、config、config_watcher）和 7 个模块级函数。 ### 2.6 测试重构 1. 测试目录镜像源码结构： tests/node_manager/ __init__.py conftest.py test_config.py core/ __init__.py test_daemon.py test_engine_manager.py test_heartbeat_manager.py test_fault_reporter.py test_api_ready_event.py services/ __init__.py test_registry.py memcache/ __init__.py test_lifecycle.py 2. test_main_process_title.py 从 NodeManager 和 EngineServer 各一份合并为 tests/common/utils/test_process_title.py，NodeManager 用例适配新 NodeManager 类 API。 ### 2.7 改动文件清单 | 文件 | 改动类型 | |------|----------| | motor/common/app/__init__.py | 新增 | | motor/common/app/application.py | 新增 | | motor/node_manager/node_manager.py | 新增 | | motor/node_manager/core/services/protocols.py | 新增 | | motor/node_manager/core/services/memcache/__init__.py | 新增 | | motor/node_manager/core/services/memcache/worker.py | 新增 | | motor/node_manager/core/services/memcache/lifecycle.py | 重命名自 local_service.py | | tests/node_manager/core/__init__.py | 新增 | | tests/node_manager/core/services/__init__.py | 新增 | | tests/node_manager/core/services/memcache/__init__.py | 新增 | | tests/node_manager/core/services/test_registry.py | 新增 | | tests/node_manager/core/services/memcache/test_lifecycle.py | 重命名 | | tests/common/utils/test_process_title.py | 合并自两份拷贝 | | motor/node_manager/core/services/registry.py | 重构 | | motor/node_manager/core/daemon.py | 重构 | | motor/node_manager/core/services/engine.py | 改动 | | motor/node_manager/main.py | 瘦身 | | motor/config/node_manager.py | 改动 | | motor/node_manager/core/__init__.py | 删除多余版权声明 | | motor/node_manager/core/services/__init__.py | 删除多余版权声明 | | motor/node_manager/__init__.py | 删除多余版权声明 | ## 3. 资料变更 不涉及。 ## 4. 接口变更 不涉及（所有改动为内部重构，对外接口不变）。 ## 5. 测试结果 python -m pytest tests/node_manager/ tests/common/utils/test_process_title.py tests/engine_server/ -q 529 passed in 1.47s 测试覆盖： - **registry**：注册、过滤、排序、发现、线程安全（20 个用例） - **memcache lifecycle**：should_launch、prepare、pull、stop、health_check（11 个用例） - **daemon**：engine pull、参数校验、D2D peer、signal handler（13 个用例） - **heartbeat manager**：状态上报、端点管理、自杀检测 - **engine manager**：注册、re-register、ranktable、snapshot - **config**：配置解析、验证、热加载 - **process_title**：NodeManager + EngineServer 标题设置（4 个用例） ## 6. CheckList - [x] 代码注释完备 - [x] 正确记录维测日志 - [x] 是否有UT用例（新增 24 个用例，全量 529 passed） - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 - _ServiceRegistry 使用 threading.Lock 保护 _registrations 和 _module_map - daemon.py 和 engine.py 的锁均为短临界区非嵌套使用 - Application 的信号处理仅设 threading.Event，清理在主线程执行 See merge request: Ascend/MindIE-Motor!620 | 10 天前 |