线上故障分析-故障分级原因分类混沌工程排除方法

线上故障分析-故障分级，原因，分类，混沌⼯程，排除⽅法线上故障分析1⽣产故障分级规范概要1.1开篇计算机是当今世界的命脉，你能看到的任何地⽅，计算机都在改变着世界，不论是传统的制造⽣产，医疗通讯。还是新兴的虚拟现实，⽆⼈驾驶汽车等领域。过去的⼏⼗年，计算机硬件飞速发展，软件领域也是不断刷新着⼈们的想象。可以说，计算机学科复杂⽽且庞⼤，甚⾄有⼈说，不亚于物理学。今天我们讨论的话题，线上事故分析，只是其中的⼀部分，⼀⼩部分，为了说清楚这⼀点，我们简单了解⼀下软件⼯程学科。玛格丽特·希菲尔德·汉密尔顿（英语：MargaretHeafieldHamilton，1936年8⽉17⽇－[1]）被认为发明了软件⼯程⼀词。她帮助了NASA在阿波罗计划中避免了严重问题。她曾这样说：“有点像⽛根管治疗：你总是拖到最后才做，但有些事可以预先做好，有点像预防性体验，只不过是预防软件出错”。我们不妨简单总结如何开发⼀个⼤型的软件项⽬下：1-基于⾯向对象的编程语⾔2-容易使⽤的集成开发环境3-⽂档和注释（程序员最讨厌的两件事，写注释给别⼈读，阅读别⼈没有写注释的4-构建管理和版本控制5-质量保证测试(QUALITYASSURANCE-QA)每个软件从业者从写下第⼀⾏代码开始，就⼀刻不停地和软件中的错误做⽃争开发和维护（修复缺陷、确保资源充⾜等保障软件运⾏的活动）是⼀对伴随软件运⾏⽽产⽣的双热爱从零到⼀开发软件是开发者的天性看着⾃⼰编写的软件完美运⾏，为其他提供服务，⼀直是驱动开发者前进的动⼒。为了更快更好地开发软件，我们不断改进开发⽅法和软件架构，但是开发者在使⽤新的⽅法和更复杂的架构时，往往也会低估潜在的风险。本课程话题，主要讨论质量测试上线后，运营环节期间的⼀些问题，当然，我们暂时并不界定事故的产⽣到底是因为测试覆盖不全还是操作不当等，这某种程度体现着管理的⽅式问题。1.2事故等级定义业务和产品的线上质量、是研发团队的⽣命线，也是⽀撑业务快速是错，⼩步跑的前置条件。1.2.1故障等级定义

