The Salesforce Developers website will undergo maintenance on May 29, 2024 from 3:00 a.m. UTC to 10:00 a.m. UTC. The maintenance process may affect the availability of our documentation. Please plan accordingly.

As Salesforce development continuously evolves, so do instrumentation needs. While Salesforce standard components have long been observable through internal instrumentation frameworks, the same level of insight into custom components has been a persistent challenge. Responding to the demand from Salesforce customers and ISV teams, we are thrilled to unveil a new solution: the Logger API. This API empowers developers to glean valuable insights into the performance, usage, and security of their custom Lightning web components (LWCs).

Problem statement

Until Spring 2024, custom components developed by Salesforce customers and ISVs remained elusive in terms of observability. Organizations were compelled to seek workarounds, resorting to third-party observability tools like Google Analytics. However, integrating these tools with Salesforce presented challenges due to security constraints, and the generated data did not seamlessly integrate with event monitoring log files. These challenges left organizations struggling to bridge the gap.

Proposed solution

The Salesforce Instrumentation team (part of the Web Platform organization) came up with a solution: the Logger API, a JavaScript API that allows developers to instrument custom component code effortlessly. It allows an easy-to-use way of logging arbitrary JSON-formatted information in custom LWC components.

To kickstart the flow of data that is being collected by the Logger API, customers need to meet two prerequisites: 1) purchase the Event Monitoring add-on, and 2) enable the toggle in the Event Monitoring setup.

Lightning Logger event data details

The Logger API emits the Lightning Logger events containing information from the logs. This event type is available in the Event Monitoring’s EventLogFile object in API version 58.0 and later.

The EventLogFile file includes fields needed for successful debugging and log analysis about the application. These fields are noted in the table below.

Field Description
MESSAGE The string message passed to the lighting-logger log method. This can contain JSON encoded javascript objects for richer data schema. The length of this string is limited to 4KB (4096 characters).

COMPONENT_NAME
Name of the component calling into the JavaScript Logger API.

SEQUENCE
Auto incremented counter for every call to the Logger API in the browser tab.

UI_EVENT_TIMESTAMP
Time at which this event was emitted in the browser.

CLIENT_SESSION_ID
Unique GUID attached to every event taking place in a single browser tab.

BROWSER_NAME
Browser being used.

LOGIN_KEY
The string that ties together all the events in a user’s login session.
The PAGE_ fields below are from the page where the log call was executed

PAGE_URL
Page URL on which the log was generated.

PAGE_ENTITY_TYPE
Entity type of the page being displayed.
PAGE_CONTEXT Name of the component hosting the main content of the page.

PAGE_ENTITY_ID
Entity ID if any of the record is being displayed.

USER_ID
15 char ID of the user accessing the Salesforce UI.

Usage

To harness the capabilities of the Logger API, developers need to import a logger module.

The end-to-end flow for instrumenting components involves importing the logger module and utilizing it within the Lightning web component code. For instance:

Finally, enabling the toggle in Event Monitoring settings allows the data to flow seamlessly within the Salesforce org.

Screenshot of the Event Monitoring Settings page

Once the toggle is enabled, the data in the org starts flowing into Event Monitoring.

Here is an example of a hypothetical row of data (single log row split into multiple lines):

EVENT_TYPE TIMESTAMP REQUEST_ID ORGANIZATION_ID USER_ID DEVICE_SESSION_ID UI_EVENT_TIMESTAMP UI_EVENT_RELATIVE_TIMESTAMP UI_ROOT_ACTIVITY_ID USER_TYPE CLIENT_ID SESSION_KEY LOGIN_KEY CLIENT_GEO CONNECTION_TYPE APP_NAME SDK_APP_VERSION DEVICE_PLATFORM DEVICE_MODEL SDK_VERSION BROWSER_NAME BROWSER_VERSION OS_NAME OS_VERSION PAGE_URL PAGE_ENTITY_TYPE PAGE_CONTEXT PAGE_ENTITY_ID SDK_APP_TYPE MESSAGE TIMESTAMP_DERIVED USER_ID_DERIVED CLIENT_IP
LightningLogger 20240423005813 TID:2321659000098c792d 00DSG000000qHRN 005SG000000eu6j 25a6c716992826a4 1713833891778 22267.9 7f2a92fdbafdec66 Standard 69NAmsx+zTAPhzo5 oVWfGX63RJrmVkS8 United States/California 4g one:one CHROME 124 OSX 10.15.7 /lightning/page/home home:landing {“type”:”click”,”action”:”save”} 2024-04-23T00:58:12.996Z 005SG000000eu6jYAA 13.110.54.10

Conclusion

The introduction of the Logger API marks a significant milestone in addressing the observability gap for custom Lightning web components. Salesforce Developers can now seamlessly gain insights into the performance, usage, and security aspects of their applications. By leveraging this powerful API, organizations can elevate their development practices and ensure a more robust and transparent Salesforce environment. Embrace the future of observability in Salesforce development with the Logger API!

Further Resources

About the authors

Grisha Lyukshin is a Senior Product Manager at Salesforce who works on the LWC framework and technologies adjacent to it. Connect with him on LinkedIn or X.

Suvda Myagmar is a Director of Product Management at Salesforce. Suvda is passionate about data and AI platforms. Outside of work, she’s mastering the art of wilderness camping without sacrificing her zzzs. Connect with her on X.

Tariq Rafique is a Senior Architect at Salesforce.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS