Engineered in Helsinki, Finland

Telemetry for machines that cannot afford to stop.

We build telemetry software for workstation fleets, virtualized infrastructure, embedded devices, and other systems where collecting diagnostics must not become the thing causing the problem.

  • 01 Established 2011
  • 02 Erlang + C/C++
  • 03 Helsinki, Finland
fleetwatch / hel-03
SAMPLE OUTPUT
$ fwctl observe --fleet production
CONNECTED DEVICES 48,216 queues: 0 stalled
INGEST RATE 8.4M events / min
P95 LATENCY 21ms edge → store
ONE SIGNAL PLANE
01 SILICON
02 DEVICES
03 FLEETS
04 DATACENTERS
OPERATING ASSUMPTIONS

Our work sits in the inconvenient space between application software and infrastructure. Everything starts with four facts.

  1. 01Networks fail.
  2. 02Disks fill.
  3. 03Clocks disagree.
  4. 04The monitored system is more important than the monitoring system.
01 / PRODUCTS

Two products.
Explicit jobs.

FleetWatch collects telemetry from computers. ChipWatch records structured events in embedded systems. Neither attempts to “discover everything.”

P/01 FLEET TELEMETRY

FleetWatch

A lightweight telemetry agent and collection system for engineering workstations, virtual machines, render nodes, laboratory systems, and long-lived servers.

  • Bounded queues and sampling budgets
  • Local journals for disconnected operation
  • Direct collectors or store-and-forward relays
Read about FleetWatch
P/02 EMBEDDED TELEMETRY

ChipWatch

A C/C++ telemetry library for constrained firmware. It can operate without dynamic allocation, threads, filesystem access, or an IP network.

  • Bounded memory consumption
  • Compile-time event definitions
  • Application-defined transport
Read about ChipWatch
02 / ARCHITECTURE

C++ at the machine.
Erlang in the cluster.

This was not originally an architectural statement. Erlang was simply the thing that kept working. C and C++ remain where predictability and hardware access matter.

01 / PRODUCE
Edge + devices C++ / ChipWatch
binary events
02 / PROCESS
Concurrent core Erlang / OTP
normalized signals
03 / OPERATE
Fleet control FleetWatch
01

Degrade before failing.

When resources become constrained, collection becomes less detailed before the host becomes less reliable.

02

Bound everything.

Queues, buffers, retries, and logs have limits. “Effectively unlimited” is only a missing maximum size.

03

Debuggability beats cleverness.

A clever distributed system is entertaining exactly once. A boring one can be operated for ten years.

03 / HARDENING
DEFENSE IN DEPTH

Ship binaries that reveal less.

For regulated, offline, or otherwise sensitive installations, Hardened Builds may include reduced diagnostics, stripped metadata, customer-specific feature sets, signed offline updates, and additional binary hardening.

Hardened Builds and security
04 / ENGINEERING

Made by people who read the logs.

Most of our staff write software, operate infrastructure, review protocols, or answer technical support requests. The engineer answering your ticket probably wrote the code involved.

collector.erl chipwatch.cpp UTF-8   LF
01 -module(collector).
02 -behaviour(gen_server).
03
04 handle_cast({event, Signal}, State) ->
05   ok = pipeline:ingest(Signal),
06   {noreply, State};
07
08 handle_info({'DOWN', _, process, _, _}, State) ->
09   {noreply, recover(State)}.
INSIGHT-TECHNOLOGYLn 9, Col 36   Erlang
READY WHEN YOU ARE

What do you need
to make observable?

Tell us about the fleet, the constraints, and the signals that matter.

sales@insight-technology.org