Documentation

Appearance

Dataplicity Lens ​

What is this? ​

Dataplicity Lens is an open-source terminal toolkit for Linux and macOS. It brings processes, services, logs, storage, networking, and hardware into one suite of commands you run on the machine you are inspecting.

Lens is built and published by WildFoundry, the team behind Dataplicity. It is not a Dataplicity cloud feature, subscription add-on, or replacement for the agent. Dataplicity remains the operations layer for connected devices; Lens is the on-host inspection toolkit we use while supporting those systems.

Why does it matter in Dataplicity workflows? ​

Dataplicity gets you to the device: inventory, evidence, Remote Shell, Wormhole, and fleet context. Once a shell is open, support still needs a repeatable way to read the host.

Lens fills that gap without inventing a second ops platform:

DataplicityLens
Reach the device over its outbound agent connectionInspect the host once you are on it
Fleet status, logs, monitors, and incident contextLive process, service, storage, network, and hardware views
Roles, device identity, and support historyLocal commands that run as the shell user under normal OS policy

Use both when a field unit needs a deep host reading during a support session, factory bring-up, or image validation.

How do teams use it with Dataplicity? ​

A typical IoT support path:

  1. Identify the device in Dataplicity from alert, customer, site, or class context.
  2. Confirm connectivity and collect platform evidence (logs, monitors, timeline) as usual.
  3. Open Remote Shell when an interactive host check is justified.
  4. Run lens on the device for a live overview, then open the specialist view that answers the next question (processes, services, logs, storage, networking, or hardware).
  5. Capture a one-shot or JSON report when you need something to attach to a ticket or hand to another engineer.
  6. Return to Dataplicity for the shared record: what changed, who accessed the device, and whether monitors recovered.

Bake Lens into a golden image, or install it during bring-up, when your support runbooks expect those commands on every unit. Keep install, upgrade, and command reference on the Lens site so this documentation does not fork that detail.

When should I use it? ​

  • A Remote Shell session needs a structured host reading beyond ad-hoc ps, journalctl, and df
  • Factory or staging validation should produce the same host snapshot operators use in the field
  • You want plain-text or JSON output from the device for a ticket, without leaving the Dataplicity access path
  • Local lab machines and gateways should use the same inspection toolkit as deployed Linux IoT units

Prefer Dataplicity monitors, logs, and fleet views for ongoing fleet health. Prefer Lens for the interactive host dive once you are already on a specific machine.

Example workflow ​

A gateway at a customer site reports high load. Support opens the device in Dataplicity, checks recent logs and monitors, then starts Remote Shell. On the device they run lens, move from the overview into process and service views, and confirm which workload is saturating the unit. A one-shot process report goes into the ticket; the service restart and recovery stay visible in the Dataplicity device record.

Where to go next ​

Lens has its own documentation site. Use it for installation, the full command suite, architecture, and troubleshooting:

On this site: