What is Event Monitoring
Event Monitoring is a module part of the Salesforce Shield suite, along with Encryption and Extended Audit Trail capabilities. Event Monitoring provides access to technical servers logs that Salesforce group by event types, such as ApexExecution, ApexTrigger, RestAPI, ReportExecution…. The list of supported event type is listed here.
Retention period of Event Monitoring logs is 30 days maximum.
Event Monitoring brings additional features that needs to be assessed and enabled separately when needed such as Real-Time event monitoring Check this link for further information. Real time monitoring allows storage in objects/bigObjects for querying using async SOQL, reporting, and transaction security policies definition. Not all event types are supported. Retention is up to 6 months Check this link for further information.
Event Monitoring also comes by default with 10 Tableau licenses (ex Einstein Analytics), and a Tableau application dedicated to visualizing the events on a daily basis in Tableau.
Outside of Real-Time event monitoring, log refresh rates and availability of the logs is twofold; daily and hourly. Usually logs for yesterday UTC time would be available to day after around 12pm. For hourly logs, they are available same day, usually 2-3 hours after the event occurred.
Key training links
Trailhead basics of Event Monitoring, and how to access event log raw files:https://trailhead.salesforce.com/en/content/learn/modules/event_monitoring
Trailhead on Event Monitoring Analytics App: https://trailhead.salesforce.com/content/learn/modules/event_monitoring_analytics
Trailhead on Real-Time Event Monitoring: https://trailhead.salesforce.com/en/content/learn/modules/realtime-event-monitoring
Accessing and downloading raw log files
Easiest way it to use ELF browser heroku application https://salesforce-elf.herokuapp.com/
Ensure your profile / pset have the following system permission assigned: View Event Log Files
Login to your application, select the date you are looking logs for, the event type and the interval. Then click on green arrow next to the file to download it.
Understanding the content of the event files
Through this link, open up the specific event type Salesforce Developers
All fields are described for the event, including values for ENUM fields type.
Key field: REQUEST_ID
This field allow navigation cross different event type files, and identification of event records between for instance API, ApexExecution, ApexTrigger. That enables for instance to trace for a given API call what backend process got generated in Salesforce (ApexExecution), and what triggers got fired (ApexTrigger). Same apply with other frontend actions, using AuraRequest, ApexExecution, …
Use case 1: identify long running transaction
Best is to use the ApexExecution event for this.
It is critical for system health to ensure long running transactions are kept minimal and under control, as the following governor limit when reached would completely block the org: Number of synchronous concurrent transactions for long-running transactions that last longer than 5 seconds for each org.
Download the file and open it. there is a column called IS_LONG_RUNNING_REQUEST, filter on value=1.
CallOut time doesn’t count anymore against this limit, only CPU time and DB time. So root cause of this type of issue is either a complex process, a transaction going into a loop, or a non optimized query.
Using ENTRY_POINT column, CPU_TIME and DB_TIME, you can easily identify the components that need to be analyzed and optimized.
Use case 2: identify contentions / record locks
Best is to use the ApexExecution, ApexTrigger, API and RestAPI events for this.
When a lock record happens in Salesforce, the conflicting transactions don’t necessary fail. One will be paused few seconds by Salesforce before retry. It is visible through the logs that a backend transaction can be paused till 20s, and fails only after 20s if contention is still there.
In order to identify these potentials logs, download the backend event file needed, and filter on RUN_TIME > 10000ms.
In order to identify what process/user is conflicting with what other process/user, look for concurrent transaction happening almost during same second. This could be in different log files if for instance an API call conflicts with a Composite REST API call.
To further assess what object is impacted, you can nail it down by using other event type like ApexTrigger, FlowExecution, … and the REQUEST ID field to look for same backend transaction.
Use case 3: identify backend performances
Best is to use the ApexExecution event for this.
Backend synchronous transactions are usually having a direct impact on the end user experience. In order to identify, prioritize and tune the code processing badly, use the ApexExecution event for this, and look for RUN_TIME over what you consider acceptable (5000ms for instance).
Through the ENTRY_POINT column, you can identify the method involved in the long transaction. Looking at the CPU_TIME value and the DB_TIME value, this will help you identifying what type of optimization is required. Also you can again lookup to the ApexTrigger file if you want to check for potentials loops in the execution.
Use case 4: identify callout performances
Best is to use the ApexExecution, ApexCallout events for this.
CallOut from Salesforce is usually done through Apex Callout and named credential. As with all Apex callout method, it will be found in the ApexExecution event type, ENTRY_POINT column. As same method can execute multiple CallOuts (one for authentication, one with the payload for instance), look up to the ApexCallout event type file through the RequestID in order to get the detail of each call out performance and against which endpoint it was sent.