东方智慧AI 算力
AI算力 · 昇腾部署课件 E2

E2 日志在哪里：应用日志 / Device 日志 / MindIE 日志三处

2026-10-05

编制：观澜｜日期：2026-10-06｜层级：E 层 · 排障（E 层第 2 课，前接 E1《报错定位法》） 素材来源：昇腾官方 CANN 9.2.0-beta.2《日志参考》《故障处理》《环境变量参考》 + MindIE 3.1.0《日志参考》 + 昇腾故障案例库 数据纪律：路径、参数、环境变量、报错原文、注意事项逐字出自官方文档；标注「归纳」的是便于记忆的整理，非官方口径； 官方未给出的地方，正文里明写「官方未给出」，不用推测填满。

第一段 · 章前定位

E1 给的是地图，这一课把地图走成路。

E1 的第六段用一页讲清了「日志分三类、分别在哪」—— 那一页是索引，这一课是操作手册。 分工是这样的：

问题 在哪一课
报错由哪几块组成、错误码第一位数字是什么意思 E1
三步定位法（先看什么、再看什么） E1
三类日志的完整路径、目录结构、文件名规律 本课（E2）
每条命令怎么敲、敲完看到什么才算对 本课（E2）
Device 侧日志在物理机上根本没有，怎么把它弄到 Host 上来 本课（E2）
这个错在官方案例库有没有现成的答案 E3（下一课）

这一课也纠正 E1 里一处当时没能落实的地方。

E1 写到 Device 日志导出时，只给了一行示例并注明「本课不写死参数」—— 那是没查到就不编的正确态度，但读者拿去用不了。 这一课补上：从官方文档里逐条取回 msnpureport 的真实参数，并把每条参数是干什么的写清楚；取不到的那部分，明写取不到。

本课不教什么，也说清：

  • 不教怎么读懂日志内容 —— 日志里某一行代表哪个模块出了什么问题，属于 A/B/C/D 各层的事，各层课件里讲；
  • 不教 trace 日志的完整解析 —— trace 日志（$HOME/ascend/atrace/）是另一套机制（程序出错或退出才落盘），本课只给路径与去向，解析要用 asys；
  • 不教 AI Core Error 的归因 —— 那要用官方的 mscaicerr / asys 工具，本课只教把 Device 日志收上来这一步。

一句话定位：

排障的一半工作量在「拿到对的日志」。 这一课就是把「对的日志」拿到手的那一课。

第二段 · 学习目标

学完这一课，你应该能回答：

  1. 官方把日志分成哪两大类，分类的界线是什么
  2. 应用类日志的默认路径是什么，debug / run / security 三个子目录各装什么，plog 和 device-id 各是谁打的
  3. MindIE 日志的默认路径是什么，文件名规律怎么拆
  4. 为什么 Device 侧的日志在 Host 上找不到，官方给的原因是什么
  5. 把 Device 侧日志弄到 Host 上要用哪个工具，至少要能说出 5 个参数各干什么
  6. Device 日志默认落盘路径是什么，导出后目录里有什么
  7. 日志落盘路径怎么改（应用侧用哪个变量、MindIE 侧用哪个变量）
  8. 这 5 条命令：ls -lt $HOME/ascend/log/debug/plog、npu-smi info、msnpureport -f、msnpureport -g debug -d <设备号>、grep -rn ringbuffer

第三段 · 全景：日志按谁产生分成两类，按在哪查落在三处

3.1 官方怎么分类（原文）

官方《日志参考 · 日志简介》把日志分成两大类：

系统类日志：系统运行时在 Device 侧产生的日志。主要包括： - Control CPU 上的系统类日志，包括内核态日志和系统进程运行产生的用户态日志，主要反映 AI 处理器的整体运行情况。 - 非 Control CPU（例如低功耗）上的系统类日志，主要反映低功耗、Task Scheduler、ISP 等组件的运行情况。

应用类日志：AI 应用程序运行产生的日志。主要包括： - Host 侧 AscendCL、GE、Runtime、HCCL 等组件打印的日志。 - Device 侧 AI CPU 进程打印的日志。

⭐ 分界线是什么（这才是要记住的）：

界线不是「在 Host 还是 Device」，而是「谁产生的」。 系统类日志 = 系统自己产生的（内核、常驻进程）； 应用类日志 = 你的程序跑起来产生的（哪怕它打在 Device 上，也算应用类，而且官方说 Device 侧的应用类日志会自动回传到 Host 侧）。

这条分界线的实用含义：

  • 你在 ${HOME}/ascend/log 里能看到 Device 侧的日志（device-id 目录）—— 因为它是应用类，会自动回传；
  • 你在 Host 上看不到 Device 的系统类日志 —— 因为它是系统类，且 EP 形态下你没有 Device 的登录权限。

3.2 按「在哪查」落成三处（本课的组织方式）

官方按「谁产生」分类，本课按「在哪查」组织（归纳，非官方表述）—— 因为现场的人是拿着屏幕上的现象去找文件的，不是拿着分类去查：

处 名字 默认落盘路径 谁产生的 哪个场景挂
① 应用类日志 ${HOME}/ascend/log 你的应用 + Host 侧 AscendCL/GE/Runtime/HCCL 所有场景（第一优先看这里）
② Device 侧系统类日志 不在 Host 上，需 msnpureport 导出 Device 的系统 / 常驻进程 底层问题（驱动、内核态、硬件）
③ MindIE 日志 ~/mindie/log MindIE 各组件（服务化、LLM 等） 用了 MindIE 才看

本课就按这三处展开。 加上一个「顺带记一下」的落点：

处 名字 默认落盘路径 特点
④ trace 日志 $HOME/ascend/atrace/ 不是持续落盘，而是「先把维测信息记在内存里，程序运行出错或进程结束时才落盘到文件」

官方对 trace 机制的解释（原文）：

trace 机制是指在程序运行过程中将软件栈的维测信息记录在内存中，当程序运行出错或进程结束时落盘到文件，以免在程序运行过程中频繁产生和记录日志文件，影响性能。 当前仅 Ascend EP 标准形态支持该功能。

3.3 ① 应用类日志：目录结构（官方原文）

官方给的目录树长这样：

├── debug
│   ├── device-0
│   │   ├── device-2272_20220617234019449.log
│   │   └── device-6564_20220617232348429.log
│   └── plog
│       └── plog-16027_20220618001623878.log
├── run
│   ├── device-0
│   │   ├── device-2272_20220617234019449.log
│   │   └── device-6564_20220617232348429.log
│   └── plog
│       └── plog-16027_20220618001623878.log
└── security
    ├── device-0
    │   ├── device-2272_20220617234019449.log
    │   └── device-6564_20220617232348429.log
    └── plog
        └── plog-16027_20220618001623878.log

⭐ 这张树的读法（三行记住）：

  1. 第一层是「哪一类日志」：debug（调试）/ run（运行）/ security（安全）—— 三个目录的内容是一样的划分逻辑，差别只在级别和用途；
  2. 第二层是「谁打的」：plog（Process log，Host 侧进程打的）/ device-id（Device 侧打的，id 是 Device ID）；
  3. 第三层文件名：plog-<pid>_<时间戳>.log / device-<pid>_<时间戳>.log。

官方对六个路径的逐条说明（原文表格）：

存储路径 官方说明
$HOME/ascend/log/debug/device-id/device-pid_*.log 在 Device 侧运行应用程序产生的调试日志。主要包括 Device 侧 AI CPU、HCCP 等模块的日志。
$HOME/ascend/log/debug/plog/plog-pid_*.log 在 Host 侧运行应用程序产生的调试日志。主要包括 compiler 中各组件（如 GE、FE、AI CPU、TBE、HCCL 等）、runtime 中各组件（如 AscendCL、GE、Runtime 等）和 Driver 用户态日志。
$HOME/ascend/log/run/device-id/device-pid_*.log 在 Device 侧运行应用程序产生的运行日志。
$HOME/ascend/log/run/plog/plog-pid_*.log 在 Host 侧运行应用程序产生的运行日志。
$HOME/ascend/log/security/device-id/device-pid_*.log 在 Device 侧运行应用程序产生的安全日志。
$HOME/ascend/log/security/plog/plog-pid_*.log 在 Host 侧运行应用程序产生的安全日志。

官方对文件名的说明（原文）：

上述日志中 id 和 pid 分别代表 Device ID 和业务进程 ID，请以实际为准； 日志文件中的「*」表示该日志文件创建时的时间戳。

⭐ 三条官方注意事项（都是现场会踩的）：

注 2：以上目录是容器或物理机内所有应用程序共同使用的，会不断增加新的应用进程，日志会不断增多，因此需要用户定期清理该目录（可以使用系统自带的 logrotate 实现日志切分），否则可能导致磁盘空间不足，影响业务正常运行。

注 3：如果存储在只有 emmc/flash 等有写次数限制的介质下，建议将日志落盘路径设置到内存文件系统路径下，启动业务进程时通过环境变量 ASCEND_PROCESS_LOG_PATH 设置日志落盘路径。

注 4：在容器内，目录中的 device-id 为逻辑 ID。

⚠️ 注 3 和注 4 是本课最容易被忽略、又最容易坑人的两条 —— 一条说「写多了会把介质写坏」，一条说「容器里看到的设备号不是真实设备号」。两条后面都会用到。

3.4 ② Device 侧系统类日志：为什么它在 Host 上找不到

官方原文（《查看日志（Ascend EP）》）：

系统类日志用于记录系统运行信息，Ascend EP 标准形态下，用户没有 Device 的登录权限， 因此需要通过 msnpureport 工具将 Device 侧的系统类日志传输到 Host 侧进行查看。

⭐ 把这句话拆开，就是本课的题眼：

不是「日志没产生」        —— 它一直在产生
不是「路径没找对」        —— 它根本不在 Host 上
没有登录权限，只能用工具搬 —— 这才是真原因

所以 Device 日志这一节，讲的不是「在哪」，而是「怎么搬」。

两条官方约束（很重要）：

  • 容器内不支持查看 Device 侧系统类日志，也不支持通过 msnpureport 工具导出 Device 侧系统类日志。
  • 系统类日志支持老化，如果日志文件数量和大小超限，将会自动删除最早的日志目录或文件。

第一条要划重点：如果你拿到的是容器（租用环境常见），这一处日志你就拿不到了 —— 这不是你操作错了，是官方明说不支持。这种情况的替代办法在第四段第 ⑧ 步里写。

3.5 ③ MindIE 日志：路径与命名规律

官方原文（MindIE 3.1.0《日志参考 · 查看日志》）：

表 1 日志路径

路径 说明
~/mindie/log 默认的日志落盘路径。
~/mindie/log/security 默认日志落盘路径下，自动生成的安全日志路径。
~/mindie/log/debug 默认日志落盘路径下，自动生成的运行调试日志路径。

日志文件命名格式统一为：mindie-<组件名称>_<pid>_<datetime>.log。 可以根据组件名称、进程号和时间戳来定位到相关的日志文件。

官方还给了两个示例：

mindie-service_123_202410080206.log      ← 示例 1：MindIE Motor CPP 的日志文件

cat mindie-service_123_202410080206.log  ← 示例 2：查看 MindIE Motor CPP 的日志文件

⭐ 这个命名规律就是「定位靠三个字段」：

字段 例子里的值 怎么用它
组件名称 service 先按组件缩小范围（哪个组件出问题就看哪个）
pid 123 和你的进程对得上（ps 查到的 pid）
datetime 202410080206 和出错时间对得上

官方对 MindIE 日志的两条基础口径：

MindIE 默认收集 Informational 级别及以上的日志。

目前 MindIE 的日志按照内容分为安全审计日志和运行调试日志。 任何与系统运行过程出现的登录认证、账户管理、访问控制、网络攻击等安全事件相关的信息都应该在安全审计日志中呈现。 安全审计日志以外，在业务和调试过程中出现的日志为运行调试日志。

⭐ 这解释了 ~/mindie/log 下面为什么直接就是 security 和 debug 两个子目录（归纳）： 一个装安全审计、一个装运行调试。与 3.3 里 CANN 应用类日志的 debug/run/security 是同一套思路，但不是同一套目录。

