For Ops: Monitoring SpiceGrinder

For Ops: monitoring SpiceGrinder with Splunk (or whatever you’re already using)

If your team runs SpiceGrinder across more than a couple of workstations — or in CI, or as a service — you’ve probably already asked the questions Ops always asks about a new tool: who’s running it, how much, how heavy is the load, and how do we know? You don’t have to go check with the team, SpiceGrinder answers it with structured logs you can point your existing tooling at.

It’s opt-in and local-only. Nothing here phones home — every log line is written to disk on the machine that produced it, and every stream defaults to off. (We do strongly recommend enabling audit and performance logging for our Pro and Enterprise customers, though.) You turn on what you want in ~/.spicegrinder/instrumentation.properties:

# Strongly recommended for customer-side license attestation / peak concurrency
audit.enabled=false

# Throughput + complexity (customer capacity planning)
performance.enabled=false

# Debug-only structural detail — turn on per incident, then off
diagnostic.enabled=false

# log.directory=/var/log/spicegrinder

Three streams, three different jobs: audit for “who ran what, when, and how often” (attestation, peak concurrency), performance for capacity planning and monitoring, diagnostic for the kind of structural detail you only want on while you’re actively chasing an incident. Point log.directory at wherever your log shipper already watches — such as /var/log/spicegrinder on a server — and every run writes real, structured NDJSON right where you’re looking for it.

Here’s an actual audit record from a real run:

{"@timestamp":"2026-08-31T11:45:31.989856Z","log.level":"info","event.type":"audit",
"service.name":"spicegrinder","instance.kind":"runtime","event.action":"run.summary",
"spicegrinder.model.name":"SixStats","spicegrinder.seed":"6360338997739602050",
"spicegrinder.observation_count":5,"spicegrinder.run.duration_ms":2,
"spicegrinder.complexity_score":401}

And a performance record from a heavier run:

{"@timestamp":"2026-08-31T12:51:04.368836Z","log.level":"info","event.type":"performance",
"service.name":"spicegrinder","instance.kind":"runtime","event.action":"run.performance",
"spicegrinder.model.name":"SixStats","spicegrinder.observation_count":50000,
"spicegrinder.run.duration_ms":246,"spicegrinder.observations_per_sec":203252.03}

One line per event, one JSON object per line — the format every log aggregator already expects, with field names (@timestamp, log.level, event.type, service.name) that should feel immediately familiar if you’ve worked with structured logging before. Point a Splunk universal forwarder, Filebeat, or any file-tailing shipper at the .ndjson files and you’re querying real usage data, not parsing custom output.

instance.kind gives you filtering criteria to build a dashboard or report around. Every event is tagged seat (a human running it interactively — GUI or terminal) or runtime (unattended — CI, a service, a scheduled job). That split is what many teams are looking for: how much usage is a developer poking at something locally, versus how much is production load. No need to guess from hostnames or timestamps, just pull the actual data the application gives you for free.

Logging is a core feature of SpiceGrinder, not limited to Pro or Enterprise customers only. It’s your data: your logs, entirely within your infrastructure, in a format your existing tools already read.