如何在缺少 CAD 团队的情况下进行异常日志分析

笔者进行了归纳和总结，针对如何在缺少 CAD 团队的情况下，对设计过程中的异常或失败日志进行分析形成初步解决方案。请注意，以下的分析流程是基于没有 CAD 团队，没有设计流程工具的状况下，可以由 IC 工程师和IT工程师协同工作进行初步异常分析。同时，本例中的 EDA 堆栈是基于 Amazon Web Services 开源解决方案 Scale-out Computing on Amazon Web Services（简称SOCA）搭建。SOCA 是一种可帮助客户轻松部署和操作多用户环境，从而支持计算机辅助工程 (CAE) 等计算密集型工作流的解决方案。该解决方案具有多种多样的计算资源、快速网络主干、可扩充存储空间以及直接集成在 Amazon Web Services 中的预算和成本管理。

我们将设计过程中的日志分为四种：

调度器日志: 调度器服务会针对任何发生的错误记录诊断消息，并保存在日志文件中，这就是调度器日志。该类型的日志通常存储在调度器的安装路径下，例如 SCHEDULER_HOME/server_logs。以 SOCA 为例，SOCA 集成了开源调度软件 PBS，并将 PBS 安装于 ’/var/spool/pbs/’ 路径下，日志文件保存在’ /var/spool/pbs/server_logs’目录下。如果无法打开日志文件，则调度器会将诊断消息写入系统控制台。在本文中，我们把这部分日志称为 server_logs 。
另外，会记日志也会对异常排查起到一定辅助作用，该日志可以展示作业运行结束后的终止原因，运行时长，资源使用量等内容。这部分的日志通常位于 SCHEDULER_HOME/server_priv/accounting 路径下。在 SOCA 中，这部分日志文件保存在’ /var/spool/pbs/server_priv/accounting’ 目录下，SOCA 也整合了 Amazon Elasticsearch Service 对会记日志做大数据分析。在本文中，我们把这部分日志称为 accounting_logs。
作业日志：IC 工程师可以在提交作业的同时输出作业日志，该日志会输出作业的执行信息。例如，在 SOCA 中我们使用 PBS 作为作业调度器，并且编写作业提交脚本 job_submit. que，我们可以使用如下内容将作业执行过程中的日志进行输出：#PBS -V -j oe -o /out/put/of/your/job.qlog

EDA工具日志：描述 EDA 工具运行中产生的日志。在您使用相应的 EDA 工具进行设计时，开启日志并指定输出路径。建议这部分日志保存在共享文件存储上便于检查分析。

计算节点资源使用日志：计算节点设备状态日志，描述计算节点的资源状态信息，如 CPU 和网络的使用状况等。您可以周期性的对计算环境进行资源使用状况信息收集，例如 CPUUtilization, NetworkOut 等参数指标，从而绘制资源使用曲线用于帮助您诊断异常是否和资源过载有关。例如，SOCA 中默认使用 Amazon CloudWatch 服务进行 CPU 利用率指标收集，并会在 Amazon CloudWatch 的服务台中绘制利用率曲线。

具体异常排查流程请参考如下流程图：

我们以 SOCA 中的异常分析来具体诠释以上的流程图。

Step1：如果作业提交发生异常，我们需要查看调度器日志，SOCA 集成了 PBS 作为调度器，那么在本例中我们需要查看的日志为：/var/spool/pbs/server_logs。同时，如果作业无法提交，还可能与 IC 工程师的权限相关，或者与该作业所在项目的预算超额相关。以上部分需要IT工程师结合第一类日志综合判断。

Step2：通过 PBS 的配置我们将第二类日志输出。如果作业异常任务失败，那么我们可以通过第二类日志的提示信息将异常分为两类：

任务自身造成的异常：该类异常通常输出造成异常的原因。例如软件安装异常或者套件缺失问题：

此时 IC 工程师可以联系 IT 工程师进一步确认异常原因。IT 工程师可以排查第一类日志中的 server_logs 和 accounting_logs 来初步确定异常原因，如果异常信息的异常码小于128，例如 Exit_status=127 ，那么就可以进一步的确认异常来源于作业本身。

针对这类问题，可以进入 Step4。

系统原因：人为/操作系统/调度器终止任务，例如：

此时 IC 工程师可以联系IT工程师进一步确认异常原因。IT 工程师可以通过排查第一类日志，如果异常信息的异常码大于128，例如 Exit_status=143，那么就可以进一步的确认异常来源于系统问题。

针对以上状况，可以进入 Step3。

Step3: 如果是因为系统原因造成了任务终止，可能是因为计算节点资源过载造成，此时 IT 工程师可以根据资源的实际使用状况进行综合判断。在 SOCA 中的所有计算节点都会定时向 Amazon CloudWatch 提交 metrics 数据，在 Amazon CloudWatch 的控制台中可以看到相应的曲线。例如：

如果计算节点的资源使用率过高，有可能造成任务被终止。任务异常可以通过配置更多的计算资源来解决。

Step4: IC 工程师通过排查第三类“EDA工具日志”，定位设计中的错误，修改设计文件来解决异常。

总结

以上排查方案旨在解决半导体设计团队在开发过程中异常状况分析的难题。典型场景是前端设计的回归测试中部分任务失败，IC 工程师和 IT 工程师因为缺少对 EDA 堆栈的整体理解无法定位异常原因。通过以上排查流程，在缺少 CAD 团队的情况下 IT 和 IC 工程师可以通过协作，初步定位到设计过程中失败作业的的异常原因。如果您遇到相似问题，可以基于以上流程进行初步排查，同时，还可以根据自身需求扩展和定制化排查流程。此外，为具体化实际的排查流程，本文中以 SOCA 作为 EDA 堆栈来进行举例，如果您对 SOCA 感兴趣，请参考：《SOCA 帮助半导体企业快速启动 EDA 云上部署》。