Skip to main content

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

  1. Download the installer
    • In Chipper: Integrations → Log Collector → Download for Windows, or directly from https://downloads.chipper.bio/lorry/latest/chipper-collector.msi
  2. Run it — double-click the MSI and follow the prompts, or install silently:
    msiexec /i chipper-collector.msi /quiet
  3. Confirm the service is running:
    Get-Service ChipperLogCollector
    The status should read Running.

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=..."
SectionPurpose
[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 credentialsaccess_key_id and secret_access_key (S3) or the connection_string (Azure). These stay on the machine in collector.toml; Chipper never receives or stores your push credentials.
  • The sink bucket/region (or Azure container) and the source include globs.

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.

Your customer_prefix and your bucket's S3 → SQS notification must line up

Because 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

  1. Service running: Get-Service ChipperLogCollectorRunning
  2. Logs: the agent writes to C:\ProgramData\Chipper\Collector\logs\
  3. 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 include glob 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 = true and that the PC can reach downloads.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.toml has a valid source and sink.
  • No data in Chipper? Verify the bucket/credentials and that files match your include globs.
  • Other questions? Contact support.