Salesforce operational considerations
Salesforce Reader monitor metrics
Metric |
|---|
Read timestamp (called Last Event Modified Time) |
Number of deletes |
Number of inserts |
Number of updates |
CPU |
CPU rate |
CPU rate per node |
Number of servers |
Number of events seen per monitor snapshot interval |
Source input |
Source rate |
Input |
Input rate |
Rate |
Last event position |
Latest activity |
Read lag |
I/O latency in ms |
Table name |
Salesforce CDC Reader monitor metrics
Metric | Description |
|---|---|
Read timestamp | Timestamp of the most recent record read by the adapter. |
Number of deletes | Number of delete operations |
Number of inserts | Number of insert operations |
Number of updates | Number of update operations |
Max CPU rate | Maximum CPU rate across all nodes |
Max CPU rate per node | Maximum CPU usage per node |
Server count | Number of nodes in the Striim cluster |
Number of events | Number of events seen by the Striim platform |
Source input | |
Source rate | |
Input | |
Input rate | |
Rate | |
Last event position | Timestamp and ID of the most recent event |
Last observed timestamp | The commit timestamp of the most recent change event that the reader received from Salesforce, in Salesforce server time. Striim sets this value when the reader receives the event. The value is "Not Ready" if the application is not started. |
Latest activity | The time at which the reader most recently sent a WAEvent downstream, in Striim server time. |
Read lag | |
Table name | Name of the table |
Total rows | Total number of rows handled by the table |
Rows read | Total number of rows read by the source |
Number of subscribed objects | Total number of objects that are subscribed to receive events |
Number of events delivered | Total number of events delivered by CometD clients |
Number of concurrent CometD subscribers | Number of concurrent CometD subscribers |
Comparing the last observed timestamp and latest activity metrics
The last observed timestamp and latest activity metrics come from different clocks and are set at different points in processing, so interpreting them together requires knowing what each one measures.
Striim sets the last observed timestamp from the Salesforce change event header when the reader receives an event, and sets the latest activity from Striim server time when the reader sends the resulting WAEvent downstream. Because the reader receives an event before it emits the corresponding WAEvent, the last observed timestamp is usually earlier than or the same as the latest activity.
The last observed timestamp can be later than the latest activity when Salesforce emits gap events and the reader is still processing them.
Salesforce sends a gap event in place of a change event when it cannot generate the change event or needs to report an error. A gap event identifies the affected records in its header but does not carry their data, so the reader retrieves those records from Salesforce one at a time.
The reader updates the last observed timestamp as soon as it receives each event. A gap event does not always produce a WAEvent, because the corresponding records may no longer exist in the source, and change events that arrive while the reader is still processing a gap event wait behind it. Since the latest activity advances only when the reader sends a WAEvent downstream, it can fall behind the timestamps of events that the reader has already received.
This difference reflects the point at which Striim updates each metric. It is not by itself an indication that events have been lost.