日志分析

河北媛福达商贸团体成立于2017年，从起初繁多的传统批发企业倒退至现在集生产、物流、种植、餐饮、电商+实体批发为一体的新批发团体。现有五大业务板块（连锁超市、线上商城、加工生产、迷信种植、文化餐饮）。媛福达主营业务以订单交易为外围，对系统的稳定性、可靠性要求高，须要全面无死角、高效灵便的运维反对。在运维层面次要通过各个层级和各个功能模块的日志零碎来监测零碎运行状况，定位问题，优化性能。零碎晚期利用开源ELK零碎的形式构建整个运维零碎，将日志会集到ELK零碎提供对立检索。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1195412?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

河北媛福达商贸团体成立于2017年，从起初繁多的传统批发企业倒退至现在集生产、物流、种植、餐饮、电商+实体批发为一体的新批发团体。现有五大业务板块（连锁超市、线上商城、加工生产、迷信种植、文化餐饮）。 媛福达主营业务以订单交易为外围，对系统的稳定性、可靠性要求高，须要全面无死角、高效灵便的运维反对。在运维层面次要通过各个层级和各个功能模块的日志零碎来监测零碎运行状况，定位问题，优化性能。零碎晚期利用开源ELK零碎的形式构建整个运维零碎，将日志会集到ELK零碎提供对立检索。 容器部署维服务架构，对系统运维提出更高要求媛福达整体的IT零碎基于容器的微服务架构进行构建，因为容器具备可灵便开启敞开的特点，随着业务的倒退，运维压力也呈指数增大。原有运维架构已无奈满足高频次的开关容器带来的冲击，因而媛福达须要一套牢靠的运维零碎保障业务的稳定性。在云原生技术的飞速推动下，云上资源愈发简单，架构更加多样，从最开始的服务器、数据库，到前面的负载平衡、WAF、CDN、OSS等产品的联合应用，急需一个对立的监测平台来洞察云上资源的运行状况。因为媛福达属于批发行业，线上与线下订单量会随节日、促销流动、爆品等因素大幅晋升， 因而在特定工夫内C端用户访问量和订单量会有很大稳定，因而媛福达须要一个可观测的平台来实时预测业务的变化趋势，以及时调整云上资源的大小，优化用云老本。一站式可观测运维解决方案，轻松缓解一劳永逸的零碎压力传统运维IT零碎的运维老本过高、压力过大，采纳容器容器的微服务架构之后，其轻量化的个性使得运维更加灵便高效。相较于传统运维，这种形式能够实现更疾速的部署与交付。但随着媛福达业务的增长，容器数量也逐步减少，且随同着高频次容器开关次数，传统利用开源ELK零碎的形式构建整个运维零碎的形式已无奈满足一劳永逸的业务需要。 因而阿里云为其提供了一站式云原生可观测运维解决方案，该计划基于 SLS 云原生可观测平台实现，以大数据源为撑持，兼容开源规范，可实现多场景适配 AI 算法，进行大规模数据处理剖析。是阿里云针对企业级大数据运维场景推出的解决方案，帮忙企业在日常运维工作中轻松实现异样检测、根因剖析、秒级响应以及实时预测。 针对媛福达面对的性能瓶颈问题，阿里云云原生可观测运维解决方案为其提供了免运维、高性能的日志数据存储、查问和建模服务。可反对PB级数据实时查问与剖析，提供10多种查问运算符、10多种机器学习函数、100多个SQL函数。帮忙媛福达在节日流动、电商大促等高并发、大流量的场景下轻松实现日志数据的查问。即便呈现突发性的问题，也能疾速查问问题日志，迅速定位问题点，极大水平晋升用户的产品应用体验。 且因为媛福达大部分零碎曾经迁徙上云，联合不同的业务需要，往往须要搭配各种不同类型的云产品，由此带来的老本治理与资源管理难度会进一步晋升。阿里云云原生可观测运维解决方案，依靠于日志服务SLS一站式的观测能力，可无缝接入各类云产品，实现资源与应用老本一站式的可视化治理，自定义图表、数据实时监控、数据异样报警等能力，帮忙媛福达对业务的异样数据进行监管告警，及时发现异常变动，实现最快的零碎排障与最优的云产品资源应用布局。 客户证言阿里云的SLS，为咱们提供了高质量、高容量的日志存储服务，以及高效率的日志查问剖析服务。SLS的一站式服务，操作简略，直观明了，对于咱们产品线上问题可能随时疾速的溯源，极大的升高了服务器存储资源和人力资源的投入老本。同时领有从多维度统计分析日志的性能，对咱们的业务晋升也有很大帮忙。 原文链接 本文为阿里云原创内容，未经容许不得转载。