⚠️ 别把两者混起来： CANN 应用类日志在 ${HOME}/ascend/log；MindIE 日志在 ~/mindie/log。 两个都在你的 home 下、长得都像「日志目录」、都带 debug 子目录，但一个是 CANN 侧、一个是 MindIE 侧，互不相通。

3.6 全景图（一张表收口）

┌──────────────────────────────────────────────────────┐
│日志的三个落点（本课地图）                            │
├──────────────────────────────────────────────────────┤
│                                                      │
│【应用类】你的程序 + Host 侧组件                      │
│   ├─> ${HOME}/ascend/log                             │
│   │     debug / run / security                       │
│   │     ├─ plog/         Host 侧进程打的             │
│   │     └─ device-<id>/  Device 应用，自动回传       │
│   └─> ~/mindie/log     （用了 MindIE 才有）          │
│         ├─ debug/   └─ security/                     │
│                                                      │
│【系统类】Device 侧产生                               │
│   ✗ 不在 Host 上（用户没有 Device 登录权限）         │
│   ↓ 用 msnpureport 搬到 Host 来                      │
│   /var/log/npu/report/...                            │
│                                                      │
│【另】$HOME/ascend/atrace/   出错/退出才落盘          │
│                                                      │
└──────────────────────────────────────────────────────┘

这张图就是本课的地图：左边两处可以直接看，右下那一处必须搬，最下面一行是「顺带记一下」。

第四段 【如果我来做】收一次日志，我会按这个顺序做（八步）

这一节是本课的核心。 前三段讲的是「日志分几类、分别在哪」，这一节讲： 如果现在把这个任务交给我 —— 「服务报错了，把日志收上来」——我从哪里开始、按什么顺序、每一步凭什么判断。

排列原则不是「知识点的逻辑」，而是「手伸进去的顺序」： 先做零成本的、先做能立刻出结果的、最后才做需要搬机器的。

4.1 先记住一句话：顺序错了会白干

收日志最容易犯的错，不是「不会用工具」，而是「顺序错了」：

  • 一上来就 msnpureport -f 导 Device 日志 → ① 容器里根本导不出来（官方明说不支持），白试； ② Device 日志是系统类，你一个应用层的业务报错，九成在这上面找不着； ③ 导出一次要占磁盘、要时间，而应用日志本来就在 Host 上躺着，零成本就能看。
  • 先看日志、再去复现 → 官方明确提醒：「如果日志中的时间与发生问题的时间相距较远，则旧日志可能已经被覆盖或清理」。 所以看日志之前先确认日志的时间窗，别一头扎进一个三天前的旧日志里。
  • 调了日志级别，却忘了自己调过 → export ASCEND_GLOBAL_LOG_LEVEL=0（DEBUG）之后，日志量会暴涨（官方原文：「设置为 DEBUG 级别后，可能会因为日志流量过大影响业务性能」）， 并且 D5 讲过的那条：日志级别被显式改掉以后，某些能力（如虚推健康检查）会被悄悄关掉。 所以调级别这件事，做完要记得还原。

所以我的顺序是： 先定问题 → 看最便宜的那一处 → 锁时间窗和进程 → 不够细再调级别重跑 → 看服务层那一处 → 查设备号 → 搬 Device 日志 → 收口出证据。

4.2 我按这个顺序做（八步）

① 先定问题：先判断这是哪一层的错，再决定去收哪一处的日志。（别先导日志） ② 看最便宜的一处：应用类日志在 Host 上就有，先看它。 ③ 锁时间窗与进程：按 pid + 时间戳把范围缩到一个进程、一段报错前后。 ④ 不够细就调级别重跑：把 ASCEND_GLOBAL_LOG_LEVEL 调到 DEBUG，复现一次，完事记得还原。 ⑤ 看服务层那一处：用了 MindIE 就去 ~/mindie/log，先按组件名筛。 ⑥ 查设备号：搬 Device 日志前，先把设备号查准（别硬编码 0）。 ⑦ 搬 Device 日志：msnpureport -f，在一个有读写权限的目录下执行。 ⑧ 收口出证据 + 诚实：把收上来的东西按时间戳归档；拿不到的部分如实写明。

4.3 第①步 先定问题：这是哪一层的错

目的：在动手收日志之前，先用 E1 的三步法把「层」判出来。 层判不对，收日志就是全量乱收。

我要先问自己三个问题（这就是 E1 的三步法）：

# 我要先问自己什么 怎么用这个答案
① 报错里有没有错误码？ 有 → 看第一位数字判层（E1 第四段）
② 报错发生在什么阶段？ 启动 / 加载 / 推理 / 退出 —— 阶段本身就指向层
③ 谁最先报的？ L2 报的错，根因常在 L0/L1（E1 反复讲的这条）

第①步不敲命令，但它是后面七步的分流器。 决策表（归纳）：

判出来的层 先收哪一处日志 为什么
L4 应用 / L3 服务 ① 应用类日志，用了 MindIE 加看 ③ MindIE 日志 你的程序和服务自己的日志最直接
L2 框架 / L1 CANN ① 应用类日志（重点是 plog） 官方说 plog 里是 compiler + runtime + Driver 用户态 打的
L0 硬件 / 驱动 ① 应用类日志先兜底 → 再搬 ② Device 日志 设备侧的现象只有 Device 日志说得清

不过会怎样：层判错、直接去搬 Device 日志 → 大概率什么也找不到， 而且如果环境是容器，连搬都搬不了（4.8 里讲）。

4.4 第②步 看最便宜的一处：应用类日志

目的：Host 上躺着、不用装任何东西、不用改任何配置就能看的日志，先看完。 这是投入产出比最高的一步。

为什么先看它（官方依据）：官方《故障处理简介》把 plog 称为最常用的日志——

应用类日志：用于记录在 Host 和 Device 上运行应用程序产生的用户态日志， 其中常用的日志为 plog-pid_*.log，通常称为 plog 日志。

命令　ls -lt ${HOME}/ascend/log/debug/plog

含义：按时间倒序列出应用类调试日志目录里的文件，最新的一次跑在最上面 拆解：ls（列出）＋ -l（长格式：权限/大小/时间/名字）＋ -t（按修改时间排序，新的在前）＋ ${HOME}/ascend/log/debug/plog（要看的目录） 用法：ls -lt ${HOME}/ascend/log/debug/plog；只想看最近 10 个可加 | head -10 期望：列出若干 plog-<pid>_<时间戳>.log。最新那个的时间戳，应该和你刚刚那次运行的时刻对得上 不过会怎样：报 No such file or directory → 应用类日志没落盘（去第七段第 ① 条按官方 FAQ 四步查）； 目录在但最新文件的时间还是几天前 → 你这次跑的不是这套环境，或日志被落到别处了（查 ASCEND_PROCESS_LOG_PATH，见 4.9）

看完这一眼，先做两个判断：

  1. 最新文件的时间对不对 → 对得上，说明日志是新的、可以往下看；对不上，先解决「为什么没有新日志」；
  2. 要看的 pid 是哪个 → 从文件名末段取 pid，下一段命令就靠它缩范围。

4.5 第③步 锁时间窗与进程：把范围缩到一个 pid、一段报错前后

目的：日志文件可能很大，一次全看是看不完的。 这一步是把「一个文件」缩成「一段」。

为什么必须先缩（官方依据）：官方在《收集 AI Core Error 问题信息》里明确提醒 ——

在收集日志时，需收集本次问题附近时间的日志， 旧日志中的不相关信息或其它报错信息可能导致后续工具分析时报错。

⭐ 这条的意思是：「把所有日志都打包发过去」不是好做法，时间窗选对才算有效。 这条纪律从「自己看」一直延到「发给技术支持」。

命令　grep -n "<报错里的稳定特征词>" <日志文件>

含义：在日志文件里找出含这个特征词的行号和内容 拆解：grep（在文本里找含关键词的行）＋ -n（同时打印行号）＋ 特征词 ＋ 文件名 用法：grep -n "Call halGetDeviceInfo failed" plog-89696_20230307171327894.log 特征词要去掉具体化信息（不要搜「我们的服务莫名不动了」，要搜稳定特征词，这条 E1 讲过，第七段还会再用一次） 期望：打印出行号 + 该行原文。拿到行号后，用 sed -n '1000,1100p' <文件> 或编辑器跳到那一行，看它前后各几十行 不过会怎样：什么都没输出 → ① 特征词是中文描述而不是报错原文；② 时间窗不对（这个文件不是那一次的）；③ 级别不够（这一行在 DEBUG 级别里，见第 ④ 步）

这一步的产出是两个坐标：哪个文件 + 第几行。 后面所有动作都围着这两个坐标转。

4.6 第④步 不够细就调级别重跑：把日志级别调到 DEBUG

目的：当前日志级别下，报错前后的上下文不够用，这时才提高日志级别、复现一次。

官方对日志级别的定义（《设置日志级别》原文）：

日志级别等级由低到高顺序：DEBUG < INFO < WARNING < ERROR，级别越低，输出日志越详细。

  • 0：DEBUG，调试级别。该级别的日志记录了调试信息，便于开发人员或维护人员定位问题。
  • 1：INFO，正常级别。记录系统正常运行的信息。
  • 2：WARNING，警告级别。记录系统和预期的状态不一致，但不影响整个系统运行的信息。
  • 3：ERROR，一般错误级别。
  • 4：NULL，NULL 级别。不输出日志。

⚠️ 一个很容易看漏的官方细节： 调试日志默认为 ERROR 级别，且支持调整日志级别；安全日志默认为 DEBUG 级别，运行日志默认为 INFO 级别，且均不支持调整日志级别。

⭐ 把它读成一句话：你能调级别的只有 debug 那一支；run 和 security 是固定的。 所以「调了级别却没变化」的时候，先确认你看的是不是 debug 目录下的文件。

命令　export ASCEND_GLOBAL_LOG_LEVEL=0

含义：把应用类日志的全局级别设为 DEBUG（=0），输出最详细的日志 拆解：export（定义环境变量并传给子进程）＋ ASCEND_GLOBAL_LOG_LEVEL（官方：设置应用类日志的日志级别及各模块日志级别）＋ 0（官方取值：0=DEBUG / 1=INFO / 2=WARNING / 3=ERROR，3 是默认值）+ / 4=NULL 用法：export ASCEND_GLOBAL_LOG_LEVEL=0，然后再跑一次你的业务程序 期望：重新跑之后，日志文件里出现大量 [DEBUG] 行。用 grep -c "\[DEBUG\]" <新日志文件> 能数出条数 不过会怎样：官方原文警告 —— 「设置为 DEBUG 级别后，可能会因为日志流量过大影响业务性能」。 所以只在你确实需要更细上下文时才调，复现完就还原。 另外：这条 export 只在当前窗口有效，新开一个终端就没了 —— 这是 B1 讲过的 export 的本性。

还原：把级别调回默认的 ERROR ——

命令　export ASCEND_GLOBAL_LOG_LEVEL=3

含义：把应用类日志级别还原为 ERROR（默认值） 拆解：3 对应官方取值表里的 ERROR 级别，官方原文标明「默认为 ERROR 级别」 用法：export ASCEND_GLOBAL_LOG_LEVEL=3，或直接 unset ASCEND_GLOBAL_LOG_LEVEL（官方：若环境变量未配置/配置为非法值/配置为空，采用默认日志级别） 期望：之后跑业务，日志量回到正常水平 不过会怎样：忘了还原 → ① 磁盘被 DEBUG 日志快速吃掉；② D5 讲过的连带影响：某些依赖日志级别的能力会被悄悄关掉（D5 里那条是「虚推仅允许在 ERROR 日志级别下开启」）； ③ 下一次别人来排查，会被海量 DEBUG 日志淹掉

划重点的替代：如果你只是想让日志打一份在屏幕上，官方给了专用变量 —— ASCEND_SLOG_PRINT_TO_STDOUT（官方：日志的默认输出方式为将日志保存在 log 文件中，如果需要打印，可以配置环境变量 ASCEND_SLOG_PRINT_TO_STDOUT）。 这样就不必为了看日志去改级别。 官方还给了一个更省事的通用做法：开启日志打印功能后，也可以在启动应用进程时通过输出重定向方式把日志保存到指定文件中，例如 ./main > log.txt。

4.7 第⑤步 看服务层那一处：MindIE 日志

目的：前面看的是 CANN 侧的应用类日志；如果你部署的是 MindIE 服务，服务自己的日志要去另一个地方看。

判断依据很简单：你的服务是不是 MindIE 起的？ 是 → 去 ~/mindie/log；不是（例如 vLLM Ascend 裸起）→ 跳过这一步。

命令　ls -lt ~/mindie/log/debug

含义：按时间倒序列出 MindIE 的运行调试日志目录 拆解：ls（列出）＋ -lt（长格式 + 新的在前）＋ ~/mindie/log/debug（官方《查看日志》表 1 里「自动生成的运行调试日志路径」） 用法：ls -lt ~/mindie/log/debug；安全审计日志在 ~/mindie/log/security 期望：列出若干 mindie-<组件名称>_<pid>_<datetime>.log，组件名、进程号、时间戳三个字段都能对上你这次的服务 不过会怎样：目录不存在 / 空 → ① 你这套不是 MindIE 起的；② 日志被 MINDIE_LOG_PATH 指到别的地方去了（见附录 B B.2）；③ 官方说明 MindIE 默认收集 Informational 级别及以上，如果你确实什么都没看到，先确认服务真的起来过

看单个文件：

命令　cat mindie-service_123_202410080206.log

含义：打印这个 MindIE 日志文件的全部内容（官方示例 2 给的命令就是它） 拆解：cat（原意 concatenate 拼接，现今主要用来「看文件」）＋ 文件名 用法：cat mindie-service_123_202410080206.log；文件大时用 less mindie-service_123_202410080206.log 或配合 grep -n 缩范围（同 4.5） 期望：打印出该组件的日志行 不过会怎样：报 No such file or directory → 文件名拼错了（文件名里的 123 是 pid、202410080206 是 datetime，都是变的，要照 ls 的输出抄，不要照本课的例子抄）

⭐⭐ 顺带把「哪个日志归谁管」记牢（归纳，但依据是官方路径表）：

你看到的问题 先在哪个目录找
应用进程自己报错、AscendCL/GE/Runtime/HCCL 相关 ${HOME}/ascend/log/debug/plog/
Device 侧 AI CPU / HCCP 相关（应用类） ${HOME}/ascend/log/debug/device-<id>/
MindIE 服务化、LLM 组件相关 ~/mindie/log/debug/
登录认证 / 账户 / 访问控制 / 网络攻击类事件 ~/mindie/log/security/（官方：安全审计日志）

4.8 第⑥步 查设备号：搬 Device 日志前先把「设备号」查准

目的：msnpureport 的很多参数要指定 Device ID。设备号查错了，导出来的东西就是错的。

为什么这一步不能省（实测过的坑，已在体系里记过）： 不要假设设备号是 0。 在租用的容器环境里，透传进来的卡可能只有一部分， 实测遇到过 Device ID 从 5 开始的情况，照抄 -i 0 / -d 0 全部失败。 所以设备号一律从命令里读出来，不写死。

命令　npu-smi info

含义：查昇腾设备信息（型号、温度、显存、进程） 拆解：npu-smi（昇腾的设备管理工具，官方：驱动包全名是「驱动 & npu-smi 工具包」）＋ info（子命令，显示设备信息） 用法：npu-smi info 期望：一张表，其中 NPU ID 一列就是设备号（Chip Count 是芯片个数、Chip ID 是芯片 ID、Product Type 是产品类型） 不过会怎样：命令不存在 → 驱动没装（回 A1）；有输出但只列出部分卡 → 这是容器/虚拟化环境的正常现象，照样以它列出来的 ID 为准，不要按物理机的习惯假设从 0 开始

⚠️ 一条官方口径：npu-smi 不支持多线程并发使用。排查脚本里不要并发调它。

如果只是想拿到芯片健康状态，官方还给了带 -t health 的用法（原文示例，id 是设备 ID、chip_id 是芯片 ID，先 npu-smi info 拿到这两个值）：

命令　npu-smi info -t health -i <id> -c <chip_id>

含义：查指定芯片的健康状态；若存在 RAS 故障，最多可以查询到最近 8 次故障的 event id 拆解：info（查信息）＋ -t health（-t = 查什么，这里是健康）＋ -i <id>（-i = 查哪台，设备 ID）＋ -c <chip_id>（芯片 ID） 用法：npu-smi info -t health -i 0 -c 0 期望：打印该芯片的健康信息；有 RAS 故障时能看到 event id 不过会怎样：报参数错误 → -i 和 -c 别混（-i 是设备、-c 是芯片）；查到的 event_id 不是一个可以直接搜的数字， 官方说要在对应版本的《健康管理故障定义》手册里查,该手册是站外文档，本课未收录

4.9 第⑦步 搬 Device 日志：msnpureport

目的：把 Device 侧的系统类日志（还有黑匣子等维测信息）搬到 Host 上。

先确认三件事，再动手：

# 确认什么 怎么确认 不满足会怎样
① 是不是容器 容器内不支持查看和导出 Device 侧系统类日志（官方原文） 会白试（判别与替代见 4.10）
② 当前用户权限 官方要求「在 Host 侧以 root 用户运行 msnpureport 工具」（《收集 AI Core Error 问题信息》原文） 非 root 时能收到的数据范围会受限（官方在 asys 约束里说明过同类限制）
③ 在哪个目录执行 在一个有读、写、执行权限的目录下执行（官方反复强调） 导出失败或中途写不进

命令　msnpureport -f

含义：导出 Device 侧系统类日志和其他维测信息（slog 日志、syslog 日志、event 日志、黑匣子等） 拆解：msnpureport（官方工具名）＋ -f（全量导出，是官方文档里出现频率最高的一个参数） 用法：cd 到一个有读写执行权限的目录再执行，例如官方示例路径 cd /var/log/npu/report && msnpureport -f； 官方另一处示例是在自定义目录下执行：cd ${HOME}/ascend/report && msnpureport -f 期望：在当前路径下生成一个「以时间命名的日志文件夹」。 官方在《黑匣子日志参考》里说明：存放目录是运行 msnpureport 工具的所在路径（如 /var/log/）； 另一处官方原文又说「导出的日志和文件默认存放在 /var/log/npu/report 目录下」 ⚠️ 这两处官方口径不完全一致 —— 以你实际执行的目录和命令回显为准，本课不替你选一个。 不过会怎样：报错 → 官方《日志参考 · FAQ》给的两步见第七段第 ② 条；容器里跑 → 官方明说不支持

导出后要看什么（官方给的目录结构）：

/var/log/npu/report/*/slog/device-os-<id>/[run|debug]/device-0     ← 进程拉起与结束的日志
/var/log/npu/report/*/slog/device-os-<id>/run/device-os/            ← 系统进程运行日志（SYSMONITOR 在这里）
/var/log/npu/report/*/slog/dev-os-<id>/run/event/event_*.log        ← event 日志（找 event_id 用这个）
/var/log/npu/report/*/hisi_logs/device-<id>/*/bbox                  ← 黑匣子日志（找 Hardware Error）

⭐ 这张对照表是本课最有用的一页（每一行的出处都在附录 A）：

我要看什么 去哪个子目录 官方给的关键词
进程什么时候拉起、什么时候结束 slog/device-os-<id>/[run\|debug]/device-<id> create_ringbuffer / delete_ringbuffer
资源占用过高（内存/CPU/句柄/僵尸进程） slog/device-os-<id>/run/device-os/ SYSMONITOR 模块的 memory usage alarm 等
RAS 硬件故障 slog/dev-os-<id>/run/event/event_*.log event_id
未知硬件问题 hisi_logs/device-<id>/*/bbox Hardware Error

按设备号导出（把第 ⑥ 步查到的号填进去）：

命令　msnpureport -g debug -d <deviceID>

含义：获取指定 Device 上的 Debug 日志（这条出自官方故障案例库里的处置步骤） 拆解：-g debug（-g 指定级别，这里是 debug）＋ -d <deviceID>（-d 指定设备号） 用法：把 <deviceID> 换成第 ⑥ 步查到的实际编号，例如 msnpureport -g debug -d 0 期望：在导出目录下出现该设备对应级别的日志 不过会怎样：什么都不出来 / 报设备不存在 → 设备号写错了（回第 ⑥ 步）；或者这个形态不支持（容器里就不支持）

⭐ 换个常见用法：先用 -g 把 Device 侧的日志级别压到 error，减掉噪声。

命令　msnpureport -g error -d <deviceID>

含义：把指定 Device 侧的日志级别设为 error 拆解：-g error（级别设为 error）＋ -d <deviceID>（针对哪台设备） 用法：官方在《模型迁移调试 · 环境变量配置》里就是逐台设置的 —— msnpureport -g error -d 0 / -d 1 / -d 2 …… 有多少台就写多少条（该示例里写到 -d 7） 期望：命令成功返回，之后 Device 侧只会输出 error 级别的日志 不过会怎样：这条是「调级别」，不是「导日志」 —— 别把它当成导出命令用； 级别定得太高会把你要的上下文一起过滤掉，且这条改变的是 Device 侧状态，建议定位完还原

顺带记住还有一条来自官方的开关：

命令　msnpureport -e disable

含义：关闭 Device 侧 Event 日志（官方《环境变量配置》示例里的注释原文：「关闭 device 侧 Event 日志」） 拆解：-e（event 相关开关）＋ disable（关闭） 用法：msnpureport -e disable 期望：命令成功返回，Event 日志不再产生（官方用它的场景是「跑性能基线，先把噪声关掉」） 不过会怎样：把 Event 日志关了，等你真要查 RAS 硬件故障（要 event_id）时就没数据了 —— 用完记得开回来

⭐ 还有几条官方记录的 msnpureport 用法，按需用（全部出自官方原文）：

命令 官方说明
msnpureport -a 导出 proc 日志信息（官方案例 dvppcase_0010 用它查 DVPP 编解码统计）
msnpureport config --get --device 0 获取当前 Device 配置信息
msnpureport config --set --device 1 --accelerator_recover 0 设置 TaskSchedule 是否自动复位加速器（该配置后会影响执行性能）
msnpureport config --set --device 1 --singlecommit 0 设置 AI Core 的 singlecommit（关闭后 AI Core 内部多指令并行）
msnpureport config --set --aic_switch 0 --coreid 3 --device 0 屏蔽指定 AI Core 上的任务执行（另有一条 --aiv_switch 用于 Vector Core）
msnpureport report --type 2 导出寄存器信息，便于后续辅助定位硬件问题

⚠️ 官方对上面这批命令给了一条硬约束（原文）： 基于昇腾 AI 处理器的 AI 应用进程运行过程中不支持使用本步骤中的定位方法， 可能会导致应用进程运行异常或本步骤中的命令执行异常，需应用进程退出后才能使用。

并且官方还要求：定位问题后，建议恢复配置，以免影响业务性能。

周期化导出（长期跑的服务用这个）： 官方在 MindCluster 的《NPU Device 侧日志采集配置》里给了一个周期导出脚本：

命令　/bin/bash /usr/local/Ascend/driver/tools/msnpureport_auto_export.sh 300 10 /ascend_cluster_log/device_log/

含义：周期性导出 Device 侧日志（官方示例就是这个路径与顺序） 拆解：脚本路径在 <Driver 安装目录>/driver/tools/msnpureport_auto_export.sh（官方示例里 Driver 安装目录是 /usr/local/Ascend）； 三个参数依次是 ① 采集间隔时间（大于 0 的整数，单位 s）② 最大存储目录容量（大于等于 2 的整数，单位 G）③ Device 日志存储目录名（任意绝对路径） 用法：/bin/bash /usr/local/Ascend/driver/tools/msnpureport_auto_export.sh 300 10 /ascend_cluster_log/device_log/（示例＝每 300 秒导一次，目录上限 10G） 期望：指定目录下按周期不断出现新的 Device 日志 不过会怎样：官方三条提醒 —— ① 间隔设太短会「导致系统资源开销较大」，官方推荐 300（5 分钟）； ② 开机后只需执行一次，但服务器重启后需要重新执行，官方建议做成开机自启动脚本； ③ 参数写错（比如容量写成 1）不符合取值范围（官方的两个取值下限是「大于 0」和「大于等于 2」）

