2

I am trying to setup filters on the Debug Logs page so that only entries caused by System.debug('foo') in my code show up.

Is there a way to do that?

4

You can check the debug log via developer console. There is a checkbox named 'debug only'.

3

OK, here's an approach I use

  1. Every System.debug(..) is coded as System.debug(LoggingLevel.INFO,mydebugtexthere);
  2. Set your debug level when you execute to System (NONE) and Apex Code (INFO)

This way you avoid getting debug noise each time a system.debug is entered as well as lots of other noise as methods are entered/exited

You can also reduce noise by changing the debug level for Validation Rules and Workflows which often are a distraction

  • I did as you instructed and now it says that it will be filtered to these events: BULK_COUNTABLE_STATEMENT_EXECUTE; EXCEPTION_THROWN; EMAIL_QUEUE; FATAL_ERROR; VF_APEX_CALL; VF_PAGE_MESSAGE; ENTERING_MANAGED_PKG; HEAP_DUMP; SCRIPT_EXECUTION; PUSH_NOTIFICATION_NOT_ENABLED; PUSH_NOTIFICATION_INVALID_CERTIFICATE; PUSH_NOTIFICATION_INVALID_APP; PUSH_NOTIFICATION_INVALID_NOTIFICATION;. And the actual log still contains a ton of information (e.g. SYSTEM_METHOD_ENTRY/SYSTEM_METHOD_EXIT, etc...). – AngryHacker Aug 15 '14 at 22:48
  • In fact, even when I set all filters to NONE, it still returned a ton of stuff. Do I need to reset something? – AngryHacker Aug 15 '14 at 22:50
  • Ok, sometimes, you need to delete the entry for yourself in the Setup | Monitor | Debug Logs and then re-add it with the desired filters. For reasons I don't understand, if you change the filters while there are still < 20 logs available, SFDC ignores the change – cropredy Aug 15 '14 at 23:43
  • It's for that reason I use logging level Error, and set the filter to Error level only. Also, you need to set all other categories to None for best results. – sfdcfox Aug 25 '14 at 18:35
3

A debug log can record database operations, system processes, and errors that occur when executing a transaction or running unit tests. Debug logs can contain information about: Database changes HTTP callouts Apex errors Resources used by Apex Automated workflow processes, such as: Workflow rules Assignment rules Approval processes Validation rules You can retain and manage the debug logs for specific users.

To view saved debug logs, from Setup, click Monitoring | Debug Logs or Logs | Debug Logs.

The following are the limits for debug logs: Once a user is added, that user can record up to 20 debug logs. After a user reaches this limit, debug logs stop being recorded for that user. Click Reset on the Monitoring Debug logs page to reset the number of logs for that user back to 20. Any existing logs are not overwritten. Each debug log can only be 2 MB. Debug logs that are larger than 2 MB are reduced in size by removing older log lines, such as log lines for earlier System.debug statements. The log lines can be removed from any location, not just the start of the debug log. Each organization can retain up to 50 MB of debug logs. Once your organization has reached 50 MB of debug logs, the oldest debug logs start being overwritten. Inspecting the Debug Log Sections After you generate a debug log, the type and amount of information listed depends on the filter values you set for the user. However, the format for a debug log is always the same.

A debug log has the following sections: Header The header contains the following information: The version of the API used during the transaction. The log category and level used to generate the log. For example: The following is an example of a header:

25.0 APEX_CODE,DEBUG;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;VALIDATION,INFO;VISUALFORCE,INFO;
WORKFLOW,INFO

In this example, the API version is 25.0, and the following debug log categories and levels have been set:

Apex Code DEBUG
Apex Profiling    INFO
Callout   INFO
Database  INFO
System    DEBUG
Validation    INFO
Visualforce   INFO
Workflow  INFO
Execution Units

An execution unit is equivalent to a transaction. It contains everything that occurred within the transaction. The execution is delimited by EXECUTION_STARTED and EXECUTION_FINISHED. Code Units A code unit is a discrete unit of work within a transaction. For example, a trigger is one unit of code, as is a webService method, or a validation rule. Note A class is not a discrete unit of code. Units of code are indicated by CODE_UNIT_STARTED and CODE_UNIT_FINISHED. Units of work can embed other units of work. For example:

EXECUTION_STARTED
CODE_UNIT_STARTED|[EXTERNAL]execute_anonymous_apex
CODE_UNIT_STARTED|[EXTERNAL]MyTrigger on Account trigger event BeforeInsert for [new]
CODE_UNIT_FINISHED <-- The trigger ends
CODE_UNIT_FINISHED <-- The executeAnonymous ends
EXECUTION_FINISHED

Units of code include, but are not limited to, the following:

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 Apexstart and finish methods, as well as each execution of the execute method
Execution of the ApexSystem.Schedule execute method
Incoming email handling
Log Lines

