Network telemetry · in development
Canary.
Understand the traffic before deciding what is unusual.
A self-hosted telemetry platform for private networks. I built the collection, query, and collector-health foundation needed to develop detection against real evidence.
Collect
Flow metadata
Bounded buffers
Cross-platform capture
Retain & inspect
Queryable history
Collector heartbeats
Agent-silence detection
Detect & explain
Ratified baselines
Traffic anomalies
AI-assisted triage
Architecture illustration. Private fleet topology and live telemetry stay inside the system.
- My role
- Creator & engineer
- Focus
- Traffic metadata · fleet health
- Status
- In development
The problem
A quiet network and a missing observer are different things.
A private mesh network has no single traffic chokepoint. To understand behavior across machines, collection must happen at the nodes and preserve enough context to investigate what was seen.
The collector also becomes part of the evidence. If it stops reporting, the system must make that silence visible rather than treating missing observations as normal traffic. Canary starts with those foundations before adding higher-level detection.
The work
The implemented foundation.
Cross-platform collection
Collectors capture flow metadata on Linux, macOS, and Windows and send bounded aggregates to a central hub. The design accommodates the capture mechanisms available on each platform.
Queryable traffic history
Compacted Parquet and DuckDB support investigations without a separate database-ingestion pipeline. Retention and dropped-data reporting make the limits of the evidence visible.
Health of the collecting fleet
Build versions, heartbeats, and agent-silence detection help distinguish an active collector from one that has stopped reporting. Silence is a finding; its cause still needs investigation.
How it fits together
Collect, retain, and inspect.
- 01
Observe at the node
Capture traffic metadata and aggregate within bounded buffers. Record what was dropped rather than silently treating an incomplete window as complete.
- 02
Retain at the hub
Receive batches, compact history, and retain it for a defined window. Replay handling and evidence timestamps matter as much as the happy-path ingest.
- 03
Query the evidence
Inspect traffic and the collectors themselves. Use the retained corpus as the basis for the next stage of baseline proposal and detection.
This is an architecture and development-status view. It contains no private fleet topology or live traffic data.
Engineering decisions
Build trust in the evidence first.
Bound collection and storage
An observer should not exhaust the machine it protects. Bounded buffers, spooling limits, compaction, and retention are explicit parts of the collection design.
Make gaps observable
A missing heartbeat, a dropped window, and an empty result mean different things. Collector health and completeness signals stay alongside the traffic history.
Ratify baselines from real traffic
The next step is to propose and review observed traffic baselines. Incomplete history must remain an explicit confidence limit rather than making novel traffic disappear.
Detect first, explain second
The planned detection layer uses deterministic findings before asking an AI layer to explain them in context. Broad traffic detection and AI triage are not implemented capabilities today.
- Go
- Linux / macOS / Windows
- Parquet + ZSTD
- DuckDB
- Flow metadata
- Fleet liveness
What this demonstrates
Reliable detection starts with reliable observation.
Canary demonstrates cross-platform collection, bounded data pipelines, operational visibility, and the discipline to keep implemented capabilities separate from a product roadmap.