故障等级定义，不同的业务形态，不同的公司团队，有不⼀样的划分标准，下表列举了⼀般常见的维度和标准【1】核⼼数据定义个⼈敏感信息：姓名、出⽣⽇期、⾝份证件号码、个⼈⽣物识别信息、住址、通信通讯联系⽅式、通信记录和内容、账号密码、财产信息、征信信息、⾏踪轨迹、住宿信息、健康⽣理信息、交易信息等。⽤户画像：职业、经济、健康、教育、个⼈喜好、信⽤、⾏为等。【2】系统级别定义零级系统(P0)：为公司核⼼业务服务的核⼼系统，⼀旦发⽣不可⽤会直接影响公司核⼼业务的业务连续性，对所有系统⽤户造成影响。⼀级系统(P1)：重点的业务系统，⼀旦发⽣不可⽤，影响核⼼业务的连续型，并造成⼤部分内部⽤户或外部⽤户不可使⽤此系统。⼆级系统(P2)：重要的业务系统，⼀旦发⽣不可⽤存在⼀定的业务可⽤性问题，但不会影响核⼼业务的业务连续性。三级系统(P3)：⾮核⼼的⽀撑系统，⼀旦发⽣故障不直接产⽣业务影响，但会影响少部分内部⽤户使⽤此系统。【3】影响范围与故障等级1.2.2故障报告模板⽰例模板参考1.2.3故障响应处理机制如图所⽰，⼤体描述了⼀般⽣产故障的处理机制故障发现：1-客户投诉或者业务反馈，研发⾃我发现2-监控报警：技术监控，业务监控1.2.4思考为什么会发⽣这个问题？为什么测试阶段没有发现？为什么系统不能容错？能不能更早发现问题？解决过程能不能更快？怎样防⽌类似的事情发现？2⽣产故障原因和分类2.1故障分类代码bug：上线代码逻辑有问题，遇到特殊情况下，导致故障的情况操作不当：线上配置或资源配置错误，操作不当，⽐如启动顺序不合理，初始化脚本不对，语法⽣产数据隔离混⽤等系统级别软件bug：技术架构中使⽤到的任何OS，第三⽅类库，软件在特殊场景下，bug被处罚导致故障的情况。突发流量：热点或突发事件，引发的瞬时流量超过⽇常峰值或成倍增长，造成性能下降或功能不可⽤问题资源使⽤不均：整体产品线利⽤率不达标，但有些业务冗余度不⾜，导致资源不能正确合理使⽤容量预估不⾜：对个别业务核⼼池预估不⾜⽹络类：公⽹拥堵、丢包、专线、⽹络设备故障、ip被攻击（包括DNS被攻击）、IP被封、域名被封、⽹络软件BUG、业务部门使⽤不当、未及时扩容等安全类：被攻击，漏洞被利均归为此类局⽅故障：ISP，根域名服务，电⼒，空调，光缆等外部单位故障导致的问题。硬件故障：任何硬件⾮⼈为原因损坏导致的故障均归为此类第三⽅合作公司或接⼝故障：项⽬依赖的第三⽅公司或接⼝故障2.2bug是可以完全避免的么？-了解⽇常项⽬⾥中，站在开发者的⾓度：⼤多数程序员会花费70%-80%时间调试，⽽不是在写代码，虽然现在有很好的⼯具能极⼤帮助程序员防⽌和解决错误另⼀个重要部分给代码写⽂档由于现在的需求越来越复杂，依赖的外部条件，技术组件也是越来越多，很多bug在所难免。但也有⼀些bug是不能被原谅的，所以养成良好的开发习惯，很重要。【bug起源】：1945年9⽉9⽇，格蕾丝·赫柏（GraceMurrayHopper）使⽤的MarkⅡ出现故障，导致⼯作⽆法⾏。经过了近⼀天的检查，格蕾丝找到了故障的原因：继电器中有⼀只死掉的蛾⼦。蛾⼦被夹了出来。后来，”bug”(⼩⾍)和”debug”(除⾍)这两个本来普普通通的词汇成了计算机领域中特指莫明其妙的“错误”和“排除错误”的专⽤词汇⽽流传⾄今，⽽格蕾丝·赫柏也因此成了第⼀个发现“bug”的⼈。另⼀⽅⾯，⼤名⿍⿍的"千年⾍"bug，也是由她带来的。当然，这也不全完全算作bug。2.3经典故障⽰例-了解由软件Bug引发的18次重⼤事故|程序师-程序员、编程语⾔、软件开发、编程技术()近年的CSDN600万⽤户信息泄露事件：CSDN⽹站六百万⽤户信息外泄-⽉光博客()2018年github服务中断24⼩时11分钟事件：GitHub服务中断24⼩时11分钟事故分析报告()2.4混沌⼯程简介观念和思想来源于：【混沌⼯程】⼀书说起混沌⼯程⼀次，也许你听过阿⾥的红蓝军对抗。混沌⼯程是⼀种通过实验探究的⽅式来让我们理解系统⾏为的⽅法，就像科学家通过实验来研究物理和社会现象⼀样，混沌⼯程通过实验来了解特定的系统如何使⽤混沌⼯程提⾼系统弹性呢？混沌⼯程通过设计和执⾏⼀系列实验，帮助我们发现系统中潜在的、可以导致灾难的或让我们的⽤户受损的脆弱环节，推动我主动解决这些环节存在的问题和现在各⼤公司主流的被动式故障响应流程相⽐，混沌⼯程向前迈进了⼀⼤步。混沌⼯程解决的问题：要设计良好的系统需要考虑很多因素，⽐如可靠性、安全性、可扩展性、可定制化、可伸缩性、可维护性、⽤户体验等。为了更⾼效地⽀撑业务发展，越来越多的企业选择基于云服务或云原⽣理念来构建平台。采⽤新思路和新技术必然会带来系统架构和组织结构的变⾰，引⼊风险因素。如何通过实验证明⽣产环境下的分布式系统在⾯对失控条件的时候依然具备较强的“可观测性”和故障恢复能⼒这就是混沌⼯程要解决的问题。混沌⼯程和测试的区别：混沌⼯程故障注⼊和故障测试在侧重点和⼯具集的使⽤上有些重叠举个例⼦，Netflix的很多混沌⼯程实验的研究对象都是基于故障注⼊来引⼊的。混沌⼯程和其他测试⽅法的主要区别在于，混沌⼯程是发现新信息的实践过程，⽽故障注⼊则是基于⼀个特定的条件、变址的验证⽅法。混沌⼯程和故障注⼈本质上是思维⽅式上的不同。故障注⼈⾸先要知道会发⽣什么故障，然后⼀个⼀个地注⼈，⽽在复杂分布式系统中，想要穷举所有可能的故障，本⾝就是奢望混沌⼯程的思维⽅式是主动去找故障，是探索性的，你不知道摘掉⼀个节点、关掉⼀个服务会发⽣什么故障，虽然按计划做好了降级预案，但是关闭节点时却引发了上游服务异常，进⽽引发雪崩，这不是靠故障注⼈或预先计划能发现的⼀些混沌实验的输⼊样例：模拟整个云服务区域或整个数据中⼼的故障部分删除各种实例上的Kafka主题。重新创建⽣产中发⽣的问题。针对特定百分⽐的交易服务之间注⼊⼀段预期的访问延迟。基于函数的混乱（运⾏时注⼊）：随机导致抛出异常的函数。代码插⼊：向⽬标程序添加指令和允许在某些指令之前进⾏故障注⼊。时间旅⾏：强制系统时钟彼此不同步。在模拟I/O错误的驱动程序代码中执⾏例程。在Elasticsearch集群上最⼤化CPU核⼼。混沌⼯程实验的机会是⽆限的，可能会根据分布式系统的架构和组织的核⼼业务价值⽽有所不同混沌⼯程实现的四个步骤：1.定义并测量系统的“稳定状态”。⾸先精确定义指标，表明您的系统按照应有的⽅式运⾏。Netflix使⽤客户点击视频流设备上播放按钮的速率作为指标，称为“每秒流量”。请注意，这更像是商业指标⽽⾮技术指标;事实上，在混沌⼯程中，业务指标通常⽐技术指标更有⽤，因为它们更适合衡量⽤户体验或运营。2.创建假设。与任何实验⼀样，您需要⼀个假设来进⾏测试。因为你试图破坏系统正常运⾏时的稳定状态，你的假设将是这样的，“当我们做X时，这个系统的稳定状态应该没有变化。”为什么⽤这种⽅式表达？如果你的期望是你的动作会破坏系统的稳定状态，那么你会做的第⼀件事会是修复问题。混沌⼯程应该包括真正的实验，涉及真正的未知数。3.模拟现实世界中可能发⽣的事情，⽬前有如下混沌⼯程实践⽅法：模拟数据中⼼的故障、强制系统时钟不同步、在驱动程序代码中模拟I/O异常、模拟服务之间的延迟、随机引发函数抛异常。通常，您希望模拟可能导致系统不可⽤或导致其性能降低的场景。⾸先考虑可能出现什么问题，然后进⾏模拟。⼀定要优先考虑潜在的错误。“当你拥有⾮常复杂的系统时，很容易引起出乎意料的下游效应，这是混沌⼯程寻找的结果之⼀，”“因此，系统越复杂，越重要，它就越有可能成为混沌⼯程的候选对象。”4.证明或反驳你的假设。将稳态指标与⼲扰注⼊系统后收集的指标进⾏⽐较。如果您发现测量结果存在差异，那么您的混沌⼯程实验已经成功-您现在可以继续加固系统，以便现实世界中的类似事件不会导致⼤问题。或者，如果您发现稳定状态可以保持，那么你对该系统的稳定性⼤可放⼼。引⼊混沌⼯程的⼀些建议：来源于-周洋（花名：中亭）-阿⾥巴巴⾼可⽤架构团队⾼级技术专家第⼀，引⼊混沌⼯程，需要建⽴进⾏⾯向失败设计（可以使系统暴露出已有问题的设计）和拥抱失败的技术⽂化第⼆，实施混沌⼯程，需要定义⼀个清晰可衡量的⽬标。第三，推⼴混沌⼯程，要在控制风险的前提下不断提升效率。混沌⼯程是⼀种实践思想，其本⾝是不绑定任何技术或⼯具的。减少问题的最好⽅法就是让问题经常性地发⽣，通过不断重复失败过程并找出解决⽅案，来持续提升系统的容错能⼒和弹性。混沌⼯程⼯具3⽣产故障定位和解决流程3.1影响服务质量的因素3.1.1我们常常⾯对如下的业务场景

⼤量⽆⽤业务逻辑sleep循环⾥写查询磁盘满了、影响到有磁盘写操作的接⼝慢查询的SQLRedis中存在⼤key，带宽打满不知是哪些接⼝影响与被影响队列堆积却不知哪些接⼝影响流量放⼤系数评估全靠经验和看代码3.1.2资源依赖接⼝依赖（内部服务、外部服务）⽆法整体查看服务、接⼝、资源之间的依赖关系没有很好的外部服务监控机制、⽆法统计依赖的服务质量数据资源依赖（DB、Redis、Memcached、队列）⽆法整体查看服务、接⼝、资源之间的依赖关系容量评估及扩容标准全靠经验出问题后仅能凭经验逐⼀排查、⽆法迅速定位到代码层⾯完全依赖dba帮忙排查服务器资源依赖（负载、内存、⽹络······）资源指标上升后、⽆法判断数值是常规上升还是资源异常3.1.3流量⼤流量来袭时、⽆法整体感知流量状况流量多⼤算⼤？核⼼业务是否收到影响？单⼀接⼝流量增加却未达到整体的告警线、导致⽆法感知可视化是否实时⽆法直观统计流量分布、⽆法查看具体每个接⼝的流量情况容量评估时、流量放⼤系数全靠⼈为判断、对服务整体的放⼤系数⽆感知3.2故障发现⼀个⾼可⽤的业务系统除了技术架构⽀撑之外，监控系统作为事中决策⽀撑和事后决策⽌损是必不可少的⼀部分⼯具：Prometheus、Zabbix、Nagios、Open-Falcon、Pageduty等3.2.1监控体系汇总监控体系分类：⼀般可分为：业务监控，系统级别监控，⽹络监控，程序代码监控，⽇志监控，⽤户⾏为分析监控，其他种类监控等系统级别监控：主要跟操作系统相关的基本监控项物理监控（对物理机或者容器的监控）：存活、内存、cpu、load、硬盘（速率、使⽤率）、⽹络活性检测：进程、端⼝应⽤服务监控：jvm、gc、线程数服务监控：rpc和http接⼝的qps、rt、错误码等业务监控：包含⽤户访问的QPS，DAU，访问状态（http状态码），业务接⼝（登录，注册，聊天，送礼，留⾔，下单，⽀付，播放按钮点击率，搜索次数，好评差评数等等），产品转化率，充值额度，客诉等很宏观的概念1-基础业务监控交易运营数据业务监控⾃定义数据2-业务监控的发展1-业务监控设置静态阈值⽆法满⾜要求阈值应该配成多少，不同的业务甚⾄不同的时间段都需要不同的阈值业务总是出现周期性的趋势，规则配置极易产⽣误报特殊的业务场景例如活动引起的冲⾼回落、⼤促的冲击都会引起⼤量误报对⼤量维度的业务，⽐如要监控外部千万级别的商户、上百个不同类型的错误码该如何配置2-我们要根据业务特征和历史数据⽣成动态阈值，⾃动化报警，及时发现故障3-业界产品：⽀付宝lego阿⾥妈妈goldeneye4-⼀般架构图⽹络监控IDC，对⽹络状态的监控（交换机、路由器、防⽕墙，vpn）对于⼀个互联⽹公司必不可少，但是有很多时候⼜被忽略：例如：内⽹之间（物理内⽹，逻辑内⽹），外⽹，丢包率，⽹络重传，延迟等等⽇志监控⽇志监控⽐较重要，所以⼀般单独管理和分类，⽇志不仅限于服务系统⽇志，对于很多专业化的运维⼯程师来说，需要采集的包括系统⽇志，设备⽇志，⽤户⾏为⽇志等等，后续可加⼯处理，（splunk，ELK）常⽤监控图⽰链路监控中间件监控：异常监控：当前排除故障的流程【项⽬背景】⽬前公司线上业务，经常遇到以下⼏种问题：1.由于环境的隔离，导致⽆法从本地开发环境访问线上环境，故⽽遇到问题，⽆法使⽤IDE远程调试应⽤程序。2.为了线上业务的正常运作，所以不能在⽣产中调试，防⽌因调试导致所有线程不可⽤，从⽽影响线上业务。3.不同环境，参数不同，重现问题难。⼀旦我们在⽣产中检测到问题，我们必须：1.回滚到稳定版本。2.在⽇志和代码中搜索错误和异常。3.添加log⽇志，创建新的修补程序版本。4.提交测试，等待测试和发布（有可能数天）。5.部署预发，获取详细⽇志，验证问题。6.发布新版本到线上。完成上述步骤，有的故障甚⾄持续数天，效率⾮常低下故障诊断跟踪系统因此产⽣，其实纵观计算机科学的发展，也是需求促使着新技术不断被发明，⼜在⼀层⼀层的技术之上建⽴新的抽象。以京东的JEX平台为例功能：1.⾃动捕获程序中发⽣的异常事件2.⾃动保存异常发⽣时的完整调⽤栈（callstack）3.⾃动保存异常发⽣时的变量值4.⾃动关联相关源代码和变量异常退栈：JEX：保存了异常的DEBUG和TRACE信息3.3线上排除故障3.3.1故障排除⽅法上⼀节，我们有提到，故障排除的⼀般流程，不妨在此再次总结如下：1.回滚到稳定版本。2.在⽇志和代码中搜索错误和异常。3.添加log⽇志，创建新的修补程序版本。4.提交测试，等待测试和发布（数天）。5.部署预发，获取详细⽇志，验证问题。6.发布新版本到线上。另外，别忘了⼀个很重要的⽅法：重启服务3.3.2故障排除⼀般需要掌握的技能-⼯具篇1-⼀般情况下，需要了解业务场景，千万不要第⼀时间着急解决bug，应先评断是否可以回滚，影响⾯⼤⼩，是否为上层提供服务，是否有数据异常。2-应熟悉项⽬依赖的监控，学会看监控。3-应熟练开发环境的断点排查与诊断，熟悉git，maven，idea的使⽤，分析如何复现线上故障。4-线上排查故障的⼯具链（仅供参考）-随着课程慢慢补齐IDEA断点⾼阶1.window快捷键：所在⾏处：Ctrl+F8断点属性编辑：Ctrl+Shift+F82.断点类型与设置⾏断点（linebreakpoints)在到达设置断点的代码⾏时暂停程序。这种类型的断点可以设置在任何可执⾏的代码⾏上。该类型断点的图标：字段断点（fieldbreakpoints）当指定的字段被读取或写⼊时暂停程序。这允许你对与特定实例变量的交互作出反应。例如，如果在⼀个复杂的过程结束时，你的某个字段出现了明显的错误值，设置⼀个字段观察点可能有助于确定故障的来源。该类型断点的图标：⿏标右键点击该断点图标，弹出该断点配置，会有Fieldaccess和Fieldmodification选项，此选项是字段类型断点特有的，分别对应访问该字段或修改该字段触发断点，两项同时选中，则访问与修改该字段都会触发断点。⽅法断点（methodbreakpoints）在进⼊或退出指定的⽅法或其实现之⼀时暂停程序，允许你检查该⽅法的进⼊/退出条件。该类型断点的图标：当断点加在class类名这⼀⾏，且该类中没有编写构造函数（只有默认⽆参构造函数），当⽤默认⽆参构造函数时会触发此断点，程序挂起，故该断点虽然图标是⾏断点类型图标，但实际上属于⽅法类型断点。⿏标右键点击该断点图标，弹出该断点配置，会有Emulated、Methodentry、Methodexit选项，此选项是⽅法类型断点特有的。Emulated勾选中，会将⽅法断点优化成⽅法中第⼀条和最后⼀条语句的⾏断点，这样会优化调试的性能，因此在IDE中会默认选中，通过匹配符批量添加⽅法断点，在断点列表页匹配符⽰例:异常断点（Exceptionbreakpoints）异常断点分为两种，⼀种是AnyException，任意Throwable异常被捕获或未被捕获就会触发断点，另⼀种是指定类型的异常及其该异常⼦类被捕获或未被捕获会触发断点，该类型断点图标⿏标右键点击该断点图标，弹出该断点配置，会有Caughtexception和Uncaughtexception选项，此选项是字段类型断点特有的，Caughtexception选项选中时，当指定的异常被捕获时，触发断点程序挂起，Uncaughtexception选中时，当指定的异常未被捕获时，触发断点程序挂起3.断点控制断点删除1-所有类型断点：断点设置中移除对应的即可。2-快捷移除：⾏位置⿏标左键单击即可移除（异常断点除外）建议：为了避免意外删除断点并丢失其参数，通常选择点击⿏标中键来删除断点。要做到这⼀点，请进⼊“设置/⾸选项”|“构建、执⾏、部署”|“调试器”，选择"拖到编辑器"或⽤⿏标中键点击。点击⼀个断点将启⽤或禁⽤它。断点静⾳如果某些时候不需要在断点处停留⼀段时间，可以将断点静⾳。这样就可以在不离开调试器会话的情况下恢复正常的程序操作。之后，可以解除中断点的静⾳，继续调试。断点静⾳会静⾳所有断点在断点调试窗⼝，点击断点静⾳按钮启⽤/禁⽤断点正常通过断电删除的断点，会连同当时断点的内部所有配置⼀并删除。如果想暂时关闭⼀个断点，后续可能还会使⽤，这是⼀个很好的选择同断点删除操作断点移动/复制断点移动：⿏标左键拖动断点复制：按住ctrl，⿏标左键拖动4.断点属性配置⿏标操作：右键断点：More(Ctrl+Shift+F8)快捷键：Ctrl+Shift+F8快捷键：光标所在⾏Alt+Enter断点有许多属性配置，如下图所⽰，下⾯将会对各个属性的作⽤以及使⽤进⾏说明。Enabled表⽰是否启⽤该断点，选中表⽰启⽤，取消选中表⽰不启⽤。Supend当断点的Suppend属性被勾选，触发该断点时，会触发程序挂起，当该属性未选中时，程序触发该断点时，程序不会挂起，常⽤于输出⼀些表达式结果⽇志。当断点的All属性被勾选，触发该断点时，会挂起所有线程当断点的Thead属性被勾选，触发该断点时，只会挂起触发该断点的那个线程，不影响其他线程当需要在不暂停程序的情况下记录⼀些表达式时（例如，需要知道⼀个⽅法被调⽤了多少次时），或者需要创建⼀个主断点，在击中后启⽤附属断点时，⾮暂停性断点是⾮常有⽤的。实际⽣产实践中，可⽤于调试多线程并发的问题Condition可以输⼊⼀段能获得true或false的表达式，程序运⾏到断点处，且表达式条件为true才会触发断点Log下⾯三个属性选项经常配合Suppend属性⼀起使⽤，⽤于在不挂起的情况下，输出⼀些想要的⽇志信息Breakpinthitmessage：控制台输出触发端点的⽇志信息，类似如：Breakpointreachedatocean.Whale.main(Whale.java:5)Stacktrace：输出触发断点时的堆栈信息Evaluateandlog：计算表达式结果并输出表达式结果到控制台，表达式的计算基于断点所在⾏的上⽂下，表达式的语句可以是字符串字⾯量，如“我是字符串”,也可以是⽅法调⽤，如users.size()，也可以是多⾏语句块，表达式的结果取⾃return语句，如果没有return语句，会取表达式中的最后⼀⾏语句。Removeoncehit是否在断点触发后移除该断点，后续不在触发Disableuntilhittingthefollowingbreakpoint指定在另⼀个断点触发后，该断点才启⽤，若该断点启⽤后，并且被触发，场景：当只需要在某些条件下或某些操作后暂停程序时，这个选项很有⽤。在这种情况下，触发断点通常不需要停⽌程序的执⾏，⽽是做成⾮暂停状态。Filters前边说的⼤都数属性，都只针对⽅法程序运⾏上下⽂。此属性更多关注通过过滤掉类、实例和调⽤者⽅法来微调断点操作，只在需要时暂停程序。，有如下⼏种过滤⽅式：Catchclassfilters：此选项只对异常类型的断点可⽤，可以让程序只在指定类和⼦类中抛出的异常才会触发断点或者不在指定的类和⼦类中触发断点（即排除⼀些类，排除通常以-开始，例如-pacakge.ClassName），Instancefilters：只有指定实例id号可以触发断点，多个实例id号以逗号隔开，实例id号可以在Variables和Memory⾯板中查看Classfilters：可以让程序只在指定类和⼦类中才会触发断点或者不在指定的类和⼦类中触发断