4.10 第⑧步 收口：出证据，也诚实标出拿不到的部分

收口要做四件事：

① 按时间戳归档，别混在一起。 官方示范的做法是这样的（出自《收集 AI Core Error 问题信息》，原文）：

mkdir ${HOME}/aic_err_info                 # 建一个空目录统一放
cd ${HOME}/aic_err_info && mkdir report
cd report && msnpureport -f                # 在这下面执行 msnpureport
mv ${HOME}/aic_err_info ${HOME}/aic_err_info_timestamp   # 带时间戳改名，便于按时间管理

官方说明（原文）：「将 ${HOME}/aic_err_info 目录下的信息移动到另一个目录下，目录名上可带上时间戳，便于按时间管理每一次收集的故障信息。」 ⭐ 这条纪律值得抄走：一次故障一个目录、目录名带时间戳 —— 否则收了三次以后你自己也分不清哪份是哪次的。

② 给「去哪找」留一张单子（验收证据）：

证据 在哪
应用类日志（Host 侧） ${HOME}/ascend/log/debug/plog/plog-<pid>_<时间戳>.log
应用类日志（Device 侧，自动回传） ${HOME}/ascend/log/debug/device-<id>/device-<pid>_<时间戳>.log
MindIE 日志 ~/mindie/log/debug/mindie-<组件>_<pid>_<datetime>.log
Device 系统类日志（导出后） msnpureport 执行目录下以时间命名的文件夹
收齐后的归档目录 ${HOME}/aic_err_info_<时间戳>/

③ 如果环境是容器，把「拿不到」如实写出来（这才是本步最重要的部分）。

官方原文非常明确：

容器内不支持查看 Device 侧系统类日志，也不支持通过 msnpureport 工具导出 Device 侧系统类日志。

所以容器环境下的替代方案是这样的（归纳，依据是官方的「哪类日志属于哪边」）：

想拿 容器里能拿到吗 替代办法
应用类日志 ✅ 能（官方说「应用类日志支持在容器内或物理机内查看」） 直接看 ${HOME}/ascend/log
Device 侧应用类日志 ✅ 能（会自动回传到 Host 侧） 看 ${HOME}/ascend/log/debug/device-<id>/
Device 侧系统类日志 ❌ 不能 要找宿主机（在 Host 侧以 root 执行 msnpureport），或直接找平台方
Device 侧的黑匣子 / 寄存器 / 硬件故障码 ❌ 不能 同上

⭐ 官方给了容器内查看应用类日志的一个前提条件（原文）： 「为保证日志工具在容器内正常运行，需要将日志工具动态库文件 libascendalog.so 及其依赖的 libc_sec.so 所在路径映射到容器内。 所在路径分别为 ${INSTALL_DIR}/compiler/lib64/libascendalog.so 和 ${INSTALL_DIR}/driver/lib64/common/libc_sec.so。」 → 容器里看不到应用类日志时，先查这一条，别急着怀疑业务。

④ 最后一条纪律：拿不到就说拿不到。

把「哪一处日志拿到了、哪一处没拿到、为什么没拿到」写进交付记录，本身就是交付能力。

本课自己也要遵守这条 —— 哪些地方是官方未给出所以本课没写，第九段末尾单独列了一张表。

第五段 · 怎么确认就位：三处日志，逐个找到

这一段是「照着敲」的清单。 每一条给命令、给期望、给不过怎么办。 全部不过也不要紧 —— 那是环境形态的问题，不是你的问题（见第七段）。

5.1 ① 应用类日志：目录在不在、有没有内容

命令　ls -l ${HOME}/ascend/log

含义：看应用类日志的根目录：debug / run / security 三个子目录在不在 拆解：ls（列出）＋ -l（长格式）＋ ${HOME}/ascend/log（官方默认路径，逐字取自《查看日志（Ascend EP）》） 用法：ls -l ${HOME}/ascend/log；想一次看到底用 ls -lR ${HOME}/ascend/log | head -40 期望：看到 debug run security 三个目录（debug 下还有 plog 与 device-0） 不过会怎样：报 No such file or directory → 还没跑过任何应用，或日志被指到别处（回 4.4 的「不过会怎样」）

5.2 ① 应用类日志：能不能定位到本次进程

命令　ls -lt ${HOME}/ascend/log/debug/plog | head -5

含义：只看最新的 5 个 Host 侧调试日志文件 拆解：ls -lt（按时间倒序）＋ | head -5（管道：把左边的输出交给 head，只留前 5 行） 用法：ls -lt ${HOME}/ascend/log/debug/plog | head -5 期望：最新文件的时间 ≈ 你刚刚那次运行的时刻；文件名里的 pid 与你的进程对得上 不过会怎样：时间对不上 → 日志级别太高、或这次运行没产生应用日志 → 回 4.4 / 4.6

5.3 ② Device 日志：能不能导出（先确认不是容器）

命令　df -h

含义：看各文件系统的剩余空间 —— 这是执行 msnpureport 前的官方前置检查项 拆解：df（disk free，磁盘剩余）＋ -h（human-readable，以 G/M 显示而不是字节数） 用法：df -h 期望：导出目标所在分区还有足够空间；并且能看出根文件系统是不是 overlay（容器环境的典型特征） 不过会怎样：目标分区已满 → 官方《日志参考 · FAQ》明确说这是「日志没有正常落盘」和「导出 Device 侧系统日志失败」的共同处理点，先腾空间再导； 看到根是 overlay → 大概率是容器，先回 4.9 确认第①条（容器不支持）

命令　msnpureport -f

（完整解释见 4.9 与附录 B B.1；这里只关注怎么算成功） 含义：全量导出 Device 侧系统类日志和维测信息 拆解：见 4.9 用法：先 cd 到一个有读、写、执行权限的目录，再执行 期望：当前目录下出现一个以时间命名的文件夹，里面有 slog/、hisi_logs/ 等子目录 → 这就是「导出来了」的证据 不过会怎样：报错 → 第七段第 ② 条（官方 FAQ 两步）；命令不存在 → 驱动没装（回 A1）；容器里 → 官方不支持

5.4 ③ MindIE 日志：服务场景才需要

命令　ls -lt ~/mindie/log/debug | head -5

含义：看 MindIE 运行调试日志的最新几个文件 拆解：同 4.7 的 ls -lt，只是路径换成官方《查看日志》表 1 的 ~/mindie/log/debug 用法：ls -lt ~/mindie/log/debug | head -5 期望：出现 mindie-<组件>_<pid>_<datetime>.log 形式的文件名 不过会怎样：目录不存在 → 这套不是 MindIE 起的（不是故障）；有目录没文件 → 官方说 MindIE 默认收集 Informational 及以上，确认服务真的跑起来过

5.5 收日志前的一张「级别确认」小卡

命令　echo $ASCEND_GLOBAL_LOG_LEVEL

含义：打印当前环境变量里设的应用类日志级别（官方原文就给了这条查法） 拆解：echo（把值打印到屏幕）＋ $ASCEND_GLOBAL_LOG_LEVEL（$ = 取这个变量的值） 用法：echo $ASCEND_GLOBAL_LOG_LEVEL 期望：0/1/2/3/4 之一，或空（官方：未配置/非法值/空 → 采用默认日志级别，默认是 ERROR(3)） 不过会怎样：输出空字符串是正常的 —— 官方说这时走默认值，别以为「变量坏了」 ⭐ 这也是收日志前的必查项：级别太高，你要的上下文根本没被打印出来

5.6 三处日志定位速查（截图存手机）

我要找 命令 / 路径
应用类日志根目录 ${HOME}/ascend/log
应用类日志·Host 侧·调试 ${HOME}/ascend/log/debug/plog/plog-<pid>_<时间戳>.log
应用类日志·Device 侧·调试 ${HOME}/ascend/log/debug/device-<id>/device-<pid>_<时间戳>.log
MindIE 日志·运行调试 ~/mindie/log/debug/mindie-<组件>_<pid>_<datetime>.log
MindIE 日志·安全审计 ~/mindie/log/security/
Device 系统类日志 不在 Host，需 msnpureport -f 导出
trace 日志 $HOME/ascend/atrace/（出错/退出才落盘）
当前日志级别 echo $ASCEND_GLOBAL_LOG_LEVEL

第六段 · 判据 / 验收

6.1 五条判据（全过 = 这一课的事做完了）

# 判据 验证方式 不过说明问题在
① 应用类日志目录就位 ls -l ${HOME}/ascend/log → 有 debug/run/security 没跑过应用，或参考 4.4
② 能定位到本次进程的日志 ls -lt ${HOME}/ascend/log/debug/plog \| head -5 → 最新时间对得上 级别太高 / 日志路径被改过
③ 知道日志归属（不查错文件） 能说出「Host 侧 plog / Device 侧 device-id / MindIE / 安全日志」各自在哪 回第三段 3.3、3.5
④ Device 日志能导出 在有读写权限目录下 msnpureport -f → 出现以时间命名的文件夹 容器环境 / 权限 / 磁盘满（第七段）
⑤ 知道当前日志级别 echo $ASCEND_GLOBAL_LOG_LEVEL → 有值或空 回 5.5（空是正常的）

⭐ 判据 ④ 要单独说一句：它在容器环境下注定过不了，而且官方明说不支持。 这不是你没做完 —— 见 6.3 的「三种出口」。

6.2 验收证据（拿什么给别人看）

证据 形态
一次完整收日志的记录 aic_err_info_<时间戳>/ 这样一个归档目录（官方示范的命名法）
日志归属说明 上面 5.6 那张速查表，按你实际的路径填一遍
日志级别状态 echo $ASCEND_GLOBAL_LOG_LEVEL 的输出
拿不到什么、为什么 一句话：例如「Device 侧系统类日志未取到 —— 容器环境，官方明示不支持导出」

6.3 三种出口（这一步卡住了怎么办）

卡在哪 第一选择 第二选择 兜底
应用类日志没有新文件 查 echo $ASCEND_PROCESS_LOG_PATH（可能被改路径） 查磁盘 df -h 官方 FAQ 四步（第七段第 ① 条）
容器里导不出 Device 日志 确认是不是真的容器 到宿主机上执行 msnpureport -f 如实标注后跳过（官方明示不支持）
msnpureport 命令不存在 确认驱动装了（npu-smi info 有输出＝驱动在） 用 asys（注意：集群/容器/虚机/云也不支持） 只交应用类日志 + 说明
不知道从哪下手 回第四段，按八步走 回 E1 三步法判层 只做第 ② 步（应用类日志永远是兜底）

⭐ 判据 ④ 在容器里过不了的时候，请记住这句话： 把「没做成的」如实写进交付记录，本身就是交付能力。

6.4 官方给的「一键全收」以及它为什么不总是能用

官方确实提供了一个一键收集工具（asys，官方原文）：

为提高系统故障维测效率，提供故障信息收集工具 asys 一键式收集信息。该工具仅支持在 Ascend EP 形态下使用。

它的官方命令：asys collect --task_dir=$HOME/cache_path --tar="True" --output=$HOME/dfx_info

⚠️ 但官方给了六条使用约束（原文），其中第 4 条直接决定了你的环境能不能用：

  1. 不支持在 Ascend RC 形态下使用。
  2. 相同用户、相同时间段内、同机器同时作业时，收集到的数据会有交叉。
  3. 非 root 用户，获取到的数据范围会受限。
  4. 集群、容器、虚拟机、云场景不支持一键式工具收集故障信息。
  5. asys 涉及大量维测信息的收集，涉及内存占用，不建议多进程并行执行。
  6. asys 会检索 trace 日志所在目录，若 trace 日志文件过多，可能会导致 asys 执行时间长。

⭐ 第 4 条一句话：租用容器环境上，asys 和 msnpureport 一样用不了。 所以「一键全收」是物理机上的省事办法，不是所有环境的通用解 —— 这就是本课为什么要把「三处分别怎么收」讲清楚。

第七段 · 出问题怎么查（排查表）

现场的人是拿着现象来找的。 所以下面按现象排，不按「日志类型」排。

7.1 主排查表

你看到的现象 先查什么（命令） 官方口径 / 说明
${HOME}/ascend/log 下什么都没有 ls -l ${HOME}/ascend/log；echo $ASCEND_PROCESS_LOG_PATH 可能被 ASCEND_PROCESS_LOG_PATH 改到别处（官方：日志落盘优先级 ASCEND_PROCESS_LOG_PATH > ASCEND_WORK_PATH > 默认路径 ${HOME}/ascend/log）
应用类日志没有正常落盘 ① cat /var/log/messages（aarch64）或 cat /var/log/syslog（x86_64）② df -h ③ 用 msnpureport 看 Device 侧有没有相关错误 官方 FAQ 给的正是这三步（详见 7.2）
msnpureport 导出失败 ① 看命令回显的提示信息 ② df -h 官方 FAQ 给的两步（详见 7.3）
屏幕上一直有日志，但文件里没有 ulimit -a；lsof \| wc -l 官方解释：日志模块会建 Socket 交给 slogd 落盘，Socket 建失败就打到屏幕；常见原因是打开文件数超过系统上限（详见 7.4）
日志里的时间戳和系统时间对不上 timedatectl 官方：可能是启动 AI 任务后改了系统时区；处理方式见 7.5
日志级别调了却没变化 确认你看的是不是 debug 目录 官方：运行日志默认 INFO、安全日志默认 DEBUG，且均不支持调整；只有调试日志支持调整
容器里看不到 Device 侧系统日志 确认环境形态（根文件系统是不是 overlay） 官方：容器内不支持查看，也不支持通过 msnpureport 导出
容器里应用类日志也看不到 查 libascendalog.so / libc_sec.so 有没有映射进容器 官方原文：为保证日志工具在容器内正常运行，需把这两个动态库所在路径映射到容器内
磁盘被日志吃满 df -h 官方：应用类日志目录是容器/物理机内所有应用共用，会不断增多，需定期清理（可用 logrotate）
日志突然只剩最近的几条 不用查，这是设计 官方：应用类日志支持老化，数量或大小超限会自动删除最早的；Device 侧系统类日志同样支持老化
只想要某台设备的日志 msnpureport -g <级别> -d <设备号> 官方逐台设置的写法见 4.9
想把 Device 日志收得细一点 msnpureport config --get --device 0 看当前配置 ⚠️ 官方：应用进程运行过程中不支持用这批命令，需应用进程退出后才能使用

7.2 官方的「应用类日志没有正常落盘」四步（原文照录）

  1. 执行如下命令查看 Host 侧 /var/log/messages 文件中是否有相关的错误日志。 - aarch64 架构：cat /var/log/messages - x86_64 架构：cat /var/log/syslog
  2. 在 Host 侧执行如下命令查看日志落盘路径（$HOME/ascend/log/）所在的磁盘空间是否已满：df -h
  3. 在 Host 侧通过 msnpureport 工具导出 Device 侧系统日志，查看是否有相关的错误日志。
  4. 若未能解决问题，您可以获取日志后单击 support 联系技术支持。

⭐ 这四步的顺序值得记：先看系统日志 → 再看磁盘 → 再下探 Device → 最后找支持。 它和本课第四段的八步是同一套思路：从最便宜、最靠上的地方开始。

7.3 官方的「msnpureport 导出 Device 侧系统日志失败」两步（原文照录）

  1. 在 Host 侧执行 msnpureport 工具命令后，查看打印的提示信息定位问题。
  2. 在 Host 侧执行如下命令查看 Host 侧日志存放路径（运行 msnpureport 工具所在路径）所在的磁盘空间是否已满：df -h
  3. 若未能解决问题，您可以获取日志后单击 support 联系技术支持。

⭐ 第 2 步里的那句话很重要：「运行 msnpureport 工具所在路径」 —— msnpureport 把东西导到哪，就取决于你在哪个目录运行它。 所以 4.9 里那句「先 cd 到有读写权限的目录」不是废话。

7.4 官方的「屏幕上有日志但文件里没有」（原文照录）

异常现象：用户未设置日志打印环境变量（export ASCEND_SLOG_PRINT_TO_STDOUT=1），但是在屏幕上仍有日志显示。

可能原因：日志模块收到日志消息后，首先根据环境变量判断是否打印到屏幕上，若不需要打印到屏幕上，则创建 Socket 与 slogd 进程建立连接，将日志发送给 slogd 进程，由 slogd 进程落盘。但是如果创建 Socket 失败，则会将日志打印到屏幕上。

处理方式：创建 Socket 失败的原因一般是用户在执行用例时，打开文件的数量超过了系统默认的最大数量。可以通过 ulimit -a 和 lsof | wc -l 命令分别查看系统默认打开文件的最大数量（即 open files 字段的取值）以及当前已经打开的文件数量。如果超过限制值，可以通过 ulimit -n <num> 命令设置打开文件的最大数量。

⭐ 这条是「现象反直觉」的典型：屏幕上多出来的日志，其实是「落盘失败」的症状，不是「打印开关没关」。

7.5 官方的「时间戳不对」（原文照录）

可能原因：用户启动了 AI 任务后修改了系统环境的时区。

处理方式：方法一，重新启动 AI 任务；方法二，修改系统环境时区： timedatectl（查看当前时区设置）→ sudo timedatectl set-timezone Asia/Shanghai（以 Asia/Shanghai 为例设置新时区）。

7.6 一条通用的检索技巧（E1 讲过，这里再用一次）

搜报错要「去具体化」：去掉路径、pid、时间戳，只留稳定特征词。 例如不要搜「我们的服务莫名不动了」，要搜 Call halGetDeviceInfo failed、create_ringbuffer、SYSMONITOR、event_id 这种。

第八段 · 常见报错清单（官方真实案例编号）

⚠️ 数据纪律：下表的案例编号、报错原文、浏览量全部取自昇腾官方故障案例库（实时接口）， 案例详情页统一形式为 https://www.hiascend.com/document/caselibrary/detail/<案例编号>。 官方没有一份「日志课专属的报错码表」 —— 本课不编。

8.1 与「看日志」直接相关的官方案例

案例编号 标题 报错原文（片段） 浏览量 本课相关的看点
aclcase_0019 执行应用程序的权限不足导致 AscendCL 初始化报错 [ERROR] RUNTIME(89696,main):… Call halGetDeviceInfo failed: drvRet=4, module type=0, info type=1. / [ERROR] ASCENDCL(89696,main):… aclInit: … init soc version failed, ret = 507008 / [ERROR] acl init failed 6597 案例里明确写「查看应用类日志」→ 说明这类报错的入口就是 ${HOME}/ascend/log；处置末尾给出 export ASCEND_GLOBAL_LOG_LEVEL=0 + msnpureport -g debug -d deviceID 组合
dvppcase_0009 图像解码进程超时退出 [ERROR] AICPU(pid,pName):… task timeout, userData=0xe7ffe0001280, timeout=30, duration=30.930062. / [WARNING] DVPP(pid,pName):… frames statistic: ACL receive(16), send(15) 3217 同样是「查看应用类日志」发现的两条不同级别的日志（ERROR + WARNING）—— 提醒别只 grep ERROR
dvppcase_0010 参数设置不合理，导致视频编码耗时长或编码失败 ——（案例步骤是用 msnpureport -a 导 proc 日志排查） 3100 官方在案例里给出的 msnpureport -a 用法：导出 proc 日志后看 module_info\dev-os-0\dvpp\dvpp_proc.log
dvppcase_0008 图片格式不支持或图片数据不完整，图片解码失败 ——（案例说明「查看日志有类似如下报错信息」） 7039 又一个「从日志下手」的案例
topic_0000002193154190 部署 DeepSeek 服务化，性能不佳 ——（部署后实测性能较差，与预期差异较大） 7969 服务化部署类问题，对应本课的 ③ MindIE 日志那一处

⭐ 从这五个案例里能读出一件事（归纳）：

官方案例的处置步骤，几乎都是从「查看应用类日志」开始的。 这从侧面印证了本课 4.4 的判断：应用类日志是第一优先，不是因为它简单，而是因为它最常给出答案。

8.2 与日志机制本身相关的官方「现象 → 说明」

这几个不是报错码，而是官方 FAQ 里明确列出的现象（详见第七段）：

现象 官方说明（原文要点） 先查什么
应用类日志没有正常落盘 官方 FAQ 列了四步 cat /var/log/messages（aarch64）/ cat /var/log/syslog（x86_64）→ df -h
msnpureport 导出失败 官方 FAQ 列了两步 命令回显的提示信息 → df -h
未设打印变量但屏幕有日志 Socket 建失败 → 日志打到屏幕 ulimit -a / lsof \| wc -l
日志时间戳不正确 启动 AI 任务后改了系统时区 timedatectl
日志没落盘（Control CPU 开放形态） 依次查动态库、磁盘、slogd 进程 ldd xxx → df -h → ps -elf \| grep slogd
日志进程启动异常 可能是 /var 所在磁盘使用率过高 df -h，必要时手工清理 /var/log/npu/slog 下较大较早的文件后重启日志进程

8.3 报错里会出现的两个「稳定特征词」（Device 日志用）

特征词 官方含义
create_ringbuffer 进程拉起。官方补充：为避免重复创建，每一次创建 ringbuffer 前都会先做一次删除，所以创建的日志会同时出现 delete_ringbuffer 和 create_ringbuffer；若同一进程有多个 create_ringbuffer，其中含 ringbuffer_addr 关键字的那条时间表示该进程的拉起时间
delete_ringbuffer 进程结束。官方补充：若同一进程有多个 delete_ringbuffer，最后一次的时间表示该进程的结束时间

官方给的那段日志片段（节选，字段含义：YYYY-MM-DD-HH:MM:SS.fff.uuu）：

device-0_******.log:23103:[EVENT] TSCH(-1,null):YYYY‑MM‑DD‑HH:MM:SS.fff.uuu 17642 (dieid:0,cpuid:0) ringbuffer.c:134 create_ringbuffer: pid=3299758, vf_id=0, buffer_len=10, runtime ver=2, offset=276096, ringbuffer_addr=0x1f7dc00000.
device-0_******.log:23503:[EVENT] TSCH(-1,null):YYYY‑MM‑DD‑HH:MM:SS.fff.uuu 47266 (dieid:0,cpuid:0) ringbuffer.c:177 delete_ringbuffer: pid=3299758, vf_id=0

⭐ 这两个词解决的是一个很实际的问题：「任务到底几点起的、几点没的」 —— 官方原话：问题定位时往往需要先初步定界到问题发生的大致时间点，再根据出错时间的详细日志继续定位。

第九段 · 小结 + 钩子 + 自测

9.1 三句话带走

  1. 日志按「谁产生」分两类，按「在哪查」落三处： 系统类日志（Device 侧产生，不在 Host，要 msnpureport 搬） vs 应用类日志（你的程序产生，${HOME}/ascend/log，Device 侧的还会自动回传）； 加上 MindIE 日志 ~/mindie/log（含 debug / security），以及 trace 日志 $HOME/ascend/atrace/。
  2. Device 日志要搬，是因为「没有权限」，不是「日志没产生」 —— 官方原文：「Ascend EP 标准形态下，用户没有 Device 的登录权限」。 所以搬它的工具是 msnpureport；而容器里官方明说不支持查看和导出这一处。
  3. 收日志的顺序是「从便宜到贵」： 应用类日志（Host 上有）→ 调级别重跑 → MindIE 日志 → 才轮到搬 Device 日志； 搬之前先查设备号（别假设是 0），搬之后按时间戳归档（官方示范的命名法）。

