Advanced Logging

Salesforce provides some valuable logging capabilities out of the box. To learn more about the built in Apex Debug Logs, see the documentation here.

Built in logging

The Apex Debug logging is very useful, but has certain limitations

  • A developer must manually enable the logging. Note: opening the developer tools will also turn on logging for the current user temporarily.
  • Logging is only enabled for a maximum of 24 hours.
  • Logging must be enabled per user.
  • The desired information may be logged into many separate log files; each log must be opened individually to find the desired data.
  • Salesforce limits the size of each log file, and further limits the total log size.
  • It a bad practice to swallow exceptions, however an error may never be seen if it is only written to an Apex Debug log. :-(

Developers from other platforms may be accustomed to having the ability to write a persistent log at will, and may be surprised to learn that Salesforce doesn't have this ability natively.

Advanced Logging

To have a more advanced logging system, we require certain features:

  • Logs should persist and be available at anytime.
  • Logs should be searchable.
  • Logs should be written even if an error roles back the transaction.
  • Errors should not increase per-transaction limits (e.g. maximum DML counts).
  • Logs should have a way of filtering sensitive info; I've seen logs that inadvertently stored credit card info, social security numbers etc.
  • We should allow different levels of logging with the ability to configure which levels are actually logged at any time. One might log different levels in a sandbox vs a production org.

To see useful code for advanced persistent logs, please see this github repository.

For this project, we've implemented the following features:
  • Writes log data to Salesforce database for convenient access with reports and SOQL
  • Logs are written in a manner so DML is not added to the current transaction, and there is no rollback when errors occur
  • Provides both static methods, and a concrete class that implements an interface developers that might want to mock logging in tests, or provide other loggers.
  • Configure data that should be filtered out of logs, e.g. Social Security numbers.
  • Configure which entries are logged by LoggingLevel/User
  • Log from ProcessBuilders
The Designed process:
  1. A dev writes code that calls the LogService to log something with a specific logging level.
  2. The LogService determines if the custom metadata allows logging items at that level (i.e. Debug vs Error). If it is not to be logged, the process ends here.
  3. If the entry should be logged, the service raises an event with the appropriate data. Note that events are handled in a different execution context which prevent then from being rolled back should an error occur, and also means the DML will be in a separate context, minimizing governor limit issues.
  4. The service looks for filters in the form of regular expressions (stored in custom metadata) and filters them out of the logged message.
  5. From there an administrator can view the Log__c table, write reports, etc. so analyze any issues.
  6. Since the log is written by raising a Platform Event, one could also write a Lightning Web Component to dynamically push log data to the browser, allowing the user to do a Tail on the logs.

 

 

© 2001 – 2023 Object Factory Inc
marker marker marker marker marker