Operations
Running Reamer Server
The core holds no durable state of its own. On start, order and position
state is re-seeded entirely from your broker connector's pull_state(), so a
process restart loses nothing the core was responsible for keeping.
What a restart does
Rebuilt from the venue
- Order and position stateRe-seeded through
pull_state()on start. - Fills that landed during downtimeThey arrive in the next
pull_state(), so report current state rather than a delta. - Open ordersThe core never cancels one during drain, and calls
pull_state()once more before exit.
Not carried across
- In-flight intents at the moment of a killAnything not yet at the venue is gone; anything already there is the venue's.
- The event-bus sequenceNumbering restarts at 0, even when the core reattaches a segment a previous run left behind.
The core keeps no second copy of position state
to diverge from the venue's, so drift in the usual sense is structurally absent.
pull_state() is yours, and the core adopts whatever it reports as fact.
Sequence numbers across a restart
A sequence that goes backwards means a restart. Treat a decrease as a stale cursor and
reset to the new value. The gap flag covers a different case, events lost
within one run, so for a definite restart marker have your gate or connector publish a
known event on startup and key on that.
Licence validity governs startup
Unaffected by expiry
- A process already runningIt keeps trading past
expires_at.
Blocked once the term ends
- Any restartRequires a
Validlicence, with no grace period. A drain, a redeploy, a reschedule, or an evicted pod is the same case.
Treat license.expiring and
license.expired as a restart freeze and renew ahead of one.
Pricing and purchase carries the full expiry position.
Monitoring surface
- Metrics endpoint
- 15Metrics on /metrics PrometheusText format
- Liveness
- /healthProbe endpoint
- Event stream
- ShmEventBusShared memory ring
The core exposes exactly 15 metrics, and that is the whole
set. Every one carries its own HELP and TYPE line in the
response. MONITORING.md in the kit gives the full reference and a starting
alert table with a signal, threshold, severity, and action for each one.
Two rules that are not thresholds
- Gate every automated restart on licence validity
An expired seat turns a restart into an outage, so a supervisor restarts only when
bin/reamer-license statusexits 0. - Alert when
reamer_uptime_secondsdecreases That is a restart nothing in your deploy pipeline ordered.
The live event stream
ShmEventBus is a shared-memory broadcast ring the core writes to, which
any number of readers in any number of processes attach to independently. A reader's
since() call returns every retained event newer than the sequence it names.
The ring holds a fixed event count set by event_buffer_capacity, so a reader
that falls further behind sees gap: true.
Storage is your decision. Point whatever you already run at the stream, and the product's job stops at supplying it.
Two commands
| Command | What it does |
|---|---|
| bin/reamer-diag-bundle | Writes one JSON file carrying a
/health and /metrics snapshot plus every retained event, with
the monitoring auth token redacted. Attach it to a support email. |
| bin/reamer-config-check | Validates an edited config before you restart on it, because a path that does not resolve starts the core on defaults. Config changes take effect on restart rather than on reload. |
DEPLOYMENT.md, MONITORING.md,
CONFIG.md, and CAPACITY_AND_LIMITS.md ship in the server kit
and carry the full operational reference, including the capacity envelope to check a
proposed deployment against.