Installing Chipper's Log Collector on Your Computer
The Chipper Log Collector is a lightweight Windows agent that tails your instrument log files and securely ships them to your cloud storage, where Chipper ingests them. Install it once on the PC connected to your instrument; it then runs as a background service and keeps itself up to date automatically.
When to use it
| Use the Log Collector if... | Use another method if... |
|---|---|
| ✅ Continuous, automatic log shipping | ❌ One-off / testing → Manual Upload |
| ✅ A Windows PC is connected to the instrument | ❌ Logs already in S3/Azure → AWS / Azure |
| ✅ You want a turnkey, auto-updating agent | ❌ You already run your own log shipper |
It's Chipper's recommended agent for the Hardware → Cloud Provider step: purpose-built, supervised, and self-updating, rather than stitching together generic sync tools.
How it works
The Collector watches the folders you configure and ships new log lines to your own cloud storage bucket; Chipper ingests from there. Your raw logs stay in your storage as a bonus (redundant backups).
System requirements
- OS: Windows 10/11 or Windows Server 2016 or later (64-bit)
- Permissions: Local administrator to install (it runs as a Windows service,
ChipperLogCollector) - Network: Outbound HTTPS to your storage destination and to
downloads.chipper.bio(for automatic updates) - Runtime: None — the installer is self-contained (no .NET or other prerequisites)
Install
- Download the installer
- In Chipper: Integrations → Log Collector → Download for Windows, or directly from
https://downloads.chipper.bio/lorry/latest/chipper-collector.msi
- In Chipper: Integrations → Log Collector → Download for Windows, or directly from
- Run it — double-click the MSI and follow the prompts, or install silently:
msiexec /i chipper-collector.msi /quiet - Confirm the service is running:
The status should read Running.
Get-Service ChipperLogCollector
Configure
The Collector reads C:\ProgramData\Chipper\Collector\collector.toml. Edit it to tell the agent which folders to watch and where to ship the logs. Changes are picked up automatically (hot-reload) — no restart needed.
A minimal example — watch one folder, ship to an S3 bucket:
[chipper]
customer_prefix = "acme-labs"
[[chipper.sources]]
name = "tecan"
include = ['C:\Instruments\Tecan\*.log']
log_source_id = "<paste the Log Source id from Chipper>"
# optional: encoding = "windows-1252"
[[chipper.sinks]]
type = "aws_s3"
bucket = "acme-instrument-logs"
region = "us-east-2"
access_key_id = "AKIA..."
secret_access_key = "..."
For Azure, use an azure_blob sink instead:
[[chipper.sinks]]
type = "azure_blob"
container = "instrument-logs"
connection_string = "BlobEndpoint=https://<account>.blob.core.windows.net/;SharedAccessSignature=sv=..."
| Section | Purpose |
|---|---|
[chipper] | customer_prefix — the key prefix all your objects are written under (you choose it) |
[[chipper.sources]] | One per folder to watch: name, include globs, log_source_id (from Chipper), optional exclude/encoding |
[[chipper.sinks]] | Where to ship: aws_s3 or azure_blob, plus credentials |
[chipper.update] | Auto-update settings (see below) |
What you provide. The Collector ships to your own bucket, so the config values are all yours to choose — Chipper does not supply them. In practice the values you fill in are:
customer_prefix— a slug you pick for the key prefix all your objects are written under (e.g.acme-labs). It is customer-chosen, not assigned by Chipper.- Storage credentials —
access_key_idandsecret_access_key(S3) or theconnection_string(Azure). These stay on the machine incollector.toml; Chipper never receives or stores your push credentials. - The sink
bucket/region(or Azurecontainer) and the sourceincludeglobs.
Provision the Log Source first. Create the Log Source in Chipper, then paste its id as each source's
log_source_id. That's what links shipped files to the right Log Source — without it, data is ingested as unprovisioned and matched only by path prefix.
customer_prefix and your bucket's S3 → SQS notification must line upBecause the bucket is yours, you own both ends of the delivery — the Collector writes objects under customer_prefix, and it is your own S3 event notification that tells Chipper an object arrived. There is no hidden Chipper-side prefix match: if you scope the notification to a prefix, that prefix must cover the customer_prefix you ship under, or Chipper is never notified and nothing ingests.
When you set up Event Driven (Instant) ingestion, set the notification's Prefix to your customer_prefix (or leave it blank to cover the whole bucket). The two values are set in two different places — keep them consistent.
For creating the storage bucket and credentials, see the AWS or Azure setup guides.
Automatic updates
The Collector periodically checks downloads.chipper.bio and upgrades itself in place — no manual reinstall. The defaults work out of the box; you can tune them:
[chipper.update]
enabled = true # set false to pin the current version
check_interval_secs = 3600 # how often to check (minimum 60)
Verify it's working
- Service running:
Get-Service ChipperLogCollector→ Running - Logs: the agent writes to
C:\ProgramData\Chipper\Collector\logs\ - Data flowing: new objects appear in your bucket, and logs show up in Chipper's dashboards
Troubleshooting
Service won't start or keeps restarting
- The most common cause is an incomplete
collector.toml. It needs at least one source and one sink — a config missing either won't start the log shipper. Add a valid[[chipper.sources]]and[[chipper.sinks]]. - Check the logs under
C:\ProgramData\Chipper\Collector\logs\.
Nothing is shipping
- Verify your
includeglob matches real files, and that the sink credentials are correct with write access to the bucket/container. - Confirm the PC has outbound HTTPS to your storage endpoint.
Updates aren't happening
- Confirm
[chipper.update] enabled = trueand that the PC can reachdownloads.chipper.bio.
Uninstall
Remove via Settings → Apps → Chipper Log Collector, or silently:
msiexec /x chipper-collector.msi /quiet
Security
All log shipping happens over HTTPS. Storage credentials are read from collector.toml on the machine.
Need help?
- Service not running? Check that
collector.tomlhas a valid source and sink. - No data in Chipper? Verify the bucket/credentials and that files match your
includeglobs. - Other questions? Contact support.