HiveCast Platform

Appearance

Dashboard: Logs ​

Status: target state. No log viewer UI exists. Operators tail per-runtime log files on the platform Host.

Target view ​

A queryable log explorer:

  • Time range, principal, runtime, severity, free-text filters.
  • Live tail mode + historical query mode.
  • Saved queries.
  • Export to file.
  • Per-event drill: full payload, related event chain.

Plus a separate audit log view (security-reviewer audience) with structured audit events — see Security: Audit trails.

What exists today ​

bash
# Per-runtime logs on the platform Host
tail -f /var/lib/hivecast/host-home/logs/runtimes/<runtime-id>.log

# Aggregate
tail -f /var/lib/hivecast/host-home/logs/runtimes/*.log

Lines are JSON or human-readable, depending on the writing actor. actorLog (the standard actor logger per Rule 9) writes structured records to its own bus topic plus the local file.

A subscriber on the bus can read live:

bash
matrix invoke <log-topic-actor> ... # not standardized today

This is operator-fluent but not user-friendly.

What the target needs ​

  1. Structured log schema. All actors emit { ts, runtime, mount, severity, message, ... } consistently.
  2. Storage layer. A queryable store (target: durable JetStream stream + indexed projections, or external sink like Loki).
  3. Query API. system.observability.logs.query '{"range":..., "filter":...}'.
  4. UI.
  5. Retention policy.

The system-observability package has scaffolding (per ARCHITECTURE-OBSERVABILITY-PIPELINE-V2.md). The end-to-end pipeline is not assembled.

Why this is admin-critical ​

Three reasons:

  • Incident response. When a paired Device fails, the operator needs to read its logs fast. Today this is "ssh to platform Host, tail."
  • Audit response. When a security review asks "did principal X access resource Y," the operator needs to query a structured log. Today this is grep.
  • Performance debugging. Slow runtimes show in logs first. Today: manual.

Privacy considerations for the UI ​

Logs may contain user data. The target UI must:

  • Scope visible logs by the admin's grant (cross-principal access requires admin role).
  • Redact known-sensitive fields (token values, seeds) automatically.
  • Audit the audit (every log query is itself audit-logged).

These are policy decisions the design must address before the UI ships.

Operator workarounds today ​

bash
# What did principal X do today?
grep '"principalId":"p_xxx"' /var/lib/hivecast/host-home/logs/runtimes/*.log \
  | grep "$(date +%Y-%m-%d)" | jq -r '.'

# What recently failed?
grep '"severity":"error"' /var/lib/hivecast/host-home/logs/runtimes/*.log \
  | tail -100

# Live tail with filter
tail -f /var/lib/hivecast/host-home/logs/runtimes/*.log | jq 'select(.severity=="error")'

These are scriptable but not UI.

See also ​

Source: projects/matrix-3/packages/system-platform/src/actorLog.ts. ARCHITECTURE/ARCHITECTURE-OBSERVABILITY-PIPELINE-V2.md for design.