Log lines are Included inside units of code and indicate what code or rules are being executed. Log lines can also be messages specifically written to the debug log. For example: Debug Log Line Example Log lines are made up of a set of fields, delimited by a pipe (|). The format is: timestamp: consists of the time when the event occurred and a value between parentheses. The time is in the user's time zone and in the format HH:mm:ss.SSS. The value represents the time elapsed in milliseconds since the start of the request. The elapsed time value is excluded from logs reviewed in the Developer Console. event identifier: consists of the specific event that triggered the debug log being written to, such as SAVEPOINT_RESET or VALIDATION_RULE, and any additional information logged with that event, such as the method name or the line and character number where the code was executed. Additional Log Data In addition, the log contains the following information: Cumulative resource usage is logged at the end of many code units, such as triggers, executeAnonymous, batch Apex message processing, @future methods, Apex test methods, Apex web service methods, and Apex lead convert. Cumulative profiling information is logged once at the end of the transaction and contains information about the most expensive queries (used the most resources), DML invocations, and so on. The following is an example debug log:

11:47:46.546|CUMULATIVE_LIMIT_USAGE_END

11:47:46.038 (38715000)|CODE_UNIT_FINISHED|myAccountTrigger on Account trigger event BeforeUpdate for [001D000000IzMaE]
11:47:47.154 (1154831000)|CODE_UNIT_FINISHED|TRIGGERS
11:47:47.154 (1154881000)|EXECUTION_FINISHED

Setting Debug Log Filters for Apex Classes and Triggers Debug log filtering provides a mechanism for fine-tuning the log verbosity at the trigger and class level. This is especially helpful when debugging Apex logic. For example, to evaluate the output of a complex process, you can raise the log verbosity for a given class while turning off logging for other classes or triggers within a single request.

When you override the debug log levels for a class or trigger, these debug levels also apply to the class methods that your class or trigger calls and the triggers that get executed as a result. All class methods and triggers in the execution path inherit the debug log settings from their caller, unless they have these settings overridden.

22.0 APEX_CODE,DEBUG;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;VALIDATION,INFO;VISUALFORCE,INFO;
WORKFLOW,INFO
11:47:46.030 (30064000)|EXECUTION_STARTED
11:47:46.030 (30159000)|CODE_UNIT_STARTED|[EXTERNAL]|TRIGGERS
11:47:46.030 (30271000)|CODE_UNIT_STARTED|[EXTERNAL]|01qD00000004JvP|myAccountTrigger on Account trigger event BeforeUpdate for [001D000000IzMaE]
11:47:46.038 (38296000)|SYSTEM_METHOD_ENTRY|[2]|System.debug(ANY)
11:47:46.038 (38450000)|USER_DEBUG|[2]|DEBUG|Hello World!
11:47:46.038 (38520000)|SYSTEM_METHOD_EXIT|[2]|System.debug(ANY)
11:47:46.546 (38587000)|CUMULATIVE_LIMIT_USAGE
11:47:46.546|LIMIT_USAGE_FOR_NS|(default)|
  Number of SOQL queries: 0 out of 100
  Number of query rows: 0 out of 50000
  Number of SOSL queries: 0 out of 20
  Number of DML statements: 0 out of 150
  Number of DML rows: 0 out of 10000
  Number of code statements: 1 out of 200000
  Maximum heap size: 0 out of 6000000
  Number of callouts: 0 out of 10
  Number of Email Invocations: 0 out of 10
  Number of fields describes: 0 out of 100
  Number of record type describes: 0 out of 100
  Number of child relationships describes: 0 out of 100
  Number of picklist describes: 0 out of 100
  Number of future calls: 0 out of 10

The following diagram illustrates overriding debug log levels at the class and trigger level. For this scenario, suppose Class1 is causing some issues that you would like to take a closer look at. To this end, the debug log levels of Class1 are raised to the finest granularity. Class3 doesn't override these log levels, and therefore inherits the granular log filters of Class1. However, UtilityClass has already been tested and is known to work properly, so it has its log filters turned off. Similarly, Class2 isn't in the code path that causes a problem, therefore it has its logging minimized to log only errors for the Apex Code category. Trigger2 inherits these log settings from Class2.

Fine-tuning debug logging for classes and triggers Debug log filters for classes and triggers The following is a pseudo-code example that the diagram is based on. Trigger1 calls a method of Class1 and another method of Class2. For example:

trigger Trigger1 on Account (before insert) {
    Class1.someMethod();
    Class2.anotherMethod();
}

Class1 calls a method of Class3, which in turn calls a method of a utility class. For example:

public class Class1 {
    public static void someMethod() {
        Class3.thirdMethod();
    }
}

public class Class3 {
    public static void thirdMethod() {
        UtilityClass.doSomething();
    }
}

Class2 causes a trigger, Trigger2, to be executed. For example:

public class Class2 {
    public static void anotherMethod() {
        // Some code that causes Trigger2 to be fired.
    }
}
1

Additional issue with resetting this, even from the ui, if you limit the information to tighten it down, all seven settings will record a log of its own, so you end up with 13 remaining logs available... If you have a big test, you can easily use up all 13 available logs, hit reset on the user and everthing is reset, not just the number of logs that have been recorded. IMHO Salesforce really needs to some work on this area of the application. Its pretty bad.

1

Don't forget that you can filter any log that you're viewing in the Developer Console by typing a few characters in the filter text box. That will limit the lines shown to the ones that contain the text you type

If you prefix your system.debug calls with something unique (eg. "ProjectFred-"), you can then use this feature to show just the log lines with the unique tag you've added.

enter image description here

1

Quick and dirty:

system.debug(´--- the value I want to debug is: ´+value);

Then I run the code and use the filter (just like shown above) with --- (the three dashes).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.