作者：云智慧算法工程师 Hugo Guo 运维日志畛域钻研方向次要蕴含异样日志检测、日志模式解析、日志内容分类、日志告警等。本篇文章介绍了热门异样检测模型 DeepLog、A2Log 等模型，以及云智慧自研模型 Translog 等。与此同时，在文章最初介绍了将来基于深度学习的运维日志畛域次要钻研方向。 日志钻研概述日志工作与数据日志是运维畛域中的必不可少的一种半结构化数据类型，基于此发展的钻研工作也多种多样。 日志数据实时处理次要蕴含以下几方面： Log Compression：在运行时压缩软件日志。Log Parsing：从软件日志中主动提取事件模板和要害参数。Log Mining：进步零碎的可靠性，次要关注异样检测。 日志模式解析海量日志数据之间语义相似性较高，理论需要须要将日志示意化。因而学者冀望对日志提取出固定的模版以求代表整个日志数据库。 下方为四个经典的日志模式解析算法： Drain（基于树结构类似度）Spell（最长公共子序列）AEL （常数和变量的产生频率）IPLoM（迭代分区策略，依据音讯长度、令牌地位和映射关系等）下图为日志模版提取过程，从上到下顺次是原始日志，解析后的日志模版。 学术前沿工作分享DeepLogDeepLog 是日志深度学习开山之作，采纳LSTM编码提取好模板的日志并为给定序列中的下一个模板提供了一个具备概率的排序输入，以此进行异样检测。 A2LogA2Log 采纳无监督的形式去寻找失常和异样之间的boundary，基于Attention机制和最新的Transformer框架，对失常的日志输入得分依据阈值去判断boundry。 LogRobustLogRobust 双向LSTM+Attention进行编码分类，对原始日志的模版进行word vector的向量化送入模型进行分类。 HitAnomalyHitAnomaly 是对于日志模版和参数别离采纳Transformer进行编码。 LogsyLogsy 测试数据来源于新的零碎，同时最初将异样分数退出思考。 自研模型分享TranslogTranslog 首次思考多起源、资源不对齐的日志源异样检测。是基于 Transfer learning 和 Transformer 的全新框架 Pretraining 和 Tuning 的学习范式，通过 Translog 耗费可升高为原来的5%，然而成果达到 SOTA。 AdapterAdapter 的构造非常简略，像一个适配器为大模型的常识流动进行贯通。 下图右所示的是不同的日志源有着雷同的异样问题，为迁徙学习提供可能性。 云智慧将 Adapter 在三个公开数据集上进行测试，最终 Adapter 算法都取得了SOTA。同时 Adapter 的参数量减少了将近百分之95% 下图左方的试验阐明预训练的形式会比间接从头开始训练更快收敛，同时会在较少的step下失去更高的F1分数。下图右方试验阐明不同数据源的预训练的模型会产生不同的成果，发现BGL的预训练模型成果更好。 下图试验阐明 Translog 在 low-resource 会体现出比失常的更好的后果。阐明对于其余散布不平衡的日志源咱们的模型也会有肯定较好的成果。 ...

背景目前，日志异样检测算法采纳基于工夫序列的办法检测异样，具体为：日志结构化->日志模式识别->工夫序列转换->异样检测。异样检测算法依据日志指标时序数据的周期性检测出历史新增、时段新增、时段突增、时段突降等多种异样。 然而，在理论中，日志指标时序数据并不都具备周期性，或具备其余散布特色，因而仅依据周期性进行异样检测会导致误报率高、准确率低等问题。因而如果在日志异样检测之前，首先对日志指标时序数据进行分类，不同类型数据采纳不同办法检测异样，能够无效进步准确率，并升高误报率。 日志指标序列的类型日志指标序列分为时序数据与日志指标数据两大类： 时序数据： 蕴含安稳型、周期型、趋势型、阶跃型。 日志指标数据： 蕴含周期型、非周期型。 工夫序列分类算法工夫序列分类是一项在多个畛域均有利用的通用工作，指标是利用标记好的训练数据，确定一个工夫序列属于事后定义的哪一个类别。 工夫序列分类不同于惯例分类问题，因为时序数据是具备程序属性的序列。 工夫序列分为传统工夫序列分类算法与基于深度学习的工夫序列分类算法。传统办法又依据算法采纳的用于分类的特色类型不同，分为全局特色、部分特色、基于模型以及组合办法4大类。基于深度学习的工夫序列算法分为生成式模型与判别式模型两大类。本文次要对传统工夫序列分类算法进行介绍。 传统工夫序列分类算法基于全局特色的分类算法全局特色分类是将残缺工夫序列作为特色，计算工夫序列间的相似性来进行分类。分类办法有通过计算不同序列之间间隔的远近来表白工夫序列的相似性以及不同间隔度量办法 + 1-NN（1-近邻）。次要钻研序列相似性的度量办法。 工夫域间隔问题场景形容： 如下图所示，问题场景是一个语音辨认工作。该工作用数字示意音调高下，例如某个单词发音的音调为1-3-2-4。两个人说同一单词时，因为音节的发音拖长，会造成不同的发音序列 前半部分拖长，发音：1-1-3-3-2-4 后半局部拖长，发音：1-3-2-2-4-4 在采纳传统欧式间隔，即点对点的形式计算发音序列间隔时，间隔之和如下： 欧式间隔 = |A(1)-B(1)| + |A(2)-B(2)| + |A(3)-B(3)| + |A(4)-B(4)| + |A(5)-B(5)| + |A(6)-B(6)| =6_x0001_ 算法原理： 如果咱们容许序列的点与另一序列的多个间断的点绝对应（即，将这个点所代表的音调的发音工夫缩短），而后再计算对应点之间的间隔之和，这就是dtw算法。dtw算法容许序列某个时刻的点与另一序列多个间断时刻的点绝对应，称为工夫规整（Time Warping）。如下图所示，语音辨认工作的dtw间隔如下： dtw间隔= |1-1| + |1-1| + |3-3| + |3-3| + |2-2| + |2-2| + |4-4| + |4-4| = 0 dtw计算出的间隔为0，由此代表两个单词发音统一，与理论状况相符。 算法实现： dtw算法实现包含计算两个序列各点之间间隔形成矩阵以及寻找一条从矩阵左上角到右下角的门路，使得门路上的元素和最小两个次要步骤。间隔矩阵如下图所示，矩阵中每个元素的值为两个序列对应点之间的间隔。DTW算法将计算两个序列之间的间隔，转化为寻找一条从间隔矩阵。左上角到右下角的门路，使得门路上的元素和最小。实现要点如下： 转化为动静布局的问题（DP）;<!----> 因为寻找所有门路太耗时，须要增加门路数量限度条件（能够等效为寻找矩阵横纵坐标的差的容许范畴，即warping window）。 差分间隔法差分间隔法是计算原始工夫序列的一阶微分，而后度量两个工夫序列的微分序列的间隔，即微分间隔。差分法将微分间隔作为原始序列间隔的补充，是最终间隔计算函数的重要组成部分。 对于一个工夫序列t=（t1, t2, …,tm），其一阶微分计算公式如（2-1）所示，二阶微分计算公式如（2-2）所示，更高阶的微分计算形式顺次类推。 差分间隔法将位于工夫域的原工夫序列和位于差分域的一阶差分序列相结合，晋升分类成果。钻研方向次要是如何将原序列和差分序列正当联合。 基于部分特色的分类算法将单条工夫序列中的一部分子序列作为特色，用于工夫序列分类。次要有以下特点： 关键在于寻找可能辨别不同类的部分特色；因为子序列更短，因而构建的分类器速度更快；但因为须要寻找部分特色，须要肯定的训练工夫。 ...

