Observability

Register a service. It's monitored immediately.

No agent to install, no dashboard to build. A Nucleus Framework service self-registers with live health, CPU, memory, disk, threads and GC — then, when you need to dig in, records a diagnostic window and replays logs, GC pauses, thread dumps and CPU/heap on one synchronized timeline.

Zero-setup monitoring

Add the dependency, enable the monitoring profile — that's the whole setup.

📡

Self-registering fleet

Each service pushes a health snapshot over Kafka on an interval; the monitoring service aggregates every instance into one fleet registry. Nothing to wire per service — it appears the moment it boots.

📈

The metrics that matter

Live CPU load, heap used/max, non-heap, thread count, DB pool, disk and uptime per instance — with history charts so you see the trend, not just the current value.

🔴

Red when it's in trouble

An instance that goes stale or unhealthy turns red in the console, and alerts are pushed live over server-sent events — you hear it from the platform, not from a customer.

🔎

Log Explorer

Remote logs stream to a searchable Log Explorer with infinite scroll and a timeline playback mode. Filter by service, level or a single user's session id to follow one request across every service it touched.

🎚️

Toggle remote logging at runtime

Turn remote logging on or off per service from the console — no redeploy, no logback edit. A Keep across restarts toggle persists the choice so a specific instance boots with it active; a hard allowed=false lock can forbid it entirely.

🗄️

Retention, handled

Ambient logs and metrics are retained for a configurable window, then archived to MinIO object storage and purged from the database — history stays available without the database growing forever.

The Nucleus host-metrics console: a self-registered node with live CPU, memory, disk, load, network and disk-I/O cards — memory in red at 90% — above 24-hour history charts for CPU and memory.
Zero-setup host monitoring — a registered node's live CPU / memory / disk / load / network snapshot, red when it's in trouble, over 1h–7d history charts.

Session Recordings — capture and replay

When ambient monitoring isn't enough, record a window and scrub it back on one clock.

Schedule or record now

Arm a capture window ahead of time — tonight's 03:00 batch, next Tuesday's release — choosing the log level and which signals to capture. Or press Record Now on a live instance when something's happening.

Capture four signals

Inside the window, logs, GC events, thread dumps and CPU/heap samples are tagged with the recording's id as they stream in — the service's own per-instance settings are applied through the audited property gateway, never by writing to its tables.

Replay on one timeline

Scrub a single cursor across five aligned tracks and see exactly what coincided — the log line, the GC pause that interrupted it, the threads that were running, the CPU and heap at that instant. Bundles archive to MinIO for later.

One cursor, five tracks, the same clock

📜Logs
Every log line emitted in the window, at the level you chose — searchable by session id.
🧹GC pauses
Garbage-collection events and pause durations, so a latency spike lines up with the pause that caused it.
🧵Thread dumps
Periodic thread-stream snapshots — what every thread was doing at that moment.
🖥️CPU
CPU load sampled across the window, on a dedicated chart.
💾Heap
Heap used vs. max over time — watch pressure build before a pause.

Every HTTP request also carries a session id from the browser through every backend service into each log line — so "trace this user's whole session across services" is a single search, live or in a recording.

Read the monitoring reference, or watch it live.

Monitoring reference → Live demo →