Oplog Browser & Analyzer

The Oplog Browser tails local.oplog.rs — MongoDB's replication log — with rich UI filtering so you can see exactly which writes are flowing through your replica set right now. The Analyzer layers on session attribution, index-build detection, and a replication-lag heat-map so you can turn a wall of oplog entries into an actionable picture of what your cluster is doing.

Opening the Browser

The Oplog Browser needs read access to the local database. On most connections the user in your URI already has this; if not, VisuaLeaf displays a permission hint. Once open, you get three modes:

• Tail: stream live entries as they land on the primary.
• Range: select a wall-clock or optime range to load a bounded window.
• Cursor: resume from a specific ts — useful when reproducing an incident from logs.

Namespace Typeahead Filter

The namespace filter accepts db.coll patterns. Typing populates a typeahead of every namespace currently active in the oplog window. Wildcards are supported:

• orders.* — every collection in the orders database.
• *.users — the users collection in any database.
• analytics.events_2026* — sharded / partitioned collections by prefix.

Operation Type Filter

Every oplog entry has an op field. Toggle chips in the toolbar to include or exclude each type:

Code	Operation	Description
i	Insert	A new document was written
u	Update	A document was modified (delta or full-image)
d	Delete	A document was removed
c	Command	DDL commands like create, drop, createIndexes
n	Noop	Heartbeat / periodic no-op used for consistency guarantees

Simplified View vs Raw View

The Oplog Browser can present each entry two ways:

• Simplified: one line per entry showing timestamp, namespace, op code, affected _id, and a short summary of what changed. Ideal for scanning.
• Raw: the full BSON document as MongoDB writes it — including o, o2, ui, lsid, txnNumber, and ts. Ideal for forensic work.

Toggle at any time; the tailing cursor is not interrupted.

Session Attribution

The Analyzer joins each oplog entry to the originating session where possible using lsid and txnNumber. That lets you group a burst of writes back to a single client session, and — when authenticated writes are present — to a specific user or application role. Session attribution is invaluable for answering "who ran that updateMany?".

Index-Build Event Detection

Index builds appear in the oplog as commitIndexBuild, startIndexBuild, and related commands. The Analyzer highlights them with a distinct badge and expands them into a mini-timeline showing:

• Which collection is being indexed.
• Which index spec is being built.
• Time from startIndexBuild to commitIndexBuild.
• Whether the build was foreground or background.

This is the fastest way to answer "did the rolling index build finish everywhere?" without opening currentOp on each secondary.

Replication-Lag Heat-Map

Below the oplog stream is a heat-map: rows are secondary members, columns are one-second buckets, and color intensity shows how far behind each secondary was when that oplog entry replicated. Hot bands make it obvious when replication briefly stalled — for example during a large index build or a runaway update — and which member was the slowest.

Filter Examples

Example 1: Recent inserts on the users collection

Show every insert on app.users in the last 10 minutes:

1. Set Range to last 10 min.
2. Namespace filter: app.users.
3. Operation chips: enable i, disable everything else.
4. Optionally group by session to see which app instance wrote what.

Example 2: Spot a runaway update

Runaway updateMany calls emit hundreds or thousands of u entries with the same lsid in a short window. To find one:

1. Operation chips: enable u only.
2. Sort or group by Session (the lsid column).
3. Any session with a large row-count in the last minute is a candidate.
4. Expand to Raw view to see the o2._id pattern — a wide range of unrelated IDs strongly suggests a missing filter or a bad predicate.
5. Cross-reference the timestamp with the replication-lag heat-map; a runaway update almost always shows as a hot band across all secondaries.

Pro Tips

1. Tail from a secondary: to avoid taxing the primary, point the Oplog Browser at a secondary member. The oplog is replicated identically.
2. Keep the range short: narrow time windows load faster and are easier to reason about than tailing forever.
3. Use it during migrations: confirm that a data migration is writing the expected namespaces at the expected volume.
4. Correlate with the Query Profiler: the profiler tells you which query ran; the oplog tells you what it wrote.

Related Features

• Replica Set Fleet — see health across every replica set, then drill into the oplog.
• Backup Orchestration — the oplog is the anchor for point-in-time recovery.
• Query Profiler — correlate slow queries with the writes they produce.
• Query Monitor — see currently running operations that will land in the oplog.