Collecting logs means gathering a small, self-contained diagnostic bundle that lets someone reproduce and understand a problem without guessing. When you reach out for help, a handful of well-chosen outputs — the overall status, the package versions, a daemon’s recent logs, and the failing run’s structured events — almost always tell the whole story. This page walks through the exact commands to capture each one.
Collect while it’s fresh. Logs rotate daily and only about a week is kept, so gather the evidence soon after the problem happens — once a run ages out, its detailed events are gone.
A good bundle answers four questions: what version are you on, which daemon is affected, what did it log, and what was the failing run. The steps below produce exactly that. Run them on the affected host, replacing <name> with the daemon, <service> with its log directory, and <id> with the correlation id of the run you’re investigating.
Start with a snapshot of every daemon’s readiness and the installed package versions. All Binions packages should share a single version — a mismatch here is itself a useful finding.
binions-cliconsole status
apt list --installed 'binions-*'Capture the last couple of hundred lines from the affected daemon’s journal into a file you can attach. Repeat for each daemon involved.
journalctl -u binions-<name> -n 200 --no-pager > binions-<name>.logEvery daemon emits structured events as JSONL. To isolate a single run end to end, filter the event log by its correlation_id — the identifier that ties every step of one workflow together. Use jq to pull just that run:
jq 'select(.correlation_id=="<id>")' /var/log/binions/<service>/events.jsonlIf you don’t yet know the correlation id, the daemon’s journal from step 2 will reference it; copy it from there.
When a playbook step fails, the run does not retry or land in a queue — the engine emits a Fact.Playbook.Failed event and halts. To capture a failed run, find that event on the event log and then follow the whole run by its correlation id:
jq 'select(.fact=="Fact.Playbook.Failed")' /var/log/binions/<service>/events.jsonl
jq 'select(.correlation_id=="<id>")' /var/log/binions/<service>/events.jsonlIf the problem is about speed, throughput, or resource use rather than a hard error, add a /metrics snapshot from the affected daemon. Each daemon exposes Prometheus metrics on a loopback address, so capture it locally on the host:
curl -s http://127.0.0.1:91xx/metrics > binions-<name>-metrics.txtReplace 91xx with the affected daemon’s metrics port. A before/after pair, taken a short time apart, is especially helpful for spotting trends.
Redact secrets before sharing. Logs, event records, and metrics can reference credentials, connection strings, tokens, or other sensitive details. Review every file and remove anything secret before you send it — nobody helping you needs your passwords.
Once you have the files from the steps above, you have a complete bundle: a status roll-up, the package versions, one or more daemon log files, the structured events for the failing run, the Fact.Playbook.Failed event and its correlation id if a step failed, and a metrics snapshot for performance cases. Attach these to your report. The Preparing a report page explains how to wrap them in the right context so they’re actionable straight away.