Skip to content

Why This Shipper

Last reviewed: 2026-08.

There is more than one way to get Salesforce Event Monitoring data somewhere useful, and for some orgs the built-in answer is the whole answer. This page states what sf2loki does differently and why, so you can decide whether it earns a service in your stack. It describes this codebase; it makes no claims about how anything else is implemented.

What already exists

Salesforce's own Event Monitoring dashboards. First-party, no infrastructure, and they understand the data model better than any exporter will. They also live in Salesforce, which is the wrong place if your logs, alerts and on-call workflow live somewhere else.

A vendor SIEM connector. If the destination is a SIEM and the requirement is compliance retention, a supported connector is the shortest path and there is little reason to put anything in between.

A script that downloads EventLogFile CSVs on a cron. For one event type and a modest volume this is genuinely fine — it is small, and there is nothing to operate. Most of what follows is about what stops being true once several event categories, streaming sources and a Loki bill are involved.

Design choices specific to this shipper

Four source types behind one seam. Pub/Sub streaming (gRPC + Avro), SOQL-polled objects, EventLogFile CSV exports and ApexLog debug logs all arrive through a single async-iterator interface. They have very different latency and completeness characteristics, and the Sources pages say which is which — the choice is documented as a decision rather than left as whichever one you found first.

Each event category is ingested from exactly one source. The same activity is often available through more than one path, so an either/or-per-category rule is enforced rather than left to configuration discipline. Without it the same login appears twice from two sources and every count downstream is quietly wrong — a failure that looks like data, not like an error.

A fixed Loki label allowlist, enforced at startup. user_id, source_ip, replay_id and similar are structural cardinality bombs in a Loki stream, so they cannot become labels; they travel as structured metadata instead. The allowlist is checked when the process starts, which means a misconfiguration fails immediately rather than after it has created a few million streams. See Cost Controls.

HA that respects the API's actual constraint. Salesforce allows one Pub/Sub subscriber, so the model is active-passive with a file lease or a Kubernetes Lease, not active-active. A crashed leader fails over without a second instance double-delivering. See High Availability.

Checkpoints are a first-class concern. Unattended operation means surviving restarts without gaps or replays; State & Checkpoints covers what is persisted and what a restart actually guarantees.

Redaction and sampling before egress. PII Redaction & Sampling covers what can be stripped or thinned on the way out, which matters because Event Monitoring data is user activity by definition.

When to pick something else

Compliance retention into a SIEM is the requirement. Use the supported connector. Loki is a log store optimised for querying by label, not an archive of record.

You want one event type, occasionally. A cron and a CSV download is less to run and less to understand.

Salesforce's own dashboards answer your questions. Streaming, leases and a label allowlist exist for continuous ingestion at volume with a cost ceiling. Below that they are overhead.

You need something the API does not expose. The Salesforce API and your Event Monitoring licensing are the ceiling — Real-Time Event Monitoring in particular is a licensed add-on, and no shipper can produce events your org does not emit.

See also