研发人员在我的项目开发中不可避免地要应用日志，通过它来记录信息和排查问题。Apache Log4j2提供了灵便且弱小的日志框架，尽管上手比拟快，但稍有不慎也非常容易踩“坑”。本文介绍了美团对立API网关服务Shepherd在实践中所踩过的对于日志导致线程Block的那些“坑”，以及咱们如何从日志框架源码层面进行剖析和解决问题的过程，并在最初给大家分享一些对于日志避“坑”的实践经验，心愿能给大家带来一些帮忙。1. 前言日志对程序的重要性显而易见。它很“大”，咱们在我的项目中常常通过日志来记录信息和排查问题，相干代码随处可见。它也很“小”，作为辅助工具，日志应用简略、上手快，咱们通常不会破费过多精力耗在日志上。但看似不起眼的日志也暗藏着各种各样的“坑”，如果使用不当，它不仅不能帮忙咱们，反而还可能升高服务性能，甚至拖垮咱们的服务。 日志导致线程Block的问题，置信你或者曾经遇到过，对此应该深有体会；或者你还没遇到过，但不代表没有问题，只是可能还没有触发而已。本文次要介绍美团对立API网关服务Shepherd（参见《百亿规模API网关服务Shepherd的设计与实现》一文）在实践中所踩过的对于日志导致线程Block的那些“坑”，而后再分享一些避“坑”教训。 2. 背景API网关服务Shepherd基于Java语言开发，应用业界赫赫有名的Apache Log4j2作为次要日志框架，同时应用美团外部的XMD-Log SDK和Scribe-Log SDK对日志内容进行解决，日志解决整体流程如下图1所示。业务打印日志时，日志框架基于Logger配置来决定把日志交给XMDFile解决还是Scribe解决。其中，XMDFile是XMD-Log外部提供的日志Appender名称，负责输入日志到本地磁盘，Scribe是Scribe-Log外部提供的日志Appender名称，负责上报日志到近程日志核心。 随着业务的快速增长，日志导致的线程Block问题愈发频繁。比方调用后端RPC服务超时，导致调用方大量线程Block；再比方，业务外部输入异样日志导致服务大量线程Block等，这些问题重大影响着服务的稳定性。因而，咱们联合我的项目在过来一段时间裸露进去的各种因为日志导致的线程Block问题，对日志框架存在的稳定性危险因素进行了彻底的排查和修复，并在线下、线上环境进行全方位验证。在此过程中，咱们总结了一些日志应用相干的实践经验，心愿分享给大家。 在进入注释前，首先介绍我的项目过后的运行环境和日志相干配置信息。 JDK版本java version "1.8.0_45"Java(TM) SE Runtime Environment (build 1.8.0_45-b14)Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)日志依赖版本<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.7</version></dependency><dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.7</version></dependency><dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.7</version></dependency>日志配置文件<?xml version="1.0" encoding="UTF-8"?><configuration status="warn"> <appenders> <Console name="Console" target="SYSTEM_OUT" follow="true"> <PatternLayout pattern="%d{yyyy/MM/dd HH:mm:ss.SSS} %t [%p] %c{1} (%F:%L) %msg%n" /> </Console> <XMDFile name="ShepherdLog" fileName="shepherd.log"/> <!--XMDFile异步磁盘日志配置示例--> <!--默认按天&按512M文件大小切分日志，默认最多保留30个日志文件。--> <!--留神：fileName前会主动减少文件门路，只配置文件名即可--> <XMDFile name="LocalServiceLog" fileName="request.log"/> <Scribe name="LogCenterSync"> <!-- 在指定日志名方面，scribeCategory 和 appkey 两者至多存在一种，且 scribeCategory 高于 appkey。--> <!-- <Property name="scribeCategory">data_update_test_lc</Property> --> <LcLayout/> </Scribe> <Async name="LogCenterAsync" blocking="false"> <AppenderRef ref="LogCenterSync"/> </Async> </appenders> <loggers> <AsyncLogger name="com.sankuai.shepherd" level="info" additivity="false"> <AppenderRef ref="ShepherdLog" level="warn"/> <AppenderRef ref="LogCenterAsync" level="info"/> </AsyncLogger> <root level="info"> <!--Console日志是同步、阻塞的，举荐只在本地调试时应用，线上将该配置去掉--> <!--appender-ref ref="Console" /--> <appender-ref ref="LocalServiceLog"/> <appender-ref ref="LogCenterAsync"/> </root> </loggers></configuration>3. 踩过的坑本章节次要记录我的项目过来一段时间，咱们所遇到的一系列日志导致的线程Block问题，并一一深入分析问题根因。 ...

对于以后航空业面临的海量实时业务数据监测与剖析挑战，云智慧推出了一种基于业务系统日志数据，应用实时流式数据采集、大数据处理和人工智能技术实现海量日志数据智能化剖析的解决方案，帮忙IT运维人员实时、动静发现业务及IT零碎存在的故障和异样，疾速定位问题本源，保障航司业务继续、稳固和高效运行。 挑战与需要随着航空及上下游服务产业链的疾速倒退，零碎多、架构简单、新旧业务零碎长期共存，继续产生的海量日志数据不足无效的解决伎俩，对IT运维和经营带来极大的危险与挑战。 以民航为例，旅客抉择飞机出行须要经验订票、值机、登机等一系列流程，每种业务解决都要逾越多个平台的利用零碎，每个零碎都会实时输入日志数据记录以后利用运行状况，上述流程中任何一个利用的故障或者性能问题都会影响乘客出行。 如何实时理解业务的整体运行状态，如何基于海量、实时的利用日志剖析疾速确定业务运行异样及潜在危险，如何依据业务量变动动静确定业务异样规范，如何针对以后业务中的异常情况及时预警，如何实现日志数据与其余运维监控数据的交融剖析和查问，疾速、精确定位业务及零碎的故障，这都是日志智能剖析平台须要解决的难题。 云智慧日志智能剖析解决方案及平台架构云智慧海量日志智能剖析解决方案包含系统日志数据的实时采集、传输、集群化的音讯队列、预处理组件及实时流式大数据处理，实现日志数据的解析、转换、脱敏、业务逻辑解决后，以结构化数据保留在分布式存储系统中，而后调用算法集之中的一种或多种算法组合进行多场景的智能剖析、告警及可视化展现，同时提供数据API满足其它数据深刻开掘和摸索需要。 海量日志智能化剖析平台架构如下图所示： 计划特色和劣势云智慧日志智能化剖析平台解决方案为航空业务运行的连续性、用户体验的晋升和业务的高效运维提供了牢靠的技术撑持，此计划具备如下劣势： 丰盛的日志数据实时采集 反对自有高性能采集器，兼容支流开源数据采集器、灵便程度扩大的数据接入接口，疾速接入流式数据。超高的吞吐量和极小的响应工夫，数据接入即可秒级查问。高性能、动静扩大数据处理平台。 内置数十种解决组件，反对可视化解决pipeline及单步处理结果验证、处理结果采纳列式存储、线性存储扩大。平台具备实时流式数据处理能力，满足航空业海量日志数据实时处理和智能剖析的严格要求。 反对依据数据量进行程度伸缩，数据处理能力：40T/天，EPS：130万/秒。反对多个节点同时写入，写入速度：单个节点：60万条/秒。同等条件下，写入速度比Elasticsearch 快10倍以上。多场景智能剖析平台能力 算法平台基于最新架构和人工智能算法，具备弱小的智能化剖析能力，为下层业务提供算法撑持和扩大。内置多个智能剖析场景，包含日志智能搜寻及上下文剖析、日志模式自动识别、基于算法的智能异样检测、智能告警及指标告警对接、日志与利用性能监控、根底监控数据的交融关联剖析等。计划价值基于海量日志数据的云智慧智能日志剖析计划曾经在航空、金融、能源等行业的智能运维我的项目中胜利施行，实践证明此平台能给行业客户带来显著的改善和晋升： 实现离散日志的对立采集、解决、存储、归档以及查问，极大晋升日志治理和剖析的便捷性。基于实时日志数据智能剖析帮忙业务人员及时掌控业务运行状态，疾速发现业务运行的异样并及时报警，缩小业务中断工夫。基于业务日志数据、利用性能监控数据、根底资源监控数据的交融剖析，实现简单线上业务及零碎问题起因的疾速定位，晋升简单问题解决的效率。客户案例实战某航空企业的主营业务是面向航司及上下游服务商，提供业务解决、电子分销、结算清理等服务，当呈现性能迟缓或中断时，现有监控零碎无奈无效定位故障和异样。 针对此用户需要，云智慧为该企业构建了基于海量实时业务日志数据的业务运维智能剖析平台，通过对业务数据的实时采集、解决、多维度智能剖析，及时发现零碎业务层面异常情况，加强该航空客户业务预警、故障诊断与智能剖析能力。此平台屡次提前发现业务解决响应工夫变长、业务指令交互错误率减少等故障前兆。基于智能剖析算法对行将产生的异样作出预测和及时告警，从而无效防止故障的业务危险。 总结和瞻望云智慧日志智能剖析平台基于AIOps策略，交融根底资源监控、利用性能监控、用户体验监控等多维度运维数据和人工智能剖析算法，可能及时发现业务经营中潜在危险，辅助管理人员作出精确判断和决策，实现对业务经营衰弱及将来发展趋势的继续洞察，加强企业外围竞争力。 开源福利云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现合乎本人业务需要的炫酷可视化大屏。 同时，飞鱼也提供了灵便的拓展能力，反对组件开发、自定义函数与全局事件等配置， 面向简单需要场景可能保障高效开发与交付。 点击下方地址链接，欢送大家给 FlyFish 点赞送 Star。参加组件开发，更有万元现金等你来拿。 GitHub 地址： https://github.com/CloudWise-OpenSource/FlyFish Gitee 地址：https://gitee.com/CloudWise/fly-fish 超级体验官流动： http://bbs.aiops.cloudwise.com/d/712-flyfish 万元现金流动： http://bbs.aiops.cloudwise.co... 微信扫描辨认下方二维码，备注【飞鱼】退出AIOps社区飞鱼开发者交换群，与 FlyFish 我的项目 PMC 面对面交换～

我的公众号：MarkerHub，Java网站：https://markerhub.com更多精选文章请点击：Java笔记大全.md 小Hub领读：不同级别的日志应该辨别应用，另外用 [] 进行参数变量隔离。 西格玛的博客http://t.cn/E9BkD7a应用 slf4j 应用门面模式的日志框架，有利于保护和各个类的日志解决形式对立实现形式对立应用: Logback 框架打日志的正确形式 什么时候应该打日志 当你遇到问题的时候，只能通过 debug 性能来确定问题，你应该思考打日志，良好的零碎，是能够通过日志进行问题定为的。当你碰到 if…else 或者 switch 这样的分支时，要在分支的首行打印日志，用来确定进入了哪个分支常常以性能为外围进行开发，你应该在提交代码前，能够确定通过日志能够看到整个流程根本格局 必须应用参数化信息的形式: logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);对于 debug 日志，必须判断是否为 debug 级别后，才进行应用: if (logger.isDebugEnabled()) { logger.debug("Processing trade with id: " +id + " symbol: " + symbol);}不要进行字符串拼接, 那样会产生很多 String 对象，占用空间，影响性能。 反例 (不要这么做): logger.debug("Processing trade with id: " + id + " symbol: " + symbol);应用 [] 进行参数变量隔离 如有参数变量，应该写成如下写法: logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);这样的格局写法，可读性更好，对于排查问题更有帮忙。 不同级别的应用 ERROR: 基本概念 影响到程序失常运行、以后申请失常运行的异常情况: 关上配置文件失败所有第三方对接的异样 (包含第三方返回错误码)所有影响性能应用的异样，包含: SQLException 和除了业务异样之外的所有异样 (RuntimeException 和 Exception)不应该呈现的状况: ...