SFDC : Logging As A Service

Standard “Out-of-Box” support to leadership, developer community and business users for providing visibility and ease of management of the custom functionality built on top of the Salesforce platform in form of a trusted Salesforce-AppExchange managed package.

Understanding the problems

very chatty

Salesforce logging framework is useful but is very chatty. It gives lots of internal execution detail but not very optimized for user apex code

can’t be enable for all time

SFDC-Logging can be turned on for specific time and can’t be enable for all time, to log only when relevant event occurs.

not component aware

SFDC-logging is not component aware and cannot be fine-tuned based on component. Also for managed package, to get logs, SFDC-Support needs to be involved

Project objective

Laas is an attempt to provide some “out-of-box” kind of support for developers for logging and troubleshooting. It will help in developing customer functionality, while in development and later, in troubleshooting. LAAS is a component based logging infrastructure which can be fine-tuned at run time.

About Salesforce Platform

SFDC is one of the world’s first and most popular SAAS multi-tenant platform. One of the major requirement of any multi-tenant system is enforcing controlled resource usage. SFDC has implemented various governor limits to enforce controlled resource usage by any tenant.

Although this help SFDC to support multiple tenants on single platform, it does provide some unique challenges to users of the system, especially developers and troubleshooters.

 

Overview

  • Laas is an attempt to provide “out-of-box” support for developers for logging and troubleshooting in form a Saleaforce app-exchange package. It will help in developing fast customer functionality as well as in troubleshooting test and production issues.
  • LAAS is a component based logging infrastructure which can be fine-tuned at run time. It can be user to monitor at user, group(profile) and org level.
  • As there are no free-lunches in the world, this has its own overhead, in term of CPU, heap memory and governor limits and so should be used wisely.

Target audience

All SFDC-platform developers can use this framework for their own use. Product-support team can use it to troubleshoot customer issues Managed-package can get important insight into issue, without getting help of SFDC-Support

  • Our technology leaders “CTO, VP, Directors, Manager,..”
  • Provides overall visibility to the implementation and quality of the system build by engineering – system-integration partner or in-house teams.
  • 5-15% saving in development and maintenance cost
  • Compliance to regulation like SOX, internal audit by allowing traceability to business transaction
  • Our development community of “Architects, Developers, Testers,..”
  • Provides standard framework from day-1 to use.
  • Support ease in development and debugging
  • Helps in troubleshooting issue with interfaces and internal functionality
  • No need to go-back-to-time to find the root cause of testing or production issues
  • 20-50% saving in debugging and troubleshooting PROD issue, without changing PROD for things like field-history tracking, asking customer steps to reproduce,…
  • Ease in implementing business needs to adhere to regulation like SOX, internal audit
  • Our most important “Business users, Customers,Auditors,….”
  • No need to provide “steps-to-reproduce issue”. “Engineering Community” should be able to get notification and details real-time.
  • 10-25% less time providing issues encountered during “normal” business usage
  • On-demand compliance details for regulatory needs like SOX, internal audit

Coming soon

  • Email support for sending daily summary of the system
    • Provide summary of activity
    • Any Exceptions reported
  • External Storage Support
    • Saving logs in Amazon, Box, Google Drive.
    • Proving logs for use in log-aggregators like Splunk

 

  • Implementing separate platform cache, so logging doesn’t uses user cache quota

* Please use your buying decision based on current functionality. Future roadmap may change based on factors like user feedback and system limitation