应用配置
应用设置是以应用为单位进行配置项的设置，仅对指定的应用生效。部分配置项可以继承业务系统级别的配置，在此我们将不再讲解，具体描述请见业务系统设置。需要说明的是，应用不能继承业务系统配置的自定义指标。
常规选项
应用别名
设置应用别名只是为了用户在界面中更方面的查看应用，便于识别。
自动命名事务
默认情况下，应用探针通过在Web请求的URI前加上URI前缀来命名事务，即事务名称结构为：URI/Web请求的URI部分。当启用自动命名事务功能后，应用探针根据应用框架或组件来命名事务，以增强事务的可识别性，事务名称结构为：应用框架或组件名称/Web请求的URI部分。
下面我们用一个例子来说明自动命名事务功能。假如用户从浏览器端发起一个HTTP请求，完整的URL为
http://www.tingyun.com/sql/oracleException1.do?city=beijing，如果处理该事务的组件为Servlet，当未开启自动命名事务功能时，事务的名称为URI/sql/oracleException1.do，如果开启，则事务的名称为Servlet/sql/oracleException1.do。日志溯源
请参见全局配置下的日志溯源介绍。
启用Thrift监控
开启该功能后，通过Thrift框架进行的RPC调用会被监控到。监控非官方generator生成的Thrift程序可能会造成应用崩溃，如果有定制或者二次开发，务必在测试环境充分测试后，谨慎开启此功能。
MQ消费端监控
监控MQ消费端可能造成应用处理消息能力下降，进而MQ消息队列中的数据会快速增长导致积压，因此请务必在测试环境充分测试后，谨慎开启此功能。
采样
请参见全局配置下采样的介绍。
探针熔断
请参见全局配置下的探针熔断介绍。
错误及异常
请参见全局配置下的错误和异常的介绍。
事务
开启追踪
请参见全局配置下的开启追踪介绍。
事务命名
事务命名功能能够丰富事务的命名方式，包括根据请求方法来命名事务、根据请求URI（URI是指URL中除域名或IP地址、端口号、ContextPath和参数之外的部分）的部分来命名事务，或者根据请求的各种参数来命名事务。
命名原理：探针会根据配置好的匹配规则聚合符合条件的事务，再根据命名规则重新给事务进行命名，以方便您识别事务。
匹配规则
探针采集到一个请求后，会把请求和匹配规则进行匹配，符合同一匹配规则的请求就是同一类请求。
匹配规则中，应用探针对URL的匹配方式如下：
支持多种请求方式：GET、POST、PUT、DELETE、HEAD。
支持多样化的URI匹配方式：等于、开始于、结束于、包含、正则。
支持按照URL参数名、Header参数名和Body参数名匹配URL，该部分可根据用户的需要选择性配置。如果配置了多条参数规则，各规则必须都满足才匹配请求。
URL参数（适用于GET请求时）：
请求头参数：
请求体参数（适用于POST请求时）：
命名规则
命名规则使事务命名的方法更加丰富，既可以指定请求方式作为事务名称的一部分，也可以指定URI分段作为事务名称的一部分，还可以指定一些参数作为事务名称的一部分，从而增强事务的可识别性。
如果仅指定匹配规则而不指定命名规则，那么符合条件的URL请求生成的事务的名称为事务命名规则名称。如果指定了命名规则，那么事务名称的结构为：
按请求方法命名：匹配规则名称/(请求方法)。
按URI分段命名：匹配规则名称/URI分段。
按URL参数名进行命名：匹配规则名称/?URL参数key=参数值。如果是多个参数，以&符号连接。
按Header参数名进行命名：匹配规则名称/?Header参数key=参数值。如果是多个参数，以&符号连接。
按Body参数名进行命名：匹配规则名称/?Body参数key=参数值。如果是多个参数，以&符号连接。
按Cookie参数名进行命名：匹配规则名称/?Cookie参数key=参数值。如果是多个参数，以&符号连接。
下面我们举例说明事务命名功能。
按请求方式命名举例
对于URI/portal/addchart这个事务，我们想对POST请求方式和GET请求方式进行的请求分别命名，所以就需要配置按请求方式命名，最终会生成test/（POST）和test/（GET）两个事务。
按URL命名举例
假设有URI/portal/addchart、URI/redirect/addchart多个类似的事务，我们只将POST方式下且URI的第3段为addchart的请求定义为操作，在配置匹配（聚合）规则时我们可以做如下配置：
最终生成的事务名称为test/addchart。
按URL参数命名举例
假设有请求/order，当action=1时代表提交订单，当action=2时代表支付，在配置规则时我们可以做如下配置（规则名为test）：
通过上述聚合规则就会产生两个聚合的请求：
test?action=1
test?action=2
我们可以把第一类请求定义为提交订单的操作，把第二类请求定义为支付的操作。
按Header参数命名举例
假设对于/order这个事务，我们只对POST方式下的请求按照Header参数Referer进行命名，在配置规则时我们可以做如下配置（规则名为test）：
当Referer为http://10.128.2.48:8080/server/system时，生成的事务名称为test?
Referer=http://10.128.2.48:8080/server/system。
按Body参数命名举例
假设对于/order这个事务，我们只对POST方式下的请求按照Body参数中action进行命名，在配置聚合规则时我们可以做如下配置（规则名为test）：
当action为2时，生成的事务名称为test?action=2。
按Cookie参数命名举例
假设有请求https://10.128.2.45:8080/order，我们需要根据Cookie参数中的JSESSIONID参数进行命名：
在配置聚合规则时我们可以做如下配置（规则名为test）：
那么，当JSESSIONID为1111时，生成的事务名称为test?JSESSIONID=1111。
事务追踪阈值
此处可针对已经发生过的具体事务单独设置追踪阈值。
NoSQL键值
通过在规则中设置以某字符串开头的键（Key），系统将会对涉及以该字符串开头的键的NoSQL操作名称进行聚合显示，格式为：操作+java*。例如，设置了键以“java”开头，那么操作名称会有如下显示：
事务过滤
事务过滤也可以称为事务/服务接口黑名单，即加入黑名单的事务/服务接口，系统不再收集其性能数据。
事务和服务接口的响应时间是影响应用评分的重要因素之一，大量的慢事务、慢服务接口会直接降低应用性能评分。但在一些特定场景下，例如长连接、批处理等已知的QPS高、响应时间长的慢事务，如果不希望它们的响应时间影响到应用评分，则可以通过配置过滤掉指定事务或服务接口，避免其对评分的影响。
添加需要过滤的事务或服务接口到右侧列表，单击提交即可，配置成功后不需要重启探针。勾选列表上方的事务复选框，列表中所有的事务会被选中；勾选列表上方的服务接口复选框，列表中所有的服务接口会被选中。
说明：事务过滤仅Agent Collector 3.4.5及以上版本支持，服务接口过滤仅Agent Collector 3.5.3及以上版本支持。列表显示最近30分钟有数据的事务及服务接口，不包含聚合后的事务/服务接口，即聚合后的事务/服务接口不支持过滤。
热点方法
热点方法学习
探针默认监控的是基调听云研发人员根据支持的框架、协议、数据库驱动、MQ驱动等设置好的关键方法，对可能有性能瓶颈的方法进行嵌码，但不包括用户自己的业务逻辑代码。开启热点方法学习后，探针会自主学习应用中比较耗时的、调用比较频繁的方法，相应的方法会被嵌码，探针能够比正常情况下监测到更多的事务堆栈，最终展示在事务和后台任务的性能分解表格以及追踪详情中，性能分类中会增加“Hotspot”类别。默认为关闭状态。
白名单
用户可以添加指定的几个方法到白名单中，探针只自主学习白名单中的方法。
黑名单
探针不会自主学习黑名单中的方法。默认会显示Java基础包。
学习结果
学习次数越多，说明该方法被调用的频率越高，耗时也越长。学习次数前100名的方法将显示在学习结果列表中。对方法单击启用后，相应的方法会被嵌码，探针将采集性能数据，最终展示在事务、业务接口和后台任务的性能分解表格以及追踪详情中。单击禁用后，探针将停止采集性能数据。单击删除后，相应的方法将从学习结果中删除。勾选选择前面的复选框可选择全部方法进行操作。
用户溯源
请参见业务系统配置下的用户溯源介绍。
自定义嵌码
请参见业务系统配置下的自定义嵌码介绍。
数据项
针对应用配置数据项时，可以关联具体的事务。当该事务发生慢追踪时，您可以在追踪详情中看到数据项页签。
自定义指标
请参见业务系统配置下的自定义指标介绍。
诊断工具
请参见诊断工具的介绍。