Salesforce 日志结构(一)

2019独角兽企业重金招聘Python工程师标准>>>

在开发过程中经常需要调试程序，但SF中不像JAVA开发可以借助IDE通过断点调试，观察每个变量的赋值情况从而查找问题，

那就只能借助日志，分析排错，大部分情况下我们都是通过System.debug()输出语句输出变量，跟JS中 alert()一样。大部分都是只看日志的输出语句忽略日志的其他信息

最近发现SF的日志中可以看出每个变量的赋值情况，无需通过输出语句，这个跟设定的调试等级有关。在调试等级之前先学习下日志组成部分。

Debug Log包含的信息

SF 的debug log 可以记录 数据库的操作，系统执行过程，事务或者单元测试类执行中的错误信息

日志记录的信息可以是

• Database changes

• HTTP callouts

• Apex errors

• Resources used by Apex

• Automated workflow processes, such as:

  • Workflow rules

  • Assignment rules

  • Approval processes

  • Validation rules

The debug log does not include information from actions triggered by time-based workflows.

Debug 设定

1. 在日志中可以监控某个用户，类，目前为止一般都是监控用户

2. 设置监控时间段，不能超过24h

3. 调试等级，不同的调试等级输出的日志信息不同。等级越低越详细

4. 日志中的限制：Org中日志最大为50M,超过后将覆盖最早的，每次日志输出最大为2M,超过的系统将会截断在输出的日志中会有个skip字样，这种情况下对我们调试不利。

日志整体结构

在sublime 中执行一段匿名代码块，在sublime中输出日志为列

#1 35.0 APEX_CODE,DEBUG;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;VALIDATION,INFO;WORKFLOW,INFO
#2 Execute Anonymous: Integer i = 0;
#3 Execute Anonymous: i++;
#4 Execute Anonymous: System.debug('i = '+i);
#5 22:34:06.58 (58323487)|EXECUTION_STARTED
#6 22:34:06.58 (58341923)|CODE_UNIT_STARTED|[EXTERNAL]|execute_anonymous_apex
#7 22:34:06.58 (59138044)|USER_DEBUG|[3]|DEBUG|i = 1
#8 22:34:06.59 (59206930)|CUMULATIVE_LIMIT_USAGE
#9 22:34:06.59 (59206930)|LIMIT_USAGE_FOR_NS|(default)|
#10   Number of SOQL queries: 0 out of 100
#11  Number of query rows: 0 out of 50000
#12  Number of SOSL queries: 0 out of 20
#13  Number of DML statements: 0 out of 150
#14  Number of DML rows: 0 out of 10000
#15  Maximum CPU time: 0 out of 10000
#16  Maximum heap size: 0 out of 6000000
#18  Number of callouts: 0 out of 100
#18  Number of Email Invocations: 0 out of 10
#19  Number of future calls: 0 out of 50
#20  Number of queueable jobs added to the queue: 0 out of 50
#21  Number of Mobile Apex push calls: 0 out of 10

#22 22:34:06.59 (59206930)|CUMULATIVE_LIMIT_USAGE_END

#23 22:34:06.58 (59295731)|CODE_UNIT_FINISHED|execute_anonymous_apex
#24 22:34:06.58 (60767656)|EXECUTION_FINISHED

 

 

#1 行中含义：35.0 表明使用的APEX版本

类别	日志等级
APEX_CODE	DEBUG
APEX_PROFILING	INFO
CALLOUT	INFO
DB	INFO
VALIDATION	INFO
WORKFLOW	INFO

#2 ～ #4 忽略

#5 和 #24  （Execution Units） EXECUTION_STARTED 和 EXECUTION_FINISHED 为这次动作执行的起点和结束点，也应该可以理解为事务的开始到结束

由于SF中，每次处理一次请求为一个事务，不管这次请求执行了多少次触发器，执行了多少次数据库操作，Batch中，每个批次为一个事务(目前了解的这些)

#6 和 #23 （Code Units）CODE_UNIT_STARTED 和 CODE_UNIT_FINISHED 为一个代码单元的执行起点和结束点，比如：Trigger，webService方法，验证规则为一个Code Units

     A class is not a discrete unit of code(这句话应该表明一个普通的类不认为是一个Code Units 类最终是上层在调用)

     Code Units 是会出现嵌套的，比如当匿名代码块导致触发器时，这时触发器的Code Units是在 匿名代码块Code Units内

     

     同时还会表明是什么类型的Code Units 如:execute_anonymous_apex 、MyTrigger on Account trigger event BeforeInsert for [new]

    以下为部分Code Units

• Triggers
• Workflow invocations and time-based workflow
• Validation rules
• Approval processes
• Apex lead convert
• @future method invocations
• Web service invocations
• executeAnonymous calls
• Visualforce property accesses on Apex controllers
• Visualforce actions on Apex controllers
• Execution of the batch Apex start and finish methods, and each execution of the execute method
• Execution of the Apex System.Schedule execute method
• Incoming email handling

#7 USER_DEBUG 为 用户输出日志(System.debug())      

#8 到 #22 行 则是记录 当前事务中各种限制的使用情况。每完成一个功能后，都需要检查该功能中限制使用情况，尽量把限制使用数降低。一但超过SF规定的限制系统直接出现运行时异常

Debug Event Type

15:51:01.071 (55856000)|DML_BEGIN|[5]|Op:Insert|Type:Invoice_Statement__c|Rows:1

以这条DML日志为列  日志采用 "|"为分隔符 

1） 第一段:时间 15:51:01.071 (55856000)

2）第二段:Event Name: DML_BEGIN  这里为DML开始

3) 第三段:代码行数 [5] 

4) 第四段:DML操作类型  这里为 insert

5)第五段:操作的对象 这里为:Invoice_Statement__c

6)第六段:成功的记录数:

通过日志了解程序执行情况，尤其是在正式环境后，当出现异常后，通过分析日志，先定位到某一方面的错误。SF中日志监控有2个地方，控制台中的日志(很少用，反应慢)，日志界面，通过监控，点击查看，跳转到日志详细信息，另外IDE也能打印日志，比如执行匿名代码块，执行测试类。整体还是比较麻烦。（如有错误欢迎指出）

参考资料SF文档(https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_debugging.htm)

 

 

 

 

 

 

转载于:https://my.oschina.net/SpringZhang/blog/683496