9.2 本课在体系里的位置

─── 排障（E 层）───
E1 报错定位法        ✅  ← 判层、三步法
E2 日志在哪里 ★本课  ← 三处日志的路径、命令、期望、导出
E3 官方案例库用法     ✅  ← 拿收上来的日志去案例库比对
E4 报错码速查         ✅  ← 拿到一个错误码该干什么

9.3 本课留下的「钩子」

钩子 在哪一课 / 哪份官方文档填
官方案例库怎么按报错检索 E3（下一课）
trace 日志的完整解析（schedule_tracer_*.txt / .bin） 官方《日志参考 · 查看 trace 日志》+ asys 的文件解析功能
msnpureport 的参数全表 官方《msnpureport 工具使用指南》（⚠️ 站外文档，见 9.5）
AI Core Error 的归因（msaicerr） 官方《AI Core Error 问题定位专题》
黑匣子日志怎么读 官方《Atlas A2 / A3 黑匣子日志参考》（HDK 26.1.x）

9.4 课后自测（4 题）

  1. 官方为什么要把日志分成「系统类」和「应用类」？分界线是「在 Host 还是在 Device」吗？ （提示：Device 侧 AI CPU 进程打的日志算哪一类？它会不会出现在 Host 上？）
  2. ~/mindie/log 和 ${HOME}/ascend/log 在同一个 home 下、都有 debug 子目录 —— 它们是什么关系？ （提示：谁产生的？混着看会有什么后果？）
  3. 你要在容器里收 Device 侧系统类日志，官方允许吗？如果不允许，你能收到的是哪几种日志、从哪里收？
  4. msnpureport -f 到底导出到哪个目录？ （提示：能不能从「执行命令前先 cd」这件事反推出答案？官方在 FAQ 里是怎么描述「运行 msnpureport 工具所在路径」的？）

9.5 ⭐ 哪些地方是官方未给出，所以本课没写

这张表是本课数据纪律的自证。 以下内容本课一处都没编：

# 官方未给出的东西 本课的处理
1 msnpureport 的完整参数表 CANN 9.2.0-beta.2 文档中只以样例命令形式出现；完整参数表在站外《msnpureport 工具使用指南》（support.huawei.com，编号 EDOC1100540106）——本课已尝试获取但未取到正文，因此只写「官方文档里确实出现过的参数」，并逐条标出出处。其余参数请以该指南为准
2 msnpureport -h / --help 的输出格式 官方文档未给出。本课不写
3 日志老化/轮转的具体阈值 官方只说「日志文件数量和大小超限将自动删除最早的」，未给具体数值。本课只写机制，不写数字
4 msnpureport -f 导出目录的唯一定论 官方两处口径不完全一致：一处说「在当前路径下生成以时间命名的文件夹」，一处说「默认存放在 /var/log/npu/report」。本课把两种口径都写出来，并明说以实际执行目录与回显为准，不替官方选一个
5 Device 侧日志在 Device 上的原始落盘路径 EP 形态下用户没有 Device 登录权限，官方只给「导出之后」的路径。Device 上原路径官方未给出
6 日志级别「设多少合适」的通用推荐值 官方只给取值定义和默认值（ERROR）。除「vLLM 虚推必须 ERROR 级别」这类特定场景外，官方未给通用推荐
7 ASCEND_PROCESS_LOG_PATH 与 ASCEND_WORK_PATH 同时设置时的全部细节 官方给了优先级（前者 > 后者 > 默认路径）与「同时存在时分别从哪取哪几类」，更细的冲突场景未给出
8 容器内 device-id（逻辑 ID）与真实设备号的映射关系 官方只说明「在容器内，目录中的 device-id 为逻辑 ID」以及「应用类日志支持在容器内查看」。映射表官方未给出
9 event_id 具体的故障码含义 官方说要去对应版本的《健康管理故障定义》手册查，该手册在站外。本课只给「怎么拿到 event_id」，不给故障码含义
10 trace 日志的文本解析工具与参数 官方指向 asys 的文件解析功能，本课只给路径与去向，不复述工具参数
11 本文档中「日志归属速查表」「三处归位」「八步执行者路径」 属本课归纳，非官方表述 —— 依据是官方给出的路径表与分类定义，但这个组织方式是本课自己排的

附录 A · 本课引用的官方出处

内容 出处
日志分类（系统类日志含 Control CPU / 非 Control CPU 两类；应用类日志含 Host 侧组件日志与 Device 侧 AI CPU 进程日志）；日志记录格式 [Level] ModuleName(PID,PName):DateTimeMS [FileName:LineNumber]LogContent 官方 CANN《日志参考 · 日志简介》
zh/CANNCommunityEdition/920beta2/maintenref/logreference/docs/zh/log_ref/log_overview.md
应用类日志默认路径 $HOME/ascend/log；debug/run/security × plog/device-id 六条路径的逐条说明；目录树；注 2 定期清理 / 注 3 emmc 写次数 / 注 4 容器内为逻辑 ID；容器内需映射 libascendalog.so 与 libc_sec.so；ASCEND_PROCESS_LOG_PATH、ASCEND_LOG_DEVICE_FLUSH_TIMEOUT、ASCEND_HOST_LOG_FILE_NUM、ASCEND_LOG_SYNC_SAVE、ASCEND_SLOG_PRINT_TO_STDOUT；Device 侧应用类日志自动回传、默认 2000ms 延时 官方 CANN《日志参考 · 查看日志（Ascend EP）》
zh/CANNCommunityEdition/920beta2/maintenref/logreference/docs/zh/log_ref/viewing_logs_ep.md
「用户没有 Device 的登录权限」；「容器内不支持查看 Device 侧系统类日志，也不支持通过 msnpureport 工具导出」；系统类日志支持老化 同上
日志级别取值（0 DEBUG / 1 INFO / 2 WARNING / 3 ERROR 默认 / 4 NULL）；DEBUG < INFO < WARNING < ERROR；「调试日志默认为 ERROR 且支持调整；安全日志默认为 DEBUG、运行日志默认为 INFO，且均不支持调整」；ASCEND_GLOBAL_LOG_LEVEL、ASCEND_MODULE_LOG_LEVEL、ASCEND_GLOBAL_EVENT_ENABLE；Ascend EP 形态下系统类日志级别通过 msnpureport 设置 官方 CANN《日志参考 · 设置日志级别》
zh/CANNCommunityEdition/920beta2/maintenref/logreference/docs/zh/log_ref/setting_log_levels.md
ASCEND_GLOBAL_LOG_LEVEL 功能描述、取值、「设置为 DEBUG 级别后，可能会因为日志流量过大影响业务性能」、「未配置/非法值/空则采用默认」、echo $ASCEND_GLOBAL_LOG_LEVEL 查法 官方 CANN《环境变量参考 · ASCEND_GLOBAL_LOG_LEVEL》
zh/CANNCommunityEdition/920beta2/maintenref/envvar/docs/zh/env_vars/ASCEND_GLOBAL_LOG_LEVEL.md
ASCEND_PROCESS_LOG_PATH 功能描述、落盘优先级 ASCEND_PROCESS_LOG_PATH > ASCEND_WORK_PATH > $HOME/ascend/log、仅适用 Ascend EP 官方 CANN《环境变量参考 · ASCEND_PROCESS_LOG_PATH》
zh/CANNCommunityEdition/920beta2/maintenref/envvar/docs/zh/env_vars/ASCEND_PROCESS_LOG_PATH.md
应用类日志没有正常落盘的官方四步（/var/log/messages 或 /var/log/syslog → df -h → msnpureport 导 Device 日志 → 找支持） 官方 CANN《日志参考 · FAQ》
zh/CANNCommunityEdition/920beta2/maintenref/logreference/docs/zh/log_ref/faq.md
msnpureport 导出 Device 侧系统日志失败的官方两步（看提示信息 → df -h） 同上
「未设置日志打印环境变量但屏幕仍有日志」（Socket 失败原因 + ulimit -a / lsof \| wc -l / ulimit -n <num>） 同上
「修改环境时区后，日志打印的时间戳不正确」（timedatectl / timedatectl set-timezone Asia/Shanghai） 同上
Control CPU 开放形态 / Ascend RC 形态的「应用类日志没有正常落盘」与「系统类日志没有正常落盘」处置（ldd xxx / df -h / ps -elf \| grep slogd / ps -elf \| grep log） 同上
修改 Device 侧日志配置文件后需重启日志进程；kill -15 进程ID（slogd/sklogd/log-daemon）与 kill -9 的用法；/var 磁盘满导致 slogd 启动失败的处理 官方 CANN《日志参考 · 重启日志进程》
zh/CANNCommunityEdition/920beta2/maintenref/logreference/docs/zh/log_ref/restarting_log_processes.md
trace 机制定义（记录在内存、出错或进程结束时落盘）、仅 Ascend EP 标准形态支持、路径 $HOME/ascend/atrace/、子路径命名规律、四类 trace 文件说明、ASCEND_TRACE_RECORD_NUM 官方 CANN《日志参考 · 查看 trace 日志》
zh/CANNCommunityEdition/920beta2/maintenref/logreference/docs/zh/log_ref/viewing_trace_logs.md
故障处理总体流程（收集故障信息 → 分析故障原因 → 故障排除）；故障信息包括应用类日志、Device 侧系统类日志和其他维测信息；「常用的日志为 plog-pid_*.log，通常称为 plog 日志」；「一般采用自上而下的日志分析方法」 官方 CANN《故障处理简介》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/troubleshooting_intro.md
msnpureport -f；「在某个有读、写、执行权限的目录（如 /var/log/npu/report）下执行」；导出后目录 slog/device-os-<id>/[run\|debug]/device-<id>；grep -rn ringbuffer；create_ringbuffer / delete_ringbuffer 的判定规则（含「含 ringbuffer_addr 的日志时间表示拉起时间」「最后一次 delete 表示结束时间」）；「问题定位时往往需要先初步定界到问题发生的大致时间点」 官方 CANN《故障处理 · 通过 Device 日志确认 Host 进程的拉起与结束时间》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/device_log_host_process_time.md
msnpureport -f；Device 系统进程运行日志默认在 /var/log/npu/report/*/slog/device-os-<id>/run/device-os/；SYSMONITOR 模块的关键词（memory usage alarm / cpu usage alarm / fd usage alarm / zombie process count alarm 及各自阈值 90%/90%/90%/5） 官方 CANN《故障处理 · 通过 Device 日志查看资源占用过高的信息》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/device_log_high_resource_usage.md
msnpureport -f；「导出的日志和文件默认存放在 /var/log/npu/report 目录下」；event 日志路径 slog/dev-os-<id>/run/event/event_*.log；event_id 要查《健康管理故障定义》；npu-smi info -t health -i id -c chip_id「最多可以查询到最近 8 次故障的 event id」；黑匣子 hisi_logs/device-<id>/*/bbox 与 Hardware Error 官方 CANN《故障处理 · 通过 Device 日志获取故障 ID 并排查 RAS 硬件故障》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/device_log_ras_hardware_fault.md
「在 Host 侧以 root 用户运行 msnpureport 工具」；msnpureport -f；归档做法 mkdir ${HOME}/aic_err_info → mv 带时间戳改名；「需收集本次问题附近时间的日志，旧日志中的不相关信息或其它报错信息可能导致后续工具分析时报错」；ASCEND_PROCESS_LOG_PATH、ASCEND_WORK_PATH、NPU_COLLECT_PATH 三个变量的用法；「集群、容器、虚拟机、云场景不支持 asys 工具一键式收集故障信息」 官方 CANN《故障处理 · 收集 AI Core Error 问题信息》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/collect_ai_core_error_info.md
asys 的功能清单、支持收集的信息列表、六条使用约束（不支持 Ascend RC / 同用户同时段数据交叉 / 非 root 范围受限 / 集群容器虚机云不支持 / 不建议并行 / trace 日志过多会慢）；asys collect --task_dir=path1 --tar="True" --output=path2 与输出目录结构；trace 日志默认路径 $HOME/ascend/atrace/ 官方 CANN《asys 工具功能及约束》《故障信息收集》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/asys/asys_functions_and_restrictions.md
…/asys/fault_information_collection.md
msnpureport config --get --device 0 / config --set --device 1 --accelerator_recover 0 / config --set --device 1 --singlecommit 0 / config --set --aic_switch 0 --coreid 3 --device 0 / config --set --aiv_switch 0 --coreid 5 --device 0 / config --set --icachecheck 128 --device 0 / report --type 2；「应用进程运行过程中不支持使用」这批命令、「需应用进程退出后才能使用」；「定位问题后，建议恢复配置，以免影响业务性能」 官方 CANN《故障处理 · 使用 msnpureport 工具收集更多 AI Core Error 信息》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/use_msnpureport_ai_core_err.md
msnpureport -f 生成「以时间命名的日志文件夹」；msnpureport -g error -d 0…7 逐台设级别；msnpureport -e disable（关闭 Device 侧 Event 日志）；ASCEND_SLOG_PRINT_TO_STDOUT=0；ASCEND_GLOBAL_LOG_LEVEL=3；ASCEND_GLOBAL_EVENT_ENABLE=0 官方 ModelZoo《模型迁移调试 · 环境变量配置》
zh/ModelZoo/traditional_model_train/PyTorch/docs/zh/model_training/env_config.md
msnpureport -f 「会在当前路径下生成一个以时间命名的日志文件夹」；「存放目录是运行 msnpureport 工具的所在路径（如 /var/log/）」；黑匣子日志是通过 msnpureport 工具导出的 官方 HDK《Atlas A2 / A3 黑匣子日志参考 · 日志介绍》
zh/HDK/2610/A2/A2blackboxlog/atlasbb_16_0005.html
zh/HDK/2610/A3/A3blackboxlog/atlasbb_16_0005.html
应用类日志默认路径 $HOME/ascend/log；export ASCEND_GLOBAL_LOG_LEVEL=0；msnpureport -g debug -d deviceID（官方处置步骤原文） 官方故障案例 aclcase_0019《执行应用程序的权限不足导致 AscendCL 初始化报错》
https://www.hiascend.com/document/caselibrary/detail/aclcase_0019
CANN 文档版同一问题的处置步骤（含 cat /etc/ascend_install.info、./upgrade-tool --device_index -1 --system_version、usermod -g 组名 用户名） 官方 CANN《故障案例集 · 执行应用程序的权限不足导致 acl 接口初始化报错》
zh/CANNCommunityEdition/920beta2/maintenref/troubleshooting/docs/zh/troubleshooting/acl_init_permission_denied.md
案例标题与浏览量（dvppcase_0008 7039 / dvppcase_0009 3217 / dvppcase_0010 3100 / aclcase_0019 6597 / topic_0000002193154190 7969） 昇腾官方故障案例库（/case/library/list 实时接口，检索日 2026-10-06）
msnpureport -a 导出 proc 日志；proc 日志路径 module_info\dev-os-0\dvpp\dvpp_proc.log 官方故障案例 dvppcase_0010《参数设置不合理，导致视频编码耗时长或编码失败》
https://www.hiascend.com/document/caselibrary/detail/dvppcase_0010
dvppcase_0009 的报错原文（task timeout, userData=… / frames statistic: ACL receive(16), send(15)） 官方故障案例 dvppcase_0009《图像解码进程超时退出》
https://www.hiascend.com/document/caselibrary/detail/dvppcase_0009
MindIE 日志路径 ~/mindie/log、/security、/debug；命名格式 mindie-<组件名称>_<pid>_<datetime>.log；示例 mindie-service_123_202410080206.log；cat 日志文件；默认收集 Informational 及以上 官方 MindIE《日志参考 · 查看日志》
zh/mindie/310/ref/logreference/docs/zh/user_guide/log/log_viewing.md
MindIE 六日志环境变量 MINDIE_LOG_LEVEL / _TO_FILE / _TO_STDOUT / _PATH / _VERBOSE / _ROTATE 官方 MindIE《日志参考 · 使用说明》
zh/mindie/310/ref/logreference/docs/zh/user_guide/log/introduction.md
MINDIE_LOG_PATH 用法与两条示例（export MINDIE_LOG_PATH="llm: /home/working/" 等）；默认落盘路径为 ~/mindie/log/debug 官方 MindIE《日志参考 · 配置日志落盘路径》
zh/mindie/310/ref/logreference/docs/zh/user_guide/log/setting_log_path.md
MindIE 日志分安全审计日志 / 运行调试日志；非 ERROR 级别的可选内容开关 MINDIE_LOG_VERBOSE 官方 MindIE《日志参考 · 日志简介》《配置日志内容》
zh/mindie/310/ref/logreference/docs/zh/user_guide/log/log_overview.md
…/configuring_log_content.md
周期导出 Device 侧日志：msnpureport_auto_export.sh（<Driver 安装目录>/driver/tools/）、三参数说明（间隔 s / 容量 G / 目录）、「推荐参数设置为 300（5 分钟）」、「训练服务器重启后需重新执行，建议作成开机自启动脚本」 官方 MindCluster《日志转储配置 · NPU Device 侧日志采集配置》
zh/mindcluster/2610/faultdiag/faultdiagug/docs/zh/faultdiag/ascend-faultdiag-toolkit/05_usage/02_log_collection.md
npu-smi 不支持多线程并发使用；npu-smi info 输出字段（NPU ID / Chip Count / Chip ID / Product Type）；npu-smi info -t <...> -i <设备ID> 的骨架 官方 A3《HDK 26.1.x》与体系 A1/A2 课已复核的官方口径

⚠️ 站外文档说明（本课未取到正文，仅标注位置）：

文档 位置 本课怎么处理的
《msnpureport 工具使用指南》 support.huawei.com（官方文档编号 EDOC1100540106）；CANN 文档中多处以链接形式指向它 本课已尝试获取但未取到正文（站外返回空/被拦截）。因此本课只写官方 CANN/MindIE/ModelZoo 文档里确实出现过的 msnpureport 参数，并逐条标出处；参数全表请以该指南为准
同指南（gitcode 镜像） https://gitcode.com/cann/driver/tree/master/docs/zh/msnpureport 页面内容为前端渲染，未取到正文
《健康管理故障定义》 support.huawei.com 本课只写「event_id 要在这份手册里查」，不复述任何故障码

附录 B · 命令详解（本课新增部分）

A1–G3 已解释过的命令（npu-smi info、cat、export、source、df -h、chmod 等）此处只解释本课涉及的新用法。 本课命令按「在哪一处用」分三组。

B.1 应用类日志相关

命令　ls -lt ${HOME}/ascend/log/debug/plog | head -5

含义：按时间倒序列出 Host 侧应用类调试日志目录里的最新 5 个文件 拆解：ls（列出）＋ -l（长格式）＋ -t（按修改时间倒序，新的在最上面）＋ | head -5（管道把输出交给 head，只留前 5 行） 用法：ls -lt ${HOME}/ascend/log/debug/plog | head -5；看全部就去掉 | head -5 期望：列出 plog-<pid>_<时间戳>.log，最新那个的时间能和刚刚那次运行对上 不过会怎样：报 No such file or directory → 应用类日志没落盘（走第七段 7.2 官方四步）； 有时间不符的文件 → 这次跑的不是这套环境，或日志被 ASCEND_PROCESS_LOG_PATH 改到别处

命令　export ASCEND_PROCESS_LOG_PATH=$HOME/log/

含义：把应用类日志的落盘路径改到这里（官方配置示例原文就是这个写法） 拆解：export（定义环境变量并传给子进程）＋ ASCEND_PROCESS_LOG_PATH（官方：设置日志落盘路径；日志存储时如果不存在该目录，会自动创建；如果存在则直接存储） 用法：export ASCEND_PROCESS_LOG_PATH=$HOME/log/； 官方同时给了落盘优先级：ASCEND_PROCESS_LOG_PATH > ASCEND_WORK_PATH > 日志默认存储路径 $HOME/ascend/log 期望：echo $ASCEND_PROCESS_LOG_PATH 能打印出你设的路径；重跑业务后日志出现在新路径下 不过会怎样：设了但日志还在老地方 → 有另一个优先级更高的变量在起作用（对照上面那条优先级）； 官方约束：该变量仅适用于 Ascend EP 模式，RC 等形态不适用

命令　export ASCEND_GLOBAL_LOG_LEVEL=0

含义：把应用类日志级别调到 DEBUG（最详细） 拆解：0（官方取值：0=DEBUG / 1=INFO / 2=WARNING / 3=ERROR（默认）/ 4=NULL） 用法：export ASCEND_GLOBAL_LOG_LEVEL=0 → 重跑业务 → 收完日志后还原为 3 期望：日志里出现 [DEBUG] 行，grep -c "\[DEBUG\]" <文件> 能数出条数 不过会怎样：官方明确警告 「设置为 DEBUG 级别后，可能会因为日志流量过大影响业务性能」； 并且只在当前终端有效（export 的本性，B1 讲过），新开终端就没了

命令　echo $ASCEND_GLOBAL_LOG_LEVEL

含义：查看当前环境变量设的日志级别（官方原文就给了这条查法） 拆解：echo（打印）＋ $（取这个变量的值） 用法：echo $ASCEND_GLOBAL_LOG_LEVEL 期望：0~4 之一，或空 不过会怎样：输出空是正常的 —— 官方：未配置/配置为非法值/配置为空，采用默认日志级别（默认 ERROR=3）。 别把「空」当成故障去修。

命令　export ASCEND_SLOG_PRINT_TO_STDOUT=1

含义：把日志同时打到屏幕上（而不是只写进文件） 拆解：官方：日志的默认输出方式是保存在 log 文件；需要打印时配置这个变量 用法：export ASCEND_SLOG_PRINT_TO_STDOUT=1； 官方另给一个更通用的做法：开启打印后用输出重定向存文件，例如 ./main > log.txt 期望：跑业务时日志直接滚在屏幕上 不过会怎样：屏幕日志量大到影响你看东西；而且在屏幕上看到日志」并不等于「日志落盘成功了」 —— 官方 FAQ 里正好有反向的一条：没设这个变量但屏幕有日志，说明落盘用的 Socket 建失败了（见 7.4）

B.2 MindIE 日志相关

命令　ls -lt ~/mindie/log/debug

含义：按时间倒序列出 MindIE 的运行调试日志 拆解：~/mindie/log/debug 是官方《查看日志》表 1 里的「自动生成的运行调试日志路径」 用法：ls -lt ~/mindie/log/debug；安全审计日志看 ~/mindie/log/security 期望：出现 mindie-<组件名称>_<pid>_<datetime>.log 不过会怎样：目录不存在 → 这套不是 MindIE 起的，或日志被 MINDIE_LOG_PATH 改走了

命令　cat mindie-service_123_202410080206.log

含义：看 MindIE 日志文件的内容（官方示例 2 给的就是这条命令的形式） 拆解：cat（看文件）＋ 文件名（mindie-<组件>_<pid>_<datetime>.log） 用法：cat <日志文件>；文件大就用 less 或 grep -n 期望：打印该组件的日志行 不过会怎样：No such file or directory → 文件名要照 ls 的输出抄，123 和 202410080206 都是变的，抄文档里的示例一定失败

命令　export MINDIE_LOG_PATH="llm: /home/working/"

含义：把 MindIE LLM 组件的日志落盘路径改到 /home/working/（官方示例 1 原文） 拆解：格式是 <组件名称>: <路径>；路径以 / 开头为绝对路径，不以 / 开头为相对路径且相对于 ~/mindie/log/debug； ":" 前不写组件名 = 对所有组件统一设置；多个组件用 ; 隔开，后方设置优先级高于前方 用法：export MINDIE_LOG_PATH="llm: /home/working/"；相对路径示例 export MINDIE_LOG_PATH="llm: llm" 期望：MindIE LLM 的日志出现在指定路径下 不过会怎样：官方两条提醒 ——「路径里不能有特殊字符」「程序不会校验日志路径是否包含软链接，请保证日志路径合理」 ⚠️ 官方未给出：该变量的默认值就是 ~/mindie/log/debug（官方在《配置日志落盘路径》里写明），但「组件名称」的完整取值清单本课未取到全表，请按你实际用的组件名查官方文档

命令　export MINDIE_LOG_TO_STDOUT="llm: true"

含义：只让 MindIE LLM 这个组件的日志打印到屏幕 拆解：官方格式为 <组件名称>: {0, 1, true, false}；另有 MINDIE_LOG_TO_FILE 控制是否写入文件（官方：默认为 true 写入），而 MINDIE_LOG_TO_STDOUT 默认为 false 不打印 用法：export MINDIE_LOG_TO_STDOUT="llm: true"；统一设置可写 export MINDIE_LOG_TO_STDOUT="true" 期望：MindIE LLM 的日志出现在屏幕输出里 不过会怎样：写错组件名 → 不生效且不报错（官方给了「多个组件、多段设置，后方覆盖前方」的规则，说明它是宽松解析的）

B.3 Device 日志相关

命令　msnpureport -f

含义：全量导出 Device 侧系统类日志和其他维测信息（slog / syslog / event / 黑匣子等） 拆解：msnpureport（官方工具名；在驱动包「驱动 & npu-smi 工具包」体系下）＋ -f（官方文档中出现频率最高的参数） 用法：先 cd 到一个有读、写、执行权限的目录再执行 —— 官方示例路径是 /var/log/npu/report 或 ${HOME}/ascend/report 期望：当前路径下出现一个以时间命名的日志文件夹；里面能看到 slog/、hisi_logs/ 等子目录 不过会怎样：失败 → 第七段 7.3 官方两步（看提示信息 → df -h）； 在容器里执行 → 官方明说不支持，会白试； ⚠️ 官方两处口径不一致（「当前路径」vs「默认 /var/log/npu/report」），以实际执行的目录和回显为准

命令　msnpureport -g debug -d <deviceID>

含义：获取指定 Device 上的 Debug 日志（官方案例 aclcase_0019 处置步骤里的原命令） 拆解：-g debug（-g = 指定级别）＋ -d <deviceID>（-d = 指定设备号） 用法：<deviceID> 换成 npu-smi info 里查到的实际编号，例如 msnpureport -g debug -d 0 期望：导出目录下出现该设备对应级别的日志 不过会怎样：报设备不存在 → 设备号写死成 0 了 —— 租用容器里设备号可能不是 0（实测遇到过从 5 开始的），一律先查再用

命令　msnpureport -g error -d <deviceID>

含义：把指定 Device 侧的日志级别设为 error（降低 Device 侧日志噪声） 拆解：同 -g / -d 两个参数；官方在《模型迁移调试 · 环境变量配置》里的写法是逐台一条：-d 0 到 -d 7 用法：有几台写几条，例如 msnpureport -g error -d 0 期望：命令成功返回，此后 Device 侧只输出 error 级别 不过会怎样：这是「调级别」不是「导日志」 —— 拿它当导出命令用会发现「什么都没导出来」； 级别定太高还会把要看的上下文过滤掉；它改变的是 Device 侧状态，建议定位完还原

命令　msnpureport -e disable

含义：关闭 Device 侧 Event 日志（官方注释原文：「关闭 device 侧 Event 日志」） 拆解：-e（event 开关）＋ disable（关） 用法：msnpureport -e disable（官方示例里紧跟在逐台设级别之后，用于跑性能基线） 期望：命令成功返回，不再产生 Event 日志 不过会怎样：查 RAS 硬件故障要找 event_id 时就没数据了 —— 用完记得开回来

命令　msnpureport -a

含义：导出 proc 日志信息（官方案例 dvppcase_0010 用它查 DVPP 编解码统计） 拆解：-a（官方文档中与 proc 信息导出相关联的参数） 用法：msnpureport -a，之后按导出时间进对应时间戳目录找日志 期望：出现 proc 相关信息；如 module_info\dev-os-0\dvpp\dvpp_proc.log 不过会怎样：找不到 proc 文件 → 确认参数拼写，并对照该案例的完整步骤

命令　msnpureport config --get --device 0

含义：获取当前 Device 配置信息（官方示例：获取 Device 0 的配置信息） 拆解：config（配置子命令）＋ --get（读）＋ --device 0（哪台设备，这里用的是长参数 --device，不是 -d） 用法：msnpureport config --get --device 0 期望：打印该 Device 的当前配置项 不过会怎样：⚠️ 官方硬约束：应用进程运行过程中不支持使用这批命令，可能导致应用进程异常或命令执行异常，需应用进程退出后才能使用

命令　msnpureport report --type 2

含义：导出寄存器信息，便于后续辅助定位硬件问题 拆解：report（导出类子命令）＋ --type 2（导出类型） 用法：msnpureport report --type 2 期望：生成寄存器信息文件 不过会怎样：同上的硬约束 —— 应用进程运行中不支持；且官方要求「定位问题后，建议恢复配置，以免影响业务性能」

命令　/bin/bash /usr/local/Ascend/driver/tools/msnpureport_auto_export.sh 300 10 /ascend_cluster_log/device_log/

含义：周期性导出 Device 侧日志（长期跑的服务用这个，官方 MindCluster 示例原文） 拆解：脚本路径 = <Driver 安装目录>/driver/tools/msnpureport_auto_export.sh（官方示例里 Driver 安装目录为 /usr/local/Ascend）； 三个参数：① 采集间隔时间（大于 0 的整数，秒）② 最大存储目录容量（≥ 2 的整数，G）③ Device 日志存储目录名（任意绝对路径） 用法：/bin/bash /usr/local/Ascend/driver/tools/msnpureport_auto_export.sh 300 10 /ascend_cluster_log/device_log/（＝每 300 秒一次、目录上限 10G） 期望：目标目录下按周期不断出现新的 Device 日志 不过会怎样：官方三条提醒 —— 间隔太短会导致系统资源开销较大，推荐 300； 开机后只需执行一次，但服务器重启后要重新执行（建议做成开机自启动）； 容量写成 1 不符合「大于等于 2」的取值范围

命令　npu-smi info

含义：查设备信息；第 ⑥ 步靠它拿设备号（NPU ID 列） 拆解：npu-smi（昇腾设备管理工具）＋ info（显示设备信息子命令） 用法：npu-smi info 期望：一张表，含 NPU ID / Chip Count / Chip ID / Product Type 等列 不过会怎样：命令不存在 → 驱动没装（回 A1）；官方口径：npu-smi 不支持多线程并发使用，排查脚本里别并发调

B.4 trace 与收集相关

命令　grep -rn ringbuffer

含义：在当前目录及其子目录里递归找出含 ringbuffer 的行（官方给的用法就是这样，不带文件名） 拆解：grep（筛含关键词的行）＋ -r（递归，进子目录）＋ -n（打印行号）＋ 关键词 用法：先 cd 到导出目录下的设备目录，例如 /var/log/npu/report/*/slog/device-os-0/[run|debug]/device-0，再 grep -rn ringbuffer 期望：打印出 delete_ringbuffer / create_ringbuffer 的行；含 ringbuffer_addr 的那条是进程拉起时间，最后一次 delete_ringbuffer 是结束时间 不过会怎样：什么都没输出 → ① 目录不对（要先 cd 进设备目录，不是根目录）；② 导出没成功（回 B.3）；③ 旧日志已被老化覆盖（官方：时间相距较远时旧日志可能已被覆盖或清理）

命令　npu-smi info -t health -i <id> -c <chip_id>

含义：查指定芯片健康状态；存在 RAS 故障时最多能查到最近 8 次故障的 event id 拆解：-t health（-t = 查什么）＋ -i <id>（-i = 查哪台，设备 ID）＋ -c <chip_id>（芯片 ID） 用法：先 npu-smi info 拿到 NPU ID 和 Chip ID，再 npu-smi info -t health -i 0 -c 0 期望：打印健康信息；有 RAS 故障时能看到 event id 不过会怎样：报参数错 → -i（设备）与 -c（芯片）别搞混； ⚠️ 官方说查到的 event_id 要去对应版本的《健康管理故障定义》手册里查，该手册在站外，本课未收录

命令　asys collect --task_dir=$HOME/cache_path --tar="True" --output=$HOME/dfx_info

含义：不复跑业务，仅收集故障信息（软硬件信息、日志等）——官方的一键收集工具 拆解：asys collect（收集子命令）＋ --task_dir（指定收集算子编译文件和 dump 文件的目录；不指定就从环境上自动收集）＋ --tar="True"（把结果压缩成 tar.gz 且不保留原目录；F/False 则不压缩；取值不区分大小写）＋ --output（结果输出目录的路径前缀，最终目录为 <output>/asys_output_<timestamp>） 用法：asys collect --task_dir=$HOME/cache_path --tar="True" --output=$HOME/dfx_info； 需复跑业务时改用 asys launch --task="sh ../app_run.sh" --output=path 期望：<output>/asys_output_<timestamp>/ 下出现 software_info.txt、hardware_info.txt、status_info.txt、health_result.txt 和 dfx/（含 bbox/log/graph/ops/stackcore/atrace） 不过会怎样：官方六条约束里最关键的一条 —— 「集群、容器、虚拟机、云场景不支持一键式工具收集故障信息」（这也是本课坚持先讲「三处分别怎么收」的原因）； 另外：非 root 用户能拿到的数据范围会受限；不建议多进程并行执行；--output 指定的路径无写权限时会直接报错退出

命令　ls -lR $HOME/ascend/atrace | head -40

含义：看 trace 日志的目录结构与文件名（只定位，不解析） 拆解：ls -lR（长格式 + 递归进子目录）＋ | head -40（只看前 40 行，trace 目录可能很大） 用法：ls -lR $HOME/ascend/atrace | head -40 期望：出现 trace_<进程组pid>_<首个加载trace动态库的进程pid>_<时间戳>/ 形式的目录，以及 schedule_tracer_*.txt、stackcore_tracer_*.txt、schedule_tracer_*.bin 等文件 不过会怎样：目录不存在 → ① 当前形态不是 Ascend EP 标准形态（官方：当前仅 Ascend EP 标准形态支持该功能）；② 程序还没出错也没退出过（trace 是出错或进程结束才落盘） ⚠️ 本课不解析 trace 内容：.bin 文件需用 asys 解析，stackcore_tracer_*.txt 也要用 asys —— 具体参数见官方 asys 文档

命令　df -h

含义：看磁盘剩余空间 —— msnpureport 导出失败和日志没落盘的共同检查点 拆解：df（disk free）＋ -h（以 G/M 显示） 用法：df -h 期望：导出目标分区有足够空间；能顺手看出根文件系统是不是 overlay（容器环境的判据之一） 不过会怎样：目标分区满 → 官方说要先腾空间：进入 /var/log/npu/slog 等目录手工删除较大、时间较早的日志文件，再重启日志进程

命令　ulimit -a

含义：看系统允许打开文件的最大数量（关注 open files 字段） 拆解：ulimit（显示/设置用户级资源限制）＋ -a（显示全部限制项） 用法：ulimit -a；配合 lsof | wc -l 数当前已打开文件数 期望：open files 的取值大于 lsof | wc -l 的结果（还有余量） 不过会怎样：当前打开数超过限制值 → 官方说这会导致建 Socket 失败，日志就只能打到屏幕、落不了盘； 处理方式：ulimit -n <num> 把上限调大

本课为 E 层第 2 课。收完日志之后的两步，由 E3《官方案例库怎么用》（拿收上来的日志去案例库比对）与 E4《报错码速查》（拿到错误码该干什么）接着讲。

选修 · 昇腾 AI 部署实操 本机读完 0/51
选修 C · 昇腾 AI 部署实操
从零把昇腾 AI 部署学一遍：先看懂分几层，再逐层装起来，最后出问题能自己定位到哪一层。不需要先有卡就能开始。
下一站 → A 层部署指南 · L0 硬件与环境 （文章）
看完整学习路径（6 站 + 3 门选修） · 进度只存在你这台设备的浏览器里，不用登录
辽ICP备2026019944号-1