The number that caught my eye was the transmit retry rate on my office access point. UniFi could tell me which radio was retrying frames. My switch could tell me whether errors were climbing on its uplink. I even had probes running out to the internet. What I couldn’t do from any one of those screens was answer the question I’d actually been asked: when the connection felt slow, which of those things happened at the same time?
I started with Grafana because I wanted to monitor my home network without buying a subscription to collect data my equipment already gives me. In earlier posts I built the SNMP pipeline and started following traffic conversations. Those dashboards earned their keep. The part I was still doing by hand was the investigation. I’d line up five windows, figure something out, close them, and leave the best part of the work in terminal scrollback.
Convergence grew out of wanting to keep that work. I built it into my NetClaw lab first, then packaged the collection side so somebody else could run it without owning my switches, using my firewall, or paying for a model. The video shows the lab I use today. Here’s how the pieces got there, and the much smaller setup I’d start with at home.
What runs behind the browser
I run NetClaw on a separate Linux VM and open its HUD from my workstation. Closing the browser doesn’t stop the collectors. UniFi supplies client and radio measurements. SNMP supplies switch interface state, byte counters and errors. A blackbox exporter probes destinations I’ve chosen, so I have a history of what was reachable from my lab. Prometheus and VictoriaMetrics handle those time series. For the office AP, that means I can go back to the same interval and compare radio retries, wired errors and probe results long after all three graphs have settled down.
Security gave me a reason to retain a different sort of evidence. My pfSense firewall records decisions about connections. An exporter summarises conversations into flow records with endpoints and byte counts. Suricata examines packets delivered to its sensor and records a rule match. Each answers a question the others can’t. A big transfer can show up in flows without triggering a security rule. A Suricata match can tell me what the sensor saw while leaving the firewall’s decision an open question.
In my lab, Loki and VictoriaLogs hold logs and retained observations, including flow records in VictoriaLogs. The Convergence API makes that evidence available to the HUD and to investigation tools. PostgreSQL holds something I want to keep separately: the case. It records what fired, which interval we examined, what we found and what still needs checking. That’s how I can take a WAN complaint to my provider with the history in front of me, even if every probe is green by the time I call.
Why put NetClaw in the middle of an investigation?
I already had a good example from investigating a missing storage replica. John Capobianco’s NetClaw connects a model to tools an engineer can use. In my environment that includes Nautobot, where I keep inventory. A model reading a log line can speculate about an address. With the right read access, NetClaw can look up what I’ve actually documented about the device, check the relevant telemetry and bring the results back to the case. The probes and collectors keep working regardless of which model I choose or whether I use one that day.
There are two ways into that loop. I can open a case and ask a question myself. I can also opt in to investigation for selected alert rules. A receiver on the NetClaw host accepts the alert, and in my lab an alert agent hands the case to a specialist investigator with read-only access. I start with a harmless test alert before admitting a real rule. The investigator records its sources and time window, and it can flag missing evidence for me. If the conclusion skips a step, I can select Need more and say exactly what I want checked. Finished cases can be found again in NetClaw’s knowledge base. That gives the next investigation somewhere better to start than my memory.
Build the smallest version first
If you already run NetClaw, I’d start in its chat. The upstream convergence-setup skill can install the trial for you. Here’s what I’d ask it:
Use the convergence-setup skill to set up a Docker trial on my Linux host. Start with the synthetic flow demo and local-only access. Show me the plan before installing anything. After I approve it, verify that you can query the demo flows and connect my NetClaw HUD to the demo site.
NetClaw checks what’s already running and tells you which host and ports it will use, what it will install, and how to undo it. With shell access it can carry out the plan after you approve it. Without shell access it gives you the commands to run yourself. The result I’d look for is a flow the API can retrieve and the HUD can display under Synthetic demonstration.
To run the trial by hand
The standalone project is convergence-platform. On one Linux machine, the Docker trial brings up PostgreSQL, the API, Prometheus, Alertmanager, the blackbox exporter and Grafana. Enabling the flow demo adds a collector, shipper and archive. This is enough to test the interesting part: can a known conversation go in at one end and come back out of an authenticated evidence query?
You’ll need Git, Python 3.10 or later, a local Docker Engine and the Compose plugin v2.20 or later. I suggest budgeting 4 CPU cores, 8 GiB of RAM and 20 GiB of free disk to start. Use unused service ports and a fresh bundle directory. Run the following in one Linux shell; the bundle holds the private configuration outside the checkout.
git clone https://github.com/byrn-baker/convergence-platform.git
cd convergence-platform
python3 setup/setup.py preflight
bundle="$HOME/.local/share/convergence/flow-demo"
python3 setup/setup.py prepare --output "$bundle" \
--site demo --project convergence-demo --grafana --flows demo --flow-port 2055
python3 setup/setup.py run --bundle "$bundle" --action validate
python3 setup/setup.py run --bundle "$bundle" --action startGive the first scrapes about 30 seconds, then run the checks from that same shell.
python3 setup/verify.py --bundle "$bundle"
python3 setup/flows.py demo --bundle "$bundle"
python3 setup/flows.py check --bundle "$bundle"The first check verifies the installation. The next command generates a small synthetic capture and sends it through the real flow pipeline. The final check queries what made it into storage. You can get that result without NetClaw, a model subscription or access to a router. Grafana’s installation-health dashboard is available locally on port 3300 by default. To see ranked conversations in an existing NetClaw HUD, connect it using the private bundle’s hud.env, select the demo site and open Traffic. The Synthetic demonstration label tells you exactly whose traffic you’re looking at. To stop the trial while keeping its data, run python3 setup/setup.py run --bundle "$bundle" --action stop.
Where I’d put the first real collector
Once the demo returns a flow, this is what I’d ask NetClaw next.
The synthetic flow demo works. Use convergence-setup to help me monitor my home network. Ask what traffic I want to see and what equipment I have. Recommend one source to start with, such as a Linux interface or a router that exports flows. Tell me which traffic it can see and what it will miss.
Plan a separate site and bundle for live data. Show me the changes and how to undo them, then wait for my approval. Once collection is running, ask me to make a small transfer across that interface. Find its endpoints and time window in the retained flows and show me where to see it in the HUD.
I’d pick one question before picking an interface. To learn who a single Linux machine talks to, I’d start a fresh host-mode bundle, select that machine’s interface and generate a transfer I recognize. For traffic leaving the house, I’d look at what my router can export. Conversations between two machines on the same switch may never reach that router. To inspect packets with Suricata you need a sensor on a path that actually receives them. That placement decision determines what I can claim later. The optional Proxmox VM Security view has the same constraint: its findings describe metadata sampled outside the guests, and the project offers a labelled synthetic demo to explore it.
For a persistent deployment the project recommends K3s, with Helm for the release or Argo CD if you manage deployments from Git. There’s a Proxmox path if you also need to build the cluster. NetClaw now has an upstream contribution for this part of the job: the Convergence setup skill and VM Security view were merged in PR #335. The skill discovers what’s already running, asks what site and sources you want, then shows the planned changes and rollback before you approve them. Credentials stay in private files. The important step comes after startup, when it checks that the layers can actually return evidence.
One alert, two different jobs for JEV and Canvas
One of my saved Suricata cases involved an internal source and destination. The addresses looked familiar from Kubernetes, but they weren’t on the ordinary LAN subnets I use. My first guess was traffic between workloads. That guess depended on two things I hadn’t established: who owned those addresses at the time, and where in the encapsulated path the sensor had seen the traffic.
This is where I use JEV, NetClaw’s “science officer.” I can send it a restricted summary of the saved alert for a second opinion. It assesses how much the summary supports and suggests a next read-only check. In this case it asked for the complete local alert and its capture context. That was a good answer precisely because JEV hadn’t received the packet capture or the endpoints’ histories. It gave me a specific piece of evidence to go get.
Canvas is where I pursue that question. It’s an investigation workspace inside NetClaw. I can bring the case reference and structured triage context into a card, add JEV’s advisory, then ask NetClaw to gather corroborating evidence. I can keep the timeline and working hypothesis on the main card and branch a narrower question, such as which workload held an address, onto another. If I have a diagram showing where the sensor sits, I can attach it there. That keeps the follow-up connected to the observation that prompted it.
In this case the returned evidence narrowed what I could honestly say. The sensor had observed plaintext HTTP on a decoded segment inside an encapsulated capture path. That established something about the segment it saw. It left open whether another leg was encrypted and what the firewall enforced. A useful next check would be to map the endpoints to workloads for that interval. Kubernetes traffic was still a working explanation when I put the case down. I’d much rather reopen it there than inherit a confident “all clear” and have to reverse-engineer why somebody wrote it.
Investigate your first Suricata alert
Once your sensor has produced a real alert, open its saved case in the Security panel. Request a JEV advisory on the restricted summary, then bring the case reference and advisory into a new Canvas investigation. Paste this into the card:
Investigate the Suricata case attached to this Canvas card. Start with the rule that matched, the timestamp and time zone, the endpoints, and where the sensor saw the traffic. Summarize JEV’s assessment and its suggested read-only check. Use the local alert and available flow records or firewall logs to test that suggestion in the same time window.
Write a short timeline on this card. Cite the source and time window for each observation. What explanation fits the evidence? What is still uncertain because of sensor coverage or missing records? Give me one read-only check that would best distinguish between the plausible explanations.
The first thing I’d want from a new install is one record I can explain from end to end. Where was it observed? What else could that collector see? Could I find the same record tomorrow? Once I can answer those questions, giving NetClaw access to it is worth doing. The next time someone tells me the internet was slow, I can start with “about what time?” and have somewhere to go with the answer.