GoodBoi Agent

Context#

Museum installations and games share an awkward problem: they run unattended for hours, sometimes days. A Unity application drives a touchwall through an entire exhibition day with no one watching it. If it crashes, freezes, or silently degrades, nobody notices until a visitor walks up to a dead screen.

GoodBoi Agent started as an answer to that problem. It is a monitoring and watchdog tool that keeps a target application alive, watches the machine it runs on, and turns raw system activity into readable reports.

The name comes from exactly what it does — it sits quietly next to the real application, watches it, and barks when something goes wrong. A good watchdog.

The Problem#

Three failure modes show up again and again in long-running installations:

The application crashes and stays down. A visitor-facing screen goes blank and remains blank until someone physically checks on it.

The machine degrades silently. Memory creeps up, the CPU saturates, a thermal issue throttles the GPU — the app is technically running but the experience is broken.

There is no record of what happened. When something does go wrong, there is no log of system state leading up to it, so the same problem repeats.

A person could babysit the machine, but that does not scale across exhibitions and installations. The monitoring has to be automatic.

Approach#

GoodBoi is built around a deliberate split: a lightweight agent in the field and a service at the center, each written in the language that fits its job.

The Go agent — in the field#

The agent runs on the target machine, right next to the application it watches. It is written in Go for the reasons Go is good at this kind of work: it compiles to a small, dependency-free binary that can be dropped onto an installation PC and left running. It does two things — it collects system metrics through native OS access, and it supervises the target process, restarting it if it crashes or exits unexpectedly.

For an unattended installation, that restart is the difference between a five-second recovery and a dead screen that lasts until closing time.

The Java service — at the center#

The Java service is the central side. It also collects metrics and runs watchdog logic, using the OSHI library for hardware and operating system information — CPU load, memory, GPU activity. But its real role is aggregation and reporting: it turns the continuous stream of raw samples into readable reports at three resolutions — hourly, daily, and weekly — and persists them as files on disk.

It also exposes a local REST API, which is how the dashboard gets its data.

The React dashboard#

The interface is a React and TypeScript dashboard. It reads from the Java service over the local REST API and presents live metrics and historical reports in a form a human can actually scan — the same data that lives in the report files, surfaced on a screen.

Tech Stack#

GoodBoi spans two backend languages by design. The field agent is written in Go, compiled to a single portable binary with native access to system metrics and process control. The central service is written in Java, using the OSHI library for hardware and OS metrics, and handles aggregation, reporting, and the REST API. The dashboard is built with React and TypeScript, consuming the Java service's local endpoints. Reports are persisted as files on disk.

The tool currently runs on Windows, matching the environment of the installations and machines it was built to watch.

Visuals#

// Representative — watchdog loop in the field agent
func (w *Watchdog) Supervise(ctx context.Context) {
  ticker := time.NewTicker(w.interval)
  defer ticker.Stop()

  for {
      select {
      case <-ctx.Done():
          return
      case <-ticker.C:
          if !w.target.IsAlive() {
              log.Warn("target down — restarting")
              if err := w.target.Restart(); err != nil {
                  log.Error("restart failed", "err", err)
                  continue
              }
              w.reporter.RecordRestart(time.Now())
          }
      }
  }
}

// Representative — metric sampling with OSHI
SystemInfo systemInfo = new SystemInfo();
HardwareAbstractionLayer hardware = systemInfo.getHardware();

CentralProcessor processor = hardware.getProcessor();
GlobalMemory memory = hardware.getMemory();

double cpuLoad = processor.getSystemCpuLoad(1000) * 100;
long usedMemory = memory.getTotal() - memory.getAvailable();
double memoryUsage = (double) usedMemory / memory.getTotal() * 100;

MetricSnapshot snapshot = new MetricSnapshot(
  Instant.now(), cpuLoad, memoryUsage
);
reportService.aggregate(snapshot);

Outcome#

GoodBoi is in active development. It already runs alongside real installations and games, supervising target applications and collecting metrics, and it is being extended as new needs come up.

The tool fills a gap that only becomes obvious once an installation has failed quietly in front of visitors. It is not glamorous software — it is infrastructure. But for work that has to run unattended and reliably, infrastructure is exactly what